So starts a thought-provoking post from Glen Alleman‘s blog Herding Cats; several months later and I’m still coming back to its central idea. Ask yourself: what are you doing right now to ensure that the thing you’re building doesn’t just meet documented requirements, but is successful in achieving valuable business outcomes?
Before we get hung up on the word “projects”, how about:
“All initiatives must have a strategy for success”
If you’ve heard me speak in the past year or two you may have heard stories of how we used A3 as a way to get to the heart of what was important in our portfolio of initiatives, against which we could deliver value to the business (I’m deliberately steering clear of how that was organised – it’s not that relevant here).
Last year I majored on how A3 helped us identify the few business initiatives on which we needed to concentrate our efforts; this year in my portfolio-related talks I’ve drilled into one project whose A3 helped take it from #5 to #1 on our list of priorities.
Its strategy for success?
- Re-frame the initiative not as “deliver the next milestone on the roadmap” (in this case a new trade capture system) but as “face up to a set of significant challenges” – addressing some real business risks (which we quantified at the time) linked to some big-picture architecture issues which we planned to address incrementally.
- Reverse the implementation plan, starting not with the shiny new system but with something much more mundane, some strengthened business controls to create (i) some additional stakeholder “pull” and (ii) a safer environment for the several (and sometimes difficult) implementation steps that would follow. A feedback mechanism designed both to amplify learning and to dampen any potential negative effects.
You may recognise part 1 of this strategy as the A3 approach working its magic. Part 2 was explicit, documented in its A3, agreed. What was seen previously as an IT delivery problem was now a business problem. And it worked!
Taking it down a level
What if we asked the “strategy for success” question more often? For every piece of work? Have it hanging in the air in every stand-up meeting?
Instead of that backwards-looking “Verification and Validation” arrow, what if we looked forward, asking ourselves questions like these:
- How does the work we’re currently planning (and the way we plan to execute it) really stack up against stated business goals?
- How do we know that the thing we will make operational tomorrow is what will be needed tomorrow, not just the thing that was specified yesterday?
- For this current feature, do we know what sort of UAT experience we can expect? (And if not, why not?)
- How many surprises should we expect in system test? What are we doing to pre-empt them?
- What am I doing to make my next handover (upstream or downstream) a zero-surprise non-event?
Asked daily, some of these questions are more tactical than strategic (in Kanban terms we’re in “manage flow” territory), but ask them often enough and we may crystallise out some new policies, refine our knowledge discovery process, perhaps trigger some concerted improvement activity – a strategy for change that’s supportive of our strategy for success.
So, looking at your work from business initiative right down to today’s work items, what’s your strategy for success?