Bridging the Gap: End-State Planning in Agile and Hybrid Project Management

Bridging the Gap: End-State Planning in Agile and Hybrid Project Management

As a project manager who works in absolutes (Waterfall) and unknowns (Agile), it is often hard to explain to people that I try to see the end state of a given project or initiative up-front (obviously, more on the Agile front). Sure, planning out a project using Waterfall, let's say a construction project, it's easy to visualize every step up to the end. However, as many people begin their journey into using Hybrid or Agile, they don't see how they could know the ending when no end is in sight upon starting a project.

In reality, it won't be your project managers who suffer "end-state-anxiety," but the stakeholders. Far be it from me to be the one to try and console such worries; thus, we can take comfort in knowing this has been an issue for a few years.

Seneca the Younger wrote "De Tranquillitate Animi" or "On Tranquility of Mind" around 60 A.D. Within, he notes "the importance of planning and the dangers of false conceptions. He suggests that by planning to the end, one can avoid being overwhelmed by circumstances and know when to stop. This approach allows one to guide fortune and help determine the future by thinking far ahead."

Even with Agile, we can plan to the end. So how do we quelch this fear from stakeholders that Agile is too hard to use because there is no end in sight? In my experience, it's all about setting expectations. Everyone involved should expect that if Agile (or Hybrid) in the organization is new, there will be growing pains to adapt. And the project will end.

But this doesn't mean we can't plan for that end; it simply means we must plan differently. When working with a team using a standard Waterfall process, it's best to explain the differences between how the old (Waterfall) and new (Agile) frameworks operate. We can then offer the best of both worlds through Hybrid. Even better, we can mold our Hybrid approach to the client(s).

Aspect Waterfall Agile
Approach Linear and sequential, with each phase starting only after completing the previous one. Iterative and flexible, with continuous development and testing.
Flexibility Low. Changes in requirements or scope can be costly and disruptive. High. Agile allows for changes in project development requirements.
Testing Testing comes after the "Build" phase. Testing is performed concurrently with software development.
Stakeholder Involvement Stakeholders are typically involved at the beginning and end of the project. Frequent stakeholder interaction is encouraged.
Suitability Best for projects with well-defined requirements, limited complexity, and a clear end goal. Best for projects with unknowns, high risk, or frequently changing requirements.
Project Progression Progresses in distinct, sequential phases. Progresses in smaller increments or "sprints".
Feedback and Adjustments Feedback and adjustments are difficult to implement once a phase is completed. Regular feedback and adjustments are part of the process.
Project Visibility Visibility is often limited until the end of the project. High visibility and adaptability throughout the project.

Using what we know from both frameworks, we can create a Hybrid model that will work with almost any customer. An excellent resource for all, teamgnatt, defines what we're looking for as "Hybrid project management, also known as blended project management, combines elements from different project management methodologies, typically Waterfall and Agile, to create a process that best fits the team, [client], and the project."

For those who are worried about the "how" in getting to the end state, might I suggest that everyone agree on the project's direction (the starting point) and what will likely be considered the end of the project? For example, let's assume your project is to create a new policy for your work-from-home contingent workforce. We can say that the "end" will be a signed policy. However, using a Hybrid approach to get to that point will enable our policy team to create and iterate policy drafts in sync with those reviewing.

This may sound pretty straightforward, and it is. However, in our policy example, we can move forward and take a few steps back simultaneously. Suppose the review team is working on section three of the policy and notices that the writing team accidentally got the company holiday schedule wrong, affecting several other parts. It's not a big deal; the review team can send these sections back to be updated, the project lead (aka manager) can note the change and ensure newer sections are fixed/updated en route, and the review team can continue forward, finishing this section and beyond. When the holiday section needs to be reviewed again for fixes, it could be fast-tracked at a discussion meeting later.

This might sound like something your company already does, which is excellent. The team is already being Agile without even knowing it. It shows that being Agile, Hybrid, or Waterfall-ish doesn't have to be a deal breaker in a client's endeavors to change their way of work.

Being Hybrid is more of a state of mind than a rigid or placid way of doing work. It will work if the team, leadership, and general project members are on board to be more fluid with the process. The key to moving this process is to ensure the leadership is onboard. Without their willingness to try a new framework, the plan is dead before you leave the meeting with them.

Before I close this out, here are some strategies to ensure, or encourage leadership participation:

  • Identify your “champion“ - As you start your planning, someone will inevitably rise to the top as an approachable individual in the leadership group. This person won’t usually be the most important person, but they may have sway with the group you need.
  • Articulate the value proposition - It’s no secret that doing a project for the good of the gander will no longer turn heads or ensure a projects acceptance. Even in government work, a return on investment is a must. Thus, you’ll need to ensure you are effectively communicating the benefits and potential returns of the given project. People need to understand why they should invest their resources into a new project.
  • Involve the leadership team in the project - Be sure you at least offer them a place at the table to be consulted on key metrics and decision. When people feel involve, they’re more likely to be invested in the outcome.

As a project manager, you must be aware of the trap of oiêsis, remain cautiously optimistic about the new process, and recognize that its true efficacy can only be determined through unbiased evaluation and feedback. If change doesn't work for the better, try again.


Sign In or Subscribe to leave a comment.