So, you have 4-5 months of developments behind and you’re getting ready to launch the system. The SYSTEM. You expect a big WOW, champagne has been already cooled… The truth is – launches are the most stressful moments in every project’s lifetime, both for businesses and for IT teams. How to prepare and what to expect?
Apple’s keynote events are often set as an example of ideal product premieres. So , you visualize your system’s launch as one of Steve Jobs’ presentations. But, if you’ve read Walter Isaacson’s book about Steve Jobs, you know you should expect rather lot of stress, still not working features; even hours before the show (check out the story about Mac premiere in 1984).
The deployment of enterprise software is often more complex that the one of customer products, mostly because:
- Your company must go live early; often too early; for example before Christmas (in eCommerce). There isn’t enough time to test every aspect of the project.
- The system being deployed is only a part of the puzzle: Often you have to modify ERP, CRM, and WMS, and check all integrations along the way. You unavoidably bicker with other system providers, trying to coordinate everything at once.
- Nobody wants to hear bad news about deadlines. Expectation have soared, promises have been made – it’s easier to turn a blind eye to the shortcomings than, maybe, put off the launch, even if you see warning signals on the horizon.
We’ve worked on 150+ projects so far and I can tell you this: We had most successful premieres when the clients were (as we thought at the time :)) a little bit paranoid, continuously looking for the weakest points, not trusting us or their own teams.
It’s like going on stage and giving live performance – everything has to be top-notch.
From my experience, the time needed for tests, stabilization, and going-live makes even up to 25-30% of overall project schedule. It means 1 month for each 3 months of development.
Why is that?
Implementing medium to large systems requires as minimum following pre-launch stages:
Performed by a vendor – often done on a daily basis during sprints. Vendors very rarely are able to test whole processes. They test a feature by feature, which means that very often you get systems with some logical errors, like passing bad values from / to ERP and so on. For you – “it works”, for your client – “It sucks”. You’re both right, but up to a point only.
From my experience it’s the most crucial part as it has to be done by the client’s IT team. Make sure your communication works fine. Test everything: orders, products form WMS. Check not only 1/0 data passing but also use your common sense to make sure that the data is correct. Review entire business processes. Do they work smoothly?
What’s most important here? The communication. Teams are connecting unknown to unknown; I mean systems being connected are not known in details by other party. Often I saw neglecting poses on both sides, like “What a crap, we won’t integrate with this”, “Why they don’t …” … This way will lead us to blind alley.
Another way to optimize the tests is to prepare a detailed and – most of all – up-to-date specification of all interfaces to base on. It minimizes the chaos on both sides. But keeping the documentation updated isn’t easy.
Select most communicative and enthusiastic guys on both sides and make them communication coordinators. Order full time engagement for at least 2 weeks to do the tests and implement fixes.
Tests performed by a product owner and often by a whole team who is going to use the system. From my experience it’s better to first test an app in a smaller group of IT enthusiasts – the people who are more or less open to finding bugs and who won’t get discouraged by them as they go. Make them understand the process of UATs. Running tests first on a large team of, say 10 category managers can cause irritation and a waste of time. What’s even more dangerous is selecting the wrong group of people. This can generate resistance to further system adaptation. At this stage there are still lot of issues in the application. It’s normal. If somebody keeps moaning: “What a crappy app, it only wastes my time!” – he or she isn’t your best choice as a tester.
It takes usually 2-4 weeks to test an application using all test scenarios. The scenarios should be written by a vendor OR your business team based on a specification / user stories. It’s crucial to have them. They should describe overall end – to – end processes, like executing orders and so on. Your provider needs at least 2-3 weeks to implement any fixes.
How many issues is it OK to have in an application at this point? Hard to say, but from my experience having 100-300 issues in a system that’s been developed for 6+ months is OK. Most often you’ll be able to fix them in 2-3 weeks at a standard pace.
Pre-launch / Soft-launch.
It’s a good idea to prepare your final users for a new deployment. If it’s feasible, it’s good to have 1 month or so for launching two versions (old and new) of the application for a selected, enthusiastic user group. It’s like A/B tests (showing a new application to a group of users while maintaining the old version for fallback). Gather feedback. Prepare incentives, like prizes for the best test results. Make it happen – which means – don’t pass over tests without any issues received. It means nobody bothered / tested; it doesn’t mean system is just great. No system is great.
Because users often have a very different perspective than your company does, a lot of issues will be scored as trivial or negligible. It’s extremely important to have the priorities set by your product owner. To distill what’s really worth implementation BEFORE you go live. Of course, gather and plan insights for further development, as well.
Checklists rule the world – you must plan the zero-hour in advance! Set buffer time and have a plan B – a fallback. It’s like planning meticulously every minute of deployment: When do we start the deployment? How long will it take to update DB or the application? What to do in case of issues? How to reverse the process? … Really. The stress is overwhelming and without a plan drawn up it’s easy to have some costly missteps. Prepare for that.
Most importantly, be prepared for a custom software that doesn’t work like a box solution from day one.
There’s no other implementation like yours in the whole universe. I mean it. It’s customized – with unique processes, logic and integrations. You need up to few weeks to stabilize it and to discover all the nuances. Don’t blame anybody. That’s the way it works. You need time – count it as a normal development time and plan in advance a few weeks of buffer time for internal tests and pre-launch.