When was the last time your IT engineer wanted to implement a new technology?
Did he say, “we’d like to do the installation tonight, it should be up in the morning.”
When the new appliance conflicts with your legacy applications, your operation may come to a grinding halt.
How to avoid this common pitfall – it’s really quite simple. In ITIL parlance it’s called “Change Management.” In the MAPIT® parlance we call it project planning and project management.
We see this happening in IT projects all too often. What causes a simple upgrade to take down your whole operation?
It’s very simple – no IT project is simple. There are a multitude of complexities in even the simplest IT project. Engineers cannot plan an IT project in their head. That’s where project planning and project management methodologies come into play.
Whether it be 802.11 auto-sensing, VLAN configurations, file synchronization, active directory trusts, group policy, white lists, or driver compatibility, the more the implementation is formally planned and systematically tested, the higher the chances of success.
The process of backup and restoration procedures must be developed and documented before the scheduled downtime. And possibly the most important factor is communication – before, during and after.
When the user-base knows about scheduled projects and downtime, their activities, needs and priorities can be balanced with necessary IT improvements.
IT projects (change management) should not cause problems (problem management). If an IT project is properly planned, resourced, communicated, tested, backed-up and verified, then not only have you done your due diligence to prove the upgrade will work, you will also have an idea of how long, and how complex the implementation might be.
And if for some reason, after all your testing and preparation, the implementation doesn’t work, then your backup and recovery plan will go into effect to get your operation back on track.
Don’t let projects cause problems!