I've worked for a number of organizations – both public and private and both commercial and government – and the variances in Project Management Processes has always fascinated me. One organization used something very close to the eXtreme Programming methods, another used a strict Capability Maturity Model (CMM), a third used the “mushroom model” – or “Keep the developers in the dark and feed them sh..”, and finally one used a pure firefighting model. At that final one, the division head kept a priority list with three rankings – Low, High, Very High – but I digress.
These Checklists serve as a solid foundation, but don't let them lull you into a false sense of security. No process or checklist can make a project successful. Let me repeat that, NO process or checklist can make your project successful. A process can deter specific failures/errors, but there are always new ones lurking out there waiting to bite you.
If you don't have a process in place at all, these Checklists will help you get started. They focus on simple aspects such as having the proper resources in place, tracking defects/issues, ensuring quality, clearly defining milestones and deliverables, addressing risks, and managing change. These areas are the most problematic and potentially damaging parts of any project. There is no point in reinventing the wheel, get these documents, customize them for your organization, evaluate their usefulness, and then make a decision. That's the nice thing about a process. Once you have a process established, there can be changes to it, you simply must evaluate the value of the change and figure out how to do it.
As I've told quite a few developers, team leaders, and clients: When there are mistakes made, I want them to be completely new and extraordinary.
Your processes should be the same way. Your base process should cover the majority of the situations your team will face. They WILL NOT cover all of them, but those serve as perfect opportunities for growth.