Both SW-CMM and CMMI provide excellent guidelines for planning and managing projects. It s too bad that lots of people involved in process improvement work fail to see the relevance of these guidelines to their work. But even if we just focus on software-intensive systems, CMMI does not or cannot address many of the realities of project planning and management. CMMI works as designed because it was never intended to be used by organizations as a convenient substitute for thinking.

Some of the mushy, sticky, gray areas of real project management for which you won t find an easy solution in CMMI include:

Inability to establish a consensus understanding of the word project (see Establish a Common Language in this chapter). Determining the origination of a project and figuring out which comes first, requirements or planning. If you don t have requirements, you technically don t have a reason to plan, but don t you need to plan requirements activities?

Implementing processes and procedures using tools. It s easy to say, develop a WBS for the project, but almost all of us will be required to implement that task using some sort of tool. Whether the tool is as simple as writing the work breakdown structure (WBS) tasks on a whiteboard or as complex as using an enterprisewide project management system, there will be dependencies and constraints inherent in the use of the tool that will make the actions more difficult than the words.

Prioritizing work issues. In a perfect world...