Uncertain projects are notoriously difficult to manage. Ambiguous projects are deemed impossible to plan. Early stage innovation projects are uncertain and full of ambiguity. So how do you plan and manage that in your innovation project?
When planning for an innovation project, you basically have three options, Waterfall, Agile, and Discovery-Driven planning.
Three project management options
There are three different approaches to go about project planning:
- Waterfall project management - which is time-based
- Agile project management - with is task or scope based
- Discovery-driven planning - which is assumptions based
Waterfall and Agile planning methodologies are most common. The Project Management Institute is a great resource for both.
Below is a short explanation of each.
Waterfall project management
Through my job as a process-engineer by Fluor, I am very familiar with the waterfall project management approach. For their projects, project planners would create detailed planning forecast to make sure that as per contract -for example, a billion dollar investment in a new Liquefied Nitrogen Gas Plant - this new plant would deliver within specifications, 5 years later, at the planned date.
Such project planning was possible, not in the least because Fluor had built several of these plants before. Expectations at the management level were clear, all parties involved knew exactly what had to be built. In addition, all team members had a good idea of what was coming, what tasks had to be performed to get there, how long these tasks would take on average, and what the dependencies between the tasks were, and where things could become tricky - from a scheduling perspective.
In that scenario, waterfall project management works great. The waterfall method is for when you know what you are planning, which usually is the case when you have done a similar project before.
Using waterfall planning for uncertain projects gives people a false sense of security. With dates, actions, and dependencies all laid out in a simplified overview, it makes it look like that the team knows what they are doing. While in reality, the plan is based on untested assumptions and guesswork.
Agile project management
Agile methodologies use a more incremental approach to plan for a project.
Instead of fixing the requirements beforehand, Agile project management uses short sprints to manage time and cost. Each sprint aims to deliver a specific piece of scope, as an effort to control requirements.
In these sprints, a specific task is addressed and resolved. Daily collaborative meetings, a prioritized product backlog, and frequent feedback cycles are used to accomplish the task at hand.
The involvement of the business throughout the project is critical. Agile project management relies heavily on the collaboration between the team and the customer to create the right product in a lean fashion.
Agile project management has its origin in information technology. Waterfall planning is ineffective for the management of software projects. As often in these projects, the scope keeps changing as the project progresses, because clients only realized what they really want when they see what is being built. The waterfall approach means that keeping up with all changes results in a non-stop battle about scope, time-lines, and scope changes. Conflicts that only delay these software projects further.
Agile project planning works especially well in these situations, as it is relatively easy to define small (sub) tasks that can be developed and created independently when creating new software. For the development of complex physical products, that cannot be modularized, agile project management is challenging to apply.
Discovery-driven planning a planning technique first introduced in a Harvard Business Review article by Rita Gunther McGrath and Ian C. MacMillan in 1995. It has become popular as part of the lean-startup methodology.
For Waterfall planning, the correctness of a plan is generally judged by how close outcomes come to projections. Discovery-driven planning assumes that the parameters will change as new information is revealed.
With Waterfall planning, it is considered appropriate to fund the entire project up front, as the expectation is that one can predict a positive outcome. In discovery-driven planning, funds are released based on the accomplishment of key milestones or checkpoints, at which point additional funding can be made available predicated on reasonable expectations for future success.
A discovery-driven plan incorporates five disciplines or plan elements:
- Definition of success for the plan or initiative, including a "reverse" income statement
- Benchmarking against market and competitive parameters
- Specification of operational requirements
- Documentation of assumptions
- Specification of key checkpoints
Using discovery-driven planning, it is possible to iterate and allows experimentation at lowest possible cost. The methodology is consistent with the application of real options reasoning to business planning, in which ventures are considered "real" options. A real option is a small investment made today which buys the right, but not the obligation to make further investments.
Which approach to use when?
To know which approach to know when, we need to better specify what uncertainty and ambiguity mean that plague the planning of innovation projects.
Uncertainty can mean variations of known patterns. Such as when building a new house. Unexpected things can and will happen, but since many houses have already been build you can predict with some certainty timelines and outcomes, and then add some contingency to give you a bit of flexibility when things go differently than expected.
Foreseen uncertainty is similar as the above, but then with events in there that can derail your plan. Like bad weather on a vacation trip. You know the weather can be bad, weather reports can predict the likelihood that it will rain, and you can plan and adjust your plans accordingly.
Unforeseen uncertainty occurs when you don't know what may happen or hit you during your project.
This happens a lot with information technology projects when bugs occur. You don't know when a bug will happen, what the bug will be, or how to mitigate them beforehand. In spite of the best software development practices, bugs will occur.
You will deal with each bug when they happen. Unlike the weather, there are no reliable predictions about where bugs will happen, when, and in what form they will occur.
The term chaos is used in the article to describe ambiguity and the situation in which you don't know what you don't know. Which is basically the case with most innovation projects that aim to develop novel products and services.
You know that the client has a certain problem, as that is something you can figure out and test. But you don't know if they will like the solution that you have in mind, nor do you know if this solution will actually works and delivers as expected.
In other words, chaos is when you are learning by doing and with each step you learn more and are better able to define what comes next.
Planning for uncertainty
The chart below gives an overview of the implications of these types of uncertainty on project planning in terms of the project managers role, how you manage tasks, and how to manage relationships. Underneath this overview is a table that explains which planning approach works best for which type of uncertainty.
Source: MIT Sloan management review
|Uncertainty||Chaos, unforeseen uncertainty||Unforeseen uncertainty||Variation, foreseen uncertainty|
|Customer involvement||Customer feedback is used to guide decision making.||Frequent feedback from customers is sought throughout the project.||Customer involvement is required at major milestones only.|
|Prioritization||The most uncertain and critical assumptions are tested first, to make sure the project is actually feasible. The risk of failure is embraced, by focusing on those assumptions that must come true, for the project to succeed.||The most valuable and critical tasks are worked on first. The goal is to make sure that the project does not waste unnecessary resources on matters that may change or on a project that turns out to be unfeasible. In sum, the risk of complete failure is decreased by allowing partial success.||Do everything as agreed upon approach ensures that everything gets done as requested or envisioned at the start of the project. When things go as planned, it ensures everything is accounted for. When things don’t go as plan, this all or nothing approach increases the risk of total failure.|
|Team||Small teams that take ownership of the process and that are empowered to reach out to potential customers to test the most critical assumptions.||Small, dedicated teams with changing composition depending on the task at hand. A high degree of coordination and alignment is part of the process.||Team coordination and alignment is limited to hand-off points. Reduction of dependencies is part of the process.|
|Funding||Designed to be used with a milestone-based budget, in which teams are funded per milestone. Difficult to manage with a fixed budget, as for the full project, scope and budget requirements are guesswork.||Can be used with a milestone-based budget, in which teams are funded per sprint. Difficult to manage with a fixed budget, as the scope is expected to change.||Works well with a fixed budget. That is, with an agreement upfront on what the team is expected to deliver, when, and for which amount.|
Applying the right project management approach for your innovation project matters. Pick the right approach given the uncertainty your face and then apply to correct methodology and tactics in term of the project manager's role, how you manage tasks and stakeholders. As it defines how you engage with customers, prioritize tasks, build your team, and obtain funding. In other words, the success of your innovation project depends on choosing the right project management approach!
At Organizing4Innovation, we help our team apply Discovery Driven planning for early-stage innovation teams and Agile project when they are in the development phase, as that typically works best for the innovation teams we work with.