Successful programme management at Evergreen Garden Care

In 2017, Evergreen Garden Care was established when Scotts, a large US garden products company, sold its European and Australian businesses to London-based Exponent Private Equity. Key technology challenges for the new business included; creating a standalone IT infrastructure from scratch; separating their core SAP application and a long list of other business systems; and building a new IT team; all before the pre-arranged Transitional Service Agreement (TSA) ended. 

We had undertaken IT due diligence on the deal for Exponent, so we understood the scale of the challenge and were in a good position to support the design and implementation of the technical infrastructure. It became apparent early on that the SAP separation would take up all of the in-house team’s resources, so we also took on the roles of interim CIO, project manager for the non-SAP applications and programme management of these interdependent projects. 

The programme management challenges and lessons fell into a number of categories that will be familiar to any project manager.

Scope Management

The first question; “What’s actually in scope?”. SAP was obvious, but the rest were documented on a constantly changing spreadsheet. Before project work could begin, we needed to agree which systems to keep, where they were located, on what technology, and whether to move, upgrade or replace them. 

We did this by working top-down and bottom-up, using our technical team to analyse the current IT network, while talking to stakeholders to establish clear business ownership. The original list of 76 was cut down to a programme of around 35 systems to change, categorised into ‘lift and shift’, upgrade or replace/reinstall. 

With continuing TSA costs, the programme focused on the shortest separation route possible that still met essential business requirements. In normal circumstances, a technical change gives an opportunity to roll out new features; but without the time or resources for enhancements, these were recorded as continuous improvement opportunities for phase two. 

Dependency Management

During the separation, almost everything in Evergreen’s IT landscape was changing at the same time – people, processes and systems. Key to the programme management was to make sure that dependencies were understood and visible to all interested parties. We did this using two main tools; an integrated system diagram and the good old ‘plan-on-a-page’. 

Our system diagram didn’t follow any industry recognised standards - it was designed to get the message across to various IT groups, the business, and the board, in a way everyone would understand. SAP was driving the timeline and costs, so it formed the heart of the picture. Systems that integrated with SAP were added, grouped by similar business functions and colour-coded by technology. 

When first produced, it’s fair to say that the diagram was a revelation, and quickly resolved months of confusion and discussion around scope and priorities. 

The plan-on-a-page was again kept simple. It took the core SAP implementation timeline, added dependent systems, then the rest of the projects by migration type. Key dependencies were then overlaid, such as; network trusts to be established before data migration; desktop design in place before UAT; local IT teams to be recruited before PC migration.

As much non-SAP dependent work as possible was brought off the critical path to release resources for forthcoming work. At times, this meant focusing on something that looked less important, but that would cause problems if we didn’t tackle it early on. 

Communication

It’s great knowing how all this hangs together, but it’s even better if you can explain what it means to people. The Evergreen project impacted the UK, France, Germany, Austria, Poland and Australia; with associated language and time zone challenges. A variety of communication methods were required:

• Board level governance: Evergreen’s CEO and CFO took a keen and active interest in the programme. Regular programme meetings kept them informed of issues and risks and gave an opportunity to resolve cross-function/cross-border/cross-programme issues quickly. 
• Collaboration tools: project documents were on a common Google drive and used the collaboration tools available. We added a companywide intranet site, using Google Sheets as we approached cutover. 
• Special interest groups: the system diagram made it clear that different applications supported the same function in different countries. Some of these people had never spoken to each other, so as part of the migration we called them together to explain the short-term separation approach, and start them thinking about longer-term solutions.
• Co-location: Office space was dedicated to the project so the SAP team could sit together, forming the heart of the programme with other teams working alongside them as necessary, which greatly improved the speed of resolving issues and prevented potential problems. 

Flexibility

You’ll be surprised to hear that despite this amazing feat of organisation, not everything went to plan! However, the team were able to react quickly to changing information or issues; because we understood the impact across the programme, had access to a supportive business team, and talked and listened regularly. 

Needless to say the stories we could tell are many and long. If you recognise any of the challenges we’ve talked about, or even some new ones, get in touch. We’d love to listen to your stories, and to share more of our knowledge and experience.