Protecting Project ROI for Project Sponsors

Kent Lefner
8 min readNov 20, 2020

--

Photo by Scott Graham on Unsplash

Business complexity is not shrinking and constant pressure to innovate and change is the new normal. The benefits business seek to achieve from the projects that drive that change are incredibly important to them. The costs they will spend to become the next big competitor are astronomical and have significant impact to the global economy. Business leaders must actively apply a governing framework to detect early and often those conditions that most commonly contribute to project failure.

In 2012, PricewaterhouseCoopers shared a study of over 10,000 projects across 200 companies in 30 countries that found that very few companies (2.5%) completed 100% of their projects. McKinsey found in the same year that 70% of projects fail. A Harvard Business Review study pointed to an average schedule overrun of nearly 70%. Gallup cited the cost of project failure upward of $150 billion per year in the United States in 2004 (no doubt considerably higher today). I suspect many of these studies underestimate the true rates of failure and financial impact, and in today’s dollars, they would be even more staggering.

With the stakes so high, it is critical that business leaders have the ability and courage to mitigate risk up front and actively monitor and act on project risks and performance as early warning signs materialize.

Leon A. Kappelman, Robert McKeeman and Lixuan Zhang published the results of a study in an article called “Early Warning Signs of IT Project Failure: The Dominant Dozen” that showed us 53 common reasons projects fail. Of those, the top 10 most common factors, in descending order, were:

  1. Lack of top management support or commitment
  2. Functional, performance and reliability requirements and scope are not documented
  3. Project manager(s) cannot effectively lead the team and communicate with clients
  4. No change control process
  5. Project stakeholders have not been interviewed for project requirements
  6. No documented deliverable milestones and due dates
  7. Undefined project success criteria
  8. Project team members have weak commitment to the project scope and schedule
  9. Communication breakdown among project stakeholders
  10. Key project stakeholders do not participate in major review meetings

If we recognize those as common factors that contribute to a projects high likelihood of failure, what do we do about it?

To minimize the risk of project failure to achieve business goals and ROI targets, negative impact to the careers and the business’ failure to improve its competitive position, business and project leaders should apply a framework to actively, transparently and honestly monitor risk and issues through the entire project lifecycle.

Based on the top 10 failure factors above, the following could serve as a framework for any project. A leader or group should be charged with periodically reviewing risks and the conditions around key measures and reporting issues detected to governing bodies, especially those that control budget:

Failure Factor

Key Indicators/Symptoms

Key Consideration

Lack of top management support or commitment

  • No single senior sponsor
  • Misaligned expectations across stakeholders
  • Insufficient budget
  • Insufficient SME and resource involvement

This is a project killer. If appropriate senior sponsors and stakeholders cannot provide adequate support (clear and consistent expectations, involvement, financial, resources), terminate the project as early as possible.

If you believe they can provide the support the project needs but are not, work to determine why and course correct. The project is unlikely to produce desired returns without effective leadership support.

Functional, performance and reliability requirements and scope are not documented

  • No in- or out-of-scope statements
  • Requirements do not exist (or exist in draft form)
  • Process and system performance requirements not agreed
  • Users and process owners have not reviewed requirements
  • Requirements do not include a comparison between current and future state conditions

These may indicate a lack of senior leader involvement, project and business leader incompetence, team dysfunction or ineffective scope.

Agile is a prominent project methodology that espouses that requirements can and will evolve through the lifecycle of a project — and especially when users “see” the results of the teams efforts after specific periods of time. But, even agile cannot save a project without adequate direction from statements of scope or user-driven requirements.

Leaders should insist on periodic detection of misalignment of scope and requirements as compared to team work outputs throughout the project lifecycle. They should occur often enough through the entire project lifecycle that detection can occur at the first point of disconnect. Do not wait until QA. If misalignment is detected, stop the work in progress and recalibrate the project timeline and cost expectations to allow for a sufficient understanding of scope and requirements.

Consider also calibrating the risk response to include project termination when re-forecasted time or cost exceed a defined threshold.

Project manager(s) cannot effectively lead the team and communicate with clients

  • Lack of team cooperation
  • Lack of “one team” or “team spirit”
  • Failure to timely and transparently communicate bad news
  • Frequent failure to achieve small planned tasks
  • Frequent miscommunications
  • Frequent client complaints

These may indicate a lack of senior leader involvement, project leader incompetence, team member incompetence, team dysfunction or misaligned client expectations.

Any of those are reasons to scrutinize the ability of the project leader. Even if the project leader is “doing all the right things,” his or her ability to drive team performance influenced by factors “beyond his or her control” is a risk likely to contribute to project failure.

First consider if the expectations across various stakeholders are reasonable and aligned. “Stakeholders,” in this case, are anyone on the project team or who depends on the results the project team creates. Further, “expectations” can be about any aspect of the project such as scope, requirements, plans, intended results and ROI, methodologies and tools used, and general project expectation protocols. If expectations are not aligned, attempt to recalibrate expectations and continue. If stakeholder expectations are reasonable, consider changing project managers.

No change control process

  • Key stakeholders are often surprised by changes or the effect of approved changes on the project
  • People do not know why changes are or were made
  • People do not know how the project will be impacted by changes
  • Changes are made without key stakeholder awareness

This is an indicator of a missing or ineffective change control procedure. This procedure should detect changes and describe, assess and prioritize them, and approve them before they change project conditions (e.g., requirements or plans). This is not about actual change occurring. That will happen in every single project. This is about a failure to detect, understand and accept the impact of changes before project conditions are harmed.

If there is no change control process agreed across key stakeholder — or if one exists but changes are made without its support — stop the project until one is in place or the plan is adjusted and agreed across all stakeholders, and then continue.

Project stakeholders have not been interviewed for project requirements

  • High rate of requirements change
  • User and key stakeholder expectations are not met during deliverable reviews

This is an indicator of ineffective requirements gathering. It could be related to business analysis competency issues or a lack of stakeholder or user involvement.

Catching this one early is key to preserving cost and timelines. Agile methods work well to achieve this by involving users and stakeholders “early and often” as the lifecycle and requirements unfold.

If the project lifecycle is early (e.g., pre-testing and less then 25% of development complete), it is appropriate to pause the process, review requirements with users and stakeholders and rebaseline the project as appropriate.

If the project is in the later stages, pause the process, conduct a deliverable review with users and stakeholders to assess what has been created so far. If the deliverables created to date meet requirements, review remaining requirements and update/rebaseline the project as appropriate. If they do not meet requirements, consider project discontinuance in relation to other portfolio investments or rebaseline and continue with adjusted timeline and budgets.

No documented deliverable milestones and due dates

  • Approved project plans/budgets exclude key milestones and deliverable dates
  • Key stakeholders are unaware of delivery dates
  • Status report dates change from report to report
  • The PM is not using a WBS created by the development and testing team(s)

This is an indicator of ineffective project management. This does not mean the project manager is at issue as the team at large is responsible for project plan development and ownership. However, it does indicate an issue somewhere in the team.

The project does not need to be stopped because of this issue; however, the matter must be addressed. Stakeholders depend on key measures related to time as a way to govern the project. A suitable project plan (waterfall, agile, other) should be prepared by the team and reviewed with key stakeholders, even if that means briefly pausing the project. The plan should account for known and projected risks, issues, assumptions and dependencies.

Undefined project success criteria

  • Lack of project charter
  • Lack of stakeholder agreement of what success looks like
  • Lack of business case with quantified ROI
  • ROI not based on facts
  • No plan to measure ROI post project closure

This is not a project killer but it is highly likely that stakeholder expectations will not be met. It is an indicator that expectations about the benefits to come from the project have not been aligned across the organization. It is possible that the project team is trying to accomplish something that is different from what stakeholders want.

The project should continue, but an effort to align benefit expectations should occur immediately. Consensus across stakeholders is essential. Stakeholders should agree on desired business outcomes and measurements. The project team should have a strong awareness of these outcomes and the project rebaselined if a misalignment is detected between stakeholders and team.

Project team members have weak commitment to the project scope and schedule

  • Bad behaviors on the project team
  • Pattern of ineffective communication
  • Low sense of urgency
  • Low sense of team ownership and accountability

I often advise my clients to avoid an over-reliance on procedural governance and strike a balance with emotional people factors such as team member engagement with the project and the reasons for doing it. People need to feel like they are working toward something important, something that will have real impact on the business. Management who cares about its people can inspire and drive performance. A credible business case and ROI helps people believe they actually can create value.

Depending on the nature of issues detected, actions should range from ROI projection to team building to team restructure. Also look closely at senior stakeholder behavior. People naturally follow the leader. If the leader behaves aggressively or unsupportively in meetings, people will feel stress that can put the team at odds and threaten their commitment to the project.

Communication breakdown among project stakeholders

Key project stakeholders do not participate in major review meetings

  • Pattern of ineffective communication
  • Presence of misaligned activity and awareness
  • Stakeholder disengagement

Bad communication, disengaged leadership and mismanaged expectations are three of the fastest ways to demotivate people and harm project productivity. Decision making is often slowed, and harmed project productivity often contributes to missed timelines.

Senior leaders must be acutely aware of communication, participation and alignment issues at all levels within the project team and across stakeholders impacted by the project or the results it is to achieve. Lead by example. Set and clarify expectations as needed. Work to drive consensus and contribution as often as necessary.

Action must be taken quickly to resolve issues, including key stakeholder replacement if necessary. It is not uncommon for low participation to be a symptom of over-allocation. Consider if your people have too much on their plate and take steps to lighten the load. Coach key team members to follow your example and lead others in a similar fashion.

Originally published at https://www.projectmanagement.com on September 20, 2016.

--

--

Kent Lefner
Kent Lefner

Written by Kent Lefner

25 Years of Transformation Experience, 70 Programs Managed, $500 million budgets managed, 89% first year projects completed after establishing a PMO

No responses yet