In 2015, 80% of companies had teams practicing agile. This compares to only 35% between 2012 and 2014.
Why such an evolution? The foundation of agility is based on the observation that many IT projects fail because they do not meet deadlines, costs or specifications. The constant evolution of customer needs requires rethinking models that are too rigid. Today's markets require real-time management and a high level of responsiveness. But is agility adapted to all types of projects and in particular to performance management projects?
While traditional EPM (Enterprise Performance Management) project development cycles used to be quite long - from a few weeks to several months - customers now want to see tangible results in a shorter timeframe. New solutions, born with the Internet and the democratization of the Cloud, appear regularly and promise implementation times never seen before.
As an integrator, it is essential for us to adapt to this new situation while meeting our customers' requirements.
The limits of traditional projects
The first risk inherent in a "V" project is the predominance of documentation over software. A traditional project is punctuated by the delivery of documents with contractual value that are supposed to define the target to be reached: specifications, functional design, technical.... Hundreds or even thousands of pages must be written, reread, distributed and then corrected in several successive versions. Misunderstandings or misinterpretations of the document can lead to real discrepancies between the product expected by the customer and the product actually delivered.
Another pitfall is the famous "silo effect" of the development phase, during which the customer cannot verify that the realization is in conformity with his expectations. In order to limit the risks, the realization of the solution is conditioned to the validation of the design file which describes the exhaustiveness of the expected product.
The validation of this key document is sometimes problematic and can cause a delay in the following phases: disagreement between experts on a specific management rule, uncertainty on the availability of a source or the desired finesse on an analysis axis.... When the design is finally validated, any change is experienced as a constraint and can lead to bitter negotiations between the partners.
The agile method makes it possible to mitigate these risks by encouraging collaboration with the client. It aims to deliver tangible business value in the shortest possible time, while welcoming changes throughout the project. In this context, if agility seems perfectly adapted to web type projects, it seems less obvious in the context of an EPM project, which is most of the time based on a market software package, more or less flexible, and which imposes its own constraints. In this context, agility cannot mean total freedom.
What are the benefits of agility in an EPM project?
There are many advantages to implementing the agile method for both the customer and the integrator. The first of them is to allow a very fast visualization of the results:
Demonstrations are organized at a jointly defined frequency (in practice, every 1 to 4 weeks). These demonstrations are an opportunity to check that the proposed solution meets expectations or to make changes if necessary without waiting for the acceptance phase. Following the demonstration, the customer can immediately connect to the solution, perform his own tests and validate the developments. This ability to provide immediate feedback has a direct benefit on the subsequent acceptance process.
Delivering business value
Rather than delivering 100% of the solution in the distant future, this method favors the incremental delivery of features, prioritized according to their value to the business and the maturity of the need. It is therefore the most expected and stable functionalities that will be developed and delivered first. It is the customer who prioritizes the subjects and therefore builds, step by step, the path to the final solution.
The agile method integrates the inevitability of change by freeing itself from the classic design file: it is unlikely, if not impossible, to have a completely exhaustive and unchanging vision of the final solution at the beginning of the development process. The first development sprints start with the elements that are agreed upon, while all the factors of uncertainty are dealt with in parallel without blocking the progress of the project.
Strengthening of the relationship and capitalization
Another major benefit linked to the application of the agile method is its impact on the quality of the relationship between the partners. The development sprints are punctuated by numerous meetings between the developers and the client: planning of the sprint, demonstrations, retrospectives... These meetings allow the partners to work together in complete transparency, to better understand the respective stakes and above all to capitalize on the good (or bad) practices observed, with a view to continuously improving the process.
The conditions for a successful EPM project using the agile method
The principles of agility are therefore perfectly suited to a performance management project, provided that certain conditions are met. The first is linked to the availability of the business. The strong involvement of users is necessary throughout the project, including during the development sprints. This investment is then largely recovered during the acceptance phase. The second condition is the presence of a business project manager, called Product Owner, who is responsible for the final solution and the functionalities that it must integrate. The Product Owner must have an excellent vision of the target in order to act as an arbiter on contentious issues, guarantee compliance with deadlines and budgets, and avoid the drift associated with the development of functionalities without strong business value.
These two conditions are prerequisites for any agile project. In the context of an EPM project, it is also essential to define the project's stakes and objectives upstream, as well as the specific constraints linked to the context or the chosen solution. These elements will define the framework within which agility can be implemented. For example, some solutions allow you to easily add an analysis axis to the data model, while others impose a fixed model that is difficult to evolve during the project without impacting the cost or the timeframe. It is the integrator's role to highlight these constraints so that the client can make an informed choice and understand the stakes of these decisions.
If the above criteria are correctly addressed, the agile method is not only perfectly adapted to this type of project, but it can even save a project from failure. How can it do this? By focusing on customer satisfaction and the relationship between the partners, rather than on documentation and contractual negotiation, and by allowing to progress progressively and confidently towards the expected result. Pragmatic and constructive, this vision should be used whenever the conditions allow it.
