Case Study
Using the Product Factory approach to accelerate delivery at a utility company
This study shows how a utility company cut costs by 60%, and reduced lead times by 75%, using the Product Factory approach. It also explains some of the other benefits that the approach brings to companies looking to scale their accelerated delivery capability.

These include:

• Better definition of products being produced
• Improved utilisation of cross functional teams
• Reduced lead time through better understanding of work
• Better quality with consistency reducing the cost of quality
• Early insight into cost/benefit informing on whether to proceed
• Increased success rate of projects through knowing that they comply with business standards
• More effective navigation through legacy environmental constraints (which previously forced the business down less-flexible, a large supplier only, approaches)

Background
The business had already gone through a massive organisational change to the way they work, in adopting accelerated delivery. This produced a group of very productive work streams, who were now able to communicate the work they were doing, and understand the issues that were arising from the way that work works.

It is important to remember that this business is a utility company, so it is vital that we do not introduce practices, and overheads that do not directly add value. In short we should always prefer to buy rather than build the solutions to the business requirements.

However it is also important to realise that there is a world of work that goes on at any sizeable company, which is bespoke to that organisation, and in some case there may just not be an off-the-shelf solution. This fact should never detract from the company’s need to put their customer and/or users at the heart of any solution they deliver. 

Situation
With the advent of accelerated delivery, work streams were much more able to start projects, and track their progress. This quickly showed that the work streams needed to have a certain amount of capability from testers, architects, user experience designers, business analysts, etc. These disciplines had previously been available, and were seen by the business as operational overheads.

The growing requirement for these technical disciplines, led to them being referred to as cross functional teams. At first this was fine, as a small number of people were able to deliver these skills across the business.

Scaling these cross functional teams is where we identify that seeing the work of the cross functional teams as operational overheads is obscuring the net value of projects.

This has a number of knock on effects:

• The net cost and benefit of a project is harder to compare across the business
• The quality of project delivery can vary
• Context switching means that technical work has lots of downtime during delivery cycles
• Work streams, are tempted to circumnavigate process to speed up delivery
• While not an exhaustive list, it reveals that, far from helping the work streams, the cross functional teams are seen as gatekeepers who could potentially derail projects that work streams had already expended effort and money on.

Task
The work streams were looking to grow their own capability, and beginning projects using what resource they could to start implementing their own solutions. To prevent the business from undoing the great progress that they had made, I proposed that we enable projects to get the cross functional support that they need, without slowing down their pace of delivery.

I explained that this would give the work streams a number of benefits:

• Enable to cross charge the support they get from cross functional teams.
• Consider the cost / benefit of this support
• Get the appropriate level of support
• Scope and time box this activity
• Have the involvement as early as possible and ensure that the value is delivered
• Ensure that the project succeeds
• Ensure that the project holds true to the values of the business
• By changing the approach to solution delivery the business also gains the ability to achieve its stated goal of, Stop starting start finishing.

Activities
To make this possible we need to stop working on projects, and start delivering products. Working directly with work stream leads, I began to ask their consultants to productise the projects that they were suggesting.

All too often it was hard to find the business value in a project, sometimes due to vanity projects, or projects that were sponsored by a technical concern. Productising forces the sponsor, or product owner to put a customer first and consider their reasons for wanting the product.

As soon as the idea of a product is formed, it is given a collaborative space (a product homepage on SharePoint or similar), and from that point, all project material is attached to this homepage. So from brainstorming output, through sketching, prototypes, test output, to the final readiness report, it is possible to prove that the product has acquired the value that the business requires.

This is the “Product Factory, the place where an idea is brought to life, validated, and delivered. The collaboration homepage is now also surfaced on the Product Factory board which shows the inception, consideration and delivery phases of the process. The process is subdivided into seven activities, and a decision to proceed stage, represented by columns on a board.

These are:

• Inception
• Product Definition
• User Experience
• Technical Understanding
• Consideration
• Delivery
• Scoping
• Elaborating
• Delivery
• Going Live

Cards on this board are products, and their feature/story delivery is tracked on Kanban/SCRUM boards with the work streams. The activity to deliver these features is assisted by a reactive team, a team that is stood up to deliver this product and work with the work stream as part of its staff for the duration of delivery. The work is not handed off, the reactive team will complement the work stream wherever extra capability is needed by providing dedicated team members to deliver the work.

We expect the cards to flow from left to right on the product factory board, as each of the seven activity columns is a measure of operational maturity. As the product shows that it has acquired the operational maturity by satisfying the policies in each column, it is able to progress across the board towards going live.

The policies are defined by taking the cross cutting concerns of architects, user experience specialists, and pushing them as far to the left of the board as possible. Where they require evidence, this is the opportunity for the cross functional teams to impart their value, whilst enabling the delivery team to get on with the work. We call these opportunities, Practice Hangers, as there are a number of different skill sets and practices that can be introduced at an appropriate level of rigour.

On completing the inception phase, there is opportunity to review the cost/benefit situation and allow the business to prioritise, or even scrap the project. Where the inception phase is informing the decision to buy or build, it can also be reviewed in the consideration stage.

The work streams can track the delivery of their features, and understand the progress of their product in the way that is valuable to them. Product Factory does not replace the agile practices and communications, so Kanban boards, iterations, retrospectives, etc., still happen as usual. At the same time, the Product Factory is saving work stream boards becoming too busy in trying to track cross cutting concerns.

Results
The Product Factory approach enabled a 60% cost reduction, and 75% time reduction on a number of high value solutions for the business with demonstrable ROI.

This was achieved through

• Better definition of products being produced
• Improved utilisation of cross functional teams
• Reduced lead time through better understanding of work
• Better quality with consistency reducing the cost of quality
• Early insight into cost/benefit informing on whether to proceed
• Increased success rate of projects through knowing that they comply with business standards
• More effective navigation through legacy environmental constraints (which previously forced the business down less-flexible, large supplier only, approaches)

The Product Factory approach has, so far, delivered a number products to the business. Previously these products would not have been possible due to the constraints in the traditional environment forcing the business down the large supplier route, and providing a poor return on investment.

A great use case for the product factory is a payment portal project for the company, to enable ex-gratia payments to customers. By being able to consider a more lightweight solution than the incumbent software supplier, a small delivery team was set to work on a payment portal, using a mobile application from one of the large banks.

By being able to take advantage of cutting edge, open technology, a solution was designed, with a delivery lead time shortened by 75%.

As well as reducing the lead time, the design approach meant a significant decrease in the impact of the solution on existing infrastructure. This lead to a cost reduction of 60%.

Alongside these impressive figures, comes the fact that the open technology is more compatible with other solutions currently deployed in the business. This will mean that the product will continue to add value, when new payment requirements arise from other teams, as the cost of integrating will be minimal.

Benefits
The Product Factory complements accelerated delivery to produce solutions in a way that is cohesive, transparent, and efficient. If you are finding that current accelerated delivery practice is not scaling as you might have thought, or that managing cross cutting concerns is detracting from understanding project progress, it may be something that this approach can help with.

If you have any questions, or would like to discuss details of this approach, it would be great to catch up.