The Mystery of the Missing Requirements

One of my most challenging assignments was to rescue a multi-million core package implementation by a financial institution. This Financial Institution (let us call it FinCo) was implementing the core package from a well-known product company (let us call it ProdCo).

Before I was called in by FinCo to rescue the project, here is the story of what happened.

ProdCo demonstrated and showed a prototype of its core package that was being converted into Internet enabled new technology. The user interface was cleaner, easier to use and intuitive. FinCo was impressed with this demonstration. ProdCo team was knowledgeable and spoke the language of FinCo.

ProdCo met all the requirements of the RFP floated by FinCo, including financial history over 3 years, history of proven implementations. FinCo was impressed, sought a third party recommendation, got the recommendation and went about drafting a contract for implementing the core package. It negotiated stringent terms of implementation, negotiated hard on the price, got ProdCo to agree to stiff penalties and awarded the contract to ProdCo.

ProdCo claimed that most of the functionality required by FinCo was already in the package and all that was needed was some minor changes to parameters and configuration. It asked FinCo staff to be ready for a ‘Factory test’ for the package with the exciting new Internet enabled technology within 3 months of start of project.

After 3 months, FinCo staff excitedly went to ProdCo development center for the Factory test. They were armed with data, transactions normally used in their daily business operations.

FinCo was unable to go through the first few pages, since the transactions failed and FinCo staff were unable to test other transactions, since they were all dependent on successful completion of initial set of transactions. FinCo was disappointed, but hoped for better things.

FinCo staff were promised that the changes would be made in 6 weeks.

6 weeks later, FinCo again tried testing with marginal success. Only 20% of the transactions could be tried. More disappointment for FinCo.

3 months later, FinCo was able to get 30% of the transactions through, but were still unable to test anything. Frustration and first signs of desperation could be felt in FinCo. FinCo was getting furious with each passing week and all the meetings between FinCo and ProdCo ended up with finger pointing, excuses for delays and further justifications. FinCo religiously kept minutes of meetings. All the minutes pointed to delays by ProdCo.

I was called in at this stage.

My first question to ProdCo was ‘What are the customer’s business requirements that you have to deliver to’? I got blank stares from ProdCo team. They looked at me as if I was from another planet. I was only trying to put on a customer hat and figure out what was supposed to be done in the first place. ProdCo said there were no requirements since this was a product implementation and the functionality in the package will be implemented. I then asked “When someone tests the product before implementation, how will they know whether the product will be accepted by the customer and will run without any problems’? I once again got blank stares. It appeared that the product was to be implemented “as is” and ProdCo team felt they ‘knew’ everything about FinCo’s business needs and requirements. I persisted and asked for ‘requirements’. ProdCo finally showed me some ‘page’ mockups and block diagrams as their view of “business requirements” of FinCo.

The pages were their view of business, not FinCo’s. The block diagrams were too high level and generic to be of practical use. They showed a general understanding of FinCo’s areas of operations. In summary, there was nothing specific about FinCo’s business that was written down and mapped to the product by ProdCo.

It turned out that FinCo also did not have any business requirements. They thought that the functionality in ProdCo would meet all their requirements.

This was clearly a case of ‘missing requirements’. It was obvious that both FinCo and ProdCo missed a few basic steps.

FinCo should have first determined its business requirements and should have evaluated ProdCo’s responses against the business requirements in an RFP to determine fit, gap and suitability before writing a contract for implementation.

FinCo did not follow these basic steps. Instead, it firmly believed in outsourcing and was more intent on writing up a tough contract that it could use to choke ProdCo by the throat, if ProdCo did not deliver. It thought a contract could get things done and did not focus on assessing its own business requirements and the fit of ProdCo.

ProdCo in turn should have given FinCo, a picture of all business flows it supports and should have asked FinCo about gaps between FinCo business flows and those supported by ProdCo. ProdCo did not follow any of these steps. I was surprised to discover that ‘prior implementations’ were actually done in a different country where the business needs and operational requirements were entirely different.

A SIMPLE PROCESS FOR PRODUCT IMPLEMENTATIONS

A product provider needs to identify several things clearly to prospects.

First, show clearly a set of pictorial business workflows supported by the product and matching these with the required flows for the prospect. This is the most critical step that cannot be missed by the buyer or seller. If there is no agreement or clarity about these between the buyer and seller, the project is doomed.

Based on this agreement, the product provider then needs to identify:

• Core functionality that is supported out of the box, not supported out of the box
• Parameters and settings that need to be configured
• Reports/pages or any other integration pieces/channels/user interfaces that need to be customized/built afresh.

While every experienced industry professional understands it ‘intuitively’, I must state the essence of product implementations in two simple statements:

1. Every business is different and specific. While most of the workflow is generic, each prospect has something unique that applies only to that prospect and no one else. There is a picture of ‘how business runs’ that exists for every prospect. The trick is in getting and understanding this picture, making it explicit, complete and documenting the ENTIRE PICTURE.
   
   
2. Every IT product/application has to FIT PERFECTLY into that picture of the business without any gaps. If there is a gap, it means the business will not run, as it should. The gaps could be minor or major, but they have to be fixed immediately for business to work, as it should.
   
   

This simple essence of PICTURE and FIT applies for every IT implementation. Only extremely simple, basic, small businesses can implement a product without the need for any changes whatsoever. But most companies are not simple, basic, small businesses. The real world is complex and business needs are complex.

This essence and underlying realities of a business PICTURE and FIT do not change whether it an ‘on-premise’ solution, a cloud solution, an ‘off the shelf’ implementation, a mobile or digital project or custom development.

While these are essential steps, many companies do not follow these basic steps.

There is a lot of confusion and activity around

1. Should we get the product to support our processes OR
2. Should we adapt to whatever processes are supported by the product

Even if they do resolve this question, they are caught up with intricacies and ‘how to identify and model business workflows’ since this is not so easy as it may appear. They also get entwined in a lot of confusion around process, workflow, rules and logic that range from extremely high level to very low level. There is a need for following proven and demonstrated techniques and methods to get the PICTURE and FIT to bridge business and technology.

Finally, FinCo however did get the core implementation done. How I got it done is a different story.

Who do you think is at fault here? FinCo or ProdCo? Please share your views.

Author: Ravi Bommakanti, Founder, BBITS Consulting

Ravi Bommakanti is the Founder of BBITS Consulting. He has experience as a hands-on business analyst, business consultant and as the Head of a Business Analysis Center of Excellence. He helps individuals transform themselves with eLearning courses. Visit his website or write to him at [email protected] for more information.