|
|
The Critical Path |
|
|
|
||
| February 2004 |
||
|
|
|
|
When the Process Becomes the Project −Avoiding Unnecessary Process Documentation Work
As President of Prism Communications LLC, Chris provides project management, business analysis and documentation services for his clients. He is also Co-Director of Publications for the PMI Westchester chapter and can be reached at cgaffney@prism-comm.com. Please note that the views expressed in this article are the author’s and do not necessarily reflect those of the PMI Westchester chapter. Process is important. Whether you're writing a user manual, developing a software application or building a highway bridge, following a standard process is necessary to ensure that quality is consistent from one project to another. Standards and processes help ensure that the user manual has the same look and feel as other user manuals, the software meets the agreed-upon requirements, and the bridge will remain standing for a long time through adverse weather conditions. While the value of most processes is apparent, sometimes a process can develop a life of its own. In some organizations projects are forced to adhere to a process methodology without understanding why the methodology is there in the first place. This is especially true in larger organizations. The result is that significant overhead work is required to complete process documentation that does not add value to the project or to the organization. Process Methodologies - the Flavor of the Month Depending on the industry, there are many different process and project methodologies used to maintain standards and consistency. In software development, some common methodologies and tools include:
|
All of these methodologies and tools have value. However, there is a danger to becoming so wed to them that they become more important than the projects they are supposed to help manage. This can occur because the groups that are first charged with implementing the methodology often become the watchdog that ensures the standards are followed. Over time they can forget why the process was implemented in the first place in their honest efforts to make sure standards are met. For example, at one recent client all development projects were required to adhere to CMM standards. The original intent of implementing CMM was a good one. For many years there were no standards and each project was developed as if it was the first one at the company. The primary goal of implementing CMM was to eliminate “reinventing the wheel” each time a new project was developed. While the standards group had developed a comprehensive list of process documentation, there were no guidelines for when to use them based on the size, complexity or development cost of the project. The result was that many documents were simply overkill for smaller development projects, but were still required. Project managers were frustrated because instead of managing development efforts and schedules, they were spending most of their time creating and recreating documents over and over again with the same information. A significant amount of time and cost was being spent to adhere to standards that added little value to the project, and the only people who didn't seem to recognize this were the standards group that required these documents.
(When the Process Becomes the Project continues on the next page) |
|
| Inside this Month’s Issue
When the Process Becomes the Project The Two Faces of Risk Management |
||
February 2004 |
PMI Westchester Critical Path Newsletter |
Page 1 |
|
|
||