Hi folks,
A friend of mine is starting a new job soon, and his primary responsibility will be the establishment of a new capability and program. While he has plenty of relevant experience as a consultant – identifying stakeholders, developing an understanding of needs, boiling down wish lists into something more practical – he’s never had to stand up a program before. I’ve had the opportunity to do so in several contexts, so he came to me for advice.
I think he was hoping for a pretty concrete answer – something like “oh, here’s the book/methodology/process everybody uses”. And while countless authors and organizations like PMI would love to sell you their ideas and frameworks, there’s no single definitive solution to the complexity of creating something new. Because whatever plan you have, it’s going to need to adapt and change to the conditions you encounter. As said by 19th century Prussian general Helmuth von Moltke, “no plan survives first contact with the enemy.” Or, my preferred version:
So what’s the answer then? Just wing it? That seems… irresponsible. Yeah, it would be.
The answer is to have an approach that’s inherently flexible – one that doesn’t box you into a corner or set you up for failure. In fact, one that plans for failure in the first place. There’s a bunch of these approaches out there, but one I like and has worked for me is the result optimization model. It looks something like this:
The idea is to iterate your development and deployment. It’s a pretty flexible model, but the way I like to use it is to develop a fully functional draft program, deploy, gather lessons learned, revise, and rinse and repeat. By actually deploying a program into a live environment – instead of waiting until you think you have the perfect product – you’re able to learn far more than you can through theoretical discussions at a whiteboard.
Now, there are some likely outcomes of this approach. Your first program iteration won’t do everything you want it to do. If you haven’t adequately set expectations, some stakeholders may be disappointed. And if you don’t already have a reputation for excellence, folks may think your initial draft is the best you can do.
But then again:
The good news is that there’s a number of ways to use this approach, adjusting the fidelity of each release to meet your needs. Does your organization have a low tolerance for failure? Then only release well-refined iterations. Need a quick success to establish or repair a reputation? Then take an agile-like approach and release incremental functionality and build upon each release.
I happen to like releasing fully-scoped draft programs, setting expectations for failure/friction and planning for the development and deployment of new iterations over the course of several months or years. That way, I can adhere to a broad, meta-plan that gives some overall predictability to how the program will mature over the long term. The time between deployments gives me the opportunity to see the program in action and gather feedback for improvements. And knowing the we’ve already scheduled new deployments many months in advance can calm nervous stakeholders who don’t immediately see all their needs met by the initial draft. But my ability to take this approach is very dependent upon the buy-in of my stakeholders, so your mileage may vary.
Regardless, the iterative nature of the result optimization model lets us reap the benefits of planning without being too tied to a single, rigid plan that, as Mike Tyson told us, is likely the break as soon as it’s deployed. Or, in the words of another great fighter:
Rex