Why “Successful” Projects Fail …

[The Truth About Change Management]

The project satisfied its requirements. The project was delivered on schedule AND under budget. It was a “success”, right? … Perhaps.

The open question is: How was the project received by its stakeholders?

Some were very happy with it. Most liked it a lot, but there were a handful of stakeholders who were dissatisfied. They didn’t think that the project delivered everything it should have, but those stakeholders didn’t participate fully and had false expectations of what was within the project’s scope.”

Does that sound like the familiar lament of a “wronged” project manager?

It’s easy to blame those stakeholders for their own dissatisfaction, but is that fair or even correct?

The Project Management Institute (PMI) includes “Manage Stakeholder Expectations” as one of the five processes included in Project Communications Management. On smaller projects, managing stakeholder expectations would fall under the Project Manager’s responsibilities. On larger, more complex projects a Change Management specialist might be assigned to address that process/task group.

How Quickly They Forget …

Even though stakeholders may have participated in the requirements gathering / definition activities, they may not remember (or may have chosen not to remember) what was decided to be “in” scope or “out”. A good project management team will carefully document the project and deliverable requirements, as the requirements are used to determine product acceptance criteria and completion. As the project proceeds, additional definition might be added to the requirements (progressive elaboration), but the core requirements remain unchanged.

Both the PMI  and the Information Technology Infrastructure Library (ITIL) processes include Change Management methodologies to accommodate changes in project scope (when requirements are modified). These processes / methodologies allow the change to be documented, reviewed and approved, prior to development work or implementation proceeding.

Without strict Change Management controlling of project scope, many projects have problems meeting their schedule or cost commitments. These Change Control documents are also useful in helping stakeholders understand the project scope.

Change Management: Not Just Scope Control

While PMI & ITIL focus on Change Management primarily in terms of scope control, it is actually a much larger work effort. The PMI process, Managing Stakeholder Expectations, is mostly about Change Management, in spite of not being specifically identified as such in PMBOK. (PMBOK is  PMI’s Project Management Book of Knowledge. It is a book which presents a PMI’s definitions of project management terminology and guidelines.)

Even though the project documentation may, for example, specifically describe a data input screen in terms of its fields and functions, if, after Go Live, Stakeholder B  thinks that the font size on that screen was too small to be readable, then that stakeholder will be unhappy. He might describe the project as having “failed”. So whose issue is this?

Stakeholder B might have chosen not to fully participate in the interface review or acceptance, but that doesn’t change how he feels.

Regardless of the stakeholder’s abdication of his responsibility to review the interface, it is still the project team’s responsibility to manage that stakeholder’s expectations through meetings, demonstrations and, if necessary, one-on-one discussions.

Change Management is not just about controlling scope, it’s about communications, managing expectations, education/training and it’s about helping the user community and stakeholders adjust to the changes that the new process or product might bring to their organization.

When changes occur too quickly or too dramatically, stakeholders may have problems integrating the changes into their business processes. Regardless of whether a project met its goals (definition of “success”), it could still be considered a “failure” to the user community and stakeholders if they can’t effectively integrate it into their operational processes.

“Success” may be in the eyes of a project team or project sponsor. “Failure” is commonly in the world of the end users and stakeholders. At project closure, if the users aren’t satisfied with the end product, regardless of what a contract or requirements document might say, that “successful” project might still be viewed by them as a “failure”.

That’s not fair!

The project manager and team had worked hard to deliver on scope, on time and on budget. It’s not “fair” that someone is saying that the project is a “failure”? This is one case where perception really is reality. The PM can try to convince the stakeholder that he’s wrong, but it’s very difficult to argue with a “perception”. Pushing facts toward a stakeholder with a bad perception of project delivery is generally a losing battle. Perceptions are often based more on emotion, than fact.

The best approach is one that should have been taken much earlier in the project … communicate with the stakeholders. “Communicating” means more than distributing information at a meeting or via email. “Communicating” includes the delivery of information AND the confirmation that the information has been received and understood.

Managing Stakeholder Expectations is not just sending out emails. It’s engaging the stakeholders in active discussions of the project scope and the requirements. It’s about understanding their perceptions of what the end product or service might be. It’s confirming or correcting those perceptions long before Go Live.

If, after the scope definition discussions, there is still a significant gap between the documented requirements and what the stakeholder(s) understand is to be delivered, then the Change Control Process component of Change Management should be engaged. The Change Control Process moves the project team out of the line of fire and the perceived scope gap becomes an question of money and schedule.

Start Change Management processes early and continue them throughout the project. It’s always better to confront a problem head on than to allow it to grow and fester into a more significant problem that is difficult to effectively address later.

10 responses to “Why “Successful” Projects Fail …

  1. The question, “How was the project received by its stakeholders?” could begin to answer with what strategic management plan used to begin the project. The stakeholders dissatisfied may not have the full access to the decision make process for the complete project. Sometimes problems arise making a change in the original plan necessary. With that, it would be fair to blame the stakeholders for their own dissatisfaction. It is not the project manager’s job to please each individual.
    A good project manager keeping the stakeholders informed may use the team approach. This is a way to keep communication between departments open. By using this approach, it may be easier to document all that will take place and stay on track. If the team followed the change management, then at some point the stakeholders would be aware and have an opportunity to share their thoughts about any changes or problems seen. Although the stakeholders will always have the right to disagree with the result of a project, it is not good business practice to voice what not liked in a public forum. This would be the time for the project manager to corral the team including the stakeholders to discuss the outcome.
    Change management must follow through with the original strategy and use structure to keep projects in place. The view of a project as a failure can happen in any project. Fair or not, it should not completely dictate the result of the project. If the stakeholders used the tools provided to continue communication, their views might have been different.

    • Thank you for taking the time to submit such a thoughtful comment to this posting.

      While I agree that it is “not the project manager’s job to please each individual”, it is important to proactively seek out and acknowledge stakeholder concerns, especially if that stakeholder has both legitimacy and power. Failure to do so can be leave the PM with a situation that could be disruptive to other project processes.

      I also agree that “it’s not good business practice to voice what is not liked in a public forum”, but stakeholders will take that route regardless of how unjustified their claims might be. (Sorry…just a reality.) Assigning “blame” to stakeholders for their dissatisfaction rarely yields positive results. Working with stakeholders to avoid problems and misunderstandings is what stakeholder communications and change management is all about.

      Meetings and forums can be excellent opportunities for delivery of progress reports to stakeholders and to discuss important topics. Project documents sent to stakeholders for their review are also good starting points, but both of these methods leave open the hazard of one-sided “communications”. They pass information without necessarily receiving acknowledgement of understanding.

      When that occurs, scope constraints can be misunderstood and requirements can be missed. After the fact, the PM can highlight when a stakeholder failed to read or understand something, but that does little to retroactively add a missed requirement or to change an opinion. Confirming the content of key presentations or project documents can, however, avoid an unfortunate situation. A little extra effort by the project team or the PM can go a long way.

      Change management processes are critical to correcting requirements or modifying scope, but change management includes really communicating with the stakeholders on a regular basis and using those efforts to manage delivery expectations.

      If you are an on-going student of project management (as so many of us are), you might find some very interesting posts on Fear No Project

  2. Pingback: When projects go too well « Project Management in Practice

  3. When I first read the title of this post, I thought you were going to discuss the topic of project success vs project management success …

    I think this is an excellent post and I’m sure that it will attract many readers, and that’s why I would love to republish it on PM Hut, where many project managers will benefit from it.

    • Thank you…

      The primary object of this post was to refresh the discussion on Change Management. While this topic runs hot-and-cold in the media and blogs, it is a constant reality with those of us who actively work high visibility projects. Both PMI & ITIL should include this non-scope-control topic in their processes.

  4. Woah this weblog is wonderful I love reading your posts. Keep up the good work! You know, a lot of persons are searching around for this info, you could help them greatly.

  5. Pingback: Of pointy umbrellas on public transport | Brilliant Baselines

  6. “Why Successful Projects Fail | beyondcenter” was indeed
    a superb read and also I was in fact extremely joyful to come across the article.

  7. I actually had to share this unique blog post, “Why
    Successful Projects Fail | beyondcenter” socialgeekette along
    with my personal close friends on facebook or twitter.
    I personallyonly wished to distributed your remarkable posting!
    With thanks, Gerald

  8. I have been exploring for a little bit for any high-quality articles or blog posts
    in this kind of area . Exploring in Yahoo I eventually
    stumbled upon this site. Reading this information So i am happy to exhibit
    that I’ve an incredibly just right uncanny feeling I came upon exactly what I needed. I most unquestionably will make sure to do not disregard this web site and give it a glance regularly.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s