Project Management

The connection between Agile estimation and roadmap development

When the Agile development mindset runs head-on into the traditional methods of project planning and budgeting, here are three things you can do.

Agile estimation and roadmap development is an area fraught with potential conflict and misunderstanding. Clients or business sponsors, especially those well-versed in traditional project management disciplines, make the assumption that the roadmap's function is to develop a project estimate, and they will often immediately jump from the roadmap planning exercise to the million dollar question, "How much?"

Let's visualize what we produce as a result of a roadmap exercise. Typically, we create a long-term vision, usually around 3-5 years, of where we see our product going, which major features we hope to develop and implement in what broad time frame, how individual programs and projects might fit into these overall strategic goals, and how the efforts will be parsed out among teams and leaders. Some teams will draw an actual roadmap on a flip chart or a whiteboard, and some will use a software product to capture this path.

For example, if we're thinking that we'll deliver a social networking component to our application suite, we may plot our roadmap geographically and say we'll roll out United States in 2013, then Europe in 2014, and Asia, Africa, and the Middle East in 2015. We may take an alternate approach and plan our rollout by target customer segment. The point is that we're thinking and planning strategically, and digging down into tactics only when we must in order to make critical staffing or market decisions. This is where the potential for conflict and missed expectations begins to manifest.

As we start to lay out these plans and goals against a time line, the sponsor naturally wants to quantify the investment. If the organization has not transitioned to an Agile mindset at the executive level, we may be working with a CFO and finance team that expects a fixed budget long before the actual work plans are plotted out. For public and regulated companies, there's no choice but to predict at some level the investment expected. From the agile team's view, however, the more speculative the strategy, and the more innovative the product, the more likely that we'll be modifying our feature sets, expectations, and work plans significantly as we go. In short, this is where the Agile development mindset runs head-on into the traditional methods of planning and budgeting.

Sponsors need to tell investors and executives what sort of investment will be required to deliver the features that will keep customers in the fold. Agile practitioners want to keep their options open and move forward in an iterative, incremental fashion, even if that means that we can't know the cost, the final feature set, or the exact path we'll take to get there. So what do smart Agile teams do to mitigate this rock-and-hard-place conundrum? Here are three suggestions:

  • Clarify the intent: You need to make sure that everyone associated with the roadmap exercise understands this is a broad strategic planning exercise, focused at the portfolio level, and not a detailed tactical workplan.
  • Don't get dragged into tactics: It's common for sponsors, and often for the more tactical-minded among the development and project management staff, to want to interrupt the vision exercise with the granular "who's going to do what when?" conversation. This is not strictly forbidden, because we often need to go there to build a realistic strategy, but if it threatens to derail the strategy and become a project-planning session, leaders need to remind participants about the goal of the roadmap exercise.
  • Help sponsors visualize the broad investment: All of this "vision" stuff is great, but if we insist on ignoring or shutting down the pragmatic questions of cost, we risk losing the support of our audience and sabotaging our methods.

The path to a budget or estimate often seems extraordinarily complex in an Agile environment; how can we plan for the unplanned, leave space for iterative discovery, and still help the sponsor envision the cost in dollars and resources associated with the features? The answer is simple: ask the sponsor.

If we can deliver the features in the time frame we're speculating upon, what would that be worth to the business? How much is the business prepared to invest to gain these advantages? The response to these questions not only gives the Agile team a framework to live within, but it also has the subliminal benefit of forcing the sponsor to take ownership of the business case, financial expectations, and resource limitations.

Every IT professional has banged up against the sponsor who, at every juncture, wants to remind us that "you said it would cost X!".  Now we set up the relationship that that the sponsor is telling us the number they imagine. There's no guarantee we can deliver within that investment or timeframe, but we can make sure the sponsor understands that business case justification is their job, and ours is to apply the expertise and creativity to deliver the results.

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

7 comments
PeterGomes
PeterGomes

Many might declare that agile has won the battle for the software engineering team. It is now fighting the war for the spirit of the organization. A couple of open questions: (1) How soon before we develop accepted Agile best practices for upstream processes like Product Planning and Budgeting and (2) How deeply will non-technology organizations be impacted by Agile and Lean organizational philosophies over the next decade?

Thanks

Peter

Senior Markering Manager@Fourquadrant

TownsendA
TownsendA

What Rick is saying I feel is that project managers (not just Agile types)need to get the Sponsor to take some ownership of the project. This is in the perfect world of course and does not always get done. In Standish Chaos reports disinterested sponsors are a big reason for failed projects. Every CFO and CEO needs to do Project Management 101. The project is not the project managers - it belongs to the business! If there is no Business Case - it should be simple - no project. Sponsors get behind the project and treat like it is yours!

ddmcd
ddmcd

I do not understand the paragraph, "Every IT professional has banged up against the sponsor who, at every juncture, wants to remind us that “you said it would cost X!”. Now we set up the relationship that that the sponsor is telling us the number they imagine. There’s no guarantee we can deliver within that investment or timeframe, but we can make sure the sponsor understands that business case justification is their job, and ours is to apply the expertise and creativity to deliver the results." This makes it sound like representatives of the sponsor are not on the Agile team right from the start. If representatives of the sponsor were on the team right from the start, wouldn't that help ensure that the roadmap is being driven both by business requirements as well as by what the agile team thinks makes sense over time? I must be missing something here.

drktech1
drktech1

You think that the CEO of Standard Oil should be involved in every project within the company directly? I think a lot of the so called project managers should deal in reality and understand how business operates. \ You want the mayor of New York to be involved in every project that is signed off by the mayor? Likewise, tell me how you respond to a RFP that requires a fixed price and estimated duration/completion time and a milestone schedule. I had to respond to a hundred of these before I retired.

TownsendA
TownsendA

Sponsors role and responsibilities have to be defined and signed off. It does not help if it is then delegated downwards. Sometimes it is meaningless paperwork. Yes and often the sponsors representatives ask the time and cost questions when they have to. When they did not understand the magnitude of the project. Mostly in my experience they just want the job done and it better be done within the cost estimate/budget you provided.

Ed_K
Ed_K

I don't know of any project framework where a sponsor is considered to be on the project team--and why should one? Typically the sponsor is someone in leadership and that person is busy leading the business unit (or business itself) and doesn't have the time for daily project activities.

RickFreedman
RickFreedman

I'm trying to find the section of my commentary, or the comments attached, in which it's recommended that the CEO should be involved in every project...we're all using the word "sponsor" deliberately, both because it's accepted usage (taking the place of the passive "stakeholder" so beloved of PMI and waterfall practitioners), and because we understand that the sponsor is frequently NOT going to be a high-ranking executive. The question about the fixed bid estimate and duration is the most commonly asked in organizations migrating to agile. The obvious answer is "are you giving fixed price estimates and durations now? How's that working out for you?" This is one of the conventions that waterfall supporters trot out to show how impossible agile is, but in further examination everyone agrees that fixed bids before discovery can't possibly work, and so we're back to a "we do it that way because we always did it that way" conversation. Yes, it's hard to convince CFOs and other business sponsors who are accustomed to fixed bids to take a little more risk and sign up for the unknown. Reality is, however, that they're signing up for the unknown every time they start a project - the question is, are we going to pretend we can know the future or acknowledge that we can't? The dark secret about fixed bids / schedules is that we agree to lie to the customer and they agree to pretend to believe us...this is no way to do serious business, and, I'd guess, if dr.k were to review his experience as a VAR, he'd acknowledge that fixed bids do nothing more than shift the burden of iuncertainty on the provider and away from the sponsor.

Editor's Picks