Improvement Design, a way to make things better
- Published: Saturday, 06 April 2019 11:16
Benefits Management in need of re-branding?
I needed a new job description because I don’t want to realise benefits anymore and I don’t want to manage change. Too many people think that Benefits are now the treats you give the staff so they will behave. Change is just making people do things differently. Frankly, I want to do something bigger than that.
I thought, “Not many people deliberately change to make things worse, change is done in a spirit of improvement”. And, if the ‘Management’ in Benefits Realisation Management is the stuff you do as you design your Improvement, then what I ought to do is Improvement Design.
So, welcome to Improvement Design, a way of thinking that helps you design the important, strategic stuff that will improve your enterprise. Whatever its scale, you are in charge of your bit and you want to make things better. Your way ahead isn’t straightforward or obvious so I want to help you make rational choices that will make things better.
Where does it all begin? Something is going to drive your desire to improve. It may be something big and external like a competitor’s new product or a change in the law. It might be truly personal, you wake up one day and decide to change your life. This Driver will define the sort of improvements you have to make. It sets your goals because it explains the reasons behind them and gives them purpose. This makes it rather important and not to be quickly glossed over.
The reasons why you do something will affect how you go about doing it. We expect that a football team will always play to win but that’s not necessarily the case. A safe draw to avoid relegation might be a better result. Fielding a weak team in an unimportant match will save the best players for the Cup Final. The match still gets played but these different purposes will affect the Manager’s instructions, the players who get picked and the way they play the game.
The same applies to any programme or project so it’s vital we start with the right goals (objectives, strategic outcomes, call them what you will):
- Goals are results with a purpose. If you are going to build a bridge, say why it’s necessary to cross the river.
- Goals must work towards the Drivers and wider strategic objectives. The ‘result with a purpose’ must have the right purpose
- Keep to a few key goals. Too many are unwieldy and will conflict with each other. Nobody was ever motivated by a shopping list
Having said I don’t want to realise benefits anymore, we can’t just ignore them, they are the evidence of your improvements. First let’s be clear on what makes a benefit. There are two rules, stated simply:
Nothing is a benefit until someone chooses to make it so.
A benefit is a result that a stakeholder perceives to be of value.
The faster, smaller piece of kit isn’t a benefit. Even a large bag of cash is not a benefit (unless you are a miser or a Finance Director). They are useful, they are assets and resources. They are the Means towards an End, they are not Ends in themselves. The Benefits come from someone’s choice of how they will be applied. Then the key points become stakeholder and perception. Who is the specific stakeholder who claims the benefit? Is it customers in general or a firm’s Finance Director? What sort of things do they perceive as valuable; improved products, a better experience or hard cash in the bank?
This simple definition doesn’t guarantee a good benefit though. It doesn’t stop you doing the wrong things for the wrong people just because they want them. What makes a good benefit? Good benefits start from good goals. Benefits provide the evidence that your goals are being met and your improvement is delivering the required value. Good benefits appear when the following takes place:
- Benefits are identified up-front (at least in high-level terms). They are why you are going to do the improvement, not why you did it
- Benefits are not simple treats to win people over so they do what you want
- Features or capabilities are not benefits. Smaller, faster, cheaper describe what a system is, not what it achieves
- Benefits should be SMART and stretching, don’t de-scope into something short-term or easily measured
- Set a baseline. If you don’t know where you started from then you can’t say how far you got and you can’t prove it was worth the effort
- Keep to a few key benefits. Each one will have a significant amount of work behind it
Choosing good benefits is only the first step to a successful improvement. You’ve still got a lot of hard work to do, but, at least, you’ve given yourself a tremendous head start.
The next step is to design the solution that will meet your requirements. You’ve decided on your Goals and Benefits, the Ends you want to achieve. Now, it’s a matter of working out the Ways and Means. There are a variety of mapping styles for Benefits Dependency Networks or Investment Logic Models. Use whatever makes you feel most comfortable. What you end up with is a blueprint for your Improvement. It’s a pictorial Executive Summary that begins your planning process in earnest.
This generic Blueprint has on the right a Driver, something to be fixed, a reason for improvement. On the left is a named Solution that sets the boundaries of what you are doing. It’s ‘Project X’, not everything.
Project X has features, assets, products that are useful. They give us the Means. These are then applied in various Ways to create Benefits that make a valuable contribution to specific Goals whose purpose addresses the Driver that started everything in the first place. Nets of cause – effect are made. Dependencies are identified. After a few passes back and forth you will have a feasible blueprint that connects what you must have, what you must do and what you must achieve.
Then it’s on to planning (and execution and review, I said there was a lot of hard work to do). That will take Improvement Design into more depth than I have room to cover in this short article so I’ll close by saying, “Improvement Design, do it now, before your competitors do”.