What is [Agile] Project Delivery?
“[Agile] Project Delivery: The processes and systems required for an organisation to reliably plan, track [,adapt to change] and deliver value, whether for new product development, customer delivery or internal projects.”
Introduction
One of the challenges many companies face is delivering projects on time (or, in some cases, not delivering the project at all), to budget, and adapting to changes as they occur, impacting the ability to deliver what is required. A large portion of my career has been either as a project manager managing projects, establishing project management practices and systems, and coaching individuals into the role of project manager. My experience spans over 30 years, combining the best of Project Management and agile practices to deliver projects.
Why is Project Delivery Important?
Ultimately, the success of an organisation is based on its ability to deliver value. In order to do this, it needs:
Be able to determine what value should be delivered, eg: for a product company, understanding their customers and the market well, to be able to bring the right product to market at the right time
Having the resources and mechanisms to plan and deliver that value effectively and efficiently
To Project or not to Project, that is the question
I'd firstly like to address the "Elephant in the Room": Projects
In this new world of organisations wanting to be agile, the word Project or the role of Project Manager have become frowned upon as they are perceived as anti-Agile.
If you are a software development company, incrementally adding features to your product, then agile practices such as Scrum are ideal, and the concept of a project isn’t always required.
But, the reality is that outside of software development, where there are important forms of value that need to be delivered, whether internally within the organisation (e.g., implementing a new ERP system) or its customers (e.g., new product or implementation of the product for a new customer), that a simple series of sprints as used in Scrum will not suffice.
They tend to be:
Big – amount of effort, expensive, have a longer timeframe
Risks that can impact the project, that we need to address proactively
Complicated/Complex
Contain interdependent tasks - within and between projects
Resourced by team members working on multiple projects concurrently
Defining the planning and delivery as a project and using project management practices has significant benefits. But this does not mean projects cannot benefit from adopting and using Agile practices; the key point is that how those practices are used differs from a pure software development team delivering discrete product features. This has become my area of speciality.
What is [Agile] Project Delivery?
This is a hybrid model that applies the iterative Agile approach to the Project Management model – rather than the big-bang approach (ie: plan the whole project, execute the plan and deliver at the end of the project), we break down the project into iterations and progressively deliver the project. This reduces risk by ensuring that the project can adapt as learnings are gained, and as changes occur.
0. High-level planning of the entire project
If we get the green light to proceed, then iterate:
Detailed planning of the next iteration
Execute the plan for the iteration
Retrospective – what have we learnt from this iteration, and can we do better next time?
Deliver – if there are any deliverables for that iteration
Back to 1. for the detailed planning of the next iteration
…. and so on to the end of the project
Resulting in:
Project completed ✔️
Happy customer ✔️
Happy team ✔️
High-Level Planning
In high-level planning, we have the following questions that need to be answered:
Do we have the resources to deliver the project (or what additional resources are required to deliver it)?
How long is it going to take?
How much is it going to cost?
What risks do we need to mitigate?
And ultimately:
Should/can we do the project?
The key here is that you are not planning the entire project to the nth degree – you are planning the overall project at a high level. The reason for this is that it's difficult to predict with accuracy too far out into the future – it could just be wasted effort in planning if it's likely to change. But it’s not an excuse not to plan. And when change occurs, we do it in a controlled manner – we work the plan to help identify what impact the change has, and we update the plan as a result - refer to Change Management in the Execution phase.
Execute
If the decision has been made to proceed with the project, this is where we get into the mode of regular iterations. The iteration length depends on the project, but a regular cadence should be used, e.g., weekly, fortnightly, or whatever makes sense for the project.
Detailed Planning
At the start of the iteration, from the high-level plan, identify tasks that need to be worked on (backlog to current iteration). This will include any tasks from the previous iteration that haven’t been completed yet and any tasks due to start. You go through a process similar to High-Level Planning, but it's at a detailed level for tasks in that iteration.
Task Management and Tracking
This answers the following:
Who is currently working on what?
What has/hasn't been done?
Who should be working on what next?
What impediments impact the team from completing the tasks in the iteration?
Here you can adopt other agile practices, such as the Daily (or whatever frequency works for the team) Stand-ups.
Change Management
As mentioned earlier, things change:
Tasks take longer and/or more effort/cost than we estimated
Delays
Resource unavailable at the time we planned
Prioritisation decisions impact the tasks/projects
We didn't understand the requirements correctly when we estimated for it
Additional requirements introduced
The sources of these changes can either be internal (within the project/company) or external (customers, partners, suppliers, etc.).
As a result of these changes, we need to determine what actions need to take place.
While it's tempting to throw out the plan, we should be "working the plan" to help determine what actions should take place and how the plan needs to change. And importantly, we need to update the plan, otherwise the plan gets out of date, and then the value of the plan is significantly reduced.
Risk Management
It’s important that we don’t forget about risks during the execution of the project:
Are the mitigation activities working - lessening the likelihood that the risk occurs?
If an identified risk occurs, are we addressing the impact of the risk on the project?
Are there changes that impact the likelihood that an identified risk occurs or the degree of impact of the risk occurring, that means we need to update the plan?
Are there new risks we weren’t aware of that we must consider?
Iteration Retrospective
As I’m into continuous improvement, my other favourite agile practice is retrospectives done at the end of each iteration. This is an opportunity for the team to identify the following:
What worked well – and should continue doing?
What didn’t work so well – what can we do to improve it next time?
To discover how [Agile] Project Delivery can help your business, feel free to contact me.