One of the most important decisions you will make on any project is what development approach you will take, what methodology you will base it on, and how you will structure your Project Life Cycle.
‘Wait a minute! Isn’t this “Tailoring”. Didn’t you do an article about tailoring recently?’
Good question.
Yes, we did do an article about tailoring recently: ‘Tailoring: How to Determine Appropriate Project Methodology, Methods, and Practices’. But tailoring is a wider concept. Tailoring covers the:
- Approach
- Lifecycle
- Processes
- Governance
- Tools
- Methods
- Artifacts
- …indeed any choice you make about how to deliver your project.
So, this Project Domain is just one of 8 domains… that you need to tailor to meet the needs of your project, the culture of your organization, the people on your team, and the wider politics of the stakeholder landscape.
That said, this is the one out of the 8 Project Performance Domains in the 7th edition of the PMBOK Guide that has the biggest part to play in your tailoring decisions.
Structure of this Article
This is the third of our series of eight articles, covering the eight Project Performance Domains of PMI’s Guide to the Project Management Body of Knowledge, 7th Edition (PMBOK 7). For a general introduction to these domains, check out our article, Project Performance Domains: Do You Know What they Are and Why they Matter?
For more on the PMBOK Guide, 7th Edition:
- Our article: PMBOK Guide 7th Edition: Your 20 Most Important Questions Answered
- Interview with one of the authors: PMBOK 7: 7th Edition of the PMI’s Guide to the Project Management Body of Knowledge – with Nader Rad
- Buy your copy of PMBOK 7.
In this article, we will examine:
- What is the Development Approach and Life Cycle Performance Domain?
- PMI’s Description of the Components of the Development Approach and Life Cycle Performance Domain
- Critical Evaluation of the Development Approach and Life Cycle Domain
- What Else We Should Include in the Development Approach and Life Cycle Performance Domain?
- How the Development Approach and Life Cycle Performance Domain Relates to the other Project Management Domains
What is the Development Approach and Life Cycle Domain?
The Development Approach and Lifecycle Performance Domain is all about the ‘big picture’ of how you deliver a project:
- The type of methodology you select
But not the specific methodology you’ll use, nor the adaptations you make - The general rhythm (or ‘cadence’) of major events
But not the day-to-day scheduling of activities - The broad stages or phases within your project
What each stage will focus on and how you will sequence them in time
The PMBOK Definition of the Development Approach and Life Cycle Performance Domain
PMBOK 7 defines this performance domain this way:
‘The Development Approach and Life Cycle Performance Domain addresses activities and functions associated with the development approach, cadence, and life cycle phases of the project.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
I think you will agree that this ‘definition’ is little more than a slight expansion of the title. So, how would I expand it?
Our Expanded Definition of the Development Approach and Life Cycle Performance Domain
I am going to suggest a contracted, rather than expanded definition. That is, I will use fewer words. However, crucially, this definition does imply an expanded range of concerns for the Performance Domain, which I would like to see in future editions of the PMBOK Guide. Always assuming, that is, that future definitions retain the same basic performance domain structure.
‘The Development Approach and Life Cycle Performance Domain addresses the strategic approach to delivering the project.’
Dr Mike Clayton, 2022
This ‘strategic approach’ takes in, of course:
- development approach
- cadence
- life cycle phases
But, it also includes two big items that I think are missing from the performance domain as PMBOK 7 articulates it. I’ll look at them later, in more detail, but these are:
- Governance and governance structures
- Procurement and sourcing
The Expected Outcomes for the Development Approach and Life Cycle Performance Domain
PMBOK 7 goes on to define the domain in terms of three desired outcomes, which demonstrate that the project team has executed it effectively:
- Development approaches that are consistent with project deliverables
- A project life cycle consisting of phases that connect the delivery of business and stakeholder value from the beginning to the end of the project.
- A project life cycle consisting of phases that facilitate the delivery cadence and development approach required to produce the project deliverables
Let’s take a look at these in turn.
Development Approaches
Of course, you couldn’t argue with the assertion that development approaches need to be consistent with project deliverables. But they also need to be consistent with the political environment and the skills of the team.
I would agree that, in an ideal world, the team would have the skills to work with the best development approach for the job. And I will also concede that, ideally, the political environment will allow the selection of the best development approach for the job. But we don’t live in an ideal world. Project Managers need to be pragmatists, skilled at the craft of ‘make-do and mend’.
So, I am happy with this as long as we recognize that the words say ‘are consistent with’ and not ‘are optimized to’. I choose to think that the authors have been very careful with their wording here.
Project Life Cycle Phases and the Delivery of Value
First, I’ll take the opportunity to note that PMI has chosen the word ‘phases’ – as it did in previous editions. Indeed, the definition in PMBOK 7 matches that of its predecessor, PMBOK 6.
You can consider this usage as interchangeable with the stages. Phases is probably the more common term:
- Association for Project Management: ‘Phases‘
- International Association of Project Managers: ‘Phases’
- International Project Management Association: ‘Phases’ and ‘Stages’
- PRINCE2: ‘Stages’
There is nothing wrong with this desired outcome. It just feels a bit… obvious. However, as part of PMBOK 7’s move towards a focus on value, I cheer it.
By the way, you may like our article, The Project Lifecycle and Four Essential Stages.
Project Life Cycle Phases that Facilitate the Delivery Cadence and Development Approach to produce the Project Deliverables
Is this not somewhat subsidiary to the previous desired outcome. To the extent that deliverables drive realization of value, this is redundant. To the degree that deliverables are unrelated to the delivery of value, then who cares about them.
Verifying the Outcomes from the Development Approach and Life Cycle Performance Domain
For each domain, PMBOK 7 also sets out ‘checks’ by which we can assess project performance against each of the outcomes for the performance domain.
My discontent with the desired outcomes of this project performance domain in PMBOK 7 is exacerbated by my outright frustration with the checks here. I applaud the desire to create a set of checks. But these are nothing more than restatements of the outcomes. If you get the outcome, then ‘check satisfied’.
I would interpret these checks in my own words. But, for the first two, they add nothing at all to the outcome statement, except a few more words. However, let’s look at the third.
Project Life Cycle Phases that Facilitate the Delivery Cadence and Development Approach to produce the Project Deliverables
This one does add value, because it acknowledges that different deliverables can have different delivery cadences and development methods. These may need cycles or overlapping phases. However, the text of the check does not represent a clear guide to ‘how to check’ that you have the desired outcome.
Important Definitions within the Development Approach and Life Cycle Performance Domain
In the introduction to the Development Approach and Life Cycle Performance Domain, PMBOK 7 highlights (in a box), five key definitions of jargon terms:
Let’s look at them in the order PMBOK 7 presents them, starting with the odd one out, because it’s not the subject of the domain.
Definition of Deliverable
‘Deliverable. Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
This is a good, if somewhat wordy, definition. My own is:
‘The things our project produces are called deliverables or products. They are sometimes also called outputs and are the physical or intellectual things the project produces.’
Be on the Inside: Decode the Jargon of Project Management, 2nd edition
Mike Clayton, OnlinePMCourses
Interestingly, the APM’s Body of Knowledge, the APMBoK 7th edition, does not include ‘deliverable’ in its glossary. And PRINCE2 takes a rather different approach, which is interesting to me. Firstly, it uses the term output and sends the user to that definition from the entry ‘deliverable’ in the glossary.
‘Output. A specialist product that is handed over to a user (or users).
Managing Successful Projects with PRINCE2
Note that management products are not outputs but are created solely for the purpose of controlling the project.’
Axelos limited, 2017
Here, the PRINCE2 definition distinguishes between ‘end deliverables’, which it calls ‘outputs’, and ‘interim deliverables’, which it calls ‘management products’.
Definition of Development Approach
The PMBOK Guide offers us this simple definition, which also includes its own examples.
‘Development Approach. A method used to create and evolve the product, service, or result during the project life cycle, such as a predictive, iterative, incremental, adaptive, or hybrid method.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
The Association for Project Management refers to the development approach either simply as ‘approach’ or, more grandly, as ‘philosophies for deployment’. It has no definition in its glossary. And, neither do I.
Definition of Cadence
The PMBOK 7 definition is admirably concise, and I have nothing to add.
‘Cadence. The rhythm of activities conducted through the project.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
Definition of Project Phase
I like the PMBOK definition of Project Phase:
‘Project Phase. A collection of logically related project activities that culminates in the completion of one or more deliverables.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
Picking up from my comment about the PRINCE2 definition of output/deliverable, the deliverables here can be end-deliverables or interim deliverables, like a project definition statement, a business case, a project plan, or a report on prototype testing.
My own definition is focused more on the purpose than the nature of project phases:
‘Projects are divided into stages, or phases to help us manage them.’
Be on the Inside: Decode the Jargon of Project Management, 2nd edition
Mike Clayton, OnlinePMCourses
And the APM offers us the most admirably concise definition, in its APMBoK 7th edition.
‘Phase. The major subdivision of a lifecycle’
APM Body of Knowledge, 7th Edition
Association for Project Management, 2019
I am bound to say that, against all of these, the definition in the PRINCE2 documentation of a Management Stage (its equivalent term) is clunky in the extreme. What is adds is the opportunity for the Project Board to review progress, risks, and the plan at the end of the stage. This paves the way towards PRINCE2’s gateway review process (Stage Gates), which I’ll return to, below.
Definition of Project Life Cycle
The final definition that PMBOK 7 offers is that of the Project Life cycle.
‘Project Life Cycle. The series of phases that a project passes through from its start to its completion.’
A Guide to the Project Management Body of Knowledge, 7th Edition
Project Management Institute, 2021
I cannot argue with that definition. Indeed, my own is very similar:
‘Life Cycle. The series of stages that from the start to the close of a project.’
Be on the Inside: Decode the Jargon of Project Management, 2nd edition
Mike Clayton, OnlinePMCourses
And, whilst the PRINCE2 book disdains from offering a definition, the APM makes up for it with the most wordy version by far!
‘Life Cycle. A framework comprising a set of distinct high-level stages required to transform an idea of concept into reality in an orderly and efficient manner. Life cycles offer a systematic and organized way to undertake project-based work and can be viewed as the structure underpinning deployment.’
APM Body of Knowledge, 7th Edition
Association for Project Management, 2019
Phew! And I am not convinced any of those 45 words add anything to our understanding.
PMI’s Description of the Components of the Development Approach and Life Cycle Performance Domain
After a three-line introductory subsection that states the obvious, we have subsections on:
- Delivery Cadence
- Development Approaches
- Considerations for Selecting a Development Approach
- Life Cycle and Phase Definition
- Aligning of Delivery Cadence, Development Approach, and Life Cycle
I can’t (for reasons of fairness and copyright) share too much of the detail of these sub-sections, but let’s look at a high-level summary of each.
Delivery Cadence
This offers four types of delivery cadence. However, rather bizarrely, the last (continuous delivery) is relegated to a box that makes it seem less important. It is not. The four types are:
- Single delivery
Sometimes referred to a the ‘big bang’ approach of delivering everything at a single handover event - Multiple deliveries
As it sounds. PMBOK offers a couple of examples of where delivery might be chunked into a series individual deliveries - Periodic deliveries
Where multiple deliveries follow a regular pattern of releases - Continuous delivery
Constant delivery of incremental improvements of additions. This is comment in DevOps (Development Operations)
Development Approaches
In my view:
‘All project management is hybrid project management.’
But there is a spectrum of approaches from predictive to adaptive, and we can call upon tools, methods, and structures from either end of the spectrum to create the hybrid that suits us. Yes, your development approach may sit right at one end. But I defy you to do a project where there is no tool, method, idea, or artifact that someone would not consider as sitting at the opposite end of that spectrum.
PMBOK 7 describes and illustrates with a simple case study style of example the:
- Predictive Approach
- Hybrid Approach
…with a reasonable (but somewhat lacking) diagram to explain the terms ‘iterative’ and ‘incremental’ - Adaptive Approach
Hold-up! What do you mean ‘somewhat lacking’?
What the PMBOK Guide omits is the one thing that is essential to iteration. This is that it takes the output of one iteration as an input to the next.
Want to know more about these three Development Approaches?
Take a look at our articles:
- Agile vs Waterfall: Which one is Right for Your Project?
- Hybrid Project Management: What You Need to Know
Considerations for Selecting a Development Approach
This section offers us a series of three good lists of things to take into consideration when selecting your development approach. These lists are:
- Product, Service, or Result considerations
- Project Considerations
- Organizational considerations
I think PMI would consider it unreasonable for me to offer you even the one-worders for these paragraphs. However, I can offer you my own lists, which are, happily, more comprehensive and include items the authors seem to have omitted.
The Deliverables
- Scale
- Confidence in the brief
- Innovation vs repetition
- Complexity
- Strategic priority and value
- Volatility of requirements/scope
- Ease of making changes
- Quality and regulatory standards
- Risks
- Health and Safety requirements
- Security requirements
- Competitive pressures
The Project
- Scheduling constraints
- Resourcing constraints
- Funding constraints
- External dependencies
- Governance requirements
- Team structure and location
- Stakeholder needs, priorities, preferences, and attitudes
The Organization
- Structure and governance processes
- Policies – particularly…
- Procurement policies
- Culture
- Capability
- Capacity
- Politics and political pressures
- Geographical structure
Life Cycle and Phase Definition
Here, the PMBOK Guide offers us a couple of examples of predictive life cycle phases, alongside a hybrid version, with cycles within a wider linear structure. There is also an illustration of iterations in an adaptive development approach. All in all, there is not a lot in this subsection.
Aligning of Delivery Cadence, Development Approach, and Life Cycle
This part refers back to the running mini case study of the subsection on development approaches, showing how different deliverables each need their own delivery cadence and development approach. It follows this with yet another example delivery approach, within each stage of which there is a short discussion of cadence.
Critical Evaluation of the Development Approach and Life Cycle Domain
I’m going to evaluate each of the eight Project Performance Domains in the 7th edition of the PMBOK Guide on a 5-point scale of:
- Lacking
Little more than a passing mention of what’s important - Poor
A lot of work needed - Okay
Needs Significant work - Good
Would be great but minor tweaks needed - Excellent
Everything I could wish it to be
I am really struggling here. Part of me wants to score this project performance domain as a 3, ‘Okay’. But, in truth, I think the evidence points to a score of 2, ‘Poor’.
My reasons are in the paragraph below, on the weaknesses of this domain.
Strengths of The PMBOK 7 Development Approach and Life Cycle Domain
I think it is a real strength that the PMBOK 7 team looked at this as a Project Performance Domain at all.
Some of the content is okay, verging on good. But far from all of it. And, I also quite like the running example.
Weaknesses of The PMBOK 7 Development Approach and Life Cycle Domain
There are a lot of flaws in what we must consider to be a provisional start to a mature articulation of this project performance domain. The principal weaknesses are:
- The definitions are somewhat tautological. They state the obvious and add little value to the titles
- The desired outcomes are weak and the checks, weaker still.
- Some of the principal content is ‘okay’ at best.
- There are only three key elements to a Performance Domain that I consider should have two more key elements. That means 40 per cent of the core content is missing.
- The integration between this domain and the section of the PMBOK Guide that follows Project Performance Domains, Tailoring, is weak to non-existent. Yet they should be more closely aligned, with the links more clearly drawn
- The section on interactions with other domains misses an important one
What Else We Should Include in the Development Approach and Life Cycle Performance Domain?
As I mentioned near the start of the article, there are two big items that I think are missing from the performance domain as PMBOK 7 articulates it. These are:
- Governance and governance structures
- Procurement and sourcing
Each of these represents a huge, missed opportunity.
- The first was the opportunity to better incorporate an important element of project management that is still not properly reflected in this edition of the PMBOK Guide.
- The second was the opportunity to take a strategic look at a topic that appear in the Project Work performance domain, where it is covered pretty superficially
Governance and Governance Structures
This would have been the perfect place to discuss options for good governance under different delivery approaches. After all, the Tailoring section only gives this vital topic three cursory mentions. And it does not appear in any of the other Project Performance Domains, save a passing reference in the Quality domain.
This is where it would fit best. It is a massive oversight in drafting this domain.
Take a look at our article: What has Project Governance Ever Done for Us? [Ans: A Lot].
Project Stage Gates
And wouldn’t this have been the perfect place for PMBOK 7 to make reference to Phase Gates, Stage Gates, Boundary Gates, or Gateways? It absolutely would.
Take a look at our article: How the Stage Gate Process Will Make You a Better Project Manager
Procurement and Sourcing
Strategic sourcing and procurement is not just about choosing a supplier. It encompasses development approach decisions like are we going to:
- Buy ready made components
- Create components from scratch
- Do all the work in-house
- Out-source all of the work
- Bring in contractors to do some or all of the work
- Use consultants to lead part s of our effort
- Collaborate with other industry players
…and so many more.
These are big and consequential choices that many projects face. Yet there is no reference to them at all.
How the Development Approach and Life Cycle Performance Domain Relates to the other Project Management Domains
This Performance Domain has to be at the center of your creation of a project.
The PMBOK Gide lists six of the seven other Project Performance Domains with which this one interacts. Which begs the question: ‘what about the other one?’
The one that is missing is Measurement. Yet, surely what gets measured gets managed. And the development approach is about selecting how we manage our project. Each approach will need its own measurement regime. And each delivery cadence will have a corresponding measurement cadence.
I do like the emphasis on the selection of a development approach and delivery cadence as an important part of risk management. But the omission of any reference to the relationship with measurement is a big one that I find unforgivable.
Project Management Domains eBook Series
This is a Chapter from the Development Approach and Life Cycle volume of our Kindle Exclusive Project management Domains ebook series.
What are your Thoughts about the Development Approach and Life Cycle Performance Domain?
Please share what you think of the way PMI has handles the […] Performance Domain and any comments you have about it. I’ll be sure to respond to any comments you post below.
