> 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.
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.
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.
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 ™.
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:
Related articles:
3) Governance: Sponsors, steering committee, and controlling. How does it work in theory? How does it work in practice?
> How to establish an effective Steering Committee
> The vital role of an Executive Project Sponsor and how to play it
Related articles:
> 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
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
> 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
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
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
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
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
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
Related articles:
> 10 Important questions to ask before signing your cloud computing contract