The Project Management Institute Body of Knowledge (PMBOK® Guide ) and the Agile industry organisation define two very different ways of managing projects. This blog will focus on comparing their suggested project planning approaches. We focus on this comparison because there’s a misconception that the PMI approach is outdated and cumbersome, or conversely, that Agile guidelines dispense with planning, in a dangerous way. We will explore how their project planning guidelines compare, and what drives them to define planning, if at all?
PMBOK® Guide is compiled and managed by the Project Management Institute (PMI) industry association. The 5th edition of the PMBOK® Guide encompasses a total of 47 defined processes that are matrixed into 5 Process Groups and 10 Knowledge Areas. Planning is the largest of the defined 5 Process Groups, and alone, Planning contains 24 distinct planning processes. See the PMBOK® Guide 47 defined processes in Figure 1 below.
Figure 1 – Project Management Body of Knowledge (PMBOK® Guide ) Process Matrix
Agile, on the other hand, dictates “Working software over comprehensive documentation”, so are these Project Planning approaches tailored for their environments, or is there a trend behind there adoption rates?
So, we look to answer these two questions,
1. What project environment is well supported by the breadth and approach that PMBOK® Guide Project Planning defines?
2. When is the PMBOK® Guide framework not as suitable as other Planning approaches?
PMBOK® Guide Approach
The PMBOK® Guide Planning Process Group activities stretch from the broad statement of project scope, to detailed estimates and schedules for the tasks required to deliver that scope. The outcome of Planning Process Group is a baselined schedule containing every project task.
PMBOK® Guide 5th Edition supports overlapping Process Groups, so that it is common for the implementation of a project to start prior to the completion and base lining of a project schedule, but PMBOK® Guide advises that the project baseline is completed substantially before the core implementation has begun.
Because PMBOK® Guide stipulates that project planning should precede the implementation phase (albeit with minor overlapping allowed) the underlying assumption is that features are largely fixed and that change requests should be infrequent, because the “value” appraisal for the project output is well understood. The PMBOK® Guide planned project may be complex, with regards to numbers of tasks, but the stakeholders and the project customers have a shared appreciation of the value the project is delivering on. If customers of PMBOK® Guide projects didn’t have well understood project outcome valuations, customers would be unlikely to commit to large complex projects thousands of fixed requirements and features. Once a PMBOK® Guide project plan is produced, the project plan facilitates many of the project internal challenges such as project stakeholder management and project resource management. It is typically easier to convey the benefits of a large project when the details for the project cost, project schedule, and project outcomes, can be comprehensively conveyed. Examples where PMBOK® Guide Planning suits complex projects would be skyscrapers, luxury cruise liners, or housing estates with thousands of homes, and all of these require thousands of requirements and tasks that can be articulated across the whole project scope, in minute detail.
Software Projects
Software projects, in particular, have complexity because there are almost unlimited ways to architect and design a given solution. In many complex software projects, it is not uncommon for the solution developer to be unaware of the detailed designs that will eventually be deployed, due to the volume of custom design required to produce a solution.
In addition to the design challenges that developers have for a given solution, it is also very common for the complexity to mask customer usability issues. Complexity makes it difficult for a customer to envision the quality of an intended project, and it is frequently only after the customer has been given the opportunity to test an application in an authentic environment, can they offer valuable and relevant feedback. It is very cumbersome and commercially challenging for developers to create facsimiles of solutions in authentic environments, without actually going to the trouble of building the actual solution! When software projects are delivered in short iterative releases, customer value can be quickly assessed and rectified, if necessary.
This concept of short customer feedback iterations is one of the key drivers of “Customer Development” . Customer Development suggests that software vendors should plan incremental deliveries to customers, and use feedback from the deployments to tailor subsequent deliveries, with short turn-around time periods. This approach ensures that the subsequent solutions are built on top of software that has been tailored for customer value.
The Agile software development process is specifically geared to supporting incremental customer deliveries. Scrum, which is one of the most popular Agile frameworks (there are over 40 different Agile frameworks!), defines an iteration as a “Sprint”. Common Sprint iteration cycles are two to three weeks. Scrum also defines an explicit process for planning each Sprint, and planning the higher-level scope for a chain of Sprints. From experience, the success of each Sprint is proportional to the planning effort put into each Sprint plan, so although the Agile principle of “Working software over comprehensive documentation” puts emphasis on getting working software, the principle doesn’t imply that planning can be omitted.
Summary
We have seen that very large projects, requiring thousands of detailed tasks, are ably planned from beginning-to-end because there exists alignment between Stakeholders and customers on the outcome value. The alignment lessens the need to reconfirm value, through the likes of an iteration feedback loop. Planning projects in full detail and scope, from beginning-to-end, facilitates many internal project challenges, such as project stakeholder management and project resource management.
We’ve also seen there are projects that require more frequent alignment checks to ensure the vendor development is meeting customer value expectations. We have seen that complex software projects are examples of projects like these. The frequent checks are facilitated by iteration feedback, ensuring that customer value is maintained. Iteration feedback also lessens the likelihood that end-of-project customer reviews will highlight value issues with early project features. The cyclic feedback catches issues early, which leads to reduced project maintenance costs. Modern Customer Development movement is built on the belief that short iteration feedback delivers substantial commercial benefits for both customers and developers. This philosophy is gaining popularity amongst software product development teams because of the focus on delivering projects through flexible, quick-turnaround feedback cycles that continually reprioritise customer value.
My 30 years of product and project development has shown me that there are many ways to plan complex projects, but regardless of the project management framework chosen, all project require professional planning.
Author: Jim Blair, Aspira, Senior Consultant/Trainer.
The Project Management Book of Knowledge (PMBOK) is a registered trademark of the Project Management Institute, Inc.
The Project Management Professional (PMP) is a registered mark of the Project Management Institute, Inc.
