Calleam Consulting Rotating Header Image

Disconnect Failures

Projects are about creating value but that simple fact often gets lost due to the emphasis we place on schedule and budget. Although schedule and budget are important, where they become a project’s primary focus we run the risk of triggering a “disconnect failure”. Disconnect failures occur when a project delivers its deliverables, but the connection between those deliverables and the actual creation of value gets lost.

Disconnect failures are unfortunately all too common. Likely because schedule and budget are more visible, they often take center stage when monitoring a project’s progress. Today’s project management thinking typically uses “Earned Value” as a tool for tracking progress. That can be a doubled edged sword. On the one had we have a clear picture of time, money and deliverables, but on the other hand, the focus on schedule and budget can divert attention away from ensuring the project stays on track towards its final goal, the of creation of value.

In many cases the problem comes down to the fact that projects only create deliverables and the actual realization of value comes after the project has closed. I spent much of yesterday with a class of Project Management students who are doing a case study that deals with the creation of a PMO. Such projects are prime candidates for a disconnect failure. Because ‘PMO set up’ projects typically focuses on deliverables (templates, processes, training programs and changes to the organization structure, etc) the actual realization of value (a more efficient and reliable project deliverable capability) comes after the ‘PMO set up’ project is complete.

In general when I look at projects such as the PMO creation project, I look for a template of activities that link the project to the realization of value. Firstly at project start up we need to have a clear picture of the value we are trying to create and how we will know when we got there. Clear, measurable objectives are a good starting point, but they alone are not enough. The next thing I look as is whether or not the team is using those objectives to guide their decision making as the project moves forward. The final step and the one that most often gets dropped, comes down to project closure.

Often project closure is seen as a simple handover of deliverables, followed by a party and a cheerful wave over the shoulder as the project team disappears into the distance. This is the point at which the disconnect often occurs. Because there are no planned activities for the measurement of the objectives and no framework for ongoing support, the actual creation of value often gets lost.

Although we think of such projects as “done” when earned value is 100%, at project closure we haven’t really “earned” any value at all. While we have deliverables, all they do is put us in a position to start earning value. The actual earning of value only comes as the project’s deliverables begin to get used. That is often a rocky road that requires ongoing support, monitoring and constant reference back to the original objectives. Smart organizations put in place a mechanism to ensure that the linkage between the events after project closure and the project’s objectives is firmly maintained.

2 Comments on “Disconnect Failures”

  1. #1 Dhalie Patara
    on Dec 12th, 2008 at 4:33 pm

    Great article! As a Project Manager with a strong Business Analyst background I’m always thinking about what value my project is bringing to the organization, both during my project and in sustainment.

    As a BA I’ll work on Business Cases and Charters detailing the value to the organization of the project with tangible or direct benefits and intangible or indirect benefits. These benefits may be realized during the project, but often some benefits will only come at the end of the project, or 6 months or even a year later. With my PM hat on or if another PM takes on the project it can be challenging to validate and report on benefits realized during the project and particulary benefits realized long after the project is over. Unfortunately, often once a project is approved, the value/benefits gained are not tracked. Whereas the schedule and budget will be tracked in detail. This could lead to the disconnect failure you describe.

    I’m curious… in your article above you state “In general when I look at projects such as the PMO creation project, I look for a template of activities that link the project to the realization of value. Firstly at project start up we need to have a clear picture of the value we are trying to create and how we will know when we got there. Clear, measurable objectives are a good starting point, but they alone are not enough.”

    If measurable objectives alone are not good enough, what else would you add to your project plan that would help you report value/benefits during your project or at closing?

    How specifically do you suggest that Project Plans capture/link to value for benefits gained (direct or indirect). Would you try to quantify benefits and graph that along with an EV graph?


  2. #2 Rob
    on Dec 12th, 2008 at 5:25 pm


    Thanks for the comments. The template of activities I look for a not necessarily for “reporting” value. Instead the activities I’m looking for are the activities that help ensure the original benefits the organization sought are actually attained.

    In terms of the template of activities I look for, here are some generalized pointers;

    1. 1) I look to see how strongly involved the Project Sponsor is (i.e. how many project activities involve the Sponsor). After project closure, the Sponsor is the person responsible for nurturing the “value proposition” and ensuring the benefits of the project are seen through to fruition. In many projects Sponsors don’t seem to understand that is a part of their role and hence the “disconnect failure”.
    2. 2) I check to see how closely involved the stakeholders are. Stakeholder participation is vital because after the project closes, stakeholders are the ones whose lives will be affected by the new product, system or process. In setting up something like the PMO, as well as involving stakeholders in requirements sessions, I would add into the plan a few stakeholder update sessions. Such sessions keep stakeholders up to date with what is going on and also provide an opportunity for them to give feedback.
    3. 3) I look closely at the transition activities that occur as the project team hands over the product, systems or process at project closure. Is there enough training, enough communications, etc
    4. 4) I look carefully at culture change activities. Introducing something like a PMO involves a culture change and if there is one thing cultures don’t like to do its “change”. People get used to ways of working and getting people to change is a significant effort in its own right. There is much that can be said about culture change … maybe some food for future posts ….
    5. 5) I look to see if there are post project closure checkpoints where the organization monitors to see how successful they are being. Such reviews provide valuable feedback and an opportunity to correct course to ensure the organization stays on track

    However, back to your question about “reporting value”, having some sort of graph (such as EV creates) would be a very good idea…although it would need to be tracked after project closure as well as before closure.