Welcome to the next in the series of articles that explains how we at inlumi approach our projects. In previous articles I have looked at the importance of the data model and my colleague, Kim Lam, spoke about the agile methodology we apply during the Design, Development and Test phases of our projects. In this article, I will be expanding on Kim’s article to show how we apply an agile, templated approach and how this approach works brilliantly for EPM projects.
In this blog post, I will give practical examples of how we use the agile, templated methodology depicted in the diagram below.
What do we mean by Templated Approach?
When designing a new EPM solution for a client there are always key areas that need to be addressed. For example, the design of every consolidation solution I have ever been involved in has needed meetings to discuss translation methodology, consolidation methodology, intercompany and how adjustments are processed in the system. Our templated approach then ensures that these key building blocks are addressed via the agile approach shown above.
So how does it work?
Each functional area that needs to be designed, built and tested will have a dedicated stream inside the project plan. Each of these streams will then be delivered via interactive and iterative design sessions following the flow illustrated above.
Let’s illustrate by looking at a typical workshop to discuss translation methodologies.
Firstly, the guiding principles that have been set for the project are assessed to identify any that may influence the design of the translation methodology. A typical guiding principle we see a lot is “Standardisation and simplification”. This could be applied as follows: “translation methodology should be applied in a consistent manner via a simple standard calculation.”
Once we have understood which principles are relevant, these can be used throughout the iterative design process to inform decisions.
We will next look at your “Vision for the future”. This vision, which may have been developed with our input via a Discovery phase or may be a vision that you have developed internally, will inform the future state requirements in each functional area. To understand the design and development required to reach your vision, we will look at the current process against the detailed requirements. It may be that the current process is already simple, standard, fit for purpose and meeting all your requirements. More likely there has been some complexity introduced over the years that has led to a deviation away from simple and standard, and changes to your business have left certain requirements unmet.
Understanding where you are and where you want to get to enables us to introduce some leading practice examples that will allow you to quickly visualise how your goals could be achieved. In our example of translation methodologies, the leading practice examples could be in the form of detailed worked examples showing how the different methodologies could be applied; for example:
Pulling together the guiding principles, the current ways of working and the leading practice examples rapidly enables a to-be methodology to be agreed upon. These workshop outputs are documented and made available for review.
The next step in the process is for the chosen design option to be rapidly prototyped inside your chosen technology. The prototype will be tested using the same data from the agreed worked examples, and will be iterated until you are comfortable that the prototype works as per the agreed documentation.
This iterative approach brings significant benefits:
- Discrete elements of the Design and Build can be designed, developed, tested and approved in isolation, i.e. the testing and approval doesn’t need to wait until the whole solution is developed and a full user acceptance process is run.
- The client gets hands-on with the solution early in the Design and Build process, enabling them to get familiar and comfortable with the technology. This allows the internal client team to assist in the remaining development activities, which significantly simplifies change management activities and improves user adoption.
- Required elements of functionality can be prioritised and released to enable other elements of the project to run faster. Typically, we would prioritise elements of the Design and Build that enable a rapid start to data migration. Why? Well quite simply, data migration always consumes a lot of time and effort. The sooner you start this activity the less likely it is to impact the plan. Also, data migration provides another, fuller test of the functionality that has been built.
- Finally, we find that this approach significantly improves our engagement with the client. If they are involved and can see their ideas being turned into reality, the client becomes really engaged and invested in the project. In our opinion there is nothing that helps more in delivery of these projects than having the client engaged and invested.
If you would like to hear more about how we at inlumi deliver our projects or would like to share your thoughts on our methodology, then please feel free to contact me.
