Implementation planning and architecture
The first and the most important thing for every project is planning. And a great way for planning is to start drawing the phases, and from there, adding the timelines, the activities, resources, deliverables, etc. There are methodologies that can help you to structure all those project elements in a way that are visible and understandable, and easy to follow for all the team.
Methodology is a formal technique that has structured procedures in an orderly and comprehensive fashion. A correct sequence of tasks, and ensuring all required resources and artifacts are managed properly throughout the lifecycle of your project, is essential for a successful implementation.
During a finance and operations implementation, the customer investment increases over time, regardless of the model or methodology used. But reducing the time to usage and delivering value for customer is a goal. You can plan to go with a single Go-live and start your live operations with all the functionalities in one shot. The other option is to release functionalities to production within multiple rollouts (multiple go-lives).
Iterative and Waterfall methodologies
It is important to select the correct methodology for your finance and operations implementation project according to the business solution and considering the time to value. Here we present the most used methodologies in these implementations.
Waterfall methodology
The Waterfall methodology is a sequential approach. The project is divided into different phases that flow from the previous phase to the next phase until the project is finished. Each phase is thoroughly documented with clear deliverables, reviews, and approvals. Usually, the next phase in the Waterfall methodology does not start until the previous phase is finished. For example, if you were to implement finance and operations apps, all the requirements for every integration would need to be defined before developers could begin development.
Generally, these projects have long timelines and perhaps several months of design and build activities. It may face requirement distortion, knowledge atrophy, and increased uncertainty about the following phases. Furthermore, it is more common that issues are detected late after development and testing are being executed, and it could fall into several testing cycles, and extend the timelines, delaying the project.
The Waterfall methodology should be considered when the project is simple, the requirements are known and well-defined, the full scope of the project is not intended to change, and the project is implemented all at once.
Iterative methodology
An Iterative methodology focuses on continuous feedback to alter and add deliverables to the project. Unlike the Waterfall methodology, iterative phases can loop back into each other. This means that different phases can be worked simultaneously.
For example, if requirements are defined for one integration, the developers can begin working on that integration even if other integrations are still in a requirements-gathering phase. Usually, iterative projects are separated into sprints, which have a defined duration (usually one or two weeks). These sprints have a list of deliverables to be finished during the sprint.
The iterative approach is useful when the requirements are unclear when the project starts, additional requirements or deliverables are expected over the lifecycle of the application, or if the project does not need to be released all at once. It is also good for user-driven projects, especially if the project team is fully devoted to the project. Because the iterative approach involves many players who are working on different pieces of the project at the same time, communication and coordination of the project can be difficult. Therefore, it is beneficial to have the project team in regular contact.
In every sprint you can have feedback and validation, you can detect early any potential issue, you gain more knowledge through repetition and create developments with more confidence.
Because of the iterative nature of this method, it can be complex to track. Work is frequently reprioritized when deliverables go past the original sprint or if new sprints need to be added later.
Other risks that this methodology has are having more parallel activities, needing more customer resources, being more disruptive to an organization by facing change management challenges. Scope may slip from one iteration to the next.
It is important when planning to use the adequate methodology, according to the phases, time, quality, and budget of the project.