It’s commonplace that the business and IT are simply in a position where neither is happy. There is often a natural tension due to budgets, resources and perceived value – this is quite normal. Sometimes the relationship breaks down, and this was the case when Gray Blue was engaged to resolve a failing SAP implementation.

When business critical and transformational projects fail they have a big impact on the business in terms of costs, future revenues and savings and morale. There are a number of reasons for a project or programme to fail:

• Expectations (Technology) – the technology is not able to meet the requirements
• Expectations (Delivery) – activities are simply not completed quickly enough to meet deadlines, but not related to the technology chosen due to talent or leadership
• Communication – a lack of communication or understanding between the business and the IT provider (internal and/or external) and trust is eroded
• Resources – there is not enough people and budget to complete the required project, causing delays or simply not being able to have access to the right tools, technology or applications
• Process and Governance – there are not standards to manage the project, decisions are not made and processes to keep on top of activities fail.

There are also other reasons why projects fail, for example, a change in business strategy, new leadership or internal politics. It is harder to resolve these issues and requires very careful stakeholder management to navigate to a solution.

Identifying The Issues

We believe it is crucial to understand the issues before engaging with a solution. Resolving problems that don’t exist or are simply masking the real issues wastes time and resource. A premature approach can even make an existing problem worse.

What is important is to begin to start to tackle issues quickly and be transparent with the approach. Gray Blue identified three primary issues that were preventing the project from being successful:

• Expectations (Delivery) – the business changed its mind on what was important, and the leadership in IT was not strong enough to push back.
• Communications – the business did not know what was being worked on, this meant testing resource was not available and there was a lack of trust on timescales.
• Process and Governance – there was little process in completing development work – this meant developers took work on but it was not centrally understood and therefore could not be communicated or recorded what process was being made. Testing resource was not utilised.

These in turn led to issues with Resources, where technical people were not able to work effectively on a single task, and testing resource was allocated and left unused. This was frustrating for everyone involved – and as a result, nobody could be successful in their role.

As part of the initial pre-sales engagement it was clear that both the business and IT wanted the project to be successful. It was a case of :

Fixing Process and Governance

At Gray Blue we like to keep things simple and go back to basics. Good project delivery is not about a big personality leading to success. It’s about setting standards and letting the team and organisation know what it has to do to achieve success. Success is about an outcome, not a person – this can only be achieved when a team knows how it works together, decisions being made and quality and delivery measured.

Our client had few processes in place to ensure the team worked together and knew what everyone was doing. Plans existed, but what development was being completed wasn’t tracked centrally and regular meetings with senior stakeholders took place only when issues occurred – this led to only bad news being shared and decisions made in response to issues rather than solutions and progress.

We introduced a number of processes and governance activities to resolve some of the most immediate problems:

• Agile Methodologies – including sprints and daily stand-ups for development teams. We also cleared the backlog of testing by working in an agile way with the business testers.
• Identified A Product Owner – a member of the business was the single point of contact and took day to day decisions on behalf of the business prioritising work for each sprint.
• Introduced A Kanban Board – anyone in the business or technical team could see what work was being completed and what was coming up.
• Risks and Issues – we documented the risks and issues which made it very clear to everyone the business and technical challenges and made them transparent as well as enabled the organisation to discuss and provide solutions.
• Regular ‘Board’ Meetings – regular ‘board’ meetings with agenda and minutes created purpose to them. Progress and quality could be measured. After starting weekly, within 8 weeks they were decreased in frequency until they took place once a month as the project turned around.

Communication and Delivery Expectations Increased

Through new processes the communication with the team and the organisation increased. This enabled trust to be re-established over time and the business and technology function delivering the new SAP solution understood each others needs more. Working as a team, rather than adversaries.

The development of new functionality was transparent, developers were able to work on the agreed priority to the time-scales agreed up front. Deviation to delivery time-scales and reasons were understood more by the business, and productivity increased along with more accurate estimates. Work in progress, and work requiring testing was transparent which ensured the time to deliver new business requirements was faster.

From Failing to Success!

We are always thrilled when our customers are delighted – we are even more excited when our customers are left with a legacy of success and a foundation to do even more amazing things in the future. In this case a new SAP solutions fit for purpose, a structure to provide on-going support and development, and increased revenue and profitability from the systems and solutions we have helped implement.