Avoiding Root Causes of Troubled Projects

Prevention measures should be considered to reduce or contain the root causes of troubled projects, thereby improving project quality, profitability, and customer satisfaction. This article is not intended to be a complete list of problem areas, nor an exhaustive offering of prevention measures. Experience and professional judgement should be applied to each circumstance when determining the appropriate “measures of prevention” for any proposal or project. I’ve divided my list of root causes into two areas: Root Causes from Solution Design and Root Causes from Solution Delivery. I hope will you find my recommended prevention measures useful.

Root Causes from Solution Design

Customer Expectations

Failure to set and manage customer expectations can lead to false beliefs and disputes over scope or responsibilities. Prevention Measures:

  • Be careful when setting customer expectations. Be conservative in describing the project and try to “under promise and over deliver” rather than “over promise and under deliver.”
  • Caution the customer about the challenges of the project.
  • Make sure the customer fully understands and agrees with proposed solutions.
  • Encourage the customer to budget for changes upfront, so they will have the flexibility to address changing requirements during the project without seeking additional funding.
  • At the beginning of a project, document with the customer their expectations and priorities. Once the expectations and priorities are established, the project team should list actions which will be taken to meet those expectations.
  • Make sure the customer fully understands the importance of their involvement and responsibilities in the project. The customer’s full involvement and commitment are essential to the success of a project. The customer should think of themselves as part of a team rather than spectators.

Inaccurate Estimates

Many projects have been financially doomed from the beginning because of underestimating the effort required to complete a project. Prevention Measures:

  • Utilize experienced project team members to develop or validate the estimates during proposal preparation.
  • Use the most appropriate estimating tools available.
  • Adjust for the learning curve of new development tools and methodologies, systems management efforts, untested HW and SW components, adequate testing and correction periods, and unknown risks.
  • Review Intellectual Capital for similar completed contracts for actual costs.
  • Include subject matter experts and PMs for a bottom-up, or task level, estimate of hours.

Failure to Plan for Risk Containment

All projects have risks, and they should be understood and planned for prior to beginning a project.  Prevention Measures:

  • Utilize technical, peer, and assurance reviews to identify risks and develop containment actions and strategies.
  • Create a Risk Management Plan during the proposal preparation stage. Review the plan with Quality Assurance (QA) and management to ensure that it covers the major risks and has appropriate plans to contain them.
  • Maintain/update the Risk Management Plan throughout the life of the project.

Insufficient Test Plans

All too often, the time allocated for testing is insufficient and/or doesn’t allow for time to do follow-up testing when the first set of testing points out problems that must be addressed.  Prevention Measures:

  • Include a pilot or testing phase in the approved solution and include a provision for subsequent pilot/test period as appropriate.
  • Include the pilot/testing phase in the project plan and share with the customer what the schedule expectations are.
  • If needed, re-baseline the schedule with the customer.
  • A test manager or test expert should be involved during the engagement to validate the viability of the proposed testing plans and schedules.

Inaccurate Staffing Plans

In many situations the skills thought necessary on a project do not match the skills required to deliver the project. For example, the staffing plan may call for DB2 programmers when it’s C++ programmers that are needed. Also, you might have the people with the right skills, but they are not available when you need them because they are working on other projects. Prevention Measures:

  • Use subject matter experts and PMs to validate estimates and scope.
  • Consider using subcontractors (especially when a specialized skill is to be performed) and check their references. Make it clear that the subcontractors report to the assigned PM.

Root Causes from Solution Delivery

Ineffective Startup

It’s important that the customer be entirely aware of the scope of the project, the project plan, and how the customer personnel will be used as a part of the overall project. Prevention Measures:

  • Hold a customer kickoff meeting to define scope (not to develop WBS), identify the purpose of the project and expected output, identify potential risks and preliminary plans, and present immediate plans for the project. Also, describe what each project team member will be doing in the first several days of the project or until you meet again.
  • Include the customer in the planning session(s) to assist with defining the WBS. Make the project planning session different than the project kickoff meeting.
  • The customer’s staff should also clearly understand their responsibilities

Lack of Management Oversight/Support

Line management in some cases does not have a good mechanism to track its respective portfolio of projects and therefore, projects often become troubled before they come to the attention of management. Management assistance sometimes comes too late. Prevention Measures:

  • Line management should ensure that a mechanism is in place to closely track the status of all significant projects.
  • Close monitoring of troubled projects by line management should be instituted.
  • PMs should keep line management briefed on a frequent basis about the status of their projects.

Ineffective Communications

It is critical that PMs have an effective communications plan with the customer, the project team and management. Troubled projects are often the result of simply having no regular status reporting, customer meetings, project team meetings, etc. Prevention Measures:

  • Develop a communications/escalation plan at the beginning of the project.
  • Ensure that regular communications and status reporting occur on a regular basis.
  • Keep the customer advised of the smallest delays or improvements in the schedule on a weekly basis.

Failure to Implement/Exercise Proper Change Management Process

Many well-intentioned project teams make changes during a project without the formality of change authorizations. This can lead to “scope creep.” Prevention Measures:

  • Stress the importance of adhering to a formal, documented change management process.
  • During the project kick-off meeting, walk through the change management process.
  • Execute the change management process for every change, whether there is a change in cost or price. Otherwise “no cost changes” may lead to overall scope creep that will negatively impact the project later.

Starting a Phase Prior to Completing a Preceding Phase

Starting a phase before a related preceding phase is completed is a risky decision. Much rework may be required because of work beginning prematurely. It has been proven time and time again this tactic does not work. Prevention Measures:

  • Ensure that the PM plans and executes the project in a manner that does not allow a phase (or task) to start before a dependent predecessor phase has been completed.
  • Ensure that management regularly accesses the status of the project and is aware (by reading status reports and attending status meetings) of any decisions to start a phase before a prior phase has been completed.

Continuous/Constant Change in Scope

If the customer is continuously making changes in the scope of a project, it usually means they did not have a clear understanding of what they wanted or frequently change their mind about what they want. Constant changes mean frustration for the project team. It can also mean that the PM is spending too much time understanding, documenting, and issuing change authorizations and potentially losing their focus on the actual task of managing the project. Prevention Measures:

  • Be sure to incorporate changes into the WBS and keep the customer constantly advised of the impact of the changes on the schedule, as well as the cost. By doing so, the customer will understand the impact of the excessive changes on the schedule and cost.
  • If changes are too frequent, try to establish a release plan.

Unplanned Turnover of Key Project Team Members

As a result of unplanned staff turnover, cost and schedule overruns occur because of the delays caused by the time required to locate replacements, make them available to work, and bringing them up to speed. Prevention Measures:

  • Ensure the PM has a “succession plan” in place for key project team members in the event they leave the project for personal or business reasons. This plan should include the identification of potential replacements along with the way a transition of responsibilities from the original person to the replacement might take place.
  • Ensure the PM practices “cross-training,” so that in the event a key project team member leaves the project, an existing peer on the project can at least temporarily handle the responsibilities until a permanent replacement is brought in.

Failure to Perform QA Reviews

Sometimes quality reviews are not scheduled until the project is in serious trouble. By that time, it is often too late to avoid significant problems. Prevention Measures:

  • Ensure timely reviews by independent QA staff are held. Also, QA can help ensure that the project starts on solid footing.
  • Ensure follow-through on action plans from the timely reviews.

Summary

I have covered most of the root causes of troubled projects with prevention measures. Hopefully awareness of these root issues and implementation of my suggested measures will help you do a better job in running a project more successfully. At a much higher level, this article was really about QA and what that can do for you. QA is a set of scheduled and systematic activities for each phase of a project that is necessary to ensure a service or product will satisfy the quality standards established by an organization. Your feedback is always welcome.

 

 

 

 

 

 

 

 

 

 

Next Webinar

An Oldie but Goodie: Create a Hammock Task

Ronald Smith has over four decades of experience as Senior PM/Program Manager. He retired from IBM having written four books and over four dozen articles (for example, PMI’s PM Network magazine and MPUG) on project management, and the systems development life cycle (SDLC). He’s been a member of PMI since 1998 and evaluates articles submitted to PMI’s Knowledge Shelf Library for potential publication. From 2011 - 2017, Ronald had been an Adjunct Professor for a Master of Science in Technology and taught PM courses at the University of Houston’s College of Technology. Teaching from his own book, Project Management Tools and Techniques – A Practical Guide, Ronald offers a perspective on project management that reflects his many years of experience. Lastly in the Houston area, he has started up two Toastmasters clubs and does voluntary work at various food banks.
Share This Post
Have your say!
00

Leave a Reply