Getting Your EPM Project Off to a Successful Start

I think most would agree that getting a software implementation project off to a good start is key to arriving at a successful finish. Even so, I think that many people involved with these types of projects would be able to site several instances of cases where that did not occur.

One problem I’ve experienced in the past is when there is a misunderstanding between requirements gathering and design. Essentially, the project would jump right into design without a clear understanding of business requirements. When that happens, you can end up with a constantly changing design, missed deadlines, budget overruns, and lack of user acceptance, among a host of other things. In fact, without a clear understanding of the requirements, you would rarely ever end up finishing a project successfully.

Requirements should tell an organization what its business needs are in order for it to perform and succeed. These requirements should be gathered via interviews with key stakeholders and subject matter experts, from the highest level of the organization to the lowest, as deemed necessary. They should be an all inclusive list that is prioritized based on budget, timing, business need, etc. The design, on the other hand, should tell you how to build the tool once you’ve determined what the immediate business requirements are.

What I’ve experienced most often during EPM implementation projects is a small amount of requirements (we want a distributed system that’s easily deployable to end users, we need to have single source of the truth, we need to have multiple what-if versions of data) and a lot of design (here is our chart of accounts, this is how our data is sourced, these are the reports we need to generate). Requirements should take a fair amount of time to gather, fully vet, and complete. Once completed, a document should be presented and signed-off by all parties before proceeding to the design phase. If an adequate amount of time is taken to complete requirements and design, the build portion of the implementation should, in theory, become much easier.

Let me add a caveat here. Projects have budgets and timelines and do not continue in perpetuity. Therefore, requirements gathering and design should not go on forever and, obviously, have to be done within the confines of the project. The point is to do a complete and thorough job both gathering requirements and developing the design, to give your organization the best shot at successfully building out a solution.

After requirements and design are complete, key stakeholders should stay involved throughout the project to make sure their requests are accurately being fulfilled. It’s one thing to gather a list of all the requirements and develop a design, it’s another to build it into an application and make sure the end product is truly what was desired and meets the needs of its users.

Finally, success criteria should be included as part of requirements and design and re-visited at the end of the project to make sure all criteria were met. This provides a means for “grading” the project and ensuring that key items were considered and implemented successfully.

Right Time for BI when Implementing ERP

Despite the economy and the related IT budget cuts ERP implementations are still a prevalent part of the IT project landscape. These include both upgrades to a new version of the same ERP system as well as implementations of new ERP systems to replace legacy systems. One of the questions that should come up when a company is implementing an ERP system is 'When do we start the BI project that will provide reporting and analysis of this ERP data?'

On a regular basis my firm is engaged to implement a BI solution when the ERP system has been implemented or is nearing completion. The prevailing wisdom is that we can't build a BI solution without data so why would we begin to do anything until the ERP system is complete. The prevailing outcome is that we expose design decisions made when implementing the ERP system that limit the ability to deliver the reporting and analysis requirements desired by the business. Examples include lack of detail or granularity; business processes that don't ensure critical information is recorded; data entry methods that make reporting more complex; etc. Sometimes a company lives with these decisions and their limitations but sometimes they may go back and change their ERP system as a significant cost.

We have had more than one customer restructure their GL accounts and post at a lower level of granularity. After implementing a BI solution capable of accommodating very large amounts of data, it became obvious that having access only to highly summarized data was artificially limiting business insight. Another customer changed the way their sales order entry people processed price adjustments - they were creating a second sales order with a negative price but with the same quantity resulting in non-additive sales orders. Not hard to handle with a bit of ETL coding but still not ideal for business analysis.

So when is the right time to begin the BI project. My personal feeling is that it should start as the ERP requirements are becoming firm but are not yet set. That is the time to gather reporting and analysis requirements (the most difficult but most important part of a BI project and a topic for another day) and track those back to the data in the ERP system. The high level design of the data model and ETL for the BI solution can then begin as the configuration of the ERP application progresses. Ideally about the time the ERP project is ready for the conference room pilot, complete with test data, the BI team is ready for an initial load test of the ERP data. And about the time that the ERP application is ready to be moved to production the BI solution is in it's final testing phases and ready for deployment shortly after the ERP system is put into production.

There is a legitimate concern about encountering rework of the BI solution should changes be made to the ERP system as an outcome of the conference room pilot. The risk should be less costly than the risk of reworking the typically more complicated and costly ERP system.

This approach has another advantage. The team that implements the BI solution will be engaged while the resources with first hand knowledge of the ERP design are still available. We have all encountered the situation where much of the knowledge of the inner workings of the ERP system walk out with the implementation team and the documentation lacks the needed detail or accuracy.

Interaction between the BI team and the ERP should be encouraged. A good BI implementer will be able to make efficient use of the ERP team's time (they will be very busy with their implementation) by packaging up their questions and by documenting the answers so that they ask them once.

And while we are talking about the implementation teams, BI involves a very different set of design principles and skill sets than ERP. Choose your BI implementer based upon their references and experience specifically with BI projects. Your ERP implementer may offer up a BI resource or two and you may be tempted to go with a trusted partner with whom you already have a relationship. A good BI implementer will be able to work very effectively with your ERP implementer and will provide you with the best of breed resources to ensure your success.