Do You Know Why This CIO Was Fired?

The IT outsourcing industry is one of the fastest growing industries with many outsourcing companies in low cost countries growing rapidly. I helped one such IT outsourcing company (ServCo) trouble shoot and turnaround a technology project in the financial services domain. This was a critical project for ServCo and the Business Head in ServCo was getting complaints from his customer (BigNameCo) about slippages, poor architecture, poor response times and performance.

The project manager in ServCo described the project to me as a ’47 screens project’. They did use pages, but he preferred to call them ‘screens’. He was not clear about the business domain and the bigger picture of what the project will do for BigNameCo’s business. Since my expertise is bridging business and technology, I asked a number of questions to link the technology project to the business domain.

The big picture of the business domain

My questions revealed the following big picture.

The BigNameCo CIO awarded this project to ServCo after a bid – this was only part of the development, the BigNameCo team was developing the other part along with the “architecture”. From a domain perspective, I gathered this project was trying to create a custom built equivalent of a popular rating product. By probing the teams at BigNameCo’s site, I found that the CIO had earlier tried to negotiate a license and implementation arrangement with a rating product provider. The CIO lost a lot of time since he could not reach an agreement with the rating product provider. He was now desperately trying to deliver a “custom built” rating system in 7 months to meet his commitment to the business sponsor about ‘deadlines’. The business sponsor obviously wanted a new rating capability.

I discovered that the rating product functionality was complex – and trying to build from scratch and specify, develop, test, integrate and release within 7 months was a mammoth task. I also realized that the CIO was in deep trouble and fully expected the CIO to be fired. The problems of “poor architecture and poor response time” was really a lack of complete understanding of rating complexity by BigNameCo teams and their inability to translate the business complexity into a set of clearly stated and complete list of business requirements.

Having skipped the early stages of analyzing the business domain and business requirements, the BigNameCo team cobbled together a set of screens and outsourced a ’47 screen’ piece of work to ServCo, while they worked on the ‘other screens’.

I outlined the problem, its implications, the domain complexity and the inherent lack of domain knowledge in the project teams on both sides and advised ServCo that expectations with BigNameCo had to be reset. It took a few weeks for ServCo to convince BigNameCo. The senior executives in BigNameCo also started a fresh review of the project. After the review, the CIO was fired!

Delivery guys don’t understand domain!

This is only one example of delivery guys in both companies not understanding the business domain and the bigger picture. There are several such cases of delivery teams working in a technology space without a proper understanding of domain. Meta group estimates that 60-80% of project failures can be attributed to poor requirements that arise from lack of domain understanding.

It does not matter whether the technology project is done in-house by IT teams or outsourced to a third party service provider. All parties involved (in-house and external) suffer the pain of poor understanding of business domain and a poorly defined project scope.

The realities

But are delivery guys to be blamed for not understanding the domain? I strongly believe in specialization. In my view, technology project managers cannot excel in managing a technology project and excel in understanding the business domain as well. Technology projects are real beasts and it takes a lot of managerial, technical, process, people related skills and know-how to excel in project management. I do not believe they should be burdened further by being asked to understand domain as well. What then is the answer?

Obviously, seasoned Business Analysts should work upstream of technology and develop strong domain expertise. They should help in bridging business initiatives to technology projects and help the business sponsors as well as technology project managers.

But the realities are different:

a) Experienced Business Analysts are not generally available as they are busy in projects – with multiple projects in execution, there are not enough analysts to go around.

b) Getting expertise in a domain is difficult – Business domains are inherently complex and an analyst normally has strong understanding of a few areas of the domain, but not all of them. In fact, Analysts themselves need methods and techniques to learn about business domains they are not exposed to. A capital markets expert in equity trading may not be equally knowledgeable in fixed income trading.

c) It usually takes a lot of time for a Business Analyst to translate the knowledge in his head to the project teams. There are textbooks and certification courses, but they do not directly equip an Analyst in acquiring and sharing domain knowledge quickly. It requires a lot of real-world experience and skill to use the right set of techniques.

d) More importantly, Business Analysts require advanced levels of skills and strong upstream consulting capability to understand the big picture, analyze real business needs and work with architects to clearly define technology project scope. This capability goes far beyond understanding, documenting or specifying requirements. In the normal course, proven methods or a systematic approach are not followed to decide a technology project scope and minimize the possibility of scope “creeping”. Lack of this ‘higher end’ advanced business analysis and consulting capability is perhaps the biggest constraint, even more than availability or domain knowledge of Business Analysts.

Getting the multiplier effect – non linear model

Clearly, both companies did not deploy advanced business analysis skills (it appears that there was no business analysis at all – but in my view, the problem is deeper). In addition, this story is also a classic case of ‘linearity’ that the outsourcing industry is grappling with. Projects cannot be delivered well by simply adding more people or Business Analysts. We need to think outside the box and come up with ways to scale up projects without adding more people. With only a handful of Business Analysts with real domain expertise, we should leverage these people to get multiplier effects by building assets.

The assets to be built should include:

1. Industry models that can be reused multiple times
2. Business models that are generic enough to explain business domain across multiple technology projects
3. Simple, visual models that can capture domain complexity in terms that any technology person can understand
4. Accelerators and ‘pre architected’ business solutions that can provide an integrated view of business problems and associated technology systems.
5. Toolkits and templates that can speed up business projects early in the cycle – thereby reducing the crunched deadlines and ‘poor requirements’ problems.

If only, the ServCo project manager had access to ‘assets’ like these and some basic support from a seasoned analyst, he would have realized that this was not ‘only a 47 screens’ issue but a more complex business problem.

Technology Project managers (working for companies or outsourcers) will have enough time to deliver if we accelerate projects early in the cycle before firming up technology project scope. Using scarce domain expertise to create assets for use across technology projects will bridge business and technology effectively and can truly multiply the capability to deliver quality technology projects. Understanding domain is not the responsibility of project managers. As Business Analysts, we need to enable their success by creating the right type of domain knowledge assets for them.

What do you think are the root causes for this problem and how would you fix them? Please share your views.