This article introduces the Digital Project-on-a-Page, a new method to enable cross-functional alignment within product teams and executive teams, using the BrightFire App for Innovation Pipeline Management. To learn more, or schedule a demonstration of the BrightFire App, message Bryan directly on LinkedIn, email us at contact@brightfire.co, call +1.651.301.8125, or go to our Contact Us page and we'll get back to you right away.
Aligning cross-functional teams--at both the operating and executive levels--is one of the most challenging elements of innovation pipeline management. For many reasons, it is difficult for individuals to work outside of their normal functional silos, regardless of their level in the organization. But research has consistently demonstrated that companies that do it well are more successful than those that don't.
We recently interviewed Jeff George, a former senior R&D executive at Hain Celestial, Campbell Soup Co., Hillshire Brands, and PepsiCo, who shared how he has solved this puzzle via a simple but invaluable tool: a project-on-a-page. That interview (go watch it above!) generated much interest, perhaps because it offered a new, simpler way to approach innovation decision-making, a topic especially relevant to "not-so-big" companies and those with less mature innovation pipeline processes. Many were curious to learn more about this concept, asking questions such as:
What specific information is included in a project-on-a-page?
How does this information get created, and who does it?
How is the project-on-a-page used in executive decision-making?
How can software enable the adoption of a project-on-a-page?
We'll answer those questions in this article by extending these insights from Jeff, and drawing on BrightFire's recent work with similar companies in this space.
The Project-on-a-Page as a Business Specification
Let's begin with a definition: A project-on-a-page is a short, simple synthesis of the critical information used by both operating teams and executive teams to achieve cross-functional alignment on the value and feasibility of an innovation or product investment. In this regard, a project-on-a-page is different than a product innovation charter, a project brief, a product definition, or a project homepage. These are related concepts, but such tools are typically focused on internal team alignment. A project-on-a-page extends these approaches by serving as the essential, ongoing document-of-record that gets cross-functional operating teams and cross-functional executive teams on the same page (literally!) regarding initiative goals, financial opportunity, technical feasibility, cost, resource demand and timing. It is a business specification, in contrast to a technical specification. And while a project-on-a-page can be created by hand, it is typically created with software. This increases the robustness of the data, enables visualizations that offer unique insights, and streamlines the data creation and decision-making process.
When done well, a project-on-a-page accomplishes two goals. First, it facilitates the critical dialogue between functional representatives from sales, marketing, R&D, operations, supply chain, finance, and other functions as they plan and execute a new related project. And second, it integrates this input as a singular, critical deliverable used at the executive level during phase-gate meetings. These meetings are the decision-making forum in which executives discuss and approve the investment of resources (i.e. time and money) to work on the project.
Seven Critical Components of a Project-on-a-Page
At a minimum, a project-on-a-page should include seven elements:
1. Project overview and opportunity summary. This section has the most overlap with a traditional product innovation charter (PIC) or product definition, as it contains the "why?" for the project, answering foundational questions such as:
A summary statement describing the opportunity
The target market(s) or customer(s) served by the project (note that customers may be internal to the company)
The problems or jobs-to-be-done the project will solve for the market/customer, and the benefits of solving them.
The answers to these questions should not be dissertations. This section focuses on the essential information required to ensure understanding and alignment. Additional information may accompany these answers, especially for more complex or new-to-the-world projects, but such detail should not be included here.
This overview also communicates who will champion the project, who will manage it, and who are the cross-functional core team members that will execute the project.
2. Value Scores--with Commentary. Arguably, this is the most important section of the project-on-a-page, as it is what brings cross-functional team members together to collaborate. While project scorecard approaches have been around for many years, the most critical function of these scorecards is surprisingly often overlooked: the cross-functional dialogue they enable.
One reason to use scoring models is they provide standardized criteria that can be averaged and used to compare projects against each other on an apples-to-apples basis. However, the primary benefit of a scorecard is to bring together team members from marketing, sales, R&D, operations, and other functions to contribute their unique insights as they discuss the value and feasibility of new candidate project. This ensures all parties are aligned regarding the purpose of the project, and it enables each functional representative to proactively identify challenges that must be overcome to succeed.
The format illustrated here is ideal, since it contains more information than just the numbered score for each criteria. The commentary provided with each score provides important context, and communicates the insights derived from this cross-functional conversation. Additionally, this approach reduces some of the "B.S." factor available to teams when they are only asked for numbers, without any explanation.
3. Financial assumptions. Even at the earliest stages of a product project, it is possible to document basic--albeit rough--assumptions regarding the financial value of a project. These are then validated, iteratively, as the project matures.
These can include assumptions around pricing (e.g. "what do we expect to be the price per pound?"), volume estimates over time, and cost (e.g. COGS per pound, per unit, or per case). With these minimal starting points, a simple financial model can be defined that calculates standard values such as gross profit, gross margin, and long-term financial contribution. These values are also communicated in the project-on-a-page.
Early on, these assumptions are only considered as tentative placeholders. But they offer decision-makers an important sanity check and directional understanding regarding how this project might contribute to the business, and whether or not it can meet the company's standard minimum thresholds for profitability.
This is an area in which automation makes a project-on-a-page come to life. As illustrated above, software systems designed to support time-based financial data, target thresholds with red/yellow/green indicators can help visualize these assumptions in ways that help decision-makers understand financial risks and opportunities in an intuitive manner.
4. Resource demand. A critical but often-overlooked element of early-stage project planning is modeling and communicating the number of resources required for project success. This is neglected because of the perceived complexity of doing so. However, an effective project-on-a-page must communicate the real costs of investing in a project. And for most companies, their most constrained resources are the time spent by its people, measured in FTEs (i.e. "Full-time Equivalents).
This is another area in which software makes it easier to model and communicate these demands. A simple form can standardize the collection of the data, and this can be further streamlined with "T-shirt-sizing" methods in which project or functional leaders plan their resource needs based on standard "Small, Medium, Large" resource models. This shirt-size approach began in the world of Agile software development, and has since been adapted to many other industries.
Automation can reduce the amount of time required to create resource demand plans from hours down to a matter of seconds. Resource demands may then be communicated on the project-on-a-page, so decision-makers can understand how many resources are needed from each function, and when. Additionally, when resource demand data is combined with financial assumptions, decision-makers can visualize "bang for the buck" attributes (e.g. "Profit per FTE,") which tell them how efficiently resources will be used.
5. Project timing and key cross-functional milestones. Another critical area of cross-functional alignment relates to timing - what is being done, when, and by whom? But a word of warning - for a project-on-a-page, this is not about communicating a detailed project schedule, or work breakdown structure (WBS). Rather, it is only about identifying critical gates and cross-functional milestones. These are the high-level points that cross-functional teams must track to ensure continued alignment over the course of the project. For manufacturers, such milestones typically include:
Start Ship date - First date in which product will be available to ship
Gate 0 date - when are cross-functional resources first committed?
Gate 2 date - when will gatekeepers approve the business case?
Cross-functional Milestones - Key hand-offs from one function to another
Project Complete date - when will resources complete their project work?
As with the other elements above, it is possible to model milestones manually. But automation routinizes this process, ensuring a standard set of milestones is planned and easily visualized. It also reduces the amount of time and effort required to complete this process.
6. Risk. Despite being a more temporary quality of an initiative (at least, hopefully), an project risk is equally as important as other elements on the project-on-a-page. This is relevant to cross-functional alignment at the operating level, where a common understanding of risk ensures that each team member how their contributions can help mitigate these risks, thereby increasing the likelihood of success. And risk tracking is also relevant to cross-functional alignment at the executive level, where red flags can help executives spot where they might need to provide additional support to keep the initiative on track.
Risk and issue tracking is often an area of maturity for many companies, who may have tracked risks via standard risk registers, heat maps or sophisticated RAID logs for years. In the context of a project-on-a-page, the objective is fairly simple - to communicate the overall risk level, and when a project is at-risk, flag the primary area of concern. These areas can be classified by at-risk categories such as schedule, scope, supplier, technical, cost, customer, or resource challenges. Furthermore, the duration of the risk level can also be visualized, which aids in identifying projects with chronic risks, i.e. that are not improving over time.
7. Gatekeeper Input and Approval. The last crucial element in a project-on-a-page is about cross-functional alignment at the executive level. For high-performing companies that operate within a regular cadence of gate and portfolio meetings, the project-on-a-page is used both to prepare for and to execute those meetings.
The recommended best practice is for an innovation process manager to send executive gatekeepers an email or report with a list of the projects that will be reviewed in an upcoming meeting, typically three to five days in advance. This report includes a URL that enables gatekeepers to navigate to the project-on-a-page for each project, review this critical information, and delve more deeply into supporting material if needed.
The project-on-a-page contains a section where each gatekeeper can vote and provide additional input on the project in advance of the meeting (see below). Alternatively, if the executive is unsure regarding their vote, they can share this prior to the meeting, and document issues or questions they'd like to raise in the meeting itself.
The purpose of this pre-meeting process is not to eliminate discussion, but rather to focus it and make it more productive. Rather than spending valuable time reading content to the executives or covering ground around which there is no debate, the meeting time is now completely focused on dialogue. Areas of disagreement or debate can now receive the time and full attention that is required.
At the end of each gate review, a recommended best practice is to go around the horn to validate the vote of each gatekeeper as the final step in the voting process, and record or update each vote on the project-on-a-page. This publicly affirms each gatekeeper's commitment to the decision, and reinforces the important role that each plays in approving the investment of resources into each project.
How to Apply This in Your Company
In many ways, this approach to decision-making is not entirely new. It builds upon business practices and tools that have been around for many years, such as project charters, scorecards, financial models, resource plans, and project timelines. However, what is new is the way it standardizes and synthesizes these disparate elements into a simple, unified decision-making tool, or a business specification. This elegant but powerful approach generates alignment and improves decision-making at both the operating level and the executive level.
The specific technology we have highlighted here is our BrightFire App for Innovation Pipeline Management, powered by Shibumi. This solution is simple, fast-to-implement, and uniquely designed to help any company--especially 'not-so-big' and lower-maturity companies--adopt the project-on-a-page and the business practices described above.
If the approach described here would be of value to your company, please contact us via the information below. We'd welcome the opportunity to explore how our solution and these new business practices might enable you to improve cross-functional alignment and investment decision-making in your organization.
To contact us or schedule a demonstration of the BrightFire App, message Bryan directly on LinkedIn, email contact@brightfire.co, call +1.651.301.8125, or complete the form on our Contact Us page and we'll get back to you right away. To learn more about BrightFire go to www.brightfire.co.
