Martin Sykes on Value Realization
This is a guest blog post from Martin Sykes. Martin has been involved with Enterprise Architecture and IT Strategy for 15 years and is today a coach in Microsoft Service’s Enterprise Strategy Centre of Excellence. He’s also known for his use of visual storytelling techniques and is one of the authors of Stories That Move Mountains: Storytelling and Visual Design for Persuasive Presentations. (watch his top rated session on storytelling from TechEd New Zealand if you want to improve your own presentations)
Without further ado, here’s Martin on Value Realization …
Value is in the eye of the customer
This week I was teaching a class for our Enterprise Architects where we covered some of the most important topics for success as an EA, with one of the sections focused on the identification and delivery of value. If “Beauty is in the eye of the beholder” then I think it’s fair to say “Value is in the eye of the customer”, although depending on your perspective you might replace customer with stakeholder or shareholder. In this posting I will cover some of the things we talked about that can make a big difference when creating business cases, and ensuring you realize the value promised in the business case.
Who cares?
What’s the first thing you do when creating a business case? Some may start by clarifying the scope, some by identifying the real drivers for change, some the budget.
I recommend you should first think about who will care about the opportunity proposed in the business case. Who will be reviewing it? Who will be approving it? What do they care about? Every business case must have good numbers, let’s take that as a given. Those numbers must be correct for the business case (and your reputation) to be credible. But while a business case must have the numbers it is more than the numbers. Even for purely internal teams the business case is a proposal for someone to make an investment decision, or more bluntly, to buy something.
Let’s turn that last statement around, when you create a business case you are selling something. So before you start work on that business case spend some time really understanding the consumer of the business case to work out why they will ‘buy’ your ideas now. This is important even if your customer is your own management, who have asked you to write the business case.
Use the insight into your customer to work out what narrative (or story) needs to go into the business case to support the numbers, to ensure you focus on the aspects that are important to the goals of the stakeholder. This is where so many standard templates fail to inspire. They take a business case to the point where it has all the logical argument and can totally miss, or at least hide, why the proposal is important and relevant to the customer today.
What is value?
If value is the difference between cost and benefit then let’s look at all the different types of benefit that can come from making a change. I like to use a benefits structure developed from ideas first published by the Information Systems Research Centre of Cranfield University School of Management back in the late 1990s. The desire to make a change, or create a business case often comes initially from a belief that there will some form of improvement or financial return. In most organizations belief is not good enough - that’s why we ask people to work on a business case – so the team at Cranfield defined four levels of benefit that be used to build a business case:
Observable – these are the benefits we can see, but have not worked out how to measure. These could be improvements in morale or changes in the culture of an organization.
Measurable – one step up from observable and we now have identified some way to measure the benefit. For a cultural change program you could start to survey staff members to understand their attitudes to work and track this over time. Unfortunately you may not know what the current value for your measure is, and the first task may be to go out and do an initial survey to set a baseline.
Quantifiable – if you already have some data for the measures you might use then we call the benefit quantifiable. The best case here would be that you have a trail of historic data to show not only the current position but the existing trend. If you have a trend showing a slow but steady increase in staff turnover then you may be doing well simply to make a change that levels things off. If the trend was already improving then you have to do better than the trend.
Financial – finally, can you turn your measurement into financial value? If you know the costs of recruitment and training to bring in a new staff member you can define a financial benefit to balance against the costs of your proposed changes. There are two kinds of financial benefit though, the first is where you can recognize the value, but in reality you can do nothing with the money. This is typically the case where a proposal has identified savings in time because of a new process, but in reality the saving does not allow you to reduce staff numbers. All you can really do is re-purpose that time for more work. The second is where you can realize the value and actually have real money in the bank (or avoid spending some). If a new process allows you to achieve the current workload with 3 people instead of 4 then you have a choice to reduce staff costs and realize the benefit.
All of these benefits can be included in a business case and contribute to the value of a project, but in reality only realized financial benefits can be used to provide a return on investment calculation. If you want to learn more about this approach then watch my TechEd New Zealand recording from earlier this year.
How can we be sure we’re getting what was promised?
Most of the business cases I see developed are used to secure funding, then used simply as a baseline for the project costs. As benefits usually cannot be realized until something is delivered this part of the business case is often quietly forgotten about. When an IT project team complete a delivery there is usually some form of celebration, the solution is handed to operations and a small group might be left providing some user training. The benefits drift away, someone else’s problem.
Here’s an idea I have only ever seen implemented a few times around the world, and that’s because it challenges a few basic assumptions about the role of a project manager and a PMO.
Change the definition of success for a project manager to be about the realization of value. Delivery is just another milestone. The PM should be required to stay on the project until the ROI stated in the business case is achieved. This makes the PM responsible for user adoption and achieving the benefits defined in the business case. Achieving the value becomes the goal of the project, resources are planned to ensure adoption happens, and measures are implemented to show progress. It also changes the types of business cases produced. Inflated expectations are pushed down by the PM to more realistic levels so the project can be reach the ROI as quickly as possible and the PM can move on to their next project. For such a little idea it can take a big change in mindset and culture to make it happen – but the result can be projects that have a much more demonstrable impact on the business.
You Might Also Like
Mark Bestauros on Value Realization