By David Seacombe in Insights — Jul 15, 2012

Funding Product Teams not Projects

Projects are finite. Products represent value streams, and funding a product team makes them accountable for identifying opportunities to deliver the maximum value for the lowest estimated effort, risk and uncertainty. Stable funding enables the team to deliver ROI within their calculated capacity.

Across government and commercial organisations, funding for change is traditionally approved by executive leadership, based on a prioritisation schedule of big investment decisions and historical operational expenditure.

Budgeting is a painful exercise which is, essentially, a best guess, and which often leaves project managers struggling to deliver against a budget that is set up to fail before funds are drawn down - principally due to resourcing, skills and capacity challenges.

Switching to delivering through persistent Product teams instead of spinning up new Projects pivots the organisational focus to funding capacity and outcomes, rather than requirements. This approach also improves speed to market and greatly enhances the ability to respond to new insight. With the cross-functional Product team also accountable to run the product or service, rather than just create it, quality increases and costs reduce, and it provides a direct feedback loop from the customer.

The traditional approach to funding change

Every organisation needs to change its products and how it operates, to change to stay relevant as the market evolves, consumer preference changes and technology advances. Over many decades, project funding and project management methods have evolved to allow organisations to create new value by investing in initiatives which respond to the demand to change, whilst ensuring that the resulting benefits outweigh the costs and risks of that change.

Received wisdom is that well run companies set their budgets annually, with half-year reviews, and in addition to confirming the money needed to run the company in its current guise, they select the best proposals for change - based on the merits of each business case and the perceived urgency of need to address the problem or opportunity. This discretionary work is funded by capital expenditure, money which is earmarked to be drawn down to 'change the business', rather than operational expenditure, money which is needed to 'run the business'.

Typically, the use of 'CapEx' funding results in projects with a fixed scope, an indicative schedule and a dedicated project team to execute on the plan - at a pre-agreed cost. Progress is regularly reported via an oversight function such as a Portfolio Management Office.

Whilst there are many drawbacks to this approach - including the very real challenge that the world moves on and new information can lead to a change in direction - it has evolved to work reasonably well in traditionally run, functionally siloed 'command and control' type organisations.

Challenges with Funding Projects

Nevertheless, there are a number of challenges with funding projects by one-off capital expenditure which, arguably, have never been satisfactorily resolved:

The demand for change exceeds the discretionary spend budget. When the budget is set, CapEx submissions are invited for consideration. The number of proposals received always generates a required investment amount way above the total put aside for the year ahead, so there then needs to be a way of ranking each submission. This process in itself can be challenging as sponsors each back what they see as essential spend to help them reach their bonus-triggering targets.
The demand for change exceeds the organisation's ability to absorb change. The chances are that many of the projects which made it to approval last year didn't get started immediately, or turned out to be much more of a challenge to progress at the rate expected. Either way, they are still ongoing. It's likely that more than one has had to go back for additional funding in order to progress. Not only does this diminish the money available for this year, but it adds another layer of concurrent change on the workforce, many of whom are crying out to be left to get on with delivering in their day jobs. Change fatigue is a genuine problem.
There is never enough resource available with the right skills to work on the project. If a Design Authority deems that the Sponsor's initiative is 'a good thing to do' and the Investment Committee has looked at the business case and given the go-ahead to start, then the Sponsor may reasonably expect that the project can begin straight away. BUT, it takes time to assemble a project team, and the chances are that the people who should be in this team, are already committed to working on something else, just as important! A typical response is to turn to contract resource to fill the gap, or agree a strategic souring arrangement with a third party.
Essential knowledge walks out of the door. When the agreed scope has been delivered and the money runs out, the project team disbands. Newly gained knowledge leaves the building along with the individual who holds it, or that person moves onto a different challenge where the detail drains away. Worse, support for what should now be a key part of the organisation's operating model now sits with an inexperienced support function, accessed by a 'Help Desk' who simply pass on problems to a likely resolver group. At best, it will take the support function some time to build the tacit and experiential knowledge needed to assure operations, but maintenance or revision of the service to meet evolving market demand is a much bigger ask.
The historic focus on team efficiency does not translate into organisational efficiency. The last three decades have been characterised by a strong focus on efficiency in management thinking. This has resulted in discrete, functionally-focused teams, each experts in their field. Ironically, despite excellence in architecture, development, infrastructure, or QA, for example, it is highly inefficient to manage the end-to-end outputs across the internal value stream. Waste builds up and the aggregate time and cost increases.
The project funding model gives the illusion of control. Predictions on what can be achieved by the project team over the coming months inevitably turn out to be incorrect. CapEx funding requires that a detailed specification is created, many of the requirements often aren’t needed, and it is almost impossible to accurately estimate what resource it will take to deliver them. The end-customer is rarely involved, yet the detailed implementation plan enshrines the many assumptions which have had to be made on what they want. In real life, developing new solutions is complicated and subject to many interventions, forcing projects to breach the rigid constraints that they were launched with, and to reassess the likelihood of meeting the agreed outcomes.
Approval boards are not necessarily best placed to determine the direction of travel. Governance approval boards tend to be made up of very senior, very busy people who rarely have the time to understand the implications of exactly what is needed to provide the product to the customer or the service to the citizen. In mitigation, project managers are required to explain and justify each breach of funding tolerance, or to ask for more time or more money. Not unreasonable, but not the best use of the organisation's time.

Funding Teams instead of Projects

It's a view that time-honoured organisational structures and funding methods are no longer relevant. In order to create a customer- or citizen-centric business it's time to pivot the organisation and place Product Management and Engineering as the engine-room of the internal value chain.

A product-led organisation is one which is organised to create products (and services) which are ready to deliver value to customers/citizens. Leading companies now organise cross-functionally around customer outcomes.

Aligning the business and technology as one integrated unit, optimised for speed and agility, is the key enabler of digital transformation.

Instead of discrete projects, work is organised around end-products/services and opportunity areas. Product Managers are assigned responsibility for each of these product/service lines, and available funding is distributed across several self-organising and persistent teams.

Instead of, for example, a company with an annual OpEx of £100m and a CapEx of £20m, the whole £120m can be allocated to funding operations. The organisational structure is revised so that the majority of employees work in cross-functional self-organising teams, with middle management layers removed. The organisation's expenses become much more fixed and stable. There is no need for a portfolio oversight team to referee the heated discussions on what new initiative needs funding, and no need to track the cost of the work at a project level.

Agile, product-based, working practices emerged from IT, but are no longer limited to departments or companies who build systems. The ideal product-led team ideates, builds and runs products which deliver value to the end-customer. It is an empowered, self-organising, cross-functional, outcome-oriented, business-capability aligned, long-lived team. It is expected to solve problems and improve business outcomes, rather than to just deliver scope on schedule.

Compared to project-based funding, investment requests can be rationalised back to smaller amounts as teams seek to deliver in shorter, value-generating increments to test market viability. Overall costs are reduced as the workforce becomes more productive. Organisations can adjust their course with a fraction of the money spent previously, leading to enhanced ROI for the company, more relevant products and enhanced customer satisfaction.

Advantages of funding Product teams

There are many positive outcomes from changing to an operational funding model. Some of them are included here:

Investment rather than expense. Some corporate functions are considered as cost-centres which are tolerated as a necessary adjunct to generating revenue. And this extends beyond IT. Exec focus is often on efficiency and reducing cost, but this often results in headcount loss (an easy option) for a short-term profit whilst limiting the ability to drive revenue growth. When thinking shifts from Project cost to Product cost, the operational teams become an investment rather than an expense. It is practically impossible to cost a feature, but it is very easy to cost people. Focusing on budgeting for people rather than features, frees your Product team to adjust to new demands and ideas without having to go through a lengthy cost-benefit exercise and feature sign-off. Further, they are a ring-fenced team ready to start. Product teams can then work through the product roadmap in priority order, adding product discovery to iterative delivery to fuel continuous learning of what best generates revenue.
Fast feedback on benefits arising. Major initiatives are conceived and funded with little thought on a truly effective method of capturing the benefits that arise. Often, so much time has passed until the outcome is delivered that the world it is delivered into no longer provides the expected benefits. The use of small teams, and regular incremental deliveries of new functionality, allow fast feedback on the value experienced by the end-customer.
Products and Services deliver revenue and customer satisfaction, not projects. It is hard to directly associate the money spent on Projects with improved customer/citizen outcomes. Many organisations find that they have a large number of systems, a considerable number with overlapping or duplicate functionality, and the technical and architectural debt that goes with it. By reorganising into Product teams, it soon becomes apparent which products and services are generating the revenue, and application rationalisation exercises fade away.
Market responsiveness. Change delivered by projects takes time from inception to delivery - it is not unreasonable to expect a response within a year of the initial market intelligence. Business Unit leaders despair at ever receiving the tools they need, and turn to maverick spend to meet their objectives, introducing more technical and architectural debt. Long-lived Product teams already have a Backlog of requirements assembled with those same Business Unit leaders that they are steadily working through, and it is easy enough for the Product Manager to divert team activity to respond to new requests.
Build and run greatly increases quality. Projects are set up to build new capability, which is then handed over to operations to run. Persistent product teams are funded and staffed, and have the level of authority, to solve any sub-optimal product or service behaviour or fault. The very act of having to pause building new value is a sufficient incentive to increase their own QA so that it doesn't happen again. A further benefit is that there is no need to have a separate 'Support' function to learn how to maintain the offering, and the Help Desk doesn't have to hunt around for the right resolver group.
Knowledge Retention. Projects have a finite life, and no amount of training or documentation can truly compensate for the depth of tacit and experiential knowledge held by those who built the product. Product team members stay around for much longer, their collective business-aligned capability remaining stable and enduring, and increased by occasionally having to resolve faults. Product team members do move on, but if their knowledge is collectively owned then the impact in minimal.
Architectural Integrity. Project teams may inadvertently ignore enterprise architecture guidelines whilst in the narrow pursuit of project timelines, or from a general lack of awareness. Since the project team disbands, there is little consequence to them if the corporate reference model is compromised. Long-running Product teams find it in their own interest to make sure that they, for example, secure regulatory compliance, that they don't integrate with a system due to be retired, and that they take the time to expose an API rather than linking directly to a database. Further, the iterative nature and fast feedback of product team capability provides valuable insight to augment the corporate reference model, and, once again, it is in the Product team's best interests to make sure that product evolution remains aligned to corporate direction.

Signs that it's happening ...

Change is hard. Changing how organisations have worked for generations is harder still. Changing how work is funded will take significant time to pilot and prove. But the benefits of funding Product teams rather than Projects make it worth striving for. Listed below are a number of indicators that we've seen, that will illuminate your path to success.

Resistance from hierarchical leadership. Moving to a product-led organisational structure can be a difficult concept for senior leaders who have served their time in a hierarchically structured company, and expect to continue to enjoy the control that they 'have earned'. Some may find it difficult to cut layers of middle management and become 'servant leaders' themselves, and may be scathing about the ability of their own staff to make important decisions. Pivoting to a product-led organisation requires careful socialisation with the Exec and with other influencers in the company. Early signs of interest in the benefits that could arise should be followed by a joint business-technology strategy and then a revised operating model.
What people do, and their contribution to success, becomes visible. One of the realities of any large organisation is that individuals rarely get the chance to understand what people outside of their team or functional silo actually do. They receive comms from the Exec explaining new structures and promotions, but for many it is completely irrelevant - they see themselves as just a cog in the wheel, and they accept it. If they do show some interest, it can be hard for them to make it make sense. The same worry is true of the more enlightened members of the Exec, who are sure that we could deliver what we deliver with much fewer people if only we improved our ways of working... A product-aligned customer-centric organisational structure and associated behavioural change is a huge step towards increased efficiency, improved productivity and reduced cost. Staff begin to clearly see their place in the internal value-chain to the end customer, and their engagement rises. Further, organisations who are more data-focused and can surface their progress and challenges gain transparency which helps make new outcomes visible, thereby mitigating the lack of insight into what others in the internal value chain do, and making everyone feel much more of a team.
The emergence of Value-Creation leadership is a positive organisation redesign indicator that people have pivoted from a siloed structure to a network-based organisation of small teams who are able to collaborate and make decisions without layers of management telling everyone what to do. Product Managers become an authoritative source on priorities instead of the Project Manager proxy trying to represent the interests of different business stakeholder interests. In the early stages, individuals may still have 'pay and rations' reporting lines that are similar to the traditional functional model, but as the team acquires the necessary skills that allow it to take full ownership of building and running the product, it becomes an almost autonomous, self-organising, customer-focused product delivery machine. Teams don't hire themselves though, so may notionally still report into a manager who helps develop their career, and takes care of the corporate housekeeping.
Initiative prioritisation will evolve from working within the Portfolio Management Office's single planning approach through Product Managers working with stakeholders in order to make delivery commitments for upcoming iterations, through regular planning sessions where wider customer advocacy sets Objectives and Key Results (OKRs) against available product funding, and where inter-dependencies are resolved. As Product teams mature, their self-organising skills extend into wider product discovery and they begin to focus on what generates value to the end-customer.
Product teams shrink or grow, relative to the amount of value that they are delivering. By removing the finite timeline and the fixed scope, a Product team can work on the right work, right now. As the Product team matures, its build and run delivery activities are augmented by product discovery realisations that allow it to better focus its attentions on what, truly, adds value to the end-customer (consumer, audience, user, citizen etc). Whilst sufficient value is being delivered by the Product team, as evidenced in an acceptable ROI, then the funding continues. But, when the value decreases, or the effort to maintain that value increases, then it is time to consider if that product is at the end of its natural cycle. Regular discussions with Enterprise Architecture and Finance will determine if additional investment is warranted to push growth, or if it is time to sunset the product.
Finance back the approach. As a corporate service, the Finance function is likely to continue to budget, fund, and report the same way it has for decades - and which is optimised for functionally compartmentalised teams - so take time to proactively communicate the reasons why change is needed to support innovation, and do this right from the beginning. With your guidance, in time you should see Finance developing new methods for investing across time spans, measurements of long-term value generation, and accounting for value in ways that meet accounting and reporting standards.
Execs become comfortable with proof that funding Product teams works. Sponsors have been used to counting £s out and then 3 times as many £s in. They need to see that their ROI is assured, even though ROI is a lagging indicator and cannot give any early comfort that the investment is sound. Product teams don’t have a set scope or schedule, but their great benefit is that they have an allocated capacity. The fixed run-rate of this capacity minimises cost variance, but a flow of high returns is expected as payback. An explanation of how product funding returns are calculated is the subject of a separate post, but, as a start, a funding baseline must first be set. It is a smart move to pilot using a mature team who already have a known business stakeholder and already experience continual demand. An e-commerce team might fit the bill. Areas of improvement that have high business impact are function, quality and price, so ROI may be tracked against these indicators. Over time, Execs will understand that the approach is being developed in lockstep with Finance and that it is augmenting rather than displacing current best practice.
Demand for change is under control. Work undertaken by SME's includes the regular activities that they do operationally, but some of this 'business-as-usual' work is not predictable, and may in itself be 'small change' - for example, verifying and adding a new customer to a existing product. On top of this commitment, the same SMEs are in demand by several projects for the knowledge they alone possess. Something has to give. At first, resource capacity trackers begin to make visible what everyone is working on, and when the next available slot is. Then, detailed work progress status reporting is generated, albeit a time-consuming manual activity, providing little true insight into the likelihood of meeting desired outcomes. Next, a prioritisation and resource allocation forum is established, to gain Exec backing to when (if?) the work can start. All of these constructs are helpful, but when funding products rather than projects the fight over resources is avoided because each Product team has a dependable ring-fenced resource model to plan against, and progress reporting becomes straightforward and meaningful.

Conclusion

Projects are finite, products are ongoing and persistent. Products represent value streams and live for as long as they continue to generate revenue or provide essential services. Funding a Product team makes them accountable for identifying opportunities to deliver the maximum value for the lowest estimated effort, risk and uncertainty. A stable funding structure enables the team to operate predictably within their calculated capacity to deliver at a sustainable cadence, whilst providing the desired ROI.

Moving from project-based funding to product team-based funding is a significant operational, financial and cultural change which must be iterated over time.

The aim is to create multiple high-performing, longstanding, cross-functional teams, each with the right mix of resources needed to achieve targeted business outcomes, rather than defer work or spend money on more resource as new demand is introduced.

When executed successfully, CDIOs often have closer relationships with their business partners, as well as less expensive, more efficient ways to deliver higher-quality products, while the CRO has the speed and agility they need to keep on generating revenue or servicing the citizen.