Recently I’ve gone through an unique custom tester deployment in my career. And I learnt key things to take care while deploying any system.
- Ownership and Time to deploy – Keep your deployment ownership to max and deployment time to minimal. First and foremost is the clock running in your mind which keeps telling you that action you do or thinking about may take such-and-such time and it will affect the deadline. The ownership, “I’m/we’re responsible for this deployment”, lets you decide “what actions to take” and “what actions to avoid”. So, keep a clock running in your mind and be decisive that it’s your project and you’re responsible for it’s delivery.
- No new component introduction – During deployment it’s very common that you encounter with some new items to be covered under that project scope which was not realized during the development time. Step Back and Watch Out..! Don’t take up those new items, unless that are needed (mandatory) and without that running the system becomes very difficult. Never underestimate any new items and go back to develop. Few items may look easier yet will impose lot of work when you start doing it. Ensure that you have visualized all affected parts for that new item. If it’s really needed and it looks very promising and may take more time, let the stake holders know what it cost. Stake holders would have some out-of-box thought to help you simplify it. If that new item is not much important, simply take a note of it in your journal for futuristic integration, these new items could be the next business for you.
- Test thoroughly before start of deployment – Keep your test cases fixed before start of the deployment. There would be few test cases which you might relax to do it on deployment, but importance has to be given much more for those test cases. In such cases, you are postponing the test cases due to dependencies at deployment site. For eg., maybe you are expecting a different variant of same family instrument at the deployment site. This will lead to new component introduction onsite and eat your time eventually. Keeping your test case fixed and all of them tested before deployment, can make you easier to deploy. You are at risk if there are test cases shared between development-list and deployment-list,.
- Keep the stake holders updated – All the way, keep the stake holders know about the status of deployment. Unless you do this you might end up in tremendous pressure to deploy and stake holders expecting end results without knowing the bottlenecks in the deployment process.
- Training, suggestions and observations – You would need to give a proper training to the end user of your system. Keep an ordered checklist to cover for training in a sequential way so that trainees would follow it easily. Moreover, as an end-user they start giving you suggestions, comfort or discomfort in verbal and non-verbal way. Observe them and jot down in your journal, because these observations could be your next business too.
- Write journal – Writing journal will become part of your deployment as you go through.
Though I didn’t strictly stick to these 6 things while deployment, I realize that sticking to these items would help for any deployment in future.
Ajay is a professional developer and architect of NI-LabVIEW applications with extreme interest in getting the hardware connected to LabVIEW and automating the stuff. Recently he is also putting his hands in NI-TestStand to get very dirty on it. He is also a good mentor for the various interns in his career. He is ready to help the people in techie roles.
I very strongly agree with no 2, no new components. If it is really important it can be added in the next upgrade and the stakeholders can make all the pertinent business decisions that go with it.
Test any assumptions you have made as soon as hardware is available to do so.