When creating an MBI, the question to ask is, “What can I deliver soonest to get the most value?” This question has many aspects to it. It is not “smallest,” but it is “soonest.” The focus is not on the end picture when everything has been finished; rather it is, “What is the next step for value realization?”
Another focus is, “Who is the customer?” For whom are we building the next increment of value? This is especially important in those cases where there are multiple customer bases. And not all customers are the same; some are dearer to us than others. This is as true for an IT shop as it is for a product shop. Some internal clients are more important than others. The definition of MBIs is driven by looking at the market segment we want to go after.
Consider the example of defining MBIs for an internal IT support project. A financial company has had difficulty managing its help desk. A client might start the process of signing up for a new investment service and encounter one of the 22 challenges that consumed a large part of the help desk’s time. Millions are being spent on support due to these challenges.
Let’s take an example of how to define MBIs for an internal IT support project. A financial company had difficulty managing a help desk. Clients would start the process and one of the 22 challenges would come up that took the help desk’s time. Millions were being spent on support due to difficulty of clients signing up for a new investment service.
You call a meeting with the business stakeholders to find out the business value of the different options available. You wisely understand that choosing which of these many options to pursue is really a business decision and not a technology decision.
Too often in these situations, the IT shop will want to pursue technology solutions so it might be nice if they did not even come to the meeting! But of course, they showed up. Here is how they described their four-phase approach to improving the system
- Set up the plan
- Modify the enterprise database as needed
- Improve the application’s workflow
- Automate the straight-through processing of the enrollment
This is a classic example of “system evolution”. Asked them how long it would take, they said about nine months.
You might expect the business had a different perspective. Asked if there was some subset of functionality that they would give them value they said that, indeed, addressing the first 16 challenges would give them 80 percent of the value.
So, you turn back to IT to ask them what it would take for them to build the software. just for the first 16 items. Their response? They couldn’t do that. This is very interesting because it is a smaller problem: only 16 items. Pressed on this, they admitted that while they could do it, they didn’t want to. Why not? Because there was a risk that after building a system to address the first 16 challenges, addressing the remaining six would require much more time later. They speculated that building a system to address all 22 at one time would take nine months but addressing the first 16 and then the last six would take 10 months.
They were adamant. The all-at-once approach would save an entire month! And you can appreciate their feelings. They were overloaded already and now saw the work they were going to have to do would expand on them.
What do you think? What would you do?
The real decision is whether to get all the value in nine months or to get 80% of it in six months and then get the remainder four months later. Is this a technology decision? Or a business decision?
If the goal is business agility, it is clearly a business decision. The business must decide if getting 80% of the value three months sooner is worth the cost of an extra month of development. The business answer was clearly, “Yes!”
And that’s exactly what they did. In fact, they never did address last six issues. The business decided that the return wasn’t worth it. They had other things for IT to do instead.
Go to The DA FLEX Patterns