(Determine the appropriate project methodology/methods and practices.)
No Single Best Approach
There is no specific, best way of executing every project. If there were, it would likely have been automated by now and project managers made obsolete. However, because all projects are different (even building the same house in a new location will have new variables and likely stakeholders), we need to determine how to select the most appropriate execution strategy and approach.
The factors to evaluate include the type of work being undertaken, level of project uncertainty, complexity, stakeholder needs, and timelines, among other considerations. These project inputs, coupled with industry and organizational norms and goals, help us make informed recommendations for the project approach.
For the PMP® exam, candidates are expected to understand the characteristics of Traditional predictive approaches, Agile approaches and Hybrid approaches. Let’s recap the main characteristics again:
Traditional, Predictive Approaches
Traditional, predictive approaches (sometimes called Waterfall or plan-driven) are great for defined, repeatable projects. They can be planned in detail upfront and then executed by following this plan. The mantra “Plan the work, work the plan” captures the character of the approach well.
Until agile approaches started to gain traction in the 1990’s, most large-scale projects were executed using traditional, predictive, plan-driven approaches. Deliverables such as Gantt charts, network diagrams, work breakdown structures (WBS), and detailed specification documents are commonly associated with traditional, predictive approaches.
Agile Approaches
Agile approaches started in software development, although they drew inspiration from lean design and manufacturing. They work well when solving new problems with high rates of changes and uncertainty.
Agile approaches focus on communication and collaboration while they iteratively build, inspect and adapt. In doing so, they evolve towards an emergent solution that might not have been knowable at the start of the project. In other words, they adapt as they go, to meet unclear but emerging requirements.
These days, agile approaches are used on many knowledge work type projects that are characterized by high rates of change, complexity and uncertainty. The frequent review points, and redirection if necessary, allow teams to chase today’s “moving target” projects.
Hybrid Approaches
Hybrid approaches combine elements of both tradition and agile life cycles. So, for instance, a hybrid approach may still do a significant amount of upfront planning, but then execute iteratively, perhaps with iterations of one month in duration, which is much longer than the typical agile project.
An optimist might claim hybrids are the best of both worlds, while a pessimist complain they combine the worst of both approaches. The truth is probably somewhere in between, but because there is no single, standardized hybrid approach definition, usually all stakeholders need training coming up to speed with ‘the hybrid’ approach created for the project.
The Spectrum of Hybrids
Since hybrids are unique blends, they come in many varieties. On the spectrum from highly predictive to highly adaptive (Traditional to Agile) they occupy the entire middle ground. This means we can create hybrids that are close to traditional, predictive approaches – such as a traditional approach with a series of proof of concepts before committing to a single path. Or a hybrid that is very close to a pure agile approach, but with additional documentation, approvals and governance.
The selection and application of hybrid approaches is a large topic. If you would like to learn more, the following articles will be of help:
Predictive, Iterative, Incremental and Agile
Before describing different lifecycle models, first let’s define some terms:
Predictive – Traditional, do the bulk of the planning up-front, then operate in a single-pass, sequential process.
Iterative – approaches that allow feedback for unfinished work to improve and modify that work.
Incremental – approaches that provide finished deliverables that the customer may be able to use immediately.
Agile – approaches that are both iterative and incremental to refine work items. The teams gain early feedback on “slices” of the final solution that can be used to confirm if they are on the right track.
2.13.1 Assess Project Needs, Complexity and Magnitude
Understanding Work Types and Knowledge Work
The predominant form of work has evolved over time. Humans started out as nomadic hunter-gatherers, but mostly settled in static towns and villages when farming was adopted. The industrial revolution saw many people move from these farming communities into cities to work in factories. The last big shift in work patterns started in the 1960’s with the creation of knowledge work.
Knowledge work is any kind of work where subject matter experts collaborate to solve problems. This includes engineers, teachers, scientists, lawyers, doctors, software developers, researchers, marketing, HR and customer relations.
Since much of the industrial work has been automated, it is estimated 80% of employment in developed countries is knowledge work, or contains significant knowledge work components.
Industrial Work vs. Knowledge Work Differences
Unlike industrial work, knowledge work tends to be less defined and repeatable. It is concerned more with solving new, novel problems and manipulating information rather than raw materials.
For instance, designing a new music player involves studying customer demographics and usage scenarios. Then designing the product and software that runs it. Market testing and subsequent design revisions. There is a manufacturing process at the end of it, but the project lifecycle was mainly collaborative design and problem-solving.
Peter Drucker, the management guru who coined the term “Knowledge Worker”, used the following table to help people diagnose which types of projects we are dealing with.
If your projects have the characteristics listed on the left-hand side of the table, they are likely industrial-type projects. This is good news for reliable execution, traditional project management tools and techniques should serve you well.
If your projects look more like the items on the right-hand side, you are in the knowledge worker domain. You should probably move from industrial project management approaches and adopt knowledge worker ones. If you see elements from each column, you are in a hybrid environment and likely need to draw on a combination of approaches (hybrid) to be successful.
Drucker explained that many of our project management approaches are based on industrial-era work. They use concepts inspired by Fredrick Taylors Scientific Management approach that work well on large, complex, but defined projects.
Techniques like the progressive decomposition of work and detailed scheduling of tasks allows complex projects to be planned and managed. Techniques like work breakdown structures, network diagrams, and Gantt charts were taught to project managers to tame and track engineering work.
These techniques work well for tangible, stable and mostly predictable projects. As long as an organization has a history of building a similar product, then the gap to a new design or bigger scale can be reasonably estimated and planned for.
The Rise of Agile
Yet, difficulties occur when we try to use traditional approaches on intangible, unfamiliar, and new environments. Differences in understanding frequently occur when we lack physical reference points such as “I want a wooden door like this one, but a foot taller”. These differences result in more change requests, more reported defects, more uncertainties and risks.
In novel, intangible environments like software development, marketing or filmmaking things rarely progress predictably enough to follow the “Plan the work, work the plan” mantra of industrial projects. New technology evolution accelerates the rates of change. Demands to deliver faster worsen the situation.
This leaves a higher proportion of new projects developing largely invisible, intangible, difficult to reference, products and services – knowledge work.
Obviously, not all project work has changed. Just as we still have farmers, we still have traditional industry and industrial projects. However, the fastest-growing segment of work has changed. The increasing role of software in business also means a larger proportion of projects have at least some knowledge work component. So many industrial projects have a hybrid element.
Project Uncertainty
Project uncertainty occurs in multiple dimensions. There may be uncertainty around What exactly we are building (requirements uncertainty), or How is the best way to undertake it (technology uncertainty). A popular tool used for discussing these two dimensions is the Stacey Matrix, shown below.
Here we see Technology uncertainty on the X-axis, ranging from low uncertainty (we are close to certain about how to execute) all the way up to being far from certain. On the Y-axis we have Requirements uncertainty, again ranging from low uncertainty up to high.
The bottom-left, green square shows a simple project. It has low technology uncertainty and low requirements uncertainty. Building with familiar tools and techniques to a stable specification would be ranked in the green, “Simple” domain, using the Stacey Matrix.
Even large projects that are complicated by thousands of tasks may be tagged as “Simple” – according to this matrix. When uncertainty is low, it is safe and possible to create relatively stable upfront plans. Things may still change, but the rate of change will likely be manageable. Projects in this area are well served by Traditional/predictive life cycles.
In contrast, up in the top-right, projects with very high levels of uncertainty into what we are doing and how to accomplish it, are in the “Anarchy” zone. No process or life cycle will handle it well, actions need to be taken to reduce one or both of the sources of uncertainty.
In between “Simple” and “Anarchy” lies the land of “Complex” projects. They may be “Low Complexity” all the way up to almost Anarchy. This region is well served by iterative, incremental and agile life cycles. This is because they feature frequent feedback loops and adaptation of approach and process. They try something, evaluate it, carry on if it works and adapt if it does not. Using flexible plans such as easily reprioritized backlogs of work many mid-course adjustments are accommodated.
2.13.2 Recommend Project Execution Strategy
Recommend Project Execution Strategy (e.g. contracting, finance.)
Other factors that need to be considered when selecting a project life cycle include governance, culture, and team characteristics. The Agile Practice Guide that was bundled with the PMBOK Guide 6th Edition, contains an appendix on Agile Suitability Filter tools. These tools help assess which lifecycles are most appropriate given various circumstances.
The agile suitability filter tool in the Agile Practice Guide assesses factors such as the nature of the work being undertaken, the likelihood of changes, team access to business subject matter experts, organizational trust and buy-in, etc. Using a radar chart to plot a series of scores ranging from ideal-for-agile to ideal-for-predictive, the tool outputs a visual summary of fits and gaps for critical stakeholder discussion.
The image above shows a blank Agile Suitability Filter assessment sheet. It contains segments for Team characteristics, organizational Culture, and Project characteristics. Each segment contains three sub-categories measuring elements such as, in the Team segment, the team size, agile experience and access to business or customer representatives.
The radar chart is completed by answering questions about each of the 9 sub-domain topics. The questions are scored on a continuum from a good fit for agile to better suited for a plan-driven approach. Scores in the middle indicate a hybrid approach should be considered. In the image above, these continuums are depicted by the bars on the right-hand side of the radar chart.
The example shown below depicts possible scores for a website project.
In this website project example, the scores are clustered around the centre of the chart. This indicates the project is likely suitable for an agile approach.
The Project/Criticality score is in the Hybrid zone, indicating what is at stake might be higher than the validation/verification and documentation levels normally associated with agile approaches. This does not indicate that an agile approach cannot be used, instead perhaps additional rigor and checks-and-balances might be warranted.
The example shown below depicts the scores for building a new big-box super-store and getting it ready for opening.
In this example, the scores are all in the plan-driven zone. This indicates the project is likely a good fit for using a traditional, plan-driven approach.
Agile suitability filters are not definitive, instead they are just one tool that can be used to help have meaningful conversations with the interested stakeholders about approach selection. The radar chart creates a visual that people can focus on and hopefully have objective discussions around. There may be other factors such as regulatory standards or sponsor direction that over-rule the approach suggested.
The example plots above were clear-cut examples firmly in the agile and plan-driven domains. In practice, we often find spikes and lopsided plots that point to hybrid solutions.
For a full explanation of how to use agile suitability filters with three worked examples, see the additional chapter “Life Cycle Case Studies” (Pages 39 – 63) in the PM Illustrated book.
2.13.3 Recommend a Project Methodology/Approach
Recommend a project methodology/approach (i.e., predictive, hybrid, agile)
Once we have assessed the work type, project details, organizational culture, and team dynamics plus discussed all these elements with the relevant stakeholders it is time to decide.
Based on the assessments performed, expert judgment and stakeholder discussions a recommendation for the most appropriate approach should be made. The final decision may reside with the project manager, PMO, sponsor or even the team, this will vary from organization to organization. Once made, we still have some degrees of freedom, as outlined in the next section.
2.13.4 Use Iterative, Incremental Practices Throughout the Project Life Cycle
Use iterative, incremental practices throughout the project life cycle (e.g., lessons learned, stakeholder engagement, risk.)
Even if we are following a single-pass, plan-driven traditional approach, some things are progressively elaborated. This means we revisit and refine them as new information emerges. The concepts of progressive elaboration and rolling wave planning have been present in traditional, predictive project management guidance long before agile approaches became popular.
Event Cadence
Agile approaches create a regular schedule for reviewing, communicating and learning. By having short cycles for build, demo, review and reflect on progress the cadence and visibility of these activities is baked into the DNA of the project lifecycle. However, there is nothing to stop regular reviews, communications, and learning being scheduled on traditional or hybrid approach projects either.
Project managers using any life cycle can schedule regular inspect, review and improve events. They can also schedule demonstrations, proof of concepts and stakeholder feedback events. Just because the regular cadence of these events are not part of the life cycle should not prevent them being added if they would be valuable. (Tip – they are usually valuable.)
Scheduling regular team recognition events and celebrations help sustain enthusiasm and build momentum for pushing through or around roadblocks and obstacles. Saving project celebrations until the project is over and successfully delivered is a beginner-PM mistake. Yes, have one then too, but find ways to frequently recognize contributions and show appreciation. It does not show you are weak, is shows you are paying attention
On traditional projects, phase gates provide review points for accessing progress. There is nothing to stop us scheduling interim, internal reviews where we meet with the team to review progress and suggestions for improvements. It is normal to capture lessons learned at the end of the project, but there is no need to delay improvement ideas until then. Just as we communicate frequently throughout the project, so should we learn and improve also.
Deliverables and Tools
- Surveys
- Project Overview Statement
- Project business case / needs documents
- Project Implementation Plan
- Agile Practice Guidelines
- Agile Suitability Tools
- Expert Judgement
- Workshops
- Focus Groups
- Project Integration
Related Topics
- 1.6 Build a Team
- 1.8 Negotiate Project Agreements
- 1.10 Build a Shared Understanding
- 1.12 Define Team Ground Rules
- 1.13 Mentor Relevant Stakeholders
- 2.1 Execute Project with the urgency required to deliver business value
- 2.2 Manage Communications
- 2.3 Assess and Manage Risks
- 2.4 Engage Stakeholders
- 2.5 Plan and Manage Budget and Resources
- 2.9 Integrate Project Planning Activities
- 2.10 Manage Project Changes
- 2.11 Plan and Manage Procurement
- 2.14 Establish project governance structure
- 2.16 Ensure knowledge transfer for project continuity
- 3.1 Plan and manage project compliance
- 3.2 Evaluate and deliver project benefits and value
- 3.3 Evaluate and address external business environment changes for impact on scope
Further Reading
- Blog Post: Playing in the Grey of Hybrid
- Blog Post: Flavors of Hybrid Agile
- Blog Post: Post Industrial Project Management
- Blog Post: Mixing Life Cycle Models
- Blog Post: Agile Suitability Filters
- Book: PM Illustrated pages 39-63
Congratulations! You scored 100% and won the 2.13 Determine Project Apprach badge.