A fundamental military axiom is to reinforce success.
Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.
Wikipedia: Reinforcing Success
I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
Prioritising Successful Features
As a programme manager the resources I have to reinforce success are people, equipment, and ultimately money. Given I’ve a defined budget with which to deliver certain benefits to the organisation I have to decide where to best spend the money. And the principle of reinforcing success informs that decision. I’ll outline a few examples/scenarios to illustrate how that works.
- Back the likely winners
- Say no to dodgy proposals
- Pull the plug on failing propositions
- Hold back on propositions not accepted by users
- Go for broke on success
Back the likely winners
Technically speaking the principle of reinforcing success kicks in after the initial investment. However I try to back the features I believe will be more successful. This isn’t always obvious at the start but it is worth the effort to assess prospects.
There are any number of ways to evaluate potential features for a product. Whatever the filtering criteria you’ve got to be able to filter out the dodgy propositions and (hopefully) leave the gems. I mentioned one such method in Agile Pre-project; Marty Cagan of the Silicon Valley Product Group suggests we provide good answers to nine questions before pursuing an opportunity. These questions define both the objectives and the constraints of the project so it is worth reviewing how things panned out in reality. The nine questions of the Opportunity Assessment are:
- Exactly what problem will this solve? (value proposition)
- For whom do we solve that problem? (target market)
- How will we measure success? (business metrics)
- What alternatives are out there? (competitive landscape)
- Why we are best suited to pursue this? (our differentiator)
- Why now? (market window)
- How will we deploy this? (gentle deployment strategy)
- What is the preliminary estimated cost? (small/medium/large)
- What factors are critical to success? (solution requirements)
Here are some real examples of features we considered on my current programme
- Enterprise Service Bus
- Emailing roles
- Submitting News scripts from the field
- Guest Handling
The last three all passed the initial filtering process and I’ll explain what happened to them latter. The first one, the Enterprise Service Bus, failed the opportunity test.
Say no to dodgy proposals (like Enterprise Service Bus)
The basic issue with the Enterprise Service Bus proposal is it is a technical solution looking for a business problem. In terms of Marty’s opportunity assessment it lacked a value proposition, had an unclear target market (for us), had no obvious business metrics, competed (in our case) with a simple (and much cheaper) ingest engine to bring in feeds, wasn’t clear why we’d do it when others in the organisation had previously failed to implement one, and was expensive. Didn’t seem like a winner and we didn’t back it.
Pull the plug on failing propositions (like emailing roles)
I agree with the old adage to "not throw good money after bad". Investing further in a failing endeavour is expensive and unlikely to get the return on investment hoped for. The feature "Emailing roles" fell into this category.
In a busy newsroom the roles are constant but the person in the role (and desk) varies during the day, night, and week. The newsroom relies a lot on email but some people who need the emails are not getting them. For example when somebody in a role goes off shift their replacement, in the role, won’t necessarily be on an existing email chain so will be out of the loop and may miss critical information. Our system was already being used to track who was in each role 24/7 so it seemed a small step to allow people to select roles as the recipients of emails. So we built one.
It seemed a good idea and was cleverly executed but nobody used it. So, when we migrated from Sharepoint 2007 to Sharepoint 2010 this feature wasn’t migrated.
I wasn’t involved in the original decision to prioritise this particular feature but I was involved in the decision to turn it off. The underlying business problem being addressed here was availability of information. The use of email meant people weren’t getting the information they needed. Email was part of the problem and, I would argue, shouldn’t have been part of the solution.
Hold back on propositions not accepted by users (like submitting news scripts from the field)
Breaking News has enormous value to a News organisation so a mechanism for journalists to easily submit scrips / copy from the field, in real time, has huge potential. So we built a prototype that trialled successfully. Then we rebuilt the prototype on our production stack and still got good feedback and some great little success stories. Everyone can see great potential for the tool. The trouble is that the programme team still has to keep pushing its use. Given my programme has a limited life span any reliance on us is not sustainable. Our field submission tool will only fly if my team are not involved in its normal use. The tool has to become part of the business as usual for the news teams.
We could add features to this tool but, at the moment, this seems like wasted money. Instead we are concentrating on helping the news teams to take the tool, in its current state, into their normal workflow. Only when we can stand back when they use the tool, and when it is the journalists asking for new features, will it be worth investing more on the tool itself. In this case I’m hopeful for a successful outcome but we’ll see.
Go for broke on successes (like Guest Handling)
One of the side bets we backed, Guest Handling, was surprisingly successful. We ran a pilot for couple of weeks and got good feedback. But even more significant it demonstrated the gap in the current processes and how an automated tool could fill the gap. This was sufficient incentive to back the winner and invest more.
Prioritising Successful Products and Projects
The same sort of logic can be used for products as a whole. Something that users get hold of and, well, use should be backed more than another product where the product owner is always promising results with just one more killer feature.
You could also use the same logic with projects. If the way the budgets are allocated would allow it, then a project demonstrating success early in it’s life cycle might earn more funding. In reality projects are not funded in quite so flexible a fashion when successful. Tragically this financial flexibility is more likely to be shown for failing projects; it is quite common for organisations to throw money at a failing project if the hope of rescuing it. The principle of reinforcing success would say can the failing project and allocate the money to more deserving peers.
Reinforcing Personal Success
The principle of reinforcing success also applies to our own personal development. Or at least I think so and so do Buckingham and Coffman (2001). In their book First, Break All the Rules: What the World’s Greatest Managers Do Differently Marcus Buckingham and Curt Coffman of The Gallup Organization present the findings of Gallup’s massive in-depth study of great managers across a wide variety of situations (Buckingham & Coffman, 2001). Some participants were in leadership positions and others were front-line supervisors. Some were in Fortune 500 companies; others were key players in small, entrepreneurial businesses. Despite the difference these managers shared a common insight and focus.
Buckingham and Coffman (2001) found that great managers do not accept that everybody can do anything they want. Great managers believe that people have some intrinsic talents and that not everybody has those talents. These managers believe that money, time and energy invested in trying to turn a personal weakness into a strength is wasted. They believe that instead the same time, money and energy, including the energy of the manager, should be invested in taking the talent that already exists and leveraging it to unleash exceptional performance.
This very much looks like the application of reinforcing success at the personal level. And it is interesting that great managers apply this principle on behalf of their staff.
References
Buckingham, M., & Coffman, C. (2001). First, Break All the Rules: What the World’s Greatest Managers Do Differently. Simon & Schuster.