Monday, February 19, 2018

Project Portfolio Throughput: Faster Is Better

Project portfolio throughput: faster is better
Too many organizations try to save money on projects (cost efficiency) when the benefits of completing the project earlier far outweigh the potential cost savings.

You might, for example, be able to complete a project with perfect resource management (all staff is perfectly busy) in 12 months for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.5 million, but the project would be completed in only 6 months.

What's that 6 months difference worth? Well, if the project is strategic in nature, it could be worth everything. It could mean being first to market with a new product or possessing a required capability for an upcoming bid which you don't even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for an external audit. There are many scenarios were the benefits outweigh the cost savings (see "Cost of delay").

Additional to delivering the project faster, when you are done after 6 months instead of 12 months you can use the existing team for a different project delivering even more benefits for your organization. So not only do you get your benefits for your original project sooner and/or longer, you will get those for your next project sooner as well because it starts earlier and is staffed with an experienced team.

An important goal of your project portfolio management strategy should be to have a high throughput. Get projects delivered fast so you start reaping your benefits, and your organization is freed up for new projects to deliver additional benefits.

For a typical organization this means three things;

1) Doing fewer projects (in parallel). On average only half of what you are doing now.
2) Focus on doing the right projects.
3) Focus on improving your project delivery capability.

You can buy my books The Art of Technology Project Portfolio Management and The Science of Technology Project Portfolio Management separate or as a bundle in my store. Just click here or on the image.

Read more…

Monday, February 12, 2018

The Project Recovery Process Explained

Project Recovery
Projects fail for a variety of reasonsEspecially technology projects have a low success rate. Typically more than half of them are considered a failure. But it does not have to end that way.

As soon as a project is identified as in trouble you can start thinking about project recovery. This sentence already states a very important precondition for a successful project recovery process, namely identifying a project as troubled. It takes a great deal of political savvy and courage to admit that a project is in serious trouble.

Results of a Project Recovery

A project recovery process can have three possible outcomes:

1) Delivery of the project without significant changes in scope, time and/or costs. This is very rarely and only possible when trouble is identified early and action is taken immediately. 

2) Delivery of the project with significant changes in scope, time and/or costs. There will be an impact on the business case. 

3) Termination of the project because costs and benefits or value are no longer aligned. Note that termination does not necessarily mean that everything done up to this point should be written off as sunk costs. Some part might be salvageable.

The Project Recovery Process

A typical project recovery process consists of the five phases below.

Project Recovery Process

1) The Mandate Phase

The purpose of the mandate phase is simple. The project should be identified as troubled, and a project recovery manager should be identified. The mandate of the project recovery manager should be defined clearly. Especially when the recovery manager is working with the current or new project manager instead of replacing him/her. Afterwards, the project recovery manager and his/her should be introduced to everybody that needs to know. The project recovery manager can be an internal role, but there are a number of good reasons to hire an external project recovery manager.

2) The Review Phase

Now that we have a clear mandate, we enter the review phase, which is a critical assessment of the project's existing status. You will look at what went wrong and what can be corrected rather than looking for someone to blame. A project review is all about the probability of project success. A project review will give you a good understanding of the current status of the project and how it is on track to deliver against your definition of project success on three levels:

1) Project delivery success
2) Product or service success
3) Business success

You will find a detailed outline of such a review under my project review service. Note that if the project has a technical component, the project recovery manager should have a strong technical background so that he or she can talk with the technical team on its own level, gaining trust as someone who understands the challenges. This must be coupled with an independent critical eye questioning the direction. Many aspects of technology development can contribute to, or even cause trouble on a project.

3) The Tradeoff & Negotiation Phase

Hopefully, by this point, you have the necessary information for decision making as well as the team's support for the recovery. It may be highly unlikely that the original requirements can still be met without some serious tradeoffs. You must now work with the team and determine the tradeoff options that you will present to your stakeholders.

When the project first began, the constraints were most likely the traditional triple constraints. Time, cost and scope were the primary constraints and tradeoffs would have been made on the secondary constraints of quality, risk, value and image/reputation. When a project becomes troubled, stakeholders know that the original budget and schedule may no longer be valid. The project may take longer and may cost significantly more money than originally thought. As such, the primary concerns for the stakeholders as to whether or not to support the project further may change to value, quality and image /reputation. See "The reverse triple constraint of troubled projects" for more background on this.

After defining the tradeoffs, the project recovery manager is ready for stakeholder negotiations provided that there still exists a valid business case. If the review phase indicates that the recovery is not possible and a valid business case does not exist, then there may be no point to negotiate with the stakeholders unless there are issues with which the project recovery manager is not familiar.

4) The Intervention Phase

Assuming the stakeholders have agreed to a recovery plan, you are now ready to start the intervention phase of the project. This means: 

- Briefing the team on the outcome of the negotiations 
- Making sure the team learns from past mistakes 
- Introducing the team to the stakeholders' agreed-upon recovery plan including the agreed-upon milestones 
- Introducing any changes to the way the project will be managed 
- Fully engaging the project sponsor as well as the key stakeholders for their support
- Identifying any changes to the roles and responsibilities of the team members 
- Restore team confidence 

"We cannot solve our problems with the same thinking we used when we created them." - Albert Einstein
The way I set up the delivery part of the project with my team(s) at almost every intervention phase I start I described in "A simple and effective project delivery framework". 

5) The Transition Phase

As soon as the project is in a normal state again the project recovery manager (when he/she does not have the project manager role) can transfer the responsibility for the recovered project and closes the recovery process. When the project recovery manager also has the role of project manager he/she can decide to close the recovery process and manage the project as if it was a freshly started project or keep the project in a recovery process until the project is finished. 

Read more…

Sunday, February 11, 2018

What Exactly Is a Troubled Project?

Most of my work as a project recovery consultant is with what you can call "troubled projects". But what does this actually mean? Many teams I have worked with seem to be stuck in the PMI view of things. The PMBOK® Guide defines the successful project as a project that meets its objective in terms of quality, schedule, budget, and scope (or customer satisfaction), while a project is a temporary endeavor undertaken to create a unique product, service or result. The guide does not define a troubled project but by taking the opposite of the above you can formulate a starting definition for troubled projects:

A troubled project is a project with overrun in quality, schedule, budget and scope that exceeds the acceptable tolerance limit and might be recovered.
Therefore, a specific effort is required to either define and execute a possible recovery or deciding for an early project termination, as both options are considered a solution for troubled projects. 

The Meaning of Trouble

From my point of view, this definition of a troubled project is not useful because it only captures a very small part of what a successful project is. As discussed in a previous article, project success is defined across three levels:

1) Project delivery success: this is about the process of delivering the project is successful. Essentially this addresses the classic triangle "scope time, budget, and quality?" It is limited to the duration of the project and success can be measured as soon as the project is officially completed. Intermediary measures are easy to do as part of project control processes. Besides the typical project delivery KPIs you can also look at KPIs like overtime, project member satisfaction, stakeholder satisfaction, lessons learned (improved project delivery capabilities), etc.

2) Product or service success: this is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.). These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured during or directly at the end of the project itself.

3) Business success: this is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (5% market share won, technology advantage), etc. In most cases, these business success factors can only be measured once the product/service is implemented and over a longer period of time. 

These three levels combined (and therefore measured by the combined set of KPI's from these levels) will determine your overall project success. Once you have taken the effort of defining all your project success criteria on each level (KPIs) you can define min, max and target values for them. Success is rarely a single point or value. 

The PMI view only looks at the first level: project delivery success. Personally, I think this level matters very little if level 2 and 3 are not met. Another issue with focusing on level 1 is that you measure success against estimations. I can have the best team, doing the absolute best work for 7 months, delivering great results for the client and company "failing" because some project manager without a clue about software development, without a team in place, and no deep understanding of the client requirements, decided that the scope could be delivered in 6 months.

In my opinion, a troubled project should be defined by the same three levels and KPIs as a successful project. Hence a troubled project can be defined as a project where the difference between what it is defined to be (your KPIs), and what can be expected to be (your measurements and projections) exceeds the acceptable tolerance limits (your min and max values), pushing it into a course that will inevitably lead to failure.

A troubled project is a project where the difference between what it is defined to be, and what can be expected to be, exceeds the acceptable tolerance limits, pushing it into a course that will inevitably lead to failure.

How Does This Help you?

So now we have a definition for troubled projects, but how does this help me recognizing, or even better, preventing one? It doesn't. It is just the first step of a longer process. The PMI view on troubled projects is easy to implement and measure. As shown above, all project delivery success criteria can be measured during and directly at the end of a project. But product/service success and business success cannot. So we have to work with leading indicators and assumption validations in order to make meaningful measurements for those criteria during the project. See "10 Leading indicators of troubled projects" for a number of examples of such indicators.

Read more…

Wednesday, February 07, 2018

A simple and effective project delivery framework

A few years ago I stumbled on the website of Olaf Lewitz. Olaf is a Certified Enterprise Coach that approaches Scrum a little different as most. He has written a guide to Scrum in a way that is capturing the essence of Scrum and I think he did this very well. He calls it Liquid Scrum.

I recognized a lot of my own way of project delivery during project recoveries in it, and the last few years I have applied the process with a few adjustments with much success on large software development and financial modeling projects in distress.

Note this is only the delivery part, there is a whole lot more to a successful project then just delivery.


Everyone involved takes shared responsibility for success. Focused interests (see below) never imply that something is not within your responsibility.


Assume everyone is contributing the best they can. Focus your conversations on options you have right now, not on what should be or should have been. Choose wisely: decide using consent or better. As soon as the assumption is proven to be untrue, act fast. The team is more important than its individuals.

Constrain your system with a timebox

Set a timebox of two weeks. This will give you rhythm and enable you to see what emerges, and give you options to focus:


1) Deliver.

2) Visualize what you do in a way that supports your understanding of how you do it.

3) Reflect daily on what you see, decide on choices you have. Adapt the rhythm if that makes reflecting more effective. Only execute these three options until you can reliably deliver every two weeks. Everything else may confuse you.

4) Experiment within the bi-weekly timeboxes. Detail the options you discovered to set clear goals up front and indicators for success and failure. Decide what to invest and how to limit risk. Never run an experiment without making explicit what you want to achieve or learn.

5) Focus on what to deliver.

6) Reflect on what you did, and how you did it, and discover options to get better.

7) Communicate what you are doing, and what you did, to people outside the team.

Focused Interests

Your system may get better faster at making a difference if you focus on these three interests:

1) Do the right thing. (Value)

2) Do things right. (Quality)

3) Get better and better every day. (Speed)

- Better at delivering faster.
- Better at doing the right things faster.
- Better at doing things right faster.
- Better at deciding which of these is important, right now.(some people call this effectiveness, and it’s blurry)

In many or most systems having people take explicit responsibility for one of these works well. By-the-book Scrum, for example, prescribes one voice for 1. (Product Owner) and 3. (Scrum Master). In most contexts, that’s good advice and a good choice to start with.

For me, project delivery is about continuous improvement, scope flexibility, team input, and delivering essential quality outcomes. Methodologies I use and adapt include Scrum, LeSS, eXtreme Programming (XP), Kanban, Systems ThinkingLean Software Development, and Lean Six Sigma.

Read more…

Monday, February 05, 2018

What is a project review?

- You want do to know where you are standing with that large, multi-year, strategic project?
- You think one of your key projects is in trouble?
- Or you know that one of your key projects is in trouble?

Then a project review is what you are looking for.

So what is a project review?

When we talk about a project review there are many names thrown around to indicate the same thing: project review, project health check, project audit, project retrospective, project postmortem. But are they really the same? Not really.

A project audit is about being compliant and about the now. An audit aims to show the extent to which your project conforms to the required organizational and project standards. So, if your organization uses PRINCE2 or their own project management methodology, an audit will look at how closely you follow the processes. An audit can take place during or after the project.

A project retrospective, or postmortem, is about lessons learned so that your next projects will run better or equally well. A project retrospective will be done after the project, so has no use for the project itself.

A project review is all about the future probability of project success. A project review will give you a good understanding of the current status of your project and how it is on track to deliver against your definition of project success on three levels:

1) Project delivery success: will the process of delivering the project be successful? Essentially this addresses the classic triangle "scope time, budget, and quality?"

2) Product or service success: this is about when the product or service to be delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.).

3) Business success: this is about how the product or service to be delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business.

A project review can take place at any time during or after the project, although it has very limited value at the start of a project.

Why do a project review?

A project review will give you:

- An outside 360-degree view on the current status of your project
- The information you need for good decision making
- An outside opinion on the success chances of the project (project delivery success, product/service success, and business success)
- Suggestions for corrective actions on the discovered project issues and challenges

When should you do a project review?

The three main reasons for doing a project review are:

1) Periodic review of large, multi-year, strategic projects to verify all work is on track and the business case(s) are still valid.
2) When you think one of your key projects is in trouble.
3) When you know one of your key projects is in trouble.

What will be done during a project review?

Below are the building blocks of a project review. The row order is not graved in stone and can be adapted based on availability and priorities. Results of one building block will be an input of another.

1) Understanding the project success criteria
2) Understanding the project stakeholders
3) Team Review
4) Scope Review
5) Financial Review
6) Timeline Review
7) Steering Committee and Governance Review
8) Technology & Architecture Review
9) Engineering & Quality Review
10) Impact Analysis
11) Risk Assessment
12) Communication Review
13) Contract & Procurement Review

What will be the outcome of a project review?

1) An up to date assumption List
2) An up to date issue list
3) An up to date risk assessment
4) A detailed report with findings and suggested corrective actions
5) Presentation and discussion of findings and suggested actions

Read more…