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.