Conclusion – What Framework is Best for What Situation?
So, if we accept that there are two basic and different philosophical approaches to managing projects being defined: (1) the prescriptive or “push approach” of the PMBOK® Guide, and (2) the less formal “pull approach” of Agile methodologies – which approach is best in what situation? Based on what we’ve described so far –
Agile will be best when:
- Creativity is at a premium. (Perhaps we’re in a very competitive marketplace, or a very rapidly changing marketplace.)
- Requirements are undefined at the beginning. (The customer does not know what they really need, or only has a very high level definition.)
- There are very tight schedule constraints: we need to deliver a solution as quickly as possible, even if it does not have the full feature set.
The Prescriptive (Push) Approach of the PMBOK® Guide will be best when:
- The requirements are clearly defined up front, in the beginning – (Fixed Price Contracts)
- The requirements cannot change, and there are very tight constraints. (Also, often Fixed Price Contracts)
- Projects where we have to “get it right the first time.” (The devil is in the details.”) (For example, event planning – PMI’s project for the next Global Congress Meeting!) Perhaps projects dealing with crisis situations or emergencies.
- Large projects with geographically dispersed teams, many suppliers and many interdependencies.
- The cost of making changes will be prohibitive.
Also, I think the answer will really depend on how we want to plan for the end of the project: forecast the schedule, forecast the budget, handle risks and meet constraints!
Projects are almost always undertaken with some very difficult challenges defined at the very beginning! As project managers, we are never given all the time we would like to have for planning, we are never given all the money we think we need to do the project properly, and we are never given all the resources we would like to have. It’s quite the opposite. Most times, we are given some seemingly impossible constraints limiting the project.
It is very typical that we start a project with the following scenario: we meet with the sponsor – (product owner in APM) – to understand the business need for the project and why we’re doing the project, and this all gets articulated and defined in the project charter. Then the sponsor usually has some tough questions for us, and tough constraints that must be met. We are often asked something like, “Now you can get this project completed in nine months, yes? And, furthermore, it must not cost more than $500,000, – understood?” What is the right answer? Many project managers just take these marching orders in stride, and answer that they and their team will do their best to meet all these constraints! (We will be good soldiers, and put up a good fight even if the project is starting in critical condition – the dashboard is entirely “red flashing lights” – at the outset.)
But this is not only a bad idea for the PM and his or her team, (trying to do the impossible), it’s also not the right thing to tell the sponsor. Upper management really needs to really know if the project is in “critical condition” at the start. So, the right answer is, “I don’t know yet!” “I don’t know if we have the right resources, the right skill sets, and enough time to create the required products within this budget constraint. I’ll need to do a lot more detailed planning, and I’ll come back in a few weeks and let you know what we can get done in this timeframe for this amount of money.” That would really be the recommended approach as defined in the PMBOK® Guide. In order to do this, at minimum, we have to go through all the Scope planning processes, the Time Management planning processes and the Cost Management planning processes. (We really need to do all the planning processes in all knowledge areas to properly put together the three baselines!)
We will deal with this scenario in a very different way in APM. If we can develop our first iteration – (prototype) – within one month with a key set of core features, then we will have gone a long way to validate that we have the right skill sets, and that we can successfully pull this project off. Even when we have completely impractical constraints, APM may work better than trying to plan everything out in detail upfront to know whether or not we have what it takes to do the project. This is just another case where Pareto’s law comes into play. Often times, 80% of the customer’s true needs will come from 20% of the requirements. If we attack this vital set of requirements in the first few iterations, we will go a long way to validating the project. Also, oftentimes, after seeing the first few prototypes, the customer may realize that a number of the requirements they thought originally were absolutely necessary, are really not necessary at all and can be eliminated.
As Doug DeCarlo says, Agile methods and prototyping help us identify “Fast Failures.” We see very quickly what is not going to work, and what will not meet customer requirements. We don’t waste a lot of time and money planning and developing requirements that are not going to work. A classic cause of project failure, and even in a larger way – corporate failure – is that of “half-baked projects:” projects that are allowed to survive for too long and soak up valuable company resources that should have been eliminated early on in their lifecycle. APM could be integral in helping companies see what projects are “half-baked,” and not going to work.
So, we have two different approaches for dealing with the risks of “impossible projects” with “impossible constraints.”
Management also always wants to know at the beginning how long the project is going to take, and what it is going to cost. If we are in the “Fixed Price World,” doing a type of project that we have done many times before – (and this is a “cookie-cutter project”) – the requirements will be well known, and we can do a bottom-up estimate to get a very accurate budget and schedule. (This is not to say that this type of project will be easy. Quite the contrary, oftentimes there will be tremendous challenges in bringing diverse sets of resources together at the right time, for the right cost and in the right sequence. It could be one of those projects where the old saying of, “The Devil is in the details” truly applies!)
But Agile Project Management is most applicable where the requirements will be fluid, the customer does not know exactly what they want, and we will have to discover these requirements or let them emerge. So how do we predict the final schedule and budget in this uncertain world? It is very difficult. One of the main criticisms of APM is that it does not deal with these needed forecasts very well. We are going from the prior situation of having impossible constraints, and impossible plans, to having no plans at all! And this may be worse! (The team tells upper management that because things are so uncertain, they cannot make any predictions.) So, in APM, advanced techniques must be used to do release planning, and do the forecasts for the end of the project. Estimating the amount of work and time required for stories is still a necessity, estimating the number of stories for features is needed, and estimating the number of features that can be included in a release is needed. It is not an exact science in this world where there will be significant volatility with the requirements.
On the good side of things, we will be getting real feedback and results early on in the project with the first iterations. We will see how the estimates for these iterations worked out, and we can start to project the overall “velocity” for the entire project. To be able to use Earned Value Methodology, we do need detailed baselines defined at the beginning of the project that we will measure our performance against. With EVM, we can measure such things as CPI and SPI early in the project – (20% into the project) – and get an indicator if the project is in trouble. Similarly, in APM, the first iterations and prototypes are giving us a reality check on the project.