So I am an IT Project Manager and a huge fan of Agile. I made it a must to try Agile for application implementation and with time I gathered a mix of techniques that really work and I would like to share with the PM community.
Application Implementation refer to installing, configuring and maybe customizing an existing software product (or application); such as an ERP or a Document Management application.
Most of the outdated methodologies around advice to first run an analysis where you capture all the requirements of the users, then you design the solution, then you implement it and then you test it. You know the drill. This is what I call a Requirements Driven approach: you try to map an application to the needs of a customer. Considering that the application has already been developed to fit the requirements imagined by its producers, this approach seems like a bit of a nonsense to me. Nor does it work in practice, and I've seen many colleagues Project Managers struggling desperately to fix the problems this approach brings. And what it does is induce heavy customizations and all the risks associated with custom development: uncertainties regarding effort estimations, lack of flexibility to changes in the business processes and a prolonged testing process that requires a team of professional testers before the application can be handed to the key users for User Acceptance Testing.
I use a different approach that they call an Application-Driven approach that is derived from Agile and DSDM (Dynamic Systems Development Method). As opposed to a Requirements-Driven approach, where the project starts with documenting the requirements and then the application is customized to answer the requirements, the Application-Driven approach is based on using a Gap Analysis technique rather then a holistic analysis. So the first step is to show the application as is and document only the gaps. This leads to minimizing the customizations and using the standard functionalities of the application (yes, it is that simple). This approach has the following benefits:
• Decreases the Total Cost of Ownership (TCO) for the clients since it limits the effort to maintain the customizations;
• Shortens the length of the implementation project;
• Reduces the risks associated with the project by eliminating the risks and uncertainties that are specific to custom development;
• Reduces the effort associated with the project through using development only for integration and light customizations;
• Reduces the length of the future technological upgrade projects (e.g. migrating to a superior version of the implemented product, changing the infrastructure), because there are a limited number of customizations to be ported and retested.
The approach is based on three iterations:
• Vanilla is the first iteration that exposes the users to the application as it is, with only a minimum set of configuration resulted from some initial interviews. The application is presented to the key users during several workshops. The functional consultants document the gaps between the requirements and the application;
• The pilot is the second iteration, with the application configured to answer as many gaps as possible without custom development. This application is again presented to the key users and the key users get to agree on the resolutions of the gaps;
• User Acceptance Testing is the iteration with all the gaps solved, including the ones that require development. The key-users test the application and they give acceptance for go-live.
Although I use iterations, I divide the project into distinct phases, each phase having a purpose and a set of document deliverables resulting from specific activities.
Analysis: The purpose of the analysis Phase is to obtain a unique set of gaps between application and requirements agreed by all parties involved. This is done by exposing the standard application (Vanilla) to the key users during several workshops.
Elaboration: The purpose of the Elaboration Phase is to configure the application to answer as many gaps as possible and to present the configured application to the users.
Construction: The purpose of the Construction Phase is to develop the interfaces and customizations if any, to prepare data for migration and to develop the import interfaces if they are not provided in the standard. I usually import a set of test data to have it ready for the UAT and also to decrease the risk of any surprises during import for production.
Transition: The purpose of the Transition Phase is to run the User Acceptance Testing, to provide the training for the key users and to prepare the system for the go-live. Also, I run an import test on the entire set of data needed for production. Then I prepare the production environment: install, configure and import production data.
Production: The purpose of the Production Phase is to prepare the system for the go-live. Some data will need to be imported just before go-live, the old system must be decommissioned and replaced by the new system. Users and access must be granted. I also run some non-transactional tests on the production environment (non-transactional means no saving - so there are no traces left; usually it means going through all functionalities and make sure forms open and user can access all functionalities).
I have listed below the deliverables I typically use for an application implementation.
|Analysis||Gap Analysis document - Describes the gaps between the standard application and the requirements of the Client.|
Data Mapping document - It provides the mapping between the source of the data and the future system's tables.
UAT Test scenarios - These are the agreed test scenarios that will be used during the UAT.