Supporting Projects That Just Went Live

Contributor: Vladimir Tutov, PM at Archer Software


This is it! Your project has finally been released to end-users. Now it’s time to sit back and wait for the positive feedback to start rolling in. In the meantime, what should you be doing with the technical side of the project?  How can we maintain our new product in the most efficient way? That is, with the fewest resources necessary. Let’s review what the average support process looks like.


1. Monitoring

Once the project is online, we should be aware of all the faults and problems which our hardware and software might experience. 

There are a lot of tools that help us  do this. We can either restrict ourselves to existing tools that alert us to major critical events and send notifications to admin e-mail addresses, or use more sophisticated tools (like Monit) which allow users to define custom rules and actions based on case-specific needs. The big thing here is to monitor major events and process adverse scenarios. 


2. User feedback

Another important point is to collect and process feedback from users. This process should be facilitated in our newly-released product with corresponding forms on the web-site, pop-ups in the application itself, or as feedback on the AppStore / Google Play.


3. Emergency support

Let’s assume you’re facing a critical issue and you don’t yet know the reason-it could be hardware, it could be software. What should you do in a case like this? In order to avoid interrupting your business, you should have a technical support team (at least a NetOps engineer) on hand to deal with just this sort of dilemma. 


Depending on the product type, it might require different support terms. Healthcare products, which might be depended on in life or death situations, often have a 24x7 support contract with almost immediate reaction time (up to 15 minutes). Less critical projects usually have limited support, which doesn't require an allocated engineering team and supposes a longer reaction time (usually within 1 business day). 


Naturally, the cost of support is proportional to the size of the required to deal with emergencies, and inversely proportional to the length of that team’s reaction time. Support terms must be precisely matched with the needs of the project in order to provide assistance when end-users need it while, at the same time, avoiding redundancy. 


4. Ongoing improvements

Even though you’ve presented the product to the end-users you should not expect that development is finished. This is only a milestone – your project’s first birthday. For the rest of its life the project will be developed and adapted to fit end-user requirements. The adaptations can include new features, design improvements, or even changing features in order to more smoothly fit user requirements.


Of course, you need to have a development team to implement all of these post-release changes. The The required volume of monthly improvements differs for each project and period, sometimes significantly. It’s usually better to have a flexible support contract with minimal required volume, so you’ll be sure that your provider will allocate at least minimum time, but you can also count on wider support when it’s needed.


Usually after several months or so, living project collect a bunch of new requirements which eventually turn into new full development phase. This, however, is beyond the scope of project support.


Support teams vary significantly depending on the project, but they’re always important. Even if you’re using a global product development strategy it’s vital to keep all facets of product support in mind. When it comes to supporting your new project, it’s always better to trust professionals who know how to provide balanced, detailed, and comprehensive coverage.