.jpg){kind=small}
Agile is not a Silver Bullet!
There are some projects which should not be done with Agile.
This Blog is on selecting the right Development approach and Project life cycle based on various project attributes. If you are a PMP aspirant, this blog will help you understand the Development approach and Life Cycle domain in PMBOK7.
I spend a reasonable amount of time explaining the Development approach and Project Life Cycle concepts in my PMP training. This helped me gain good insight into how to teach this topic to learners. I thought to consolidate those insights, sketches, examples, and notes I collected from various PMP reference books related to Development approaches (DA) and Project life cycles (PLC) and present them in this blog to contribute to the free high-quality PMP prep material ecosystem.
In this blog, you will learn the following PMP exam topics
1. Stacey Model
2. PLC and DA Suitability Assessment Chart
3. Linear and Complex projects
4. Project Life cycles
5. Development approaches
6. Difference between Development approaches and Project Life cycles
Let’s start with the million-dollar Question: When to apply Agile?
First, Agile is applied at two levels.
1. In the Development approach
2. At the Project Life cycle Level
Second, many project attributes decide whether we should go for Agile, Predictive, or Hybrid. The attributes are listed below.
Requirements uncertainty, Technology/Technical approach ( How to develop the solution), Team size and location, Leadership, and Organization Culture, Overall Project Risk exposure, Projects with safety and regulatory requirements, adapting products based on learning, project delivery options (single, multiple or periodic deliveries), and project benefit realization schemes ( value delivery)
From the factors mentioned above, Requirements uncertainty, Technology/Technical approach are crucial to deciding when to apply Agile. Stacey model is a famous tool used to determine if the given project is a good candidate for Predictive or Agile. The remaining elements listed above will be covered in this blog's inside suitability assessment chart section.
Stacey Model
Stacey Model is a powerful tool that helps us decide when to apply Agile and Predictive by knowing the level of uncertainty in project requirements and the Technology/Technical approach. The uncertainty levels of Requirements and Technology/Technical approach could be from low to high.
When we conceive a project, some let us go for complete upfront planning because of much clarity in the project and product requirements during the project initiation phase itself. Additionally, the Technical approach used to develop the product or solution is known to the Project Team, or know-how about the Technical approach is available in the market. An example of this type of project is the Construction of a House. It is possible to develop a clear project plan because the requirements will be almost available or known, and the technical approach to building a house is well-known—concrete, beams, column, etc.
In some projects, it is impossible to devise precise upfront planning due to much uncertainty in the product or solution requirements and technical approach. An example of this type of project is making a new animation movie using a breakthrough animation Technology that has never been tried before. Requirements tend to evolve and change during the movie-making process, and since the Technical approach used here is a new animation Technology, the Team has to go through a steep learning curve and needs to try, fail and learn to figure out things. Typically knowledge works like software application development, webpage development, marketing campaign, Research and Development work, movies, and novels are good candidates for the Agile approach.
So, should we need to use only Requirement and Technical uncertainty to decide whether to use Agile or Predictive?
Besides Requirements and Technical uncertainty, several other project attributes influence the proper development approach/project life cycle selection.
In PMI Agile practice guide’s Appendix X3, the Agile suitability filter Tool cover how to find out the suitable development approach/life cycle based on these project attributes. We are going to cover the Agile suitability filter here with more details.
According to PMI, there are nine project attributes under three main categories.
Three Categories
1. CULTURE
Agile is a mindset. Your organization should be supportive of agile practices. Your Management should see strategic alignment and business value following agile. Agile endorses self-organized empowered Teams. Command and control type Management style is not suitable for Agile. Agile approaches crave for Servant leadership style. Self-organizing teams are empowered to make local decisions and engage in participatory decision-making. We need to trust the team and let them make project decisions. Agile Teams thrive in a safe work environment where people can express their views without hesitation and try new things without fear of failure.
The three project attributes associated with Culture are
A. Trust in Team: Sponsors and business representatives’ confidence in the Team that they will accomplish the project objectives and offer them ongoing support and feedback.
B. Buy-in to Approach: Does the steering committee/PMO/Sponsor understand and support using the Agile approach? Otherwise, it isn’t easy to succeed
C. Decision-making powers of Team: Agile Teams should have the power to make local decisions. Three powers bestowed to Self-organizing Teams are Estimating the work, Work Assignments, and Team driving their improvements.
2. TEAM
The agile approach demands a high-performance Team. A Team of 3 to 9 highly skilled and motivated individuals are working in unison to accomplish a joint mission. Co-locations, Generalizing specialists, a high level of collaboration among the team members, Team working based on shared commitment rather than individual accomplishment are some of the traits of agile teams.
The three project attributes associated with Team are
A. Team Size: The optimal Team size for Agile projects is 7 ±2 ( According to PMI)
B. Experience Levels: It is acceptable to have Team members with a mix of experienced and inexperienced people. However, for every role, there should be at least one experienced Team member.
C. Access to the Customer/Business: Ongoing collaboration between the Team members and business representatives is critical for agile projects’ success. For example, in the Scrum framework, we have the Product Owner role, also called a business representative, customer, or proxy customer. The Product Owner and the Team should collaborate daily. Without customer or business access, the team can’t clarify their doubts about features, understand features priorities and business value, and get feedback on the implemented features.
3. PROJECT
Projects are undertaken to produce a product, service, or result. The nature of the product, service, or result we intend to create matters. Likelihood of change to Scope and requirement, Possible to do the project with a single delivery towards the end of the project or multiple deliveries periodically, and safety-critical products with mandatory compliance norms.
The three project attributes associated with Project are
a. Likelihood of change: In some projects, we must deal with a high rate of change to the requirement and scope. Requirement uncertainty and Scope instability could be high in some projects. Certain products or services have a high degree of innovation, or the Project Team does not have experience so the requirements will be progressively elaborated through learning, experiments, and feedback. Note: Stacey’s Model is based on the Likelihood of change in Requirement/Scope and Technical approach attributes alone.
b. Incremental Delivery: In some cases, we can go for multiple or periodic deliveries rather than single delivery to realize business values quickly and get customer/user feedback earlier. Incremental delivery has much to do with the Project life cycle and Development approach selection, and we will cover this aspect in detail later in this blog.
c. Safety-critical products: In some projects, we develop safety-critical products/services that demand thorough planning to reduce risks related to compliance. There will be a need for additional documentation and validation.
Decision-making process
Create a Questionnaire or survey to get scores for the above nine project attributes from the Team. Use the below table as a guide for scores. (Table created referring to PMI Agile Practice guide).
Follow a participatory decision-making process and reach a consensus. Involve all the relevant stakeholders in the survey or answer the Questionnaire to materialize the benefit of collective wisdom and to get stakeholders’ buy-in to the final decision.
The stakeholders shall rate all nine project attributes on a scale of 1 to 10 using the above table. As a group, discuss and agree on a score that most accurately reflects the subjective evaluation of the project attributes. If an agreement cannot be made on a score, do an open and honest discussion and, if needed, compromise.
Once the scores for each attribute are finalized, use the Radar chart for data representation.
Below is an example of a Suitability assessment survey favoring Agile approach selection.
The three concentric circles on the Radar chart represent the Agile, Hybrid, and Predictive zone. Getting the plotted graph inside a particular zone is not always possible. This Chart is just a decision-making tool. The group has to make the final call based on subjective evaluation.
Once the decision is made based on the Suitability assessment chart, it is time to apply it.
The possible decisions are Predictive, Agile, and Hybrid, and it is possible to apply the decision at two levels; At the Development approach and the Project Life cycle.
First, let’s start with Project Life cycles and Development approaches.
Project Life cycles and Development Approaches Overview.
According to PMI
Project life cycle. Describes the series of phases that a project passes through from its initiation to its closure.
Development Approach. Describes the means used to create and evolve the product, service, or result during the project life cycle.
To understand the relationship between Project life cycles and Development approaches, we need to understand the relationship between Project phases and Activities.
We know that projects are undertaken to create a unique product, service, or result. To produce the intended product or service, the project team has to produce many deliverables, culminating in the final product or service. Depending on the complexity of the final product or service, the project has to go through several phases, and each phase shall have many logical activities inside it.
Project Phase. A collection of logically related project activities culminate in completing one or more deliverables.
Activities: Work performed to produce the intended deliverable.
Phases are, in essence, small projects. Every phase has objectives, like projects, defined by the planned and agreed upon one or more phase deliverables. Even the phases have closure, just like projects, and the steps we follow to close the phases are the same as projects. For more details, refer to PMBOK 6 for the Close Project or Phase process.
And by definition, a Phase is a collection of logically related project activities. How the activities in a given phase will be planned, executed, and monitored & controlled is based on the attributes of that phase’s deliverable(s).
Then which way is better to carry out the activities inside the phases and produce the deliverables?
We can use Stacey’s Model or Suitability assessment radar chart to decide whether Predictive, Agile, or Hybrid is suitable for carrying out the activities and producing deliverables.
How we create or evolve, the planned deliverables of a phase is called the development approach. In other words, by PMI’s definition, the means used to create and evolve the product, service, or result during the project life cycle.
Project Life cycle
We know that phases are a collection of logically related project activities. Phases are created to manage large projects more efficiently by reducing overall project risk exposure and improving project governance. Simple projects don’t have phases. For large and complex projects, the activities are logically grouped as phases, and each phase shall have a Phase gate review; it’s a review done at the end of the phase to ensure whether the phase has produced the intended deliverable(s) and is it okay to start the successor phase or stay in the current phase or terminate the project.
The way phases are arranged in a project (sequential, overlapping, or parallel) and how deliverable(s) of a phase influence the next immediate phase, in other words, dependence between the phases, is called the Project Life cycle.
Again to decide which Project cycle life is suitable, the phase deliverables and dependency between the phases can be determined by applying Stacey’s Model or Suitability assessment radar chart.
You may get this Question. How can we use the same tools (Stacey’s Model or Suitability assessment radar chart) for the Development approach and project life cycle selection?
The answer is the development approach, and the project life cycle deals with similar entities.
Activity and Phase!
The Equation between Phase and Activity is
Phase = Collection of logically related activities.
We complete a few logically related activities to produce a deliverable. We produce a more significant deliverable to complete a phase if we complete many logically related activities.
The project life cycle is the way to deal with project phases based on the phases’ deliverables and dependency between phases.
The development approach is the way to deal with activities inside each phase based on the nature of the deliverable(s).
In project Management, Phase is the Big Brother of Activity.
Project Life cycle and Development approach selection is not the only place where phases and activities share the same way of doing things (Predictive, Agile, Hybrid). There are also other project management areas where they are handled very similarly.
Examples:
1. One of the Schedule Compression Techniques, Fast Tracking, can be applied at both Phase and activity levels.
2. Deliverable(s) produced by performing a few activities are formally accepted in the Validate Scope process. In the case of phases, the phase’s deliverable(s) are formally accepted in the Phase Gate review.
Types of Project Life cycles and Development Approaches
Both Project life cycles and Development approaches have the same types/classification.
Predictive, Hybrid, and Agile (Incremental, iterative, and adaptive).
Though the types of PLC and Development approaches are the same, it is better to discuss them separately to understand their significance.
Project Life cycle Types
Predictive Life Cycle
Also called Traditional, waterfall, Linear, or plan-driven. In Predictive, the project phases are organized in sequential or overlapping configurations.
A predictive life cycle is suitable when it is okay to produce and deliver the product, service, or result as a single delivery and where most of the planning can be done at the beginning of the project due to fixed requirements.
In Predictive Life Cycle, the relationship between the phases is hardwired, with Mandatory dependency between the predecessor and successor phases. In the above pictures, it is impossible to start the successor phase without completing the predecessor phase in Sequential and Overlapping. E.g., Without completing the concept development and Feasibility study phase, we cannot begin the Proof of concept phase. Each successor phase depends on the deliverables from its predecessor phase.
Predictive can have Phases arranged only in two ways: Sequential and overlapping.
In sequential, the predecessor phase should be completed with the phase gate to start the successor phase. Based on the phase gate outcome, the project gets the “Go" signal to start the next phase or complete the current phase, or sometimes the project will be terminated. You cannot begin the successor phase before closing the predecessor phase.
Overlapping phases is a way to compress the project schedule. The start date of the successor phase will be advanced concerning the end date of the predecessor activity. For example, implementation can be started for some of the designs completed in the Design Finalization and Validation phase. However, this approach has the risk of rework.
Benefit: Because the requirements are almost fixed, we plan almost everything once and do it in one go to better control project costs. For example, we complete everything related to Design in Design Finalization and Validation phase and move to the development.
There is less to no need to undo and redo things.
Demerits: This approach is more suitable for projects with stable requirements where the product to be delivered is fairly understood by the Project Team, thus incapable of adapting to changes.
Incremental Project Life cycle
Increment. A functional, tested and accepted deliverable that is a subset of the overall project outcome.
Incremental Life Cycle. An approach that provides finished deliverables that the customer may be able to use immediately.
Assume you are developing an online banking website for your client. This website is supposed to have the following features: Account summary, Money Transfer, Monthly statement, Secure login, and mobile notifications.
All of these features are independent. Isn’t it? So can’t we develop them individually, deliver them to the customer, and let the customer use the delivered features, and we can work on the other features?
Yes, we can.
These types of projects lend themselves to an Incremental Project life cycle.
In the Incremental Project life cycle, we will have multiple phases done in parallel, and the phases are independent. The deliverable of each phase is an increment, which means a potentially shippable product or service delivered to the customer.
The product is developed over a series of increments.
This is the very reason the Incremental life cycle has multiple deliveries. Each increment is a delivery. The culmination of all the increments constitutes the final product.
Online banking website = Account summary + Money Transfer + Monthly statement + Secure login + mobile notifications.
Benefits: Frequent smaller deliveries help to realize project benefits sooner and let the customer use the deliveries and provide us feedback. If resource allocation is not a constraint, the project can be completed quickly by conducting many phases in parallel. More suitable for large and complex projects and better equipped to handle requirement changes.
Iterative Life cycle
This life cycle is suitable for complicated projects where the requirement changes and can’t be derived without seeing the initial version of the product. We will start the project with little we know about the product or service and build it.
The first version of the product we built won’t be our final version, but we build it to learn more about the product through discoveries and failures and refine it. Once the first version is done, it will be reviewed by the customer and get feedback about the modifications, enhancements, and new features to be added to the product. The feedback and the learnings we got from previous version development shall help us progressively elaborate the product’s requirements and improve it in the next version. We repeat the same steps after building the next version. Version after version, the product will evolve and mature into the final one the customer wants.
The attempts we take to complete each improved version of the product or service are called Iteration; thus, this life cycle is called the Iterative project life cycle.
If each iteration has a considerable amount of work, then each iteration can be treated as a phase.
We iterate until we produce the final version of the product. The number of iterations needed depends on the complexity of the product, the efficacy of the Demos, and the feedback received.
Let’s take the below example. It took us six iterations to create the final version of the Blue Whale. We started every iteration with what we learned from the previous iteration’s feedback and continuously evolved the final version of the Blue Whale.
The Phases are sequential, and each phase helps us to get customer feedback about the product earlier. Though each phase produces a partial version of the final product, until we reach the last iteration, we can’t deliver the product or solution to the customer.
So unlike incremental, where multiple deliveries are possible, in an iterative life cycle, we do single delivery towards the end of the project.
Benefits: Helps to deal with complex projects with many unknown requirements at the beginning of the product and provides flexibility to adapt and evolve the product gradually.
Adaptive Project Life cycle
It is a combination of Incremental and Iterative Life Cycles.
Incremental has the benefit of managing large and complex projects in increments. An Iterative Product Life Cycle has the advantage of managing complicated projects, where the development of scope and requirement is difficult, by involving customers and getting their feedback to evolve the product iteration by iteration.
Adaptive uses both developing the Final solution in increments and getting customer feedback at the end of the phase to discover the unknown scope and requirements to improve the increments.
The Blue Whale art can be done using neither Incremental nor adaptive because we cannot split the final solution into small deliverables, i.e., increments. An increment is a potentially shippable deliverable. A portion (increment) of the Blue whale delivered is useless to customers.
How about the online banking website example we covered in the Incremental Project life cycle?
In the online banking website example, we assumed that the feature requirements were clear and decided to do each feature separately as a phase to produce increments of deliverables.
If the requirements of each feature are unclear and we need feedback from the Customer to elaborate the features’ requirements progressively, then the Adaptive is a more apt Project Life cycle for this project.
Benefit: Suitable for complex projects where the requirements are not unclear, so we can take the customer feedback after every iteration and improve the final result. At the same time, the project can be completed sooner by developing all the increment parallel.
Hybrid Project Life cycle
In some projects, some parts of the final solution, Features, or deliverables shall have well-defined and stable requirements, and others shall have uncertain requirements.
Suppose you choose a Predictive Project life cycle for such a project. In that case, the deliverables with stable requirements can be developed and delivered efficiently. Still, for the deliverables or features with uncertain requirements, predictive is not a suitable method as the requirements are unclear.
On the contrary, if you choose any Agile Project life cycle (Incremental, Iterative, or Adaptive), the deliverables or features with uncertain requirements can be developed and delivered efficiently. Still, the deliverables with stable requirements Agile Project life cycle is not suitable because we would end up doing a lot of unnecessary planning and reviews with the customer and attempting to deliver in increments. Moreover, if we try to deliver in increments, it makes no sense if the deliverable needs to be provided as a whole (not in increments).
A hybrid project life cycle is used when some parts of the project can be developed efficiently using a Predictive project life cycle because the requirements are stable, so upfront planning is possible. While the rest of the project can be developed efficiently using Agile project life cycles because the requirements are unclear, incremental deliveries will increase project success and reduce risk, and where customer feedback is essential for the progressive elaboration of requirements and scope.
Development Approaches
As already explained, Project life cycles are about project phases, their dependencies, and the attributes of the project deliverable(s).
Whereas the Development approach is about how we deal with project activities done to create and evolve the product, service, or result during the project life cycle.
Each phase is a group of logically related activities. They are performed to produce the phase deliverable(s).
This means how we deal with things inside a phase is about the development approach, and how we deal with the project phases (their setup and dependencies) is about the Project Life cycle.
For Example, you can have a project done using a Predictive Life Cycle. But the deliverable(s) of each phase can be developed using any suitable development approach based on the deliverable(s) attributes (Using the Stacey model or Suitability assessment chart).
If you haven’t noticed, I've used only the Predictive Development approach type phases in all the Pictorial illustrations for explaining Incremental, Iterative, and Adaptive Project Life cycles.
I did this to keep the explanation simple.
In all previous illustrations, each phase is made of the following steps.
To begin the Design activities, the Requirement analysis activities should have been completed (complete Predecessor to begin Successor activity). This applies to all other activities in the above diagram. This is linear, in other words, Predictive.
Is it always possible to have activities linearly done inside a phase? The answer is No.
Similar to complicated and complex projects, we have complicated and complex phases where the Predictive way of doing things won’t just work out.
In such cases, we must choose an Incremental, iterative, or adaptive development approach based on the nature of the phase deliverable(s), just like how we did in the project life cycle selection.
The project Life cycle and Development approach selection is independent of each other and based on the project and phase deliverable(s), respectively.
Look at the below Illustration. It’s a Project with a Predictive Life cycle with various development approaches in each phase.
Another illustration of an Adaptive Project life cycle with different development approaches in each phase.
The above are just two examples to show how Project life cycles and development approaches are applied. There is no limitation on choosing a development approach based on project life cycles.
The development approach is about how phase deliverable(s) are developed/evolved inside each phase by performing the phase activities. In contrast, the Project Life cycle is about how project outcomes are achieved (Product, service, or result) through a series of phases from start to end.
Types of Development Approaches
1. Predictive Development approach: Same as Predictive project Life cycle. When we have less uncertainty in the requirement and the approach to developing the solution is clear, choose the predictive Development approach for such a phase. First, we plan and then execute the activities to produce the phase deliverable(s).
Predictive is also called a Plan-driven, Traditional, Waterfall, or Linear development approach.
2. Agile Development approach: By definition, agile is a mindset. Regarding development approaches, we use agile when deliverable(s) are complicated or complex. We have requirement uncertainty or unclear how to develop the solution or both. Iterative, Incremental, and Adaptive are the three Agile Development approaches. Sometimes Adaptive is also referred to as the Agile Development approach.
3. Hybrid Development approach: We should not try to develop a part of a phase’s deliverable or result whose requirements and solution approach are clear using Agile. Conversely, we should not try to develop a part of a phase’s deliverable or result whose requirements and solution approach are unclear using Predictive. We often end up in situations like this in project management, and in such incidents, we use a Hybrid development approach.
Example: Mobile phone development.
The Mechanical and Electrical components of the product can be developed using Predictive because it is possible to come up with clear requirements for these components at the beginning of the project or phase. Also, changing these components after or during implementation will produce much physical waste. This will increase the project cost, so Mechanical and Electrical components should be developed using predictive.
Whereas the software component like the Mobile OS and Apps can be developed using an Agile approach. Software development is knowledge work, and in most cases, it begins with unclear requirements or less clarity on how to develop the solution or both. Moreover, software development does not produce any physical waste if we do and redo things. Of course, time is lost during the do-redo process, but it’s better than producing something the customer doesn’t want or won’t use.
Remember, in Hybrid, we apply agile and predictive Development approaches inside a single phase. At the same time, at the lowest level, an activity is either done in Agile or Predictive. And because it is hybrid, you cannot perform a given activity using both predictive and agile approaches; this is invalid.
Related Terms and their definitions from PMBOK
Agile. A term used to describe a mindset of values and principles as set forth in the Agile Manifesto.
Hybrid Approach. A combination of two or more agile and non-agile elements, having a non-agile end result.
Predictive Approach. An approach to work management that utilizes a work plan and management of that work plan throughout the life cycle of a project.
Project Phase. A collection of logically related project activities that culminates in the completion of one or more deliverables.
Life Cycle. The process through which a product is imagined, created, and put into use.
Iteration. A time-boxed cycle of development on a product or deliverable in which all of the work that is needed to deliver value is performed.
Increment. A functional, tested, and accepted deliverable that is a subset of the overall project outcome.
Project life cycle. Describes the series of phases that a project passes through from its initiation to its closure.
Predictive Life Cycle. A more traditional approach, with the bulk of planning occurring up-front, then executing in a single pass; a sequential process.
Incremental Life Cycle. An approach that provides finished deliverables that the customer may be able to use immediately.
Iterative Life Cycle. An approach that allows feedback for unfinished work to improve and modify that work.
Agile Life Cycle. An approach that is both iterative and incremental to refine work items and deliver frequently.
I hope this article helped you in making your understanding better of when to apply agile, Stacey Matrix, Suitable assessment, and topics related to the Development approach and Life Cycle Performance domain in PMBOK7.
If you’re a PMP exam aspirant, remember, “VICTORY LOVES PREPARATION.”
And Kudos! You’re doing the right thing.
Happy learning!
Please let us know your feedback. Kindly drop them in the comment section below.
References and citations
1. A guide to the project management body of knowledge (PMBOK guide) / Project Management Institute – the 6th Edition.
2. A guide to the project management body of knowledge (PMBOK guide) / Project Management Institute – the 7th Edition.
3. Agile Practice Guide - Project Management Institute
4. Effective Project Management - Traditional, Agile, Extreme, Hybrid, 8th Edition by Robert K. Wysocki
5. Lesson 2: Starting the Project, Topic: Determine Appropriate Project Methodology
Methods and Practices - PMI Authorized PMP Exam Prep Training Material
6. PMI LO choice Spotlight Video – When to apply Agile.
© 2022 by EZBRAIN EDUTECH PRIVATE LIMITED. All rights reserved.
Copyright and License to use
This blog is the intellectual property of Ezbrain Edutech Private Limited. Readers can use it for their individual learning needs and share it with others for personal use. It is prohibited for other companies and legal entities who intend to use this blog for training purposes or to benefit themselves, their clients, and customers in any possible way. To republish or reproduce our content, you must obtain our written permission.
Disclaimer
The views, facts, and opinions expressed in this blog are based on the author's professional experience, beliefs, and facts collected from reference materials mentioned under References and citations. We did our best to ensure the content's correctness to make it reliable. Learnings from this blog help the learners, in general; however, we neither guarantee this blog will make the learners clear any project management certification exam nor its correctness. We are not liable for any consequence of applying this blog's learnings and advise readers to do things at their discretion.