IT to Business: "I won't read your mind"
In any relationship, it is dangerous for one side to "decide" what the other one wants. Marriage advisors say things like "Don't control others or make choices for them." Yet, I'd like to share a story of technologists doing exactly that. Think of this as a case study in IT screw-ups. (Caveat: this project was a couple of years back, before I joined Microsoft IT. I've changed the names.)
The journey begins
Business didn't know what they wanted.
"Business" in this case is a law firm. The attorneys are pretty tight-lipped about their clients, and don't normally share details of their cases. In the past, every attorney got their own "private folders" on the server that he or she must keep files in. Those folders are encrypted and backed up daily. A 'master shared folder' contained templates for contracts, agreements, filings, briefs, etc.
Of course, security is an issue. One of the attorney had lost a laptop in an airport the previous year, and lost some client files. But security is also a problem. Major cases involved creating special folders on the server that could be shared by more than one attorney, just for that client.
None of this was particularly efficient. They knew that they wanted to improve things, but weren't sure how. Some ideas were to use a content management system, to put in a template-driven document creation system, and to allow electronic filing with local court jurisdictions. They didn't have much of an IT department. Just two 'helpdesk' guys with the ability to set up a PC or fix a network problem. No CIO either. Just the Managing Partner (MP).
To fix the problems, and bring everyone into the 21st century, the MP brought in consultants. He maintained some oversight, but he was first-and-foremost an attorney. He hired a well-recommended project manager and attended oversight meetings every other week.
Here come the geeks
The newly-minted IT team started documenting requirements in the form of use cases.
The use cases included things like "login to system" and "submit document". The IT team described a system and the business said "OK" and off they went. The system was written in .Net on the Microsoft platform, and used Microsoft Word for creating documents. They brought in Documentum for content management.
A year later, the new system was running. The law firm had spent over $1M for consulting fees, servers, software licenses, and modifications to their network. A new half-rack was running in the "server room" (a small inside room where the IT guys sat). Their energy costs had gone up (electricity, cooling) and they had hired a new guy to keep everything running. Everyone saw a fancy new user interface when they started their computers. What a success!
The managing partner then did something really interesting. He just finished reading a book on business improvement, and decided to collect a little data. We wanted to show everyone what a great thing they had in their new system. He asked each of the firm's employees for a list of improvements that they had noticed. Partners, associates, paralegals, secretaries, and even the receptionist.
He asked: Did the new system improve their lives? What problems were they having before? What problems were they having now? Did they get more freedom? More productivity?
The answer: no.
He was embarrassed, but he had told the partners that he was creating a report on the value of the IT work and so he would.
This is where I came in. He hired our company to put together the report.
Business Results: There were as many hassles as before. Setting up a new client took even longer to do. Partners and associates still stored their files on glorified 'private folders' (they were stored in a database now). There were new policy restrictions on putting files on a laptop, but many of the partners were ignoring them. The amount of time that people spent on the network had gone up, not down.
Things had become worse.
So what did they do wrong? What did we tell the Managing Partner?
The IT Team had started by describing use cases. They were nice little 'building blocks' of process that the business could compose in any way they wanted. But how did the business compose those activities? In the exact same way as before.
Nothing improved because no one had tried to improve anything. The direction had been "throw technology at problems and they go away," but they don't. You cannot solve a problem by introducing technology by itself. You have to understand the problem first. The technology was not wrong. The systems worked great, but they didn't solve measurable business problems.
The IT team should not have started with low-level use cases. That is an example of IT trying to read the minds of business people. IT was making choices for the business. "you need to do these things." No one asked what the measurable business problems were. No one started by listening.
They should have started with the business processes. How are new clients discovered? What steps or stages do cases go through? What are the things that can happen along the way? How can attorneys share knowledge and make each other more successful?
We explained that business processes describe "where we are and what we do." Therefore,operational Improvement comes in the form of process improvements. These are different questions than they had asked: What should we be doing? How should we be doing it? Where should we be? What promises do we need to make to our clients, and how can our technology help us to keep these promises?
Business requirements for an IT solution cannot be finalized until these questions are asked and answered. Writing code before understanding the process requirements is foolish. Not because the code won't work, but because the code won't improve the business. All the unit tests in the world won't prove that the software was the right functionality to create.
Our suggestions
Here are the suggestions we gave. I don't know if the law firm actually did any of them or not. (I added one that I didn't know about five years ago, but I believe would be a good approach. I marked it as "new" below).
- Spend one month figuring out which parts of the new system were actually adding value. Look for product features in their new software they were not using and consider the value of turning them on. Their existing investment was not being well spent. Look for ways to cut costs if their infrastructure was too big. Roll back bits that weren't working. Basically, "pick the low-hanging fruit." We even asked the managing partner to consider undoing the entire thing if necessary (not that they needed to, but we wanted to shatter the idea that technology is good because it's technology). Don't spend a lot, but don't live with a loss of productivity.
- Put in an operational scorecard. Use the techniques for balanced scorecards described by Kaplan and Norton. Look for the Key Performance Indicators (KPI) and those factors that are critical to quality (CTQ). Look for measures that describe success. Start tracking them and reviewing them monthly with the partners.
- (new) Hire a consultant to help the organization understand their key business capabilities and map them to both their business strategies and their scorecard KPIs. This helps to focus effort. "If we improve the ability to share case information, we can reduce costs" or "If we improve the ability for attorneys to keep up to date on changes in agreements, we can improve our client satisfaction and perception of value."
- Get buy-in from the partners to focus on ONE area of improvement at a time. Have the entire team pick one area to focus on. Improvements in other areas can and should occur eventually, but all technical investment would go to that one area. Agreement is critical. Churn is an enemy.
- Hire a consultant to create a set of process maps for the identified area. Think things through from the perspective of he customer (client) and not the attorneys. Have a steering committee that sees a presentation every month about what the consultant has discovered and recommendations that he currently believes. That committee must provide feedback and course corrections.
- Only after a good plan exists for the future business process should they invest in technology, and only then, technology to solve a specific problem.
I hate to say it, but the real mistake was starting at the middle. They started with a IT centric approach: write use cases and then write code. I love use cases. But they are not 'step one.' Step one is to figure out what needs to be improved. Otherwise, IT is being asked to read minds or worse, to make decisions for their business partners.
Technorati Tags: Enterprise Architecture,Business Process,Use Case,Scorecard