Table of Contents
We are ending our series dedicated to IT vendor management with an article on the efficient ending of the development phase and further project support. When the project is so close to the release, it’s easy to become overwhelmed and miss minor things that might later have a big impact on the product. Below, we will walk you through the main considerations when ending a development phase and will also explain how to properly structure a support and maintenance project.
A brief overview of software development stages
In order to understand when to prepare for the product testing and release, it is important to understand the project lifecycle and development stages. They are:
- Collection of the requirements: a client approaches a software vendor and explains their product idea. The vendor then collects project requirements from the client in order to provide the best solution.
- Negotiation: during this stage, the client and the vendor normally negotiate the team composition, list of features to be developed, technological stack, deadlines, and budget.
- Product development: the most important stage where the product is actually created.
- User acceptance testing (UAT): a highly recommended phase that we’ll talk about in detail below.
- Maintenance and support: after the product is released, the development team will be supporting it to timely identify and eliminate any bugs and implement further improvements.
We’ve talked about the first stages in our previous article – now let’s focus on the end of the development phase and preparation for the product testing and release. But before that, we need to understand what’s UAT and how it can help you ensure the product is ready for end-users.
User acceptance testing and its importance
User acceptance testing, or UAT for short, is a form of testing performed by end users to determine whether the product can be accepted. UAT comes after the end of the development phase and implies creating real-life conditions for the product. This can be achieved by performing load testing, deploying real systems that are in use, and attracting a number of users that will ensure a real-life load. The main goal of UAT is to ensure the infrastructure will handle the expected number of users and the load, that all integrations work as intended, and that there are no unexpected bugs.
Note that during the UAT stage, the development team often writes user guide documentation which can be created together with the client as well. Technical documentation is usually created during the development phase.
Best practices for ending a development phase
It’s wrong to think you can just finish the development process and call it quits. There are several things you can do to make the transition from development to maintenance as smooth as possible – here are our best practices for it.
Do not ignore UAT
Even though UAT may sound like a lot of work (and it is, actually), it’s 100% worth it. First of all, user acceptance testing helps stabilize the product which means adjusting it to real-life load and conditions. In this way, you’ll be able to detect any unexpected bugs at an early stage before they reach end users. Secondly, user acceptance testing can help you cut down development costs since you won’t need to quickly adjust the product after its launch. In addition to that, UAT helps retain customer loyalty and trust since an unsuccessful release may result in lost customers.
Gather a focus group
Another way to test the product’s usability is by gathering a focus group composed of loyal users that are willing to share their feedback and look for any ways to improve or fix bugs. When testing with a focus group, the product is already in production but it’s not announced so focus group participants can help you make sure the product quality is sufficient. Focus groups help avoid big failures after big announcements, detect inconsistencies, and overall share their ideas and feelings about the product.
An important note here: the main difference between a focus group and UAT is that a focus group discusses a product together and the main feedback would be regarding people’s emotions and feelings. User acceptance testing, on the other hand, happens one-on-one and people will be more focused on the performance of the product.
Prepare an infrastructure for feedback processing
After you release your software product, you will be receiving lots of feedback from users so you’ll need a scalable and robust infrastructure for that. Note that feedback collection will be happening during the UAT, during the focus group testing, and right after the release. Hence, chances are high that you’ll need to process massive amounts of information and you need to prepare for that in advance.
A few examples of processes to set up and take care of include:
- The history of feedback and queries processing;
- The way of providing a response to the feedback;
- Duration and conditions of incentives (for end users who agree to test your product).
Employee training
When the product is finally ready for release, your employees also have to be ready for it. That means, they will need to learn all the intricacies of the product in order to provide support to the customers, if needed. As well, the in-house team has to efficiently communicate and collaborate with the vendor’s team in case any questions arise regarding the product.
Starting a support and maintenance project
After the development phase is over and you’ve performed UAT and/or focus group testing, it’s finally time to enter the support and maintenance phase. Typically, the development team structures an S&M project – let’s see what it is and how to do it right.
In general, there are three levels of support:
- First-level support: this happens between the customer and first-line employees from the client side. An example would be consulting a customer on a banking-related issue – in this case, the bank itself can handle the situation.
- Second-level support: when the client resolves issues within their own technical center.
- Third-level support: when there is an issue with the software product itself and the client has to address the development team that worked on it.
An IT software vendor normally provides third-level support which implies maintenance of the software product, elimination of bugs, implementation of improvements, addition and removal of features, and similar tasks, aimed at adjusting the app to the users’ needs and the environment. However, you can’t just perform these tasks “on the go” – there are several things to consider in advance (and some of them are negotiated as early as during the contract signing).
Define the response time for different tasks
When the development phase is over, you will naturally have fewer people for project support and they are usually not available 24/7. Hence, when negotiating the terms and conditions for the project, it is vital to agree on the response time for different tasks, depending on their priority. For example, a critical bug would call for a response within one day while non-critical bugs or tasks can wait up to several days for a response.
The terms and conditions for the response should be documented in the contract to serve as a base for future negotiations.
Create a detailed Service Level Agreement (SLA)
In addition to defining the response time, you will also have to define the maximal number of incidents that the support team will handle as well as the working hours for the support team. It might be a 24/7 support in case the product is critical or it can be supported during working hours and weekdays only. These things are also discussed during the contract negotiation stage and are included in a Service Level Agreement that you’ll need to create as an annex to the main contract.
It’s usually up to the client to decide what kind of reactions (support) he expects for different kinds of incidents and tasks. Task prioritization is also the client’s responsibility.
Note: support and maintenance project is usually defined and described in an additional agreement that comes as an annex to the main contract. This agreement describes the type of support (third-level), incidents that require a reaction from the vendor’s development team, support process (starting from level one), and responsibilities of both the client’s team and the development team.
Pay extra attention to the stabilization period
When the product enters the maintenance phase, there will be a stabilization period during which you will probably encounter many unexpected bugs and edge cases. This period usually lasts for several months and thus, to minimize the impact of bugs on the product and eliminate them, you’ll need quite many developers. Therefore, when planning your S&M project, make sure you will have enough developers during the early stage of the maintenance phase. In this way, the team will be able to quickly adjust the app based on the occurring edge cases.
Bonus: test not only your product but your support team as well
When you are ready to release the product, you normally test it to make sure it handles the real-life workload – but what about testing your support system to see how well it will handle the same load?
It often happens that clients overlook the need for testing their in-house support system. This includes training first-level support employees and testing their work, collection, and maintenance of documentation, or feedback processing. All these processes have to work smoothly once the app is in production and thus the client has to test the in-house support system in advance so it can be adjusted immediately.
Comments