Yesterday I was working with an organization that was planning out the next six releases to take them from June through January. I’ve been working with this team for the past few months and it’s taken a lot of work to get to here. We were chartered with coming up with plans and options to present to the CEO the next day that ensured the new system got launched this year.

There are lots of features Marketing and product managers want, each benefiting their client base (the companies products and their product managers are aligned around the different types of clients that use their software. There’s not a single product manager). The product managers and team had identified most of the epics and stories for the rest of the year and yesterday was a full-day estimation and planning workshop. There were approximately 125+ epics and stories in the mix.

The team for the last two Sprints has provided steady velocity numbers so although we only have two data points, we feel like it’s enough to estimate what level the team could deliver at for the remaining releases, understanding that this would get more precise in time. There’s some danger here in extrapolating two data points, but it’s somewhere to start.

At the end of the exercise, with everything laid out, everything Marketing and the product managers wanted this year wouldn't be completed until next June of next year at the current pace with the current team. Features wanted in October wouldn’t be ready until January, thus missing an important seasonal window for their products (and revenue opportunities)!

The leaders were exploring options for what to do, including:

1. 1.Hiring an outside firm to turn-key develop some of the features in parallel with their development team and integrate (potentially costly and with integration risks)
   

2. 2.Exploring options to increase velocity through higher productivity on their team (worth consideration, but wouldn’t alone get the 50% productivity improvement needed to make the schedule realistic)
   

3. 3.Bringing on staff-aug folks to bolster the development team to meet the aggressive schedule (costly, would take time to train and be a hit on velocity in the short term).
   

None of the options were ideal and each presented risks that even if mitigated produced little guarantees the new system would still get launched by October.

Towards the end of the meeting, the head of IT (John) was describing how he needed to present viable options. As currently laid out, unfortunately there are no easy ones that don’t involve pain, a good amount of money and risks that the new web site (the system under development) wouldn’t be launched this year. Also, without additional funding, there wasn’t a clear path to launching a new system by October to maximize the revenue opportunities.

The head of marketing (Karen) next spoke up and said, “Ted, our CEO, has been telling the board of directors for the past two years that this new web site is our #1 priority. Because we’ve switched technology platforms and had stops and starts, he can’t go back to them again this year and say it’ll be 2009 before we’re live. That’s not a realistic option.”

I then said, “If you understood what was most important to Ted, what would the plan look like that would allow him to stand up in front of the board and declare “victory” and everyone internally feel good about what got accomplished? Does it really involve all these features we’ve discussed or can we create a plan that meets the #1 stakeholder’s definition of success, which is declaring victory that the system was launched to the board?”

The leaders in the room nodded in agreement and Karen really seemed to get it. She said, “Ted doesn’t care if we implement all these new advanced features, we just need to get a new working system launched with the same features as the current system with an updated look-and-feel. If we got a few of the new features great, but if not that’s ok too, it just needs to look new and improved! And actually, we could live with a re-skinned version of our current commerce system instead of replacing it with the new system and still launch the site.”

Then some of the others starting chiming in, “It wouldn’t be ideal and we’d have some re-work to do, but we could re-skin the older registration system and link to it from the new site for this year, instead of building the new registration system this year.” People naturally started thinking about “What’s the minimum we could we live to launch the system and Ted be able to declare victory this year?”

Based on our estimates, re-skinning commerce and registration as opposed to re-building would potentially reduce 8-10 weeks off the best schedule estimates and bring us back to the October timeframe for launching a new system. The team understood there would be some throw away work to re-skin the current system, but it would also be less risky, because they knew the nuances of the current systems quite well. Although not ideal, it does look like a workable plan.

Time will tell if this works out, but it reminded me of the lesson I’ve learned from Gilb and applied during this session:

Always focus on the needs of the top stakeholder and what’s really important to them, everything else is secondary

In this case, the #1 stakeholder is the CEO, who has to answer to the board of directors for being able to deliver the new system this year. Understanding what’s most important to him (declaring “victory” in front of the board on the #1 initiative) can help bring great focus to the leaders and team surrounded with lots of features and options for implementing them.

On your project, are the real needs of the #1 stakeholder visible to all and a part of your planning process? Do you know what it takes to declare victory?