Thoughts to Gathering Requirements

The Fit/Gap Analysis is one of the most Important Phases with any BI Applications Project. Any gap not Identified will lead to an incorrect Design and ultimately to a “wrong” Implementation.

What is often the case in BI Apps Projects is that the Customer formulates the Requirements (Afterall this is also used for RFI’s/RFP’s) without taking a look at the provided Standard in the first Place. The Problem we have with BI Apps is often that the Customer uses the OLTP (e.g. Siebel/Peoplesoft) for a certain number of Years and then buy’s the Standard Analytical System (BI Apps).

The Customer is expecting that all Standard Requirements that were used to build the plain OOTB Standard Software are used 1:1 for building the OOTB Analytical System. However, in truth this is not the Case. Also one needs to keep in mind that BI Apps is built to accommodate Data from multiple OLTP Systems with somewhat different Concepts. One particular Example of this is with Siebel and the Position Based Security. With Siebel it’s possible to have many Employees to share one Position, however in BI Apps only the Primary Employee of the Position is allowed to see the data, thus requireing more or less a one Employee per Position Concept. This is described in more detail in the following Post:

Taking a look at the OOTB Standard Transactional System from Oracle, we find the following Situation with Regards to the Requirements:

The Requirements that are used to build the Transactional System aren’t documented. Typical Documentations like Use Cases, Business Processes (Flow Charts) and Textual Description are missing. The Design is also very often undocumented, but at least ER-Diagrams exist.

Much the same is true for the OOTB Analytical System, BI Apps.

Thus, gathering Requirements and doing the Fit/Gap Analysis much depends on the Knowledge of the Team and the ability to derive the undocumented Req. from the Implementation in kind of a reverse Engineering approach.

Accepting this Fact the best Methods is to actually deliver a working OOTB Implementation of BI Apps first and then placing the Business Side in front of it and explaining the (their) data that the Business is seeing. And use this to (re-)write the Requirements.

Actually talking about the plain OOTB Standard and about the actual Customer data, can be much easier than reading through hundreds of Customer Requirements and using this Project approach increases the sensitivity to the most Important Requirements for the Customer.

Thus I argue for a shared Fit/Gap Analysis between the Customer and the Implementation Partner instead of Technically deriving the Fit/Gap based on the Requirements Document of the Customer by the Implementation Partner.


Discussing Integration Objections

The Vision of Oracle is to provide a full Software and Hardware stack, which is Integrated from Disk to Business Application. Just like the following Marketing Illustration:

However, during a customer discussion a SMB (Small-Medium Business) Customer objected to the whole suggested Solution, because of the lack of Integration of the Components. The Problem was with the Product Recommendation Engine (RTD) that didn’t use the CRM Product Eligibility & Compatibility Matrix from Siebel, thus (without any customization ) the System would recommend Product’s which would Technically fit with the existing Customer Assets.

Due to this Integration gap, the complete proposed Solution was rejected. Even after many discussions and suggested Solutions to this particular Integration Problem, the complete Software System was declined, because the Customer simply wasn’t willing to Invest into an Integration effort and was expecting this to be delivered from the Software Supplier. The Customer wasn’t even doubting the Business Benefit or the Business Case, but simply wasn’t willing to Invest into Integration work.

Even though the expectation is Understandable, but from a Software supplier perspective (especially as big as Oracle with more than 1000 Products) one would hope for a more rational evaluation of the Software System.

Afterall: in the end with doesn’t matter if the effort is with Integration work or by extending the Functionality. With most of the Standard Software available a certain gap will always exist and the real Question Business is if a Business Problem (Use Case) can be solved by the Software in the most economical way. That is the Business Goal can be reached by using the lowest possible investment.

Thus, the discussion should be about the existing gaps, but rather about the Impact/Benefit of the Business Case (Use Case) and an evaluation if the supplier actually offers to solve the Problem with the lowest possible Investment offering the highest yield/ROI of the Investment.



Time & Material vs. Fix Price

Customers often demand a Fix Price Project, because of the capped costs. However, costs are not the only Success Factor when undertaking a BI Project. Thus, I tried to highlight the Scenarios in which a certain type of Project makes Sense.

Time and Material Projects make sense when the Customer doesn’t have any previous Experience with BI Apps and consequently might not know a 100% what they want since the T&M allows to accommodate changes much better with the advantage that the customer gets what he in Terms of Business Requirements or needs.

Fixe Price Projects don’t allow any flexibility after the Requirements gathering Phase and maybe earlier since the Scope or Content of the Project have been placed into the contract, which would need to be changed if Requirements change. Thus, the Fixe Price projects are suited for Customers with Product experience and are able to formulate exactly what they want before the Project starts and when the Contract is signed.

Regardless of the Fix Price or T&M, the Project team must also balance a structured approach with pragmatic aspects. While a structured approach might provide the methodology to prevent or minimize the risk of heading into future issues it also imposes an overhead on the effort. Whereas a pragmatic approach might be to accept a certain risk of heading into issue (and possibly defining a structure to a second instance) it is also much leaner.

Thus, both these types of Project require a different behaviour from the Customer and from the Delivery supplier.

Usually Req. change or the Understanding of the Requirements change making it difficult to offer a Project on a Fix Price basis.

The most important thing in any Project is to control the Customer and e.g. resist the urge to accept Change Request, but rather formulate this for a next Phase.

Outsourcing Efficiency?

Outsourcing certain Tasks or Activities within a BI Project is more and more common these Days. The main and maybe only goal is to save costs, since the avg. daily rate might be 250$ (compared to 1000$) for an onsite Consultant. Most often the actual Build or Implementation work is outsourced, but the Requirements and Design work is executed onsite in order to stay as close as possible to the Business Side.

However, one Problem that inevitably will occur is that the knowledge gained during the Build Phase is not feed back to the People who come up with the Design and also vice-versa; the Design Document might not contain all important Information or doesn’t answer all Questions a Developer might have.

When using standard Software like Siebel or Oracle BI Applications the standard will often be customized or tailored to Customer needs. The Recommended Project Method for doing this is Oracle Unified Methode (OUM) which is based on an Iterative Approach, meaning more than one cycle is planned to correctly build the System according to the Requirements. This has the advantage that the Business Side but also the Designers/Developers get the Results sooner (or more quickly) compared to a “classic” Waterfall approach, where only one Build Phase is planned.

The following Figure should illustrate the Iterations of a OUM Project:

The darker colours denote the weighting or the Focus on the Iterations. In the first Iteration the focus is on the Req., but the next Iteration focuses on the Design and the third on the Testing.

Especially this Iterative approach has a Problem to accommodate an Outsourcing Model, since the Knowledge that is gained during the first Iteration e.g. a Problem with data or that the Data model is actually different is outsourced and needs to be feed back with more effort. In an Waterfall approach this might be not so harming since this back and forth only needs to happen once. But in an quick and agile Iterative approach the Knowledge needs to be passed constantly..

This Knowledge breach of having two separate teams needs to be factored into the Cost Savings, when Outsourcing the Build or Implementation Phase.