Managing Performance and Embedding the New Development Model

8.1 Selecting KPIs for Cycle Time, Throughput, Predictability, Quality, Attrition, Spend, and Launch Outcomes

Product development performance should be measured as a system rather than through isolated indicators. A narrow focus on speed can encourage teams to reduce scope or accept excessive risk. A narrow focus on project completion can discourage termination of weak programs. A narrow focus on budget adherence can reward teams for protecting outdated cost assumptions even when additional investment would create greater value. The KPI set should therefore balance leading and lagging indicators across the major outcomes the development model is designed to produce.

Cycle time: Measure elapsed time between meaningful start and completion points for comparable project types. Define the endpoints carefully. Concept-to-launch, development-approval-to-design-freeze, or code-commit-to-production-release may each be useful depending on the business. Segment cycle time by project archetype so major platforms are not compared directly with incremental changes. Where possible, separate active processing time from waiting, queueing, rework, and decision delays. This distinction makes the measure actionable.

Throughput: Track the number of meaningful development outputs completed during a defined period. Throughput could include products launched, releases completed, development stages exited, experiments completed, or projects retired after resolving critical uncertainty. Avoid defining throughput simply as projects started. High initiation rates combined with low completion rates usually increase work in process rather than value creation.

Predictability: Measure the organization’s ability to meet its own commitments. Useful indicators include milestone adherence, launch-date reliability, resource-plan accuracy, and frequency of schedule rebaselining. Preserve original commitments as well as current plans. A project repeatedly moving its forecast date should not appear predictable merely because it ultimately meets the most recent rebaseline. Predictability matters because downstream functions make commercial, operational, and financial commitments based on development forecasts.

Quality: Select measures that reflect whether development produces outputs capable of meeting intended requirements without excessive downstream correction. Depending on the product, indicators might include verification failure rates, defect escape rates, warranty issues, post-release severity-one defects, manufacturing yield, customer complaints, design changes after freeze, or regulatory findings. Quality metrics should distinguish productive early discovery of problems from defects identified after the economically appropriate point.

Attrition: Measure how projects leave the pipeline as well as how they enter it. Attrition is not inherently negative. A healthy portfolio should stop weak concepts when evidence no longer supports continued investment. Track termination rates by stage, resources spent before termination, reasons for stopping, and whether evidence was available earlier. Extremely low attrition can indicate that projects are rarely challenged; extremely high late-stage attrition can indicate that uncertainty is being resolved too slowly.

Spend: Monitor development spending against plans and expected value, but avoid treating budget variance as the only economic indicator. Track spend by project, stage, portfolio category, and major resource type. Compare the distribution of spending with strategic priorities. The important question is not simply whether total expenditure is on budget, but whether development dollars and scarce capacity are being directed toward the most valuable opportunities.

Launch outcomes: Close the loop between development and actual market or operational results. Relevant measures may include adoption, revenue, margin, reliability, customer satisfaction, returns, production yield, service burden, or achievement of strategic objectives. Compare outcomes with the assumptions used when projects were approved. This creates feedback on whether the development system is selecting and shaping products effectively, not merely delivering them.

The final KPI set should remain small enough for executives to use consistently. Ten carefully defined indicators are generally more useful than fifty measures with unclear ownership. For each KPI, define the calculation, data source, frequency, owner, target or threshold, and management action expected when performance deviates. Metrics that do not lead to a question, decision, or intervention should be challenged.

8.2 Building the Product Development Effectiveness Dashboard

The dashboard should convert the KPI architecture into a concise management view of development-system performance. Its purpose is not to replace detailed project-management tools, engineering systems, financial reports, or quality databases. It should integrate the small number of indicators executives need to understand whether the portfolio is moving effectively and where intervention is required.

A practical dashboard should answer five questions quickly: Is the portfolio delivering enough output? Is work moving at the expected speed? Are schedules and resources predictable? Is development quality improving? Are launches creating the expected business outcomes? Additional detail should be available beneath these questions, but the executive view should emphasize trends, exceptions, and decisions rather than raw data.

The first design principle is to organize information around management outcomes rather than source systems. Product development data often resides across portfolio software, time-recording systems, finance applications, engineering tools, quality systems, customer databases, and commercial platforms. Executives should not need to reconcile those systems mentally. The dashboard should establish consistent definitions and integrate the relevant measures into a common view.

The second principle is to show trends rather than snapshots. A current cycle time of nine months means little without knowing whether comparable projects previously took twelve months, whether current projects are deteriorating, or whether the metric changed because the portfolio mix shifted. Display several periods of performance where possible and flag structural breaks, methodology changes, or significant changes in project composition.

The third principle is to preserve segmentation. Aggregate averages can hide problems. Overall milestone adherence might be strong while platform projects consistently slip. Development spend may be on budget while a critical product family is materially overcommitted. Quality may appear stable while one manufacturing site or supplier generates most launch issues. The dashboard should support segmentation by project archetype, portfolio category, stage, business unit, major function, and other dimensions that materially affect interpretation.

A concise executive dashboard can include:

• Portfolio summary: Number and value of active projects, distribution by stage and strategic category, recent start-stop-accelerate decisions, and major changes in the portfolio.
• Flow performance: Cycle time, throughput, work in process, queue indicators, and trends in major sources of waiting or rework.
• Delivery predictability: Milestone adherence, launch-date movements, schedule confidence, and major resource-plan variances.
• Quality and learning: Significant verification failures, late design changes, defect escapes, project attrition, and recurring root causes.
• Resource and spend health: Demand versus capacity for critical skills, major resource gaps, development spending, and concentration of investment by priority.
• Launch outcomes: Performance of recent launches against the assumptions that supported investment and commercialization decisions.

Use thresholds carefully. Red-amber-green indicators can focus attention, but each color should have an operational definition. A project should not become green merely because a target has been rebaselined. Where performance is probabilistic, ranges may be more informative than binary thresholds. For example, schedule confidence could show the probability of meeting a launch window rather than presenting one apparently precise date.

Data governance matters because dashboards quickly lose credibility when teams debate the numbers. Assign an owner for every metric and define a source of record. Establish rules for project identifiers, stage definitions, milestone dates, resource categories, and financial treatment. Where estimates are required, label them clearly. A transparent estimate with known assumptions is more useful than an apparently precise figure whose source cannot be explained.

The dashboard should end with management implications. Highlight which trends require decisions, which indicators are being monitored, and what corrective actions are underway. This prevents the dashboard from becoming a passive reporting package. Its value lies in creating a common fact base for the management forums described next.

8.3 Establishing Portfolio Reviews, Operating Cadences, and Management Forums

A redesigned development model needs recurring forums in which leaders make the decisions the model requires. Without a clear operating cadence, portfolio priorities, capacity choices, stage-gate decisions, technical reviews, and launch-readiness questions compete for attention through ad hoc meetings and executive escalations. The management system should assign each recurring decision to the appropriate forum and ensure that information flows coherently between them.

Begin by identifying the essential decision types. Most product development organizations need forums for portfolio prioritization, resource and capacity allocation, major project investment decisions, technical assurance, cross-functional execution, and launch readiness. Some organizations may combine several responsibilities in one forum; others need specialized bodies because of scale, regulation, or technical complexity. The important principle is that every forum has a distinct purpose.

Portfolio reviews should focus on whether the overall set of projects remains aligned with strategy and feasible within available resources. Relevant decisions include starting or stopping programs, changing priority, reallocating scarce capacity, resolving major portfolio conflicts, and reviewing changes in expected value. Detailed task status should remain outside this forum unless it affects a portfolio-level choice.

Operating reviews should focus on development-system performance and constraints. Leaders should examine cycle time, throughput, major bottlenecks, resource conflicts, decision delays, systemic quality issues, and recurring cross-functional problems. The purpose is to improve the performance of the system rather than adjudicate every project issue. Persistent problems affecting several programs belong here even if their symptoms first appeared within individual project teams.

Project governance forums should make defined investment and risk decisions at major gates. Technical reviews should provide specialist assurance on architecture, feasibility, design integrity, verification, or other technical matters without unnecessarily duplicating the business decision of the gate forum. Launch-readiness forums should integrate product, operational, quality, regulatory, and commercial evidence as described in Chapter 7.

A practical governance architecture should define for each forum:

• Purpose: The recurring management questions and decisions the forum exists to address.
• Membership: Required decision makers and essential contributors, avoiding attendance driven solely by organizational hierarchy.
• Cadence: The frequency appropriate to the pace and consequence of the decisions.
• Inputs: Standard data, dashboards, exceptions, and decision papers required before the meeting.
• Outputs: Decisions, resource commitments, escalations, actions, and changes that must be recorded and communicated.

Cadence should reflect decision latency. A quarterly portfolio review may be too slow for a software business where priorities and releases change rapidly, yet monthly executive intervention may be unnecessary in a long-cycle industrial development organization. Fixed calendars should not prevent event-driven decisions where delay would create material cost or risk. Define mechanisms for urgent escalation without turning every issue into an exception.

Decision records should connect forums. If the portfolio committee accelerates a project, the resource-planning process should reflect the corresponding capacity change. If a gate review changes project scope, downstream launch plans and economic forecasts should update. If an operating review identifies a systemic testing bottleneck, portfolio decisions should reflect that constraint. This integration prevents different governance bodies from making individually sensible but collectively inconsistent decisions.

Joint ventures should clarify which forums possess venture authority and which decisions remain reserved for owners. Parent representatives should attend with sufficient authority to make commitments when required. The cadence should also provide a mechanism for resolving conflicts between venture priorities and parent-controlled resources before those conflicts disrupt major milestones.

Management forums become effective when leaders consistently use them for the intended decisions. If executives continue reprioritizing projects through informal conversations, teams will learn that formal portfolio governance is secondary. Embedding the model therefore depends as much on leadership discipline as on meeting design.

8.4 Piloting and Scaling Redesigned Processes, Templates, and Ways of Working

A development-model redesign should normally be tested before enterprise-wide implementation. Processes that appear coherent in workshops may behave differently when exposed to technical uncertainty, customer changes, resource shortages, and real project deadlines. Piloting allows the organization to learn which elements improve execution, which create unintended burden, and what must be adapted before broader rollout.

Select pilot projects deliberately. They should represent important development archetypes without being so exceptional that lessons cannot be generalized. A portfolio might include one major new product, one platform or technology program, one incremental extension, and one fast-cycle project. Avoid selecting only unusually strong teams, because the operating model must ultimately work under normal organizational conditions. At the same time, avoid using a severely distressed project as the sole pilot, since historical problems can overwhelm the effect of the redesigned process.

Define what the pilot is testing. The answer should be more specific than “the new development process.” Relevant hypotheses might include whether revised gates reduce decision latency, whether earlier operations involvement reduces late engineering changes, whether new capacity planning exposes resource conflicts sooner, or whether standardized handoffs reduce clarification and rework. Establish baseline measures where practical so pilot results can be compared with previous performance.

Implementation should distinguish core standards from elements open to local adaptation. Core standards might include portfolio decision rules, stage definitions, required risk controls, decision rights, critical data fields, or mandatory regulatory practices. Other elements such as meeting frequency, template detail, or workflow configuration can often be tailored by project archetype or business unit. Explicitly defining these boundaries prevents both uncontrolled variation and unnecessary standardization.

During the pilot, gather evidence through metrics, observations, interviews, and project retrospectives. Look for workarounds. If teams repeatedly create parallel spreadsheets, bypass a review, or invent informal handoffs, determine why. The behavior may indicate resistance, but it may also reveal that the redesigned process does not fit actual work. Treat pilot deviations as diagnostic evidence rather than automatically enforcing compliance.

A structured pilot review should ask:

1. Did the process improve the intended outcome? Examine cycle time, decision speed, rework, resource visibility, handoff quality, or other targeted measures.
2. Which controls added value? Identify steps that improve evidence, accountability, risk management, or cross-functional alignment.
3. Where did burden exceed value? Remove duplicate data entry, unnecessary approvals, low-value templates, and meetings that did not influence decisions.
4. What required adaptation? Determine whether differences reflect legitimate project archetypes or inconsistent execution.
5. What capabilities are missing? Identify training, tools, data, leadership behavior, or specialist support required for broader adoption.

Scaling should occur in waves when possible. Prioritize areas where the performance problem is material and leadership sponsorship is credible. Provide practical implementation support through templates, examples, coaching, office hours, and targeted facilitation rather than relying on broad communication alone. Early adopters can become internal coaches, but they need clear standards so local interpretation does not gradually recreate incompatible processes.

Track adoption separately from business impact. Process-compliance measures can show whether teams are using the new model, but they do not demonstrate that performance has improved. Combine adoption indicators with cycle time, predictability, portfolio discipline, quality, and launch outcomes. If compliance rises while business outcomes do not improve, reassess the design rather than celebrating implementation completion.

Joint ventures should pilot interfaces with parent organizations as carefully as internal workflows. New processes may fail if venture teams adopt them but parent-controlled engineering, manufacturing, or commercial groups continue using incompatible decision cycles. Scaling therefore requires agreement on the interfaces that cross organizational boundaries, not necessarily identical internal processes within every partner.

8.5 Building Capability in Portfolio Managers, Functional Leaders, and Project Owners

A redesigned development system cannot be sustained through templates and governance alone. It depends on people being able to exercise judgment within the model. Portfolio managers must evaluate competing investments, functional leaders must reconcile resource demand with capability constraints, and project owners must integrate customer, technical, economic, and cross-functional evidence into decisions. Capability building should therefore focus on the decisions people must make, not simply on teaching them how to complete new forms.

Portfolio managers require strong analytical and facilitation skills. They should be able to construct a reliable pipeline fact base, compare projects using consistent criteria, distinguish strategic importance from sponsor influence, test business-case assumptions, identify portfolio concentration, and model resource consequences. They must also facilitate difficult stop, pause, and reallocation decisions without becoming advocates for individual projects. Their role is to improve decision quality across the portfolio.

Functional leaders need a different set of capabilities. They should understand true deployable capacity, anticipate critical skill constraints, assess whether project plans are technically and operationally credible, and distinguish structural capability gaps from temporary resource peaks. They also need to make explicit trade-offs when demand exceeds supply. Agreeing to every project while privately assuming priorities will resolve themselves undermines the operating model.

Project owners sit at the center of execution. They need to integrate product management, engineering, research, quality, operations, regulatory, suppliers, and commercial functions around a coherent plan. Core capabilities include requirements management, dependency management, risk assessment, stage-gate preparation, resource planning, schedule analysis, and launch readiness. Equally important is the ability to identify when evidence no longer supports the current plan and escalate a decision before the problem becomes a missed milestone.

Capability development should combine several methods:

• Role-based training: Teach the specific decisions, tools, and accountabilities associated with each role rather than giving every participant the same generic process overview.
• Applied workshops: Use actual portfolio and project cases so participants practice prioritization, resource trade-offs, gate decisions, and risk analysis with real evidence.
• Coaching: Support leaders during the first several portfolio reviews, gates, capacity discussions, and launch-readiness sessions until the new behaviors become routine.
• Peer calibration: Compare how different teams interpret criteria, risk levels, project status, and resource assumptions to reduce inconsistent application.
• Reusable examples: Maintain examples of strong business cases, gate materials, capacity analyses, dependency registers, and decision records that demonstrate the intended standard.

Leadership behavior should be treated as a capability requirement in its own right. Executives must be willing to stop weak projects, accept that not every initiative can be top priority, require explicit resource trade-offs, and avoid bypassing governance through informal requests. They should reward teams for surfacing bad news early rather than encouraging optimistic status reporting. When leadership behavior contradicts the formal development model, employees will follow the behavior.

Capability should be assessed through performance, not training attendance. Observe whether portfolio decisions become more discriminating, gate reviews focus on evidence, capacity conflicts are identified earlier, handoffs become clearer, and project owners escalate risks before commitments fail. These behaviors provide stronger evidence of capability than certification or completion of training modules.

Joint ventures should establish common capability expectations where roles span owner boundaries. Portfolio managers may need to reconcile different parent investment criteria, functional leaders may manage resources supplied under service agreements, and project owners may depend on teams they do not directly control. Training and coaching should therefore include the venture’s specific governance arrangements, escalation rights, resource commitments, and decision thresholds.

Over time, ownership of capability building should move from the implementation team into the line organization. Incorporate key practices into role descriptions, onboarding, leadership expectations, performance reviews, and succession planning. Refresh standards when portfolio strategy, technology, regulation, or organizational structure changes. The development model becomes embedded when teams no longer experience it as a transformation initiative, but as the normal way the organization chooses development work, commits resources, makes decisions, manages execution, and learns from the products it launches.