A Tale of Two Projects*

 

It was the best of projects, it was the worst of projects, it was the age of empowerment, it was the age of hierarchy… I had better stop before Charles Dickens* gets annoyed with me.

Imagine two projects:

1. A large initiative managed and executed leveraging waterfall methodology. It has been thought through and planned in detail, with each person having clear tasks assigned, and each task having specific duration and due date.
2. A large initiative managed and executed by several small agile scrum teams. It has been loosely sketched out, with each small scrum team being empowered to make decisions and adjust their schedule as they see fit.

Now imagine a (likely) scenario. Perhaps a priority shift comes from leadership, or a new technology erupts as the hottest thing on the market, or maybe a critical privacy law changes dramatically.

Any one of these changes (and many far smaller) can wreak havoc on a project – and none of these scenarios are outlandish.

How do the two projects we imagined handle these scenarios?

• Do they crumble under the weight of their own plans, structures, and hierarchies?
• Do they scramble and struggle to communicate the new priority to disparate teams and resources?

Let’s start with the Waterfall project.

The team spends a full six months compiling requirements, interviewing stakeholders, and documenting what they plan to build; then another three to six months planning tasks, requesting resources, and laying out baselines for schedules and budgets. Then the project moves into execution where it’s scheduled to stay for several years, closely monitored and controlled. Stakeholders are happy to have clear expectations set.

It’s a year into the project’s execution (two years since the kickoff), and with minimal adjustments it’s on track. There have been a few tweaks, but everything has been falling well within established tolerances.

Enter: The Change (in this case let’s assume it’s an update to privacy law.) There is a long list of things to consider:

• What are the specific impacts to our project? It could be as small as a text update to the Privacy Policy, or it could ripple out through marketing permissions, data collection and use, how you talk to consumers, how you interact with vendors and third party partners, and more.
• When is compliance mandated? Is a tiered approach available as an option?
• What is actually required for compliance, and what is a ‘nice to have’ change?
• What is the point of view from your leadership, particularly in determining whether minimal compliance is the right path, or if there is a broader update that is best for your business?
• Etc.

Each of these considerations has a list of tasks that comes with it, including implementing the changes of course, but also communication, key decisions to be made, research, and more.

As PM of the Waterfall project, you know what to do. You pull the key people from your project together to submit a concise change request, plan an approach, and assess the impact of the work (possibly multiple assessments, if you have several options to choose from). This effort takes several weeks, partially because a key leader is on vacation for a week and three other stakeholders are at a conference the following week. The final decision can’t be made until everyone has had the opportunity to review the details and weigh in.

Then it takes a week and a half to plan the approach that’s been decided on, and several more weeks to adjust the rest of the project timeline to accommodate the new additional work.

By the time work begins on the new change, a few months have passed and the overall project plan is impacted as well. Hopefully the process didn’t take longer than your legal compliance timeline.

On to the Scrum project.

The team sketches out a high level structure of what they’re going to build, and prioritizes the work based on agreed upon evaluation criteria (criticality of the capability to the business, complexity, technical dependency, perhaps others). They dig into the first priorities and write stories for developers to work on; staying several weeks ahead so there is a steady stream of prioritized requests for the rest of the team to build.

Execution is underway about two months after the project was kicked off. The full picture still isn’t defined with complete requirements, but the team continues to deliver the highest value capabilities and stakeholders are happy to see tangible results early.

At the same time as before, about two years after the kickoff, The Change comes (the same update to privacy law). The same considerations and tasks get added to the project – after all, it’s the same change we’ve already looked at.

Managing change in a Scrum project is a team effort. The team pulls together to assess and prioritize the needs that come from this legal change. You’re all empowered to make project decisions, so you get to work on the most critical pieces as soon as possible, and add lower priority items to your backlog to work on as needed. 

The team is underway on the second high priority item when your leadership team determines that they are choosing a third party partner who is already compliant with the new regulations. A portion of your project, as well we all of the work done on as a result of the privacy law update so far, now need to be undone so you can integrate with the new third party partner’s systems.

By the time integration work begins, a few months have passed and the overall project is impacted as well. Hopefully the process didn’t take longer than your legal compliance timeline.

What does it all mean?

Both approaches, Waterfall and Scrum, have pros and cons. Waterfall is predictable and manages expectations effectively; Scrum is quick and easily adapts to change. Waterfall takes a comparatively long time to plan and adjusts slowly to changing requests; Scrum is difficult to communicate clearly and plan for long term.

Both options have a time and a place; neither is ‘the right way’ in all scenarios. Trends show that successful companies implement with the right methodology at the right time, often blending structure and speed to meet their needs.

So how could both projects have been more efficient?

• The Waterfall project could have spun up a small ‘strike team’ to focus on the most critical changes, even while the rest of the update was still being prioritized. This approach would have gotten work started quickly to help ensure that any legally mandated timelines were met.
• The Scrum project could have prioritized all of the changes and queued up the work in order in the backlog, and then worked with leadership on a final ‘go’ decision before getting started. This approach would have minimized rework and lost time.

In short, both Waterfall and Scrum can learn a little something from each other. As PMs we learn and use these standard methodologies, but perhaps the right answer is to create our own. Each company, each PMO, will have different needs and inputs. What if rather than looking at these two options as disparate, we instead view them as two ends of a spectrum? Or perhaps two tool boxes? Then we could find the right answer for our needs somewhere in between – taking pieces from each methodology (and so many others) to focus on the needs of our projects and teams.

To wrap it up, I’ll bring it back to Charles Dickens* (even if he might get annoyed).

It is a far, far more balanced project that I run, than I have ever done; it is a far, far better project close that I go to than I have ever known.

*Apologies to Charles Dickens and A Tale of Two Cities. They both deserved better.