| When the Process Becomes the Project continued
|
|
|
The risk is that eventually the pendulum will swing back and the whole CMM standards initiative will be thrown out because "it didn't work." Anarchy will again ensue for a time and the previous lessons will be forgotten. Eventually a new standard will be discovered and implemented, that flavor will be mandated and the cycle will begin all over again. Avoiding the Over-Documentation Trap It pays to have a healthy skepticism when it comes to process documentation. This can be tricky, especially when the organization is in the early stages of process implementation and has found "religion" about it. In these situations it can be a career-ending decision to question the value and need of all that process documentation. In this case it's important to pick your battles wisely. Raise the issue and then do the job as required, but document your concerns and make sure you can point back to them later should your project go over time or budget due to these unneeded administrative tasks. However, if you are still concerned about the extra time and effort necessary to develop process documentation and its impact on your project, keep the following points in mind when you address your concerns with management: 1. Remember what the real project is It's important to remember what the real project is. For software development, you may be using RUP and UML to document your requirements. However, care must be taken not to spend so much time refining the UML that the budget is used up before you can build the software. Keep the end goal in mind − it's the final user manual, working software application or completed bridge − not necessarily the process documentation created to get there. 2. Establish guidelines for what process documentation has to be developed A one-size-fits-all approach does not work. Guidelines need to be established to determine the appropriate level and amount of process documentation required for a project. These guidelines should be based on factors such as the overall project cost, complexity and the risk / reward to the organization. For example, if the project budget is $10,000 and the project will only last two months, is it cost effective to create a detailed quality management plan and get it approved by all five division Vice Presidents, even if this is a requirement for all projects? |
3. Quantify the cost of the documentation Like any work effort, writing documentation takes time. The cost of this development time can be calculated by multiplying the estimated number of hours by the corporate overhead rate for the person(s) creating the documentation. Remember to add the cost of reviewing and editing the document as well. Calculating this amount and comparing it to the project budget illustrates the true financial impact, and can be an eye-opener for managers who are unaware of how costly the extra documentation can be. 4. Eliminate redundancy and busywork One key complaint about process documentation is that the documents are often redundant and contain nearly identical information. Company procedures may require a business case, building permit, user requirements, functional requirements, system requirements, and so on before a development project is approved. These documents may be over 50% identical, with changes to one requiring updates to the others also. For major system implementations, this amount of documentation may be necessary, particularly in a conservative, risk adverse environment. However, if the development effort is small, creating all these documents may take too much time and money for the value they provide. Again, quantify the cost of the work and rework so you can present it to management and point out that your project budget would be better spent elsewhere. 5. Remember the Law of Diminishing Returns It's important to have a practical and realistic expectation as to what the process documentation can accomplish. In most cases, documentation doesn't need to be perfect. There should be an acceptable and agreed upon level of quality so the documentation can be completed and the project can move forward. |
|
|
February 2004 |
PMI Westchester Critical Path Newsletter |
Page 2 |
|
|
||