In the last post, “Are you guilty of the Project Big Reveal“, I covered what was meant by the term and the potential impact to you and the project. Understanding this is critical as the impact can be career threatening!
In this post I want to cover some of the strategies for avoiding this risk.
Overview of Risk
It is worth spending a moment reflecting on the general principle of the big reveal risk. It is the risk that the sponsor / stakeholder only gets visibility of the final deliverable at the very end and, it is not what was required meaning there is no time available to remediate (correct the deliverable). This means objectives have not been met (a big issue for projects with hard / mandatory dates), time and budget have been wasted.
Objectives of the Risk Mitigation
The mitigation needs to focus on reducing the risk by employing strategies that will ensure the deliverable is aligned to sponsor requirements and that any misalignment is identified early.
Risk Mitigation Strategies for Project Big Reveal
The following themes / concepts can be used:
Improved Communication
This is actually the answer to a lot of challenges so should apply to all of your project and management activities.
A key part of the risk is that the sponsor / stakeholders are not aware of what is being proposed. Therefore, it is important to establish a strong communication flow with the sponsor.
This can take many forms and more than one should be used:
- Regular 1:1
- Progress meetings
- Working groups / steering committees
- Status reporting (formal and informal)
The aim is to use regular communication to inform on progress and decisions so that the sponsor has a full understanding.
Requirement Walk Throughs
During the project lifecycle, the scope and objectives of the project will be captured, defined and then developed. Each step will involve expanding on the detail and understanding.
Therefore, walkthroughs should be held for each document on the journey. This will allow the sponsor to understand what is being proposed and to provide direction.
While this is more typical with business requirement documents, there is no reason that it cannot apply to charter, project management plan, functional design, test strategy, etc.
Proof of Concept
If you have the budget and time, using a proof of concept (PoC) will help eliminate the risk of the big reveal.
Essential a PoC means that the project develops enough of the functionality in order to:
- Validate the solution can work
- Demonstrate to the end user
This means that the project team can gain early feedback from the sponsor if the solution is aligned to their requirements.
Feedback from the PoC can then be taken and used to refine the final deliverables.
Pilot
A pilot is very similar to a PoC. However, the main difference is a PoC may only develop a subset of the functionality for validation purposes. Additionally a PoC may not be developed as a final solution that can be promoted into production.
A pilot will typically take the form of developing the complete solution for an agreed business area, function, location, etc.
The pilot is then executed a piece of work and then the final solution delivered. If successful the pilot is then rolled out to all other areas.
The risk is that there can still be a delay in the time the pilot takes to deliver. Therefore, this should be used in conjunction with communication and walkthrough strategies.
Agile
The Agile approach to delivery works on the premise of direct, ongoing engagement with the sponsor / users to shape the deliverables for each project sprint.
At the end of each sprint the deliverables are reviewed with the sponsor to ensure that they are complete and meet requirements. Therefore, any misalignment can be quickly identified.
Summary
There are many good tools available to project professionals to manage the risk of the “project big reveal”. Remembering to use a combination of these tools should help reduce the risk.
