EPM implementations explained: Part 2 – Leveraging the benefits of Agile

In a previous post, Paul Wilcock discussed the importance of data model design. In this article we are now moving on to discuss how to best layer on top of the data model functionality that can bring your solution to life.

If you have been working in the EPM world for a few years, you must have noticed a transition from solutions requiring heavy technical configuration and build to “out-of-the-box” Cloud solutions allowing you to deploy applications with just a few clicks. I exaggerate; maybe more than a few clicks, but surely faster than it used to be. These new Cloud-ready solutions have provided us the opportunity to modify the way we deliver our projects:

1. We are now able to mock-up your key requirements at an early stage of the project, giving you options and the ability to visualise how your requirements could be met. These options can be rapidly iterated and can easily be transitioned in to a fuller build.
2. Key members of your team can be engaged early in the process giving them visibility and hands-on experience with your new solution. In our experience, this enables better change management and user adoption.
3. We can spend less time on the technical build and therefore more time iterating concepts and processes with you to deliver the best possible solution.

Taking all this into consideration as well as the new exigencies of customers (flexibility in the build, ability to adapt to change quickly, collaboration throughout the entire duration of the project) have enabled us to become more agile in our approach to design and development.

What is Agile Development in EPM?

Agile can be defined as a set of methods and practices based on the values and principles expressed in the Agile Manifesto:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Agile Development is an alternative to traditional project management (Waterfall) and focuses on customer satisfaction. It is based on an iterative approach allowing it to adapt well to deal with uncertainties and changing situations. Teams are empowered to make decisions, and this is the key success factor of the Agile approach.

How are we integrating Agile into our iterative approach?

1. Agile Prototyping

In the past, when I was implementing EPM solutions using a traditional waterfall approach, the project would start with the Design phase where we would gather all the requirements and formulate them into a design document. After this design document was signed off, the Build phase would start, developing what would have been agreed during the Design phase with minimal customer interaction. This presented a few challenges:

1. Some customers would agree on a design without having seen the system even once.
2. The client would see the system for the first time only towards the end of the project, often to realise that it is not what they wanted or how they thought the system would work.
3. The longer it takes for one to playback something to the customer, the greater the risk to develop something that might not meet the customer’s requirements and could potentially take a lot more time to rebuild.

And that’s why at inlumi, we use prototypes from a very early stage until the end of the project, allowing early review and iteration cycles. Our prototypes start during the Discovery phase where, from the beginning, we are able to demonstrate in the system how some of the key concepts would work or how we will build them. This allows us to engage with you from the beginning of the project, presenting several benefits:

1. Continual knowledge transfer throughout the project.
2. Validating that we understand the requirements and that we are confident enough that they meet your requirements, but also helping you visualise how things would work in the tool. For example, when prototyping the data model and showing it to the customer during a play-back session, we invite her to ask as many questions as she wants and challenge us on how we have designed it in the system, which leads to iteration cycles.
3. Customer engagement: we find it is easier to engage with the customer if she can visualise the system. By showing how things are done in the application rather than just discussing concepts, we are able to keep the sessions short and focused.
4. More insightful design: our customers are more informed on the tools because they’ve been “trained” and involved from the beginning, so the requirements are clearer and decisions are better informed.
5. Reduction of overall delivery risk as we are able to demonstrate and validate each key aspect of the build before moving on to the next one.

2. Delivering in increments following an iterative process

We divide components of an implementation into key building blocks, allowing us to have workstreams working independently (i.e. as soon as the Data Model is built, it can be reviewed and signed off without other aspects of the build being completed).

Below is an example of the foundational elements we propose for a Consolidation solution:

The Data Model would always be the first critical building block as it is the foundation for any other block (Data Migration, Data Integration, Reporting). As soon as this is completed all other blocks can be built, reviewed and iterated independently. A very important aspect of designing these building blocks is responsibility, and for each of the blocks we will always define roles;

• build owner: in charge of the build
• review owner: in charge of reviewing and validating that the build is aligned with the requirements.

Within each building block we deploy the iterative cycle below:

We follow a templated approach for design and build, leveraging tools and starter kits to accelerate the process. Workshops are short and sharp, to minimise the impact on the business. We use the technology to showcase the functionality, enabling rapid finalisation of design ideas and seamless transition to build. 

3. Working with an agile mindset

Working with the right mindset is, in my opinion, what leads to a successful Agile implementation. The team part of the build must be ready for iterations and that could mean re-building the same thing many times. They also have to take ownership of their building blocks and that means planning the review sessions with the customer, giving updates during calls, escalating any issue and more.

Managers are also coaches. They are not only in charge of preparing the project plan and ensuring all tasks are completed on time, they also need to empower their team and provide feedback on performance to help them develop. They should also make sure that their team has everything they need to perform at their best and protect their time so they can meet the deadline. A great example would be keeping the number of meetings to a minimum.

While we limit the number of meetings, we also don’t hesitate to directly call the customer if in doubt. Daily catch-ups are put in place whenever needed. As we also understand that your time is precious, a key element of our ways of working is to keep meetings relevant and targeted, ensuring all meetings have a clear agenda, a clear objective and all meetings drive next steps.

Although our approach is Agile, we realise that some of our customer projects will need to follow the traditional waterfall approach (it is difficult to go live with a consolidation solution in an agile way). All our projects therefore blend this iterative, agile approach with a structured plan to ensure the whole solution comes together at the right time.

If you would be interested to hear more about our ways of working then please contact me. I’d be happy to set up a call.