Home
About Us
Site Map
Products
Services
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Links
Contact Us
BLOG

 

 

Poor Project Management - The Leading Category of Bad Projects

"By now you've gotten the idea that project management of a significant project is not for an amateur. If done right, project management is a demanding discipline that can be complex and time consuming. Because project management can be so complex, there are many areas that can go awry. The table below lists the key project management questions that you need to ask and answer to do your root cause analysis."
 
Project Management Area Question Why We're Asking
Change management Were changes to the project managed according to a formal written procedure? This area is the number one reason in the number one category for projects going wrong. Without a formal, rigorous, change management procedure, projects will experience scope creep in small and large increments.
Has a contingency or change management budget been established? Without this budget, change investigation is done as a new task, is done without tracking time, or is hidden in other tasks. Each of these situations causes management problems when the budget erodes and there is no easy way to find out where the time was truly spent.
Was there evidence that the change proecess is useful and effective? Of course, having a process is only the first step. Exercising gthe process in an effective manner demonstrates the value of the process.
Did the team members understand the change management procedure? Each individual contributor of the team has the power to make or break the change management process. If they understand and enforce it, scope creep is halted and changes can be made based upon their business value.
Project Charter Was a formal project charter present? We spent a great deal of effort explaining the value of the project charter. If one does not exist, there is no use trying to audit a project for adherence to a nonexistent entity!
Was the project charter signed by the project executive sponsor? You need to ensure the project executive sponsor approved the project's reason for being and the plan to complete the project.
Scope Management Were the in-scope statements well defined and quantified? Within the project charter, the logical scope, deliverable scope, financial scope, organizational scope, and schedule should be clearly defined and approved to establish the project baseline.
Was out-of-scope defined within the context of the in-scope statements? It is important to be as specific as possible to avoid confusion and misunderstanding. Some projects are best defined by what they will not do.
Estimating assumptions Ws the project estimated according to a written formal procedure? The entire project return on investment's expense side was based upon the project estimate and the management team's ability to manage to that estimate. An ad hoc, wild guesstimate produces no logical return and no way to track real progress.
Was there evidence of a project baseline showing effort and duration? If the team utilized an estimating method, it should have recorded the estimated effort and duration in the project management tool of choice so that the management team can manage to the inevitable variances
Did the project baseline chnage since the project inception? If the answer is no, you are either the luckiest person on the planet or the recipient of a lie. Since the project got out of control, it was most likely the latter.
If the baseline changed, is there evidence of signed change requests authorizing the changes? obviously, the project scope and estimates changed. If you do not see those changes refloected in the project plan, you know the plan was not being used. If you find the changes without the supporting authorized change requests, you know the change process was not being used. Either case presents a huge but common problem for runaway projects.
Requirements management Were the requirements formally documented? The requirements contain the scope of your project. Each requirement should be documented and approved before subsequent work is done on it. Undocumented requirements are the conduit for scope creep.
Were the requirements tracked within a traceability matrix? This technique is not necessarily required in all methodologies. It does provide an excellent way for each project team member to track their work back to a project requirement. This is especially useful during the testing phase.
Were baseline requirements separate from subsequently added requirements For clarity and ease in documenting an audit trail, the original requirements should be documented separately, as should each version of the project requirements along with the supporting authorized change requets.
Were approved change requests in place to support added requirements? You should always be able to see when a requirement was added, changed, or removed from the scope of the project via approved change requests. As previously stated, the lack of approved change requests means change was not controlled and your project got away because of a lack of scope management - the infamous scope creep.