Implementing Off-the-shelf Software Solutions (4/5): Continuous Feedback, Testing, and Documentation

Following on from the previous articles in this series, we are now at the stage in the software implementation process where we have selected a software solution to proceed with. We will also have established an understanding of how the solution works, through discussions with the vendor, as well as hands on experience with the software through a combination of self guided learning, experimentation, and training (where applicable). We should also be confident that the selected software solution meets the core business requirements defined with the key stakeholders during the proof of concept phase. Having completed these steps, we can now proceed with implementing and integrating this solution into existing workflows. How long this takes and the complexity of the implementation can vary hugely depending on the scope of the improvement project, but there are a few principles that I have found generally apply to all such projects.

Continuous feedback

During the implementation phase, it is crucial to continue the cycle of feedback that was established in the pilot phase (described in greater detail in article 3 of this series). By regularly engaging with key stakeholders, as well as the wider team (typically on a less frequent basis), valuable insights can be gained to ensure the project is continually aligned with the needs of the stakeholders, as well as identifying any risks associated with any given solution as soon as possible. Risk identification is extremely important as in general, the earlier a risk is identified, the less costly it is to mitigate. In the case of implementing off the shelf software (OTS), methodologies such as Agile which emphasise iterative improvement as not as commonly used, as implementation will usually be more focused on configuring existing functionality rather than building functionality from the ground up. However, there are cases where an Agile approach can be used.

Case Study: Agile for Off-the-Shelf-Software

In a previous role, I was responsible for gathering requirements and implementing Business Intelligence software with the goal of gathering metrics (performance indicators, units of work completed etc.) and presenting key information in intuitive visual dashboards. This information could then be used for reporting across the business.

In this example, an Agile approach was viable and practical, as the continuous feedback loop allowed users to provide feedback on what data should be presented, how they would like it to be presented (e.g. in terms of visuals), and whether requirements such as the frequency at which the dashboards should be refreshed needed to be updated.

As part of the continuous feedback loop, it is essential that stakeholders and users are provided with regular updates and opportunities to provide feedback. This not only allows the solution to be refined throughout the course of its implementation, but also promotes transparency, and helps to facilitate confidence in the solution.

Continuous testing

Combined with continuous feedback, continuous testing is an extremely powerful principle that can greatly reduce workload involved with later stages of software implementation projects, such as UAT. Note that while this series of articles focuses on Off-the-shelf software implementation, this principle also applies to software development projects.

While implementing a piece of software, testing will naturally happen as part of the implementation process as this is the only way to confirm functionality is as expected. However, where possible, it is always beneficial for prospective users of the system to perform tests as well, as their expertise in the area for which the software is being deployed may reveal bugs or nuances that may otherwise not be identified until later. A good approach to minimise the burden on the users performing these tests is to wait until a workflow has been established for a particular task or function, and provide clear instructions for how the test should be executed An added benefit of this continuous feedback and testing approach by end users is that by the time UAT is performed, they will already have a level of familiarity with the system, and their feedback will have been taken into consideration throughout the implementation process. While this does not guarantee that the UAT will pass first time, it improves the chances of this, and certainly reduces the number of issues identified during the UAT phase.

Continuous Documentation

Throughout my career as a Business Analyst, I have found it useful to document how the implementation of a software was completed as an ongoing activity, rather than leaving it to the end. Creating a user guide or training material from scratch after deploying a software that has taken weeks or months to implement can greatly increase the risk of missing key information. It may also potentially require you to revisit how certain workflows that were implemented early in the project work, often a time consuming process!

If documentation is created in parallel with implementation, and then refined later on, this hugely simplifies the documentation and training process and produces a much higher quality end result. This does not need to be a complex process, it can be as simple as noting down a series of steps for a given workflow in a text editor, which can be refined to be more visually appealing and user friendly once implementation has been completed.