Three Ways to Optimize Your Project Life Cycle Using Agile
Do you want to make an impact on PMI and the world of project management? Apply to be the next PMI Board Member for the opportunity to strengthen your leadership skills, shape the future of the profession, and make an impact on a global scale.
Written by Joshua Barnes • 11 January 2024
Whether you work in waterfall, agile or hybrid, we all want our projects to be successful and our project journeys to be as pain-free as possible. There are many tools we can draw upon to ensure these positive outcomes and, in today’s post, I’d like to highlight three approaches – taken from the agile world – that I believe can enhance the life cycle of any project you undertake.
Project life cycles, of course, are becoming increasingly complex, often involving integration with other organizational systems and coordination of an expanded range of risks. Many projects also call for collaboration with a complex network of internal and external stakeholders, many of whom may have competing or even conflicting priorities.
Approach #1: Plan in Waves
One way of dealing with such complexity is to adopt a flexible planning process that balances accuracy and precision. In agile, we call it rolling wave planning. A rolling wave plan encompasses the full scope and timeline of a traditional plan – say for a nine-month period. But instead of trying to scope out every element right from the start, we initially develop just a high-level plan – what we call the release plan. We then plan in detail only for the immediate time period in front of us.
Initially, for example, we might break the project down into a series of bite-size requirements or user stories. We can usually identify hundreds of such stories in a short amount of time and organize them in some logical order – usually by business process, user, etc. Next, we’ll identify the user stories that integrate with other systems or that pose some type of risk or uncertainty. We often try to do these early on to make sure they’re done right.
Once we’ve collected all these stories – our backlog – we’ll pull out enough stories to fill roughly two weeks of work – the average length of a “sprint.” We’ll then plan out these stories in greater detail, drilling down to the level of specific tasks and who is going to perform those tasks.
At the beginning of each two-week sprint, we’ll do another planning event in which we determine and agree on the quantity of work for the next two-week period. We’ll revisit our higher-level release plan and update that accordingly based on our outcomes.
Approach #2: Solicit Ongoing Customer Feedback
One of the significant benefits of an agile way of working is fast feedback at all levels. By decomposing our higher-level requirements into small, independent requirements such as user stories, we can decrease the feedback cycle drastically. We can get immediate feedback from team members. Then, the team’s Product Owner. From there, the Product Owner can solicit feedback from Stakeholders and, ideally, customers. We can get much more meaningful feedback when we can show working functionality, not screenshots or some other static information. Working functionality that can be seen or, even better, interacted with is a game changer.
The longest time will be from the start of the Sprint to the Sprint Review event. However, we can do on-demand demos as soon as possible, so we don’t have to wait until the end of two weeks.
This feedback process is far from perfunctory. We may demonstrate some of our work and the stakeholder or customer may agree that what they are seeing is what was asked for; however, now that they see it, they realize that it will not provide the value that originally thought. What’s important is not only that we’ve identified a divergence, but that we’ve identified the divergence early enough in the process so that the time, effort, and cost of a course correction should be minimal. Once we determine the way forward, we continue iterating and obtaining customer feedback, making progress everyday toward our desired outcome.
Approach #3: De-risk, De-risk, De-risk
All this input, of course, feeds back into the overarching release plan. Once underway, for example, we might find that there’s more work involved in the process than we originally envisioned or that the work is more complicated than we thought. If so, we can adjust the release plan accordingly.
The other piece of this puzzle, however, is risk. As with all projects, we want to be very thorough in identifying and managing risk. How we mitigate that risk, however, is very different in agile because we’re not waiting for a long period of time to test and get feedback on the risk. Instead, we often do the risk mitigation work at the very start of the project, early in our timeline, to make sure that it’s done early and done right.
At the same time, we’re always on the lookout for new risks that might emerge or become evident during our sprints and through the feedback loops. This ongoing, real-time risk assessment minimizes the chance we’ll be caught off guard by an un-anticipated vulnerability or that we’ll incur significant additional costs late in the day.
These three approaches – rolling wave planning, short feedback loops, and pre-emptive risk management – are drawn from the agile world but can be applied in just about any context. While they’re designed to make your project teams more agile, when shared with project owners and stakeholders, they can also go a long way toward building a more agile mindset and in fostering true business agility across your organization.