Guest Contributor: Berl Kaufman, Consultant, Afferent Services
A recurring pattern for most IT projects is a failure to state properly the true business objectives. Instead most business problems are couched in solution terms. This is known as “solutionizing”. This post will describe how to recognize solutionizing and provide a simple technique anyone can use to do it the right way.
We’ll illustrate by example.
The head of the Risk & Compliance dept of a large institutional asset manager, Ivan, approaches the IT manager, Sue with the following business problem statement:
I need to get all the accounts in our Asia and Europe subsidiaries on the firm’s main investment accounting platform.
She embarks on this project, follows all the standards and guidelines for account migration; management team establishes an $8 million budget for the project.
Two years and much anguish later, all the accounts are migrated onto the platform. Because the project has dragged on for two years, Ivan hires a small tech team to create a work-around. The work-around, done in 2 months is a set of risk reports showing exposure by country, currency, counterparty, account, business unit, etc.
Sue announces that at long last the account migration project is complete. Sue and Ivan have a meeting to discuss the results.
Sue: All accounts are up and running.
Ivan: That’s terrific Sue. Do all your reports tie to ours? Let’s have a look.
Sue: What reports? We just did an account migration.
Ivan: (flabbergasted) The whole purpose of this project was to produce summary reports so we can measure our exposure and react to changing market conditions.
Sue: That’s not what you told me when we started this project. You clearly stated you needed to “migrate all the accounts to a single platform”.
And so on…
What went wrong here? A critical miscommunication? Actually no. Sue based the project on Ivan’s clearly stated objective. A very costly and time-consuming project could have been avoided (or at least done very differently) by employing the remarkably simple “So that” technique.
The “So that” Technique
The key to a successful project is being laser focused on the real objective. But that can’t happen until you have actually stated that objective clearly and concisely. In the business world, all projects must trace up to one of two ultimate principles:
– To save the firm money or,
– To make the firm money
The “So that” technique can guide any business statement to one or both of these two goals. By illustration, let’s turn the clock back in our original example.
Ivan: I need to get all the accounts in our Asia and Europe subsidiaries on the main investment accounting platform.
Sue: Okay Ivan. But, please tell me: you need this migration so that you can do what?
Ivan: How can we do proper risk reporting without first migrating all our accounts onto a common platform?
Sue: Well, I don’t know yet. But you’ve just told me something important I didn’t know before. You need to do risk reporting. What sort of risk reporting?
Ivan: I need summary market values by country, currency, counterparty, etc.
Sue: And you need this so that you can do what?
Ivan: Respond to rapidly changing market conditions, and ad hoc regulatory report requests.
Sue: So that….
Ivan: Well, to keep from being fined by the SEC and to identify and liquidate high-risk assets as the need arises. And keep us out of the newspapers.
Sue: So that…
Ivan: Well…so that we can retain our client base in the event of sudden market changes. Isn’t that obvious? Maybe grab more market share from assets fleeing other managers that don’t have as good a system as us…?
Sue: Hmmm….migrating all the accounts to one platform could take up to two years. Sounds like you need this right away. Maybe there’s another approach that can get you to your reporting requirements much faster.
In this dialogue we established that the real business objective was client retention, avoidance of fines and possibly increased market share. It was not to migrate accounts. The real requirement is to produce aggregated reports. There are probably several alternative ways to accomplish that goal besides migrating accounts to a common platform.
Be very wary of any project objective that does not have a clear objective which can quickly be traced up to one of the two principle objectives of making money or saving money for the firm. And we learned about the simple “So that” technique that can help put your project on the proper direction for success.
In subsequent posts we’ll address how to quantify and measure the project benefits to a business, how to identify when an infrastructure project may be warranted, and take a deep dive into vendor selection and alternatives to the RFP.