In 2015, 80% of companies had teams practicing agile. This compares to only 35% between 2012 and 2014.
Why this evolution? Agility is based on the observation that many IT projects fail because they don't meet deadlines, costs or specifications. Constantly evolving customer needs require us to rethink models that are too rigid. Today's markets demand real-time management and a high level of responsiveness. But is agility the right approach for all types of project, and particularly for performance management projects?
While traditional EPM (Enterprise Performance Management) project development cycles used to be fairly long - from a few weeks to several months - customers now want to see tangible results in shorter timescales. New solutions, born of the Internet and the democratization of the Cloud, are appearing regularly, promising implementation times never seen before.
As integrators, it's vital that we adapt to this new situation, while at the same time adapting to the demands of our customers.
The limits of classic projects
The first risk inherent in a so-called "V" project is linked to the predominance of documentation over software. A traditional project is punctuated by the delivery of documents with contractual value, which are supposed to define the target to be reached: specifications, functional and technical design.... Hundreds or even thousands of pages have to 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 check that the product conforms to his expectations. In order to limit risks, the implementation of the solution is conditional upon validation of the design file, which describes the completeness of the expected product.
Validation of this key document is sometimes problematic, and can lead to delays in the following phases: disagreement between experts on a specific management rule, uncertainty about the availability of a source or the desired finesse of an analysis axis.... When the design is finally validated, any change is experienced as a constraint, and can provoke bitter negotiations between the partners.
The agile method helps to mitigate these risks by promoting collaboration with the customer. It aims to deliver tangible business value in the shortest possible timeframe, while welcoming change throughout the project. In this context, while agility seems perfectly suited to web-based projects, it is less obvious in the context of an EPM project, which is most often based on a more or less flexible, off-the-shelf software package, 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, both for the customer and the integrator. The first of these is to enable rapid visualization of results:
Demonstrations are organized at a jointly-defined frequency (in practice, every 1 to 4 weeks). These demonstrations provide an opportunity to check that the proposed solution is in line with expectations, or to make modifications if necessary, without waiting for the acceptance phase. Following the demonstration, the customer can immediately connect to the solution, carry out his own tests and validate the developments. This ability to provide immediate feedback has a direct benefit on the subsequent acceptance phase.
Delivering business value
Rather than delivering 100% of the solution in the distant future, this method favors the incremental delivery of functionalities, prioritized according to their value to the business and the maturity of the requirement. This means that the most eagerly awaited and stable functionalities will be developed and delivered first. It is the customer who prioritizes the topics and builds, step by step, the path to the final solution.
Integrating uncertainty and encouraging change The agile method integrates the inevitability of change by freeing itself from the traditional design file: it is unlikely, if not impossible, to have a completely exhaustive and unchanging vision of the final solution at the start of the development process. The first development sprints start with the elements on which there is consensus, while all factors of uncertainty are dealt with in parallel, without blocking the project's progress.
Strengthening relationships and capitalizing
Another major benefit of applying the agile method is its impact on the quality of the relationship between partners. Development sprints are punctuated by numerous meetings between the developers and the customer: sprint planning, demonstrations, retrospectives, etc. These meetings enable the partners to work together in complete transparency, to better understand each other's challenges and, above all, to capitalize on the good (or bad) practices observed, with a view to continuously improving the process.
Conditions for the success of an EPM project using agile methods
The principles of agility are therefore perfectly suited to a performance management project, provided certain conditions are met. The first is the availability of the business. Strong user involvement is required throughout the project, including during development sprints. This investment is then largely recouped 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 it must integrate. The Product Owner must have an excellent vision of the target in order to position himself as an arbiter on contentious points, guarantee compliance with deadlines and budget, and avoid the drift associated with the development of functionalities without high 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 make it easy to add an analysis axis to the data model, while others impose a fixed model that is difficult to evolve during the course of the project without impacting on costs or deadlines. It's the integrator's role to highlight these constraints, so that the customer can make an informed choice and understand what's at stake in these decisions.
If the above criteria are correctly addressed, the agile method is not only perfectly suited to this type of project, but can even save a bogged-down project from failure. How can it do this? By placing the emphasis on customer satisfaction and the relationship between partners, rather than on documentation and contractual negotiation, and by enabling the project to move forward gradually and confidently towards the expected result. Pragmatic and constructive, this vision should be applied whenever conditions allow.