Wednesday, 12 September 2012 09:21

Projects Done Well, a Recap - Part 1

Written by

FEATURESept12thOver the last two years, we’ve looked at 22 case studies in this blog. They were real projects. Some were wildly successful. Some were miserable failures. What were the key factors that contributed to those successes and failures? In this post, Part 1, we’ll start the review with a look at three of the nine most influential factors that contributed to those project outcomes. We’ll also suggest how you can leverage these findings to improve the performance of your own projects. In the next post, Part 2, we’ll complete the review of the remaining six factors.

The MethodologyDrewSept12th1

We analyzed the 22 articles presented in the From the Stakeholder’s Desk blog on Project Times against the 18 Factors in Project Pre-Check’s Decision Framework. The Decision Framework helps stakeholders form and articulate a common vision for a planned change from inception through completion. The stakeholders need to consider each of the four domains - all aspects of the change itself, the environment within which the change is being implemented, the assets that can be leveraged or that will be affected, and the way the project will be conducted.

The Findings

The good news – nine of the eighteen factors were identified as critical to the project outcomes in ten or more of the cases as shown in the graph below. The message: get your stakeholders agreeing on these factors first and your project has a much better chance of achieving its goals.

That isn’t to suggest that the other factors are unimportant. The Quality factor, the Investment Evaluation and Current/Future State factors and the Organization factor were material contributors to the outcomes on three or more of the projects we looked DrewSept12th2at. However, we believe the significance of the other factors will be situational, depending on the nature and characteristics of each unique project. The nine factors identified here as the leading contributors will have a much broader impact. Pay special attention to them.

Let’s take a closer look at three of the factors and some of the projects they influenced, either positively or negatively.

The Change Domain

The Change domain focuses on stakeholder decisions regarding the specifics of the change itself. It includes the dimensions of the change initiative, the quality needs and expectations that must be satisfied, the investment decisions behind the change and the stakeholders and their capabilities.

The two Change domain factors that stood out in our review were Stakeholders and Dimensions:

Stakeholders

The Stakeholder factor was a key contributor to project success or failure on all 22 cases. In fact, not one project with an effective stakeholder group failed. So, what is a stakeholder? Stakeholders are the decision makers on the project. They are the keys to project success. Without the right stakeholders on board, your project won’t be successful. Period! In fact, the fundamental premise underlying Project Pre-Check is this: if the stakeholders for a given change are actively involved in and agree with each decision, and all the vital decisions are addressed, the project will be successful.

Project Pre-Check uses a stakeholder model with the four roles shown at the left; sponsor, change agent (project manager), targets and champions. The sponsor, change agent and target roles always need to be filled. The champion role is desirable butDrewSept12th3 optional. Let’s take a look at how the stakeholder group helped or imperiled project success on a few of the case studies.

My last post, You Can’t Always Get What You Want, is a perfect example of what can happen when the balancing influence of the other stakeholders isn’t available to override the ego of a tyrant. The PM formed the stakeholder group at the start of the project but didn’t keep the members engaged over time. The project failed. The post Collaboration in a Command and Control World is another example of the destructive power of a tyrant. In this case, the stakeholder group was never formed and the sponsor attempted to intimidate by edict. That project failed as well.

Sometimes, a steering group is formed to guide a project but the roles and responsibilities aren’t clear and the results tend to reflect that uncertainty. In the post The Offshoring Challenge, Part 2, a multi-million dollar, mission critical undertaking, lack of clear roles and responsibilities in the steering group resulted in lots of back stabbing and finger pointing when things went wrong, and they often did. On top of that, the real sponsor wasn’t engaged and driving the change forward and the designated sponsor really wasn’t. You can’t delegate sponsorship! Eventually the roles and responsibilities were addressed, the right players were engaged and the project got delivered, but months late and millions over budget.

On the positive side, the posts Delivering Portfolio Management Light and A Perfect Project show the kind of successes that can be achieved with a fully formed and engaged stakeholder group – a lead-the-way sponsor, committed and aggressive targets who look after their own organizations’ interests and a change agent who facilitates stakeholder decision making from project inception through completion.

The takeaway: make sure you have your stakeholder group in place and engaged up front and throughout!

Dimensions

What the heck are Dimensions? Dimensions define the breadth and depth of the opportunity or problem being addressed and includes the burning platform, the business problem, need or opportunity, business goals and objectives, worth (what the organization is willing or can afford to spend), requirements, benefits, locations targeted, target dates and rationale, phasing and staging opportunities and expectations, assumptions, success criteria and volumes, transaction mix and peak periods.

The Dimensions factor was central to the project outcome in 21 of the 22. The only case where dimensions didn’t overtly influence the outcome was The Offshoring Challenge, Part 1. The dimensions were known but there were so many other gaps on the stakeholder front, resourcing, risk management, etc., the project went down in flames.

One project that suffered from a “dimensional” gap was covered in the post, The Never Ending Project. It had huge stakeholder issues which may explain why they also had difficulty defining requirements, no sense of the project’s worth to help guide decision making and no understanding of the phasing alternatives to help reduce risk. The project was years late and over four times the original $7 million estimate, with less functionality.

There are other examples of “Dimensional” gaps. The project covered in Eight Steps to PPM Implementation Success didn’t uncover the root causes of business unit discontent until after the Project Portfolio Management effort was terminated. Poor project management practices accounted for over half of the business unit complaints. Limited availability of certain IT skill sets was responsible for almost 40% of project delays. Lack of a comprehensive standard technology infrastructure resulted in significant custom work, increasing costs and risks and adding further delays. PPM would have contributed some value but it wasn’t even in the top ten action items identified.

Sometimes Agile Isn’t covered a similar problem - no clear understanding of the problems that needed to be solved. This project was actually four different changes grouped together. If the stakeholders had actually understood the problems being addressed by the four changes and explored the assumptions around each one and the four together, I expect a very different structure and approach to the problems would have been used. The project was cancelled with over $ 1 million in staff and contractor costs down the drain.

One of many projects that nailed the Dimensions and delivered successfully was covered in the post Avoiding New Technology Risks. The stakeholders knew explicitly what problems they were trying to solve. They figured out what the project was worth to the organization which led to the selection of an appropriate and affordable solution. As well, identifying a business based phasing and staging approach right up front helped iron out the new technology wrinkles and manage the risks effectively. It was a project well done!

The takeaway: ensure your stakeholders have fully addressed the Dimensions decision areas and that they are fully in agreement and stay that way throughout the project.

The Environment Domain

The Environment Domain addresses key dimensions of the current state enterprise infrastructure, the future state target architecture and the business plan that will move the enterprise from the current state to the desired future state.

One Environment domain factor, business plan, was identified with project success in our review.

Business Plan

The Business Plan factor includes eight decision areas: mission, vision, core values, strategies, enterprise priorities, dependencies, programs and timing. Stakeholders need to understand a project’s relationship to each of these facets to ensure consistency of direction and ongoing success. Any dichotomies between the stated directions and beliefs and the impact of a planned change need to be addressed as part of the project.

The Business plan factor was integral to project outcomes in 12 of the 22 cases. Here are some examples:

In the post Pulling the Project Plug, the project was deferred because it had a lower priority than other in-progress projects. Of course, the fact that the initiative had no sponsor and no stakeholder group to assess its relevance and priority was a key contributor to its demise. The end result was wasted millions of dollars and the time of critical resource required by other higher priority projects.

Conversely, in Speaking Truth to Power, the PM knew the project was a high priority, government mandated initiative with significant financial penalties for failure to deliver on time. He leveraged the CFO’s wrath over the lack of progress to secure the right staff, with the right skills at the right time to get the project delivered on time.

The takeaway: your stakeholders need to be fully aware of your project’s relationship with the culture, plans and activities of the larger organization and ensure your project is positioned appropriately.

The Way Forward

The stakeholder group is a most powerful force for enlightened project guidance and an essential resource for project managers. But it needs to be nurtured and cultivated from project inception through completion. That’s why it’s central to Project Pre-Check’s model, processes and Decision Framework. We’ve seen how the three factors covered in this article are central to project success. In the next post - Projects Well Done, a Recap – Part 2, well look at the other six factors and how they contribute to project outcomes.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go. This month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management.

Don't forget to leave your comments below.

Read 8527 times
Drew Davison

Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check - The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at drew.davison@projectprecheck.com

© ProjectTimes.com 2017

macgregor logo white web