Changing IT roll-outs into stakeholder-led implementations

When rolling out new IT infrastructure to a large number of client sites, it is tempting to consider it to be the same project over and over again.  But while the project may be justified in terms of the standardisation of technologies across the corporation, how those technologies get implemented and exploited by each business area may be substantially different.

Philpic1Phil and his team recognised that the crucial factor, the thing that would make-or-break this global project was not the technology but the differing business contexts and stakeholders concerns that each roll-out would deliver into.  A previous attempt at implementation had been a costly failure – the business knew it and needed other options.  Fifty-seven countries impacted;  12,000 applications reduced to just one thousand; the very way that users could access their PCs would change with admin rights removed from all personal computers.  These changes were far-reaching, and their instigation by a central controlling group was unlikely to meet with group-wide excitement and positive emotions!

The business agreed a new approach was necessary.  The first actions taken by the project manager, Phil Urwin, was to send members of his team to visit the twenty hub-countries and establish the stakeholder success criteria.  What would make it good for them at their site… in their words?  Phil’s aim was to convert the technology implementation into a stakeholder-led programme.  Each site visit resulted in a 2-page summary of what mattered to the local stakeholders, and each site was different.  Some reported non-technical users who would need hand-holding –  others reported good technical skills.  Implementation no-go times, PC wants and needs- all captured succinctly in the 2-page mandate for the site implementation.

The rollout project was a large initiative for the company.   At the Head Offices in the UK,  the normal governance structures existed – “these role-based stakeholder engagements were engaged through formal structures, but often there was little interest from them beyond getting a view about the status of the project.  It was with the agenda-based stakeholders that we needed to focus our attention.”  The project established open channels of communication with these groups using webex or whatever medium best suited the participants.  Before and during the implementation this was crucial and resulted in at least weekly meetings.  While the project team took responsibility for the initiation of the meetings, the agenda was driven by the stakeholders – it was definitely their meeting.

With fifty percent of the programme rolled out and four of the largest implementations completed the signs are good.  Customer satisfaction ratings were previously 2-3 and during and post the implementation moved from 4.1 to 4.6.  When asked about the lesson learned from the project, Phil describes two critical areas:

  • A stakeholder-led project. Right from the start, the project outcomes were aligned to the needs and agendas of stakeholders in their own business context.  Phil does not talk about the technology or what it could or could not do – his total focus is on addressing these concerns.
  • Stakeholder-focused, “like-minded team.” It’s not enough for the project and project manager to be stakeholder-focused this attitude and approach must be propagated throughout the whole team. Following the process is not good enough (although the process matters) the understanding and buy-in from every team member is crucial to translating good ideas into a reality on the client site.

Phil Urwin is currently a programme manager with The Grangeside Group.  In September he will be presenting at the New Zealand Project Management Conference in Christchurch on how to recruit the right project manager, develop and keep them. http://www.projectmanagementconference.org.nz/

My thanks to Phil for taking part in the Success Stories Shared initiative.

SSS-logo-smallSuccess Stories Shared is a South African initiative to encourage sharing across the project community. Driven by Louise Worsley & Linky van der Merwe, you can find these stories online on this blog site or at http://www.virtualprojectconsulting.com/success-stories-shared/

If you have a story to share, please do contact us:

  • Louise Worsley: lworsley@pi3learning.co.za
Advertisements

The simple upgrade which wasn’t:

Lessons from upgrading browser software

top-10-reasons-to-upgrade-your-accounting-softwareWhen IT recommended to the business that a simple PC software upgrade was needed, nobody thought it would be a major problem.

Within six months the software would no longer be supported.  Of course, it was a large upgrade – the Head office and over 400 high street stores; a total of 30,000 devices would be affected, but the IT department was confident that there would be no impact on operational systems.  The initial plan was simply to send out the upgrade links to users explaining the necessity of the upgrade and asking each person to follow the link and upgrade.  It was clear early on that this was simply not having the desired effect.  Even when managers were engaged and asked to oversee the implementation, there was an estimate of over 50% of the company not reacting to the emails.

The business change manager appointed knew that a much more structured approach where the software was ‘pushed’ to the devices would be necessary.  He was also aware that this approach would not be universally popular.

First find the PC!

An early problem was identifying all of the devices that needed the upgrade.  While it was clear for the stores, in Head Office there were a whole variety of devices, from laptops to cell phones that might be affected.  It was only a year earlier that the IT department had implemented a similar company-wide upgrade of the operating system – so it was with some disappointment that the change manager found that no accurate record was available of what devices existed and where.  (Authors note – the lack of configuration control of IT devices has been noted in other stories – it just seems too difficult to do, resulting in the repeated exercise of ‘first find the PC’!).

“We thought once we knew the devices the upgrade would be easy.  It turned out to be quite the reverse”, reported the change manager.  One of the key operational systems just would not work with the new browser.  This system was so critical, all changes to it were controlled centrally by a specialist team.  The sad thing was that these implications had been known for some time.  As the change manager suggested, “it was almost as if the IT technical people in the know were too afraid to bring forward the bad news – we should have known earlier about this problem.”

The decision lies in the hands of the business

Every one of the functions in the operational application would be potentially be affected by the upgrade, and there was no way, except through a screen-by-screen check of identifying the implications.  “After eight weeks – we could report was that it should work but with insufficient time for full regression testing the only way to test was to get access to the model office environments.”  As in most businesses, this testing environment is extremely hard to get access to, and the team could not yet estimate how long they would need in the model office.

In the end, it was decided to go to the project board. In this business, this was a very well structured group empowered to make and carry through decision across the organisation.  The change manager prepared and presented two options:

  • Option 1: Stay with the unsupported software until regression testing was complete. Support ended within four months, but it would take 12 months to do full regression testing
  • Option 2: Go-live and fix on failure. Operational risks were assessed and presented.  These were very real risks including loss of income and reputational risk.

The board selected option 2.

A fix on failure approach

The change manager worked with his team to define the approach.  The 80% most common transaction screens were identified, and this was the focus of error checking before going live in a selected store.  Once sufficient usage and fixing had occurred then a national roll-out to the remaining 400 offices would be instigated.  In the meantime planning for Head Office implementation, which involved the more complex identification of devices, would start in parallel.  For the initial store implementation, the upgrade would be applied to all but two devices.  These two devices would then be available to staff to use should there be problems in operation due to the upgrade.

The change manager had chosen to lead the briefings and be onsite during the week of the initial implementation to ensure he was there to help fix things if they went wrong. The implementation “mostly worked,” but there were critical actions, such as being able to print till receipts, which just wouldn’t work.  It took tenacity on the part of the change manager to persuade the IT team of the all the issues that were being faced by the staff.  It took two months to satisfactorily complete the store test implementation with all of the fixes that were required and the to-ing and fro-ing between the project and the IT team.

During this time, the upgrade built a reputation (often unfounded) as the cause of any problems which might occur on any system.  “Oh, that is probably caused by the new software upgrade.”  The change manager recognised that for the wider roll-out to be successful and acceptable, it was essential that a well-controlled and managed store-by-store roll-out be established, and that confidence in the roll-out process was regained.  He insisted the second store implementation should occur in a particular location so IT could be closer to the problems.  “I needed IT to see this, understand the issues faced and react quickly.”

After the early slow implementation, store roll-outs could be expedited with 100 stores implemented in just a week.  The total implementation of all stores and Head Office took six months.

Our take-aways

In reflecting back on the project the change manager identified a number of learning points:

  • Decision-making around this had to be firmly in the hands of the business. Only they could decide what risks they were prepared to expose the business to.  This was done well in this business.
  • Sometimes getting IT to react to problems was hard. “My contact in IT was hard to engage with, but my feeling is that there will always be difficult people on a project – senior and junior – it’s just about finding ways of getting things done.”

And with respect to the Head Office implementation:

  • We found we could not rely on the organisation chart in Head Office to work out who reported to who and where they sat to help us build up a picture of who we needed to engage with. So we started at the top of the organisation, talking with PAs and support staff to identify the people in the top three layers of Head Office. We opened up communications and consulted and worked with this group to agree on the roll-outs.  This worked pretty well, but it turned out there were influential and high energy stakeholders in the lower levels that we missed.  This did prove to be an issue.  Just because somebody is junior does not mean they cannot significantly impact the project – something to look out for on future projects!

This project has been anonymised.  Many thanks to those who helped us in compiling it.  For further information on the Success Stories Shared initiative click here. If you would be happy to take part in this initiative do contact me – Louise Worsley, lworsley@pi3.co.za

The stakeholder-led project

City of Cape Town Integrated Rapid Transport (IRT)

As part of the build up to the 2010 FIFA world cup the City of Cape Town embarked on the development of an ambitious new IRT system which would provide bus transport into and across the city.  In phase one the aim was to provide transport links from the airport (addressing the needs of the increased number of international and national passengers) and from selected northern and central areas where roads were increasingly overloaded (addressing citizen’s needs for improved town transport).  The IRT project was a critical infrastructure project and 2010 FIFA gave the city the energy, and publicly recognised urgency needed to get it happening.

Continue reading “The stakeholder-led project”

Bridging the divide between the business and IT

bridging the gap

Regulatory, mandated changes to financial systems and processes are common.  Rarely popular with internal stakeholders, these projects struggle without strong political support.   In 2003, Dale was working with a UK asset management group (referred to here as UK-AMG) faced with a mandatory change which was neither popular nor, as it turned out, simple to implement.

Continue reading “Bridging the divide between the business and IT”