Transforming IT is a painful experience. Projects feel they have an unequivocal mandate to change. But the business pushes against deployment. As a result, costs mount and the dreaded ‘m’ word looms large – mop-ups. Business readiness bridges the gap between ‘users’ and the IT machine.
Following a recommendation, I was asked to represent the needs of 5,000 colleagues during the deployment of Windows 7. The project included rationalisation and standardisation of apps, an email server upgrade and network upgrades. While my job title was Business Readiness Manager, I put on a Change Management hat.
I set high standards. In particular, I wanted to:
- leave no-one behind. Teams separated by software become separated in work.
- minimise business disruption. Modern employees cannot work for long without their productivity tools.
My two masters had different ideas:
- The IT project wanted me to make the business comply with their plans.
- The business wanted me to eliminate any work they had to do.
Managing the change
While I set up robust readiness processes, most of my activities focused on managing risk and issues.
- The same project team had implemented the same changes across our Berlin site. I visited the site where my German colleagues told me about their experience. I distributed my report and recommendations throughout the project and business.
- IT colleagues, a Big Four consultancy and two specialist IT firms made up the project team. I built an understanding of their goals, plans and methods.
- I listened to the business, understanding what they needed.
- I communicated value to both sides. The business learnt of the benefits of the transformation and the IT folks learnt about the business.
- Sometimes I had to persuade the project to change its practices. For instance, I insisted on a pilot at the start of the project and go/ go no gates before each deployment. On other occasions, I had to be firm with the business as some teams and individuals tried to opt out.
Most of all, I focused on the outcome. Approaching each risk, issue or concern analytically and pragmatically. On the people side, my solutions included training, better communications, hands-on support and rescheduling. I also asked the project to change. For example, changes in architecture and scope.
The results of change management speak for themselves
We experienced some significant post-deployment issues and chronic problems with the hardware and build. So, I reviewed every issue with the affected user. I directed project support to urgent cases and demanded interim solutions when necessary. We held business only reviews to agree the close-out of each deployment. We accepted no open issues and escalated repeat issues.
By the end of the project, we closed deployments within two weeks. Only people on extended leave, e.g., maternity, or overseas placements remained on the legacy systems. I built a BAU (Business As Usual) solution to give returners the latest IT. I ensured all new starters got the right standard of hardware and access to infrastructure.
The project deployed new hardware and systems to 98% of 5,000 people in less than six months – with no mop-ups.
Business outcome focus – ensured business and project readiness. Drove issue resolution. Led lessons learnt. Scheduled deployed around business constraints. Delivered business compliance with the readiness process.
Communications – sent emails from the group President to enforce compliance. Built a network of champions. Rewrote corporate communications and how to guides. Used email, documents on desks, team meetings and the intranet.
Business analysis – created and maintained a list of all users with crucial data and change control. Audited application discovery by individual and function. Understood business critical periods, processes and programmes.
Risk and issue management – identification via a network of champions, functional representatives and lessons learnt. Shared the IT project RAID log. Held regular reviews and managed escalation. Maintained a local list of post-deployment issues, drove and confirmed closure.
Project governance – introduced standard, common terminology. Reduced the cost of IT processes, implemented, go/ no-go gates and close-out reviews.