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?

Project Review Model
> You want 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.

When we talk about a project review, there are many names thrown around that, at face value, are all taken to mean the same thing: project review, project health check, project audit, project retrospective, and project post mortem. But are they really the same?

The short answer is “no.”

A project audit bears on issues of compliance and has to do with the now. An audit aims to show the extent to which your project conforms to the required organizational and project standards, its fidelity. 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 either during the project or after it is completed.

A project retrospective, or post mortem, is about learning lessons so that your next project will run better or, at least, equally well. A project retrospective is performed after the project closes, so is of no use to the project itself.

A project review has to do with project success. A project review will give you a good understanding of the status of your project and whether it is on track to deliver against your definition of project success on the following 3 levels:

1) Project delivery success: will the project delivery be successful? Essentially, this assesses the classic triangle of scope, time, and budget.

2) Product or service success: this refers to when the product or service is deemed successful (e.g. the system is used by all users in scope, up-time is 99.99%, customer satisfaction has increased by 25%, and operational costs have decreased by 15%).

3) Business success: this has to do with whether the product or service brings value to the overall organization, and how it contributes financially and/or strategically to the business’s success.

So what are you actually looking at?

This question I get asked a lot when I talk with prospects and new clients. And it is not so easy to explain. Reviews of large projects are a combination of art, science, and craft. But what really helped my clients to understand what was going to happen was the Project Review Model ™.

Just like the Project Success Model ™, the Project Review Model ™ is a conceptual model. Where a mental model captures ideas in a problem domain, a conceptual model represents 'concepts' and relationships between them.

The aim of a conceptual model is to express the meaning of terms and concepts used by domain experts to discuss the problem and to find the correct relationships between different concepts.

The Project Review Model ™ has twelve review areas that are all related to each other. Together these areas represent a project. You will find a more detailed description of the areas below. For now, the diagram is sufficient.

The Project Review Model

A serious project review means that you will look at each and every one of these areas and list Risks, Assumptions, Issues, and Decisions (RAID).

Risks are made up of two parts: the probability of something going wrong, and the negative consequences if it does, often called impact. Caution, risk is not the same as uncertainty. Risk and uncertainty are different terms, but most people think they are the same and ignore them. Managing risk is easier because you can identify risks and develop a response plan in advance based on your past experience. However, managing uncertainty is very difficult as previous information is not available, too many parameters are involved, and you cannot predict the outcome.

Assumptions are hypotheses about necessary conditions, both internal and external, identified in a design to ensure that the presumed cause-effect relationships function as expected and that planned activities will produce expected results. In other words, an assumption is an event, condition or fact that we need to happen or stay the same in order to assure project success.

Issues are a current problem – something that is happening now. Issues can be either something that was not predicted or a risk that has materialized. It can take the form of an unresolved decision, situation or problem that will significantly impact the project.

We could explain these terms with the following simple expressions

Risk: "What if?"
Assumption: "We need that it happens/stays this way".
Issue: "Oh, damn!".

If you have predicted the issue and treated it as a risk, you would already have a response plan, and the expression would be: "Hmm, that was to be expected. Let's handle it as discussed".

Even though risk, assumption, and issue have different definitions, they are deeply connected. An assumption might have a response plan if it doesn't happen or change, a risk will become an issue at the moment it happens, and an (unpredicted) issue must be included in the risk list once we identify it (and there is a chance that it will happen again).

Decisions have NOT been made until people know:

> the name of the person accountable for carrying it out;

> the deadline;

> the names of the people who will be affected by the decision and therefore have to know about, understand, and approve it—or at least not be strongly opposed to it; and     

> the names of the people who have to be informed of the decision, even if they are not directly affected by it.

An extraordinary number of organizational decisions run into trouble because these bases aren’t covered. The answers to these questions you should put in a list and act accordingly. It’s just as important to review decisions periodically—at a time that’s been agreed on in advance—as it is to make them carefully in the first place. That way, a poor decision can be corrected before it does real damage. These reviews can cover anything from the results to the assumptions underlying the decision. Such a review is especially important for the most crucial and most difficult of all decisions, the ones about hiring, firing and promoting people.

The secret to good RAID lists is to record the right risks, assumptions, issues, and decisions at the right level of detail. Too many and in too much detail simply create unnecessary bureaucracy. Too few in too little details do not provide actionable insights.

For example, I have often seen risk lists populated with boilerplate risks: these are generic project risks, such as 'we may not get sufficient executive sponsorship' which don't really add any insight to the project. If you genuinely think that is a risk, you are better off identifying the underlying reasons which might cause this, and then express the risk in those terms.

These four lists are the outcome of a project review based on the Project Review Model ™.

And these lists are the fundament of good decision making and proactive instead of reactive project management for any project.

The twelve Project Review Model ™ Areas

The areas you will need to review are:

1) Success: Understanding the project success criteria mentioned above. For a detailed guide on how to define and review project success see The Project Success Model ™.

2) Stakeholders: Understanding the project stakeholders, i.e. their desired outcomes and expectations.

Related articles:
3) Governance: Sponsors, steering committee, and controlling. How does it work in theory? How does it work in practice?

Related articles:

> How to establish an effective Steering Committee
The vital role of an Executive Project Sponsor and how to play it

4) Engineering: Is the system created through separate development? What about testing and product environments? Is there continuous integration? Bug reports? How is quality so far?

Related articles:

> How to review your team’s software development practices

5) Technology: Solution architecture, stable technologies, back-up, disaster recovery, and performance

> Stop wasting money on FOMO technology innovation projects
It's never too early to think about performance

6) Team: How is the project team working together? What is their capacity, collective skills, relationships, and project management methods?

Related articles:

> How to do a project delivery team review
How cloud computing is changing project management
Outsourcing technical competence is a very bad idea

7) Scope: Understanding when the project is “done.” Is it defined? At what level? Is it clear? Is there a change management process in place? What changes have taken place since the beginning?

8) Schedule: Is there a plan? Is it realistic? Are there contingencies? Have there been any significant changes to date?

Related articles:

Estimating with Wideband Delphi and Monte Carlo Simulation

9) Financials: Is there a clear overview of costs? Are these complete and correct? What about forecasts, budgeting, and controlling processes?

Related articles:

> The biggest mistake project managers make with project cost management

10) Impact: Who and what will be impacted when the project goes live? What changes need to take place to anticipate and respond to associated needs? How will the change be managed? How is it operationalized?

Related articles:

> Your (lack off) training efforts can easily ruin the outcome of an otherwise well-executed project
> How to champion your project

11) Risk: Assessment of (currently) identified risks, identification of new risks, and review mitigation actions in place.

Related articles:

Risk Management Is Project Management for Adults
> The Opposite of Risk Management is Crisis Management

12) Contracts: Review existing contractual obligations for all parties involved.

Related articles:

10 Important questions to ask before signing your cloud computing contract

Read more…