Why IT Projects Fail – Part 4 (The Project Plan)

Bookmark and Share
Jon Fullinwider

Jon Fullinwider

What gets measured gets accomplished!  Okay, we have an Executive Sponsor (Part 2) and a Project Team (Part 3) with the commitment and authority necessary to ensure the successful development and implementation of the project!  However, all too often, the project begins to fail when the project plan is ill defined, incomplete, not updated, developed but not used, not shared with the end-user or project team, does not have realistic completion dates, does not reflect all the project tasks or more importantly does not reflect a commitment by the customer/end-user for the time required to ensure a successful implementation within the business unit seeking the technology-based solution.

A good project plan is an essential component in the success of any project.  It is the road map for how the project will be managed and the measurement of project tasks leading to project completion.  Key attributes of a good project plan are:

  • All project tasks must be identified and each task must be assigned a start and completion date.  Start and completion dates should be reflected in two categories.  The first category is the dates associated with the “Planned” start and completion date.  The “Planned” dates should never change as they are the dates established in developing the original project completion date.  The second category of project dates are the “Actual” dates that the project task was started or completed.  It is the “Actual” dates (Actual Start or Completion) that can be changed if a task date is slipped.  Initially (at the time the project plan is developed and accepted), both the Planned and Actual dates will be the same until such time as a task start or completion date is missed or changed.  The reason that you never change the “Planned” start or completion date is that it is the basis for measuring missed project dates when compared to the “Actual” start/completion date for the project task(s) in question.
  • All project staff (project team and end-user acceptance team) must be identified with a commitment made to their assigned tasks and associated start/completion dates.  I have found it more than interesting that many mid-level managers or supervisors in the end-user community do not believe they have to make a commitment to fulfilling their responsibility in preparing themselves to accept the new system or adopt new business processes that may be required due to changes in workflow resulting from the implementation of the new system.
  • The project plan must be the basis for managing the project.  While it may seem strange, I have always been surprised that one of the first tasks after a project has been approved is the development and acceptance of the project plan.   Yet in many cases, it is set aside and not used or is not consistently updated which makes it all but impossible to measure project activities essential to ensuring a successful project outcome.  The project plan must be the document used to manage and measure project tasks and outcomes.  There can be no acceptable alternative to a good project plan!
  • The project plan must be updated on a weekly or bi-weekly basis and shared with all members of the project team.  Those tasks that have missed their planned start or completion dates need to be highlighted such that the project team can take actions to ensure task completion thus mitigating the impact on the overall project schedule.  Additionally, those tasks scheduled to be completed during the next reporting period need to be identified such that all project participants are aware of the assignments and can make the necessary commitment to ensuring there completion.
  • On a monthly basis (or more frequently if required) the Project Manager and key project staff (including the end-user community) need to brief (Project Review) the Executive Sponsor as to project status.  In briefing the Executive Sponsor it is essential that three areas be covered.  The first area is a discussion related to the Accomplishments (i.e., tasks started/completed) since the last Project Review.  The second area of discussion should deal with Management Issues impacting the project and recommendations for overcoming them.  Overcoming Management Issues may require the support of the Executive Sponsor who needs to be aware of the issues and recommended actions by the Project Team for dealing with them.  The third area of discussion (Accomplishments Planned During the Next Report Period) should be directed at those project tasks planned to be completed during the next Project Review period.  The project tasks identified during the next review period to be completed represent the basis for measuring project accomplishments during the next Project Review.
  • Lastly, the Project Plan is the ultimate document for establishing accountability by all project participants.  Failure to have and follow a good project plan will quickly result in a failed project!

While the above may seem obvious, I have seen far too many projects in both the public and private sector fail because the Project Plan failed to provide the discipline required to clearly articulate the tasks and resources essential to ensuring a successful project.

Additionally, I have found it more than interesting that when faced with project difficulties a great number of companies and government entities seek to implement a Project Management Office (PMO) as if this will solve their problems and ensure a higher degree of project success.

Establishing a PMO is another topic that I will discuss later in this series, however, any input you may have on this topic would certainly be of interest.

Jon Fullinwider

Former CIO, Los Angeles County (Retired) and Govplace Business Advisor

Tags: , ,

Jon Fullinwider served for 11 years as the Chief Information Officer of the County of Los Angeles. Prior to his position with the County of Los Angeles, he served as the Chief Information Officer for the County of San Diego for 9 years where he was responsible for all information and telecommunications-based services in the fifth largest county in the United States. Before entering public service, he spent 12 years with Rockwell International where he held several executive positions providing technology-based solutions to both corporate and government customers.

3 Responses to “Why IT Projects Fail – Part 4 (The Project Plan)”

  1. Dear Jon,

    Looking forward to parts 4-6 (ie on the clear understanding of requirements, customer/user involvement/participation, plus contracts). Interesting to know that your observations and practical experience in the US is extremely similar to those in Europe.

    In particular looking forward to your take on user-involvment and participation in light of a north-western european tradition of consultation and consensus seeking. But also in relation to the focus on eParticipation, user-centric services/solutions, user-generated content and the whole next generation and Web 2.0 debate – increasingly being used and discussed by European public sector organisations for service delivery and re-use of public sector information.



  2. Jerry Rhoads says:

    I’ve enjoyed reading your Project Management series blog and I agree with you.

    To drill down even further, we need to focus on how IT is about the people –many times the CIO will sponsor a project without thinking about his/her people. IT is about the people, and people cause a project to succeed or fail. I agree with your assessment of a great Project Manager, one thing to add would be do they have a background in the technology they are implementing. If not they need to hire a subject matter expert or SME. However how can they be assured they hired the right SME?

    Having a relavent technical SME in the PMO is very important, they can better identify project related risks and constraints. The PMO will better understand if the resources exist to design/implement/operate the technology being introduced to the business.

    That being said IT needs to change its mission to one to improving business performance and delivering business outcomes. In order to accomplish this task, IT must look must do a self assessment and see how they fit into the mission of their agency or company.

    Jerry Rhoads

Contact Us Request a Consultation