The 5 principles of project success

14. März 2018
Kategorien
Newsletter abonnieren

The 5 principles of project success

Just finished reading the book «Performance-Based Project Management» from Glen B. Alleman. You might know him from his very popular blog on project management «Herding Cats«, which I love and recommend reading. He writes great in-depth articles and has very interesting views on project and risk management.   

Whilst reading his book I found lots of things I see the same, but just as many things that I cannot imagine practicing on the type of projects I work on. I am not sure if I would disagree yet. I am absolutely not familiar with doing projects for the American Department of Defence or NASA so working with Earned Value Management might work there. I have to think a while on how I could translate this into something workable for large financial modeling projects, building an online insurance portal, or building a new intranet/extranet for a professional service company. This is something for a future article.    
One chapter where I was just nodding in agreement and recognition was the chapter «The five immutable principles of project success». These five immutable principles are applicable to every project in every business and technical domain. That is the definition of immutable – they never change and are universally applicable. 

Capabilities

Project failure starts when we can’t tell what “done” looks like in any meaningful way. Without some agreement on our vision of “done”, we’ll never recognize it when it arrives, except when we’ve run out of time or money or both. We’ve all seen the project failure numbers before. We’ve all been told how bad things are. We’ve all heard that large numbers of projects fail because of poor planning or poor project management. Whether this is true or not, how can we increase the probability of our own project’s success?
First, we must recognize that without a clear and concise description of done, the only measures of progress are the passage of time, consumption of resources, and production of technical features. These measures of progress fail to describe what business capabilities our project needs to produce or what mission we are trying to accomplish. Capabilities drive requirements. Therefore, without first identifying the needed capabilities, we cannot deliver a successful project, and we will end up a statistic like all the other failed projects.
With capabilities as our starting point, we’re now going to look at the Five Immutable Principles of project success as they apply to any project, in any domain, using any project management method and any project management tool. 

Five principles

The Five Immutable Principles are best stated in the form of five questions. When we have the answers to these questions, we will have insight into the activities required for the project to succeed in ways not found using the traditional process group’s checklist, knowledge areas, or canned project templates.
1) What does “done” look like? We need to know where we are going by defining “done” at some point in the future. This may be far in the future—months or years—or closer—days or weeks from now.
2) How can we get to “done” on time and on budget and achieve acceptable outcomes? We need a plan to get to where we are going, to reach done. This plan can be simple or complex. The fidelity of the plan depends on our tolerance for risk. The complexity of the plan has to match the complexity of the project.
3) Do we have enough of the right resources to successfully complete the project? We have to understand what resources are needed to execute the plan. We need to know how much time and money are required to reach the destination. This can be fixed or it can be variable. If money is limited, the project may be possible if more time is available and vice versa. What technologies are needed? What information must be discovered that we don’t know now?
4) What impediments will we encounter along the way and what work is needed to remove them? We need a means of removing, avoiding, handling or ignoring these impediments. Most important, we need to ask and answer the question, “How long are we willing to wait before we find out we are late?”
5) How can we measure our progress to plan? We need to measure planned progress, not just progress. Progress to plan is best measured in units of physical percent complete, which provides tangible evidence, not just opinion. This evidence must be in “usable” outcomes that the buyer recognizes as the things they requested from the project.

Conclusion

It does not matter what approaches you take to manage and deliver your project. The five principles are valid and the questions that follow from it should be answered when you want to have a good chance at success. When you have not done so yet look at the current project you are involved in and answer these questions, or when you have some time to think and review on past projects take a successful one, and one or two failed ones and answer these questions. I did the same exercise, and it validated what Glen has written in every way.

I have written a previous article about project success where I address numbers 1 and 5 in a different way. The message is the same. When you do not know what success looks like, and do not know how to measure it, you will have a very hard time having success.
Tags

Das könnte Sie auch interessieren

8 Signs of troubled projects for project sponsors

19. April 2017

When you’re dealing with a troubled project, there are usually a number of red flags surrounding you. This article is written from the perspective of senior management (for instance the project sponsor, members of the Steering Committee, or the executive management). All of us have endured troubled projects that didn’t accomplish their intended business goals. Such watermelon projects,

Weiterlesen

Building Is the Easy Part…

6. März 2017

Agile Frameworks and books tell us how to build a product–that’s the easy part… What we are not told are equally important things like maintaining, operating, fixing and extending the built product. When your agile philosophies fail to cover these areas, it greatly reduces agile’s benefits. This is where DevOps comes into play. DevOps is the combination

Weiterlesen

Paying Technical Debt

15. Januar 2017

The metaphor of technical debt in code and design can be defined as follows: You start at an optimal level of code. In the next release, you are adding a new feature. This would take an effort E. This, of course, assuming that estimations are somewhere near reality. If the level of code was less

Weiterlesen

Outsourcing Technical Competence Is a Very Bad Idea

2. Dezember 2016

Organizations do not lose control of large technology programs because they outsource work. They lose control because they outsource understanding. It usually starts with a familiar pattern. A company decides to implement a major system on a technology it does not truly understand. ERP, CRM, HCM, core banking, it does not matter. The internal capability

Weiterlesen

Estimating with Wideband Delphi and Monte Carlo Simulation

18. Oktober 2015

During the LeSS training in Berlin last week with Craig Larman he mentioned the best estimating method he knows for any big software project. Wideband Delphi with Monte Carlo Simulation. I agree with him on this one hundred percent. This article will explain what Wideband Delphi and Monte Carlo Simulation is (Part 1 & 2),

Weiterlesen
Previous