FTTM Process Maturity | lateralworks

Abstract

Most teams do not know how mature their planning process is. They know whether the project is on schedule or behind. They know whether the last meeting was painful or productive. But they cannot answer the harder question: are we set up to see problems before they hit, or only after? The Fast-Time-To-Market (FTTM) Process Maturity framework answers that question with a four-level metric, a structured self-assessment, and explicit migration paths. The framework distinguishes four levels of process maturity: ML0 (minimal schedule, gap not known), ML1 (accurate plan, gap known), ML2 (weekly refresh, tracking trends, team functioning independently), and ML3 (actively accelerating the schedule, continuously improving the process). These levels map to three stages of performance control — looking back, looking forward, and influencing forward — and to a predictable migration timeline of roughly one to two months from ML0 to ML1, two to three months from ML1 to ML2, and three to five months from ML2 to ML3. The framework is a near-relative of the Capability Maturity Model developed at Carnegie Mellon’s Software Engineering Institute in the late 1980s. Both frameworks share the central insight that process capability is observable, measurable, and progressive. The FTTM maturity model differs in two ways: it focuses specifically on the weekly schedule refresh as the unit of measurement, and it explicitly connects maturity to acceleration — not just process control. ML2 gives a team predictability; ML3 gives it speed. This paper provides the definitions of each level, a 30-criterion self-assessment scorecard with a 1–5 scoring rubric, and a description of the seven organizational and behavioral factors that determine how quickly a team can advance. It also lays out a four-month progression playbook that maps month-by-month activities onto the maturity levels reached. It is intended for product delivery teams, program managers, and the executive sponsors whose engagement is often the deciding variable in whether a team gets past ML1.

Performance — The three stages of acceleration

Every team’s journey toward faster delivery passes through three distinct stages. Each stage represents a fundamentally different relationship between the team and its schedule. Knowing which stage a team operates in is the first step toward improvement — and the most common source of confusion in coaching engagements is teams that believe they have crossed a stage boundary they have not actually crossed. The stages are not arbitrary. They correspond to whether the team is reacting to events that have already happened, anticipating events that have not yet happened, or actively shaping events that have not yet happened. The boundary between stage one and stage two is the most important shift a team can make. Reinertsen frames this as the difference between economic decision-making and proxy-variable management. A team that only updates after the fact is using yesterday’s information to react to today’s problems. The boundary between stage two and stage three is rarer and harder. It requires the team to spend time on opportunities to accelerate, not on incidents to recover from. Most teams never make this crossing because the urgency that surfaces problems also crowds out the time needed to plan acceleration.

Stage one Look back — after-the-fact control The team creates an accurate schedule, records progress, and knows where it is. The primary activity is updating the plan with what has happened. The team produces an Update Report that looks one week back. This is better than having no schedule at all — but the team is fundamentally reactive. It discovers problems after they have caused delays, and can only report on slips, not prevent them. Stage two: Look forward — before-the-fact control The team knows where it is going, knows what is critical and next, and gives people early warning. The team looks back to recover time through pull-back, mitigates the impact of slips, and improves the probability of on-time completion. The transition from stage one to stage two is the most consequential shift a team can make. It is the difference between being a passenger in the schedule and being the driver. Williams and colleagues, in their study of early warning signs in complex projects, found that teams able to act on early signals systematically outperformed teams that relied on after-the-fact reporting. Stage three: Influence forward — active acceleration The team knows what to accelerate, actually pulls work in, and finishes early or banks time for unknowns. It produces a Focus Report that looks one week forward. The schedule is no longer just a tracking tool; it is the primary mechanism for identifying and executing acceleration opportunities. This is the highest level of schedule-driven performance and is very difficult to achieve. Figure 1. The Refresh Planning Process — the operational system that has to be in place for a team to move up the maturity curve. The process spans three time windows. The day before the meeting the PM publishes the Update Report so owners can prepare. During the meeting the team runs four steps in sequence — update (1/3, look-back), pull-in (2/3, accelerate the top three critical paths), wigglechart (track milestone trends), and look-ahead (tasks for the coming week). After the meeting the PM runs CP analysis with pull-in actions and publishes the Project Status Report. Break-down work happens in or off the meeting with specific owners. ML1 requires the update and look-ahead steps to be reliable; ML2 adds disciplined pull-in and wigglechart trend tracking; ML3 adds CP analysis and live break-down. Without the process, the maturity behaviors have nowhere to land.

Measurement — Process maturity levels

The framework defines four levels of process maturity — ML0, ML1, ML2, and ML3 — that map to the three stages of acceleration. These levels exist as observable behaviors in the weekly refresh, not as theoretical constructs. Any experienced coach watching a team for thirty minutes can place it within one level of accuracy. The structure mirrors the levels in the Capability Maturity Model Integration framework administered by the CMMI Institute, which evolved from Watts Humphrey’s original Process Maturity Framework developed at the Software Engineering Institute beginning in 1986. The shared logic is that organizations move from ad hoc to managed to optimizing through observable progressions, and that the migration requires sustained behavioral change rather than reorganization. What distinguishes the FTTM levels from CMMI levels is unit of measurement. CMMI assesses an organization across many process areas. FTTM maturity is measured in a single forum — the weekly schedule refresh — against a focused set of behaviors. This makes the assessment fast, frequent, and actionable.

Figure 2. Maturity level progression with typical migration timing. ML0 to ML1 is a foundational artifacts build; ML1 to ML2 requires multiple learning cycles; ML2 to ML3 requires team-level cultural change. The transition from after-the-fact to before-the-fact control occurs between ML1 and ML2. ML0. Minimal schedule — inaccurate, not current, gap not known The team has a minimal or non-existent schedule. What exists is inaccurate, not current, and the gap between target and reality is unknown. Work is reactive: issues are discovered after they have already caused delays. There is no shared management tool driving the team’s work, and decisions are made anecdotally. Characteristics: No structured schedule, or a schedule severely out of date. No milestone tracking. No refresh cadence. Functional teams operate in silos. No critical path analysis. Status reporting is anecdotal. ML1. Basic schedule, accurate based on known data, gap known The team has built an accurate plan from known data and updates it with what has actually happened. The gap between the target date and the realistic critical path finish is quantified. The team produces an Update Report that looks one week back. This is after-the-fact control — the team knows where it is and where it is going, but is primarily recording rather than anticipating. Reaching ML1 typically takes a few weeks of focused effort. Characteristics: Credible schedule with bottom-up durations from functional owners. Milestones aligned to customer gates. Doneness criteria defined. Weekly refresh established. Critical path identified. Gap quantified. Update Report distributed. ML2. Weekly refresh, accurate schedule, tracking trends, team functioning independently The team performs weekly refreshes consistently and the schedule is accurate and current. The team tracks trends, looks back to recover time, mitigates the impact of slips, and improves the probability of on-time completion. This is before-the-fact control — the team looks forward, anticipates issues, and takes corrective action before problems materialize. The team functions independently without constant coaching. Moving from ML1 to ML2 takes months of consistent practice and multiple learning cycles. Characteristics: Refresh occurs same time and place every week. Full team prepared. PM reads out activities efficiently. Discussions parked for breakouts. Schedule drives work. Critical paths focus discussions. Near-term activities broken down via short-interval scheduling. Milestone trends tracked.

Maturity levels ML3 — the rare level ML3. Accelerating the schedule, continuously improving the process The team actively accelerates the schedule and continuously improves its own process. This is influence forward — the team knows what to accelerate, actually pulls work in, and finishes early or banks time. It produces a Focus Report that looks one week forward. Pull-in is deliberate and systematic, targeting the top three to five near-critical paths. The framing is closely aligned with Reinertsen’s argument that product development teams should optimize for flow and use cost-of-delay as a primary decision input. ML3 is very hard to achieve and requires a high-performing team that has fully internalized the FTTM methodology. Characteristics: Team uses gap and critical paths to actively pull in. Main and secondary CPs are scrubbed. Baseline used to discuss near-term activities. Wiggle chart actively discussed. Team assumes acceleration, not slip. Sub-group meetings during the week for deeper scrubbing. Focus Report produced. Business case and cost-of-delay drive decisions. ML1 and ML2 teams are still mostly looking back. ML3 teams look forward. The shift between looking-back and looking-forward postures is what makes the ML2-to-ML3 migration so difficult — it requires reallocating attention from recovery to acceleration, even when there are slips that could be recovered. Most teams find this counterintuitive and revert to recovery work as soon as the next slip surfaces.

Maturity migration Why ML3 is rare ML3 teams look forward, not back. They assume acceleration, not slip. — FTTM methodology, lateralworks Process Maturity framework

Diagnosis — Self-assessment scorecard

Maturity is observable in behavior, and behavior is measurable. The self-assessment scorecard rates a team across 30 specific criteria grouped into seven dimensions: schedule quality, refresh execution, pull-in behavior, core team effectiveness, communication, issues and risks, and decisions. Each criterion is scored 1 (poor) to 5 (excellent). The radar chart of dimension averages reveals where to focus improvement. A team generally cannot be rated higher than its weakest critical dimension. A perfect schedule with no refresh cadence is still ML0. A strong refresh on top of an inaccurate schedule is still ML0. Both schedule quality and refresh execution must reach threshold levels before the team can be considered ML1. The discipline of self-assessment is itself a maturity indicator. Teams able to score themselves honestly — surfacing weaknesses instead of defending them — are signaling the kind of psychological safety that Edmondson identified as a precondition for organizational learning. The scorecard works only when the team treats it as a diagnosis, not a verdict.

Scorecard The seven dimensions Dimension What it measures Schedule quality Bottom-up durations, customer-aligned milestones, doneness criteria, analyzer score. Refresh execution Cadence, attendance, preparedness, PM efficiency, fast read-out, parked discussions. Pull-in behavior Critical path walks, gap discussion, scrub of main and secondary CPs, milestone trend tracking. Core team effectiveness Right roles, ownership, alignment on methodology, ability to perform and adapt independently. Communication Post-refresh updates, audience targeting, completeness, timeliness. Issues and risks Structured register, ownership, mitigation, surfaced versus hidden. Decisions Schedule used to model scenarios. Cost-of-delay applied. Decisions documented.

Visualization The maturity radar Plot the seven dimension averages on the radar chart below to visualize the team’s maturity profile. Most teams are not uniformly strong or weak across all dimensions — the shape of the radar reveals where to focus improvement effort. A team with strong schedule quality and weak pull-in behavior sits at ML1; a team with strong pull-in but weak communication is operationally effective but failing to share its progress. Figure 3. Self-assessment radar with maturity-level reference rings. A team’s profile (overlaid) shows which dimensions are pulling its overall maturity rating up or down.

Progression — Maturity migration

Migration between levels is not instantaneous. It requires sustained behavioral change across the entire core team — not just the program manager. The first migration is primarily about building artifacts. The second and third are primarily about changing behavior. This is why budgets and timelines for maturity work consistently underestimate the later migrations. The pattern is consistent with Kotter’s observation that lasting organizational change requires sequential phases of urgency, coalition, vision, action, short-term wins, consolidation, and anchoring — and that anchoring change in culture is the slowest and hardest phase. The same logic applies inside a single product delivery team: the artifacts arrive in weeks, the behaviors in months, the culture last and only with sustained reinforcement.

Migration paths From ML0 to ML3 ML0 to ML1: build the artifacts (1–2 months) This migration is primarily about building foundational artifacts. Scrub the schedule with functional owners in small-group breakouts to replace top-down placeholder durations with realistic, bottom-up estimates. Establish the target date and compute the critical path gap. Define doneness criteria for every major milestone. Set up a fixed weekly refresh meeting with the full core team. Send an Update Report after each refresh summarizing what changed, the current critical path, and top actions. The primary obstacle is rarely technical — it is getting the team to invest in schedule quality before the pressure of daily execution crowds it out. ML1 to ML2: internalize the rhythm (2–3 months) This migration requires the team to internalize the refresh process so it runs efficiently without coaching. The PM must be fluent in the scheduling tool. Team members must come prepared. Discussions must be parked for breakouts. The schedule must become the team’s shared management tool, not a PM artifact that is tolerated. The team begins tracking milestone trends via the wiggle chart and using them to anticipate problems. Near-term long-duration activities are broken down into one- to ten-day tasks via short-interval scheduling. The team uses the critical path to focus technical discussions and begins looking back to recover time when slips occur. ML2 to ML3: shift attention to acceleration (3–5 months) This is the hardest migration. The team must shift from looking back and recovering to looking forward and actively accelerating. It must use the schedule to model scenarios and drive decisions. Pull-in must become systematic and deliberate, targeting the top three to five near-critical paths. The team must assume acceleration, not slip — banking time when on track rather than relaxing into the float.

Figure 4. The team’s maturity curve. Process maturity rises with the team’s ability to act earlier in the cycle. ML0 is no updating; ML1 records slip and pull-in; ML2 recovers time lost; ML3 accelerates before slipping and banks time against unknowns. The transition from after-the-fact to before-the-fact control occurs between ML2 and ML3. Inside the team-level view above sits a more granular progression — the discrete habits that define the program manager’s role at each maturity level. Figure 5 zooms in on the PM-specific behaviors that compound into team maturity. Figure 5. The Project Manager’s maturity curve. PM behaviors progress through seven discrete steps — come to meeting, come on time, come prepared, study the critical path, pull-back after slipping, follow-through on pull-back actions, and finally pull-in before it slips. Gray markers are the prerequisite habits before ML1; the blue ML markers fix the levels at which each behavior becomes routine (study CP at ML1, follow-through at ML2, pull-in before slip at ML3); green markers identify the active acceleration behaviors that distinguish ML3. Each step must be fully landed before the next can hold; teams that skip steps regress to the last stable behavior.

Migration playbook The four-month progression The migration timeline maps onto a concrete four-month playbook. Each month introduces a defined set of behaviors and produces a recognizable maturity step. The playbook is cumulative — each month does everything the prior month did, plus one new layer. Teams that try to skip a month’s practices to reach a later behavior almost always regress; the staircase only holds when each step is fully landed before the next is added. This sequencing is the operational consequence of the learning-cycle pattern Argyris described as the prerequisite for double-loop change. Figure 6. The four-month progression curve. Month 1 lands the team at ML1; Month 2 brings the first deliberate pull-in actions and reaches ML2; Month 3 widens pull-in to secondary critical paths; Month 4 shifts the team into live, dynamic breakdown and pull-in characteristic of ML3. Month 1 — update and review schedule status (reaches ML1) The first month builds the operating cadence. Send PreFresh reports before the meeting and teach activity owners how to read and use them. Run refresh meetings on time — same day, same time, starting and ending on time. Get full attendance of all core team members and activity owners. All attendees come with completed PreFresh reports so progress updates land quickly. The PM updates the schedule in 10–15 minutes by asking the update questions and nothing more, limiting extra talking. The team reviews change — slip and pull-in — for each target, walks the first critical path (CP1) to each target, and discusses the cause of slip or pull-in. The wigglechart is run and comments are added explaining the cause of change. PostFresh reports go out after the meeting; team members are taught how to use them.

Month 2 — pull-in CP1 and schedule scrub (reaches ML2) Month 2 adds deliberate pull-in to the routine. For each target, walk CP1 starting from the first task and look for opportunities to pull in. Implement pull-in actions into the schedule immediately whenever possible. Where actions cannot be implemented in the meeting, record them in the task’s notes (using the action button) and send them to all owners after the meeting. Pull-in actions should be implemented by the end of the day following the refresh, and must be implemented before the next refresh. Break down and scrub activities on or near CP1 occurring within the next six weeks, working with their respective owners. By the end of month 2, the team is consistently looking forward, anticipating slips before they happen, and the schedule is driving work rather than recording it. Month 3 — pull-in CP2–5 and CP analysis Month 3 widens pull-in beyond the primary critical path. For each target, after pulling in CP1, peel back to CPs 2–5 on each target and look for pull-in actions on each. Implement actions immediately where possible; otherwise record them and follow through before the next refresh. Run CP analysis, review it with the team, and walk the pull-in actions on CP1–5. The intent is to surface the second and third near-critical paths before they become the new critical path — a problem that, as Goldratt observed in his treatment of the theory of constraints applied to scheduling, is most visible in the transition from a single-CP focus to a multi-path one. Month 3 is still ML2 territory, but it is the month in which the team’s attention starts to migrate from recovery to acceleration. Month 4 — live dynamic breakdown and pull-in (reaches ML3) Month 4 is the threshold of ML3. The team breaks down and pulls in the schedule live in the refresh meeting and looks forward to anticipate problems and mitigate them before they happen. Sub-group meetings during the week scrub specific paths in greater depth. The Focus Report replaces the Update Report as the dominant artifact. Cost-of-delay enters decision-making. Reinertsen’s argument that product development teams should optimize for flow is now operational — the team is no longer waiting for a slip to take action; it is acting to bank time against unknowns. Most teams do not get to month 4 on the first attempt. Reaching ML3 typically requires sustained executive pull and the kind of psychological safety that allows the team to surface an opportunity to accelerate even when no one is asking for one.

Conditions — Factors that influence the speed of maturity

Seven organizational and behavioral factors determine how quickly a team can move up the maturity curve. These factors are not within the program manager’s sole control — they require alignment between the team, its leadership, and the broader organization. Of the seven factors, executive pull is the single most powerful accelerator. When senior leadership routinely asks "what is the gap?" and "what are we doing to pull in?" the team learns that the schedule matters and that investment in planning will be recognized. When leadership ignores the schedule or treats it as a status-reporting exercise, even the most disciplined teams stall at ML1. Figure 7. The seven factors that influence the speed of maturity migration. No single factor is sufficient on its own; weakness in any one factor caps the team’s achievable maturity.

Factor detail What each factor controls Team structure. Are members dedicated to the project, or split across many? Do they report to the project leader? Dedicated, co-scheduled teams mature faster because they invest focused time without the overhead of context-switching. Time committed to planning. Is planning an afterthought squeezed into the margins of the week, or is it the team’s main focus? Teams that treat planning as a first-class activity mature far faster than teams that view it as overhead. Team leadership. Is the project leader technically respected, empowered, and in control of resources? Empowered leaders make trade-offs at the team level instead of escalating, accelerating decision velocity. Contact with customer. Is the team customer-driven, with a real sense of customer needs and time-to-market pressure? Internal targets carry less force than a real customer deadline. House and Price showed that teams tracking to customer break-even time outperformed teams tracking to internal milestones. Sense of urgency. Is the team always pushing, working to an early schedule, with an early-warning system in place? Urgency is not panic — it is the disciplined practice of working to pull the schedule in rather than waiting for it to slip. Discipline. Does the team maintain the rhythm of refresh without giving up when it gets hard? The first few refreshes are always rough. Teams that push through the discomfort improve rapidly. Teams that cancel or reschedule when busy stall at ML0. Executive pull. Does senior management demand the process, ask questions about the schedule and critical path, and use the outputs to make decisions? Executive engagement is the single most powerful accelerator. The pattern matches Kotter’s finding that change efforts without sustained executive sponsorship dissolve into isolated projects.

Why migration takes time The geometry of change The reason ML2-to-ML3 migration cannot be compressed is that it requires culture change, not just process change. Lower-order changes — technology, process, skills — can be made in weeks. Higher-order changes — strategy, behavior, culture — take months to years. The diagram below maps the dependency: any large performance improvement nests culture change inside it, and culture is the outer ring that must be moved last and slowest. Figure 8. Time required to create sustainable change. Each ring represents a layer of organizational change; magnitude of performance improvement and time required scale together. ML2-to-ML3 migration sits in the outer rings. This nesting structure echoes Schein’s model of organizational culture as artifacts, espoused values, and underlying assumptions. Process changes operate in the artifacts layer. ML3 maturity requires a change in the underlying assumptions about what the schedule is for — from a status-reporting tool to a decision-making one.

A Reference Scoring rubric The scoring rubric is the operational definition of each score level on the self-assessment scorecard. Use it to calibrate scoring across teams and across time — a "3" should mean the same thing in every assessment. Calibration is what separates a useful maturity assessment from a theatrical one. Without a shared rubric, scores drift toward the self-image of whoever is doing the rating. PMs who pride themselves on discipline tend to inflate their refresh-execution scores. Teams who feel underappreciated tend to deflate their core-team scores. The rubric is the discipline that prevents both. It also makes cross-team comparison meaningful: a portfolio leader looking at twelve teams’ maturity profiles can only spot the patterns that matter — weakest dimensions, fastest movers, stalled teams — when the underlying scores are calibrated to the same standard. The rubric below covers the five core dimensions. Issues-and-risks and decisions follow analogous patterns: a "1" means the practice is not happening; a "5" means it is mastered and is being used to improve the team’s own process.

Reference Scoring rubric Figure A1. Scoring rubric for the self-assessment. Each score level (1–5) is defined across the five core dimensions. Use the rubric to keep ratings consistent across teams and over time. In practice, the most useful pattern is to score a team in three passes. Pass one is the PM’s self-rating after the refresh. Pass two is a 30-minute team conversation against the rubric. Pass three is an external coaching review. The convergence — or divergence — between the three passes is itself diagnostic. Teams whose internal and external ratings differ by more than one level on multiple dimensions are usually in denial about a specific weakness.

Sources

References

Humphrey, W. S. Managing the Software Process. Addison-Wesley, 1989. The original formulation of the Process Maturity Framework that became the Capability Maturity Model.
CMMI Institute. "CMMI Model V3.0." Capability Maturity Model Integration Institute, 2023. https://cmmiinstitute.com
Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. Especially chapters on cost of delay and queue management.
Williams, T., Klakegg, O. J., Walker, D. H. T., Andersen, B., and Magnussen, O. M. "Identifying and Acting on Early Warning Signs in Complex Projects." Project Management Journal, vol. 53, no. 2, 2012, pp. 37–53.
Edmondson, A. C. "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly, vol. 44, no. 2, 1999, pp. 350–383.
Kotter, J. P. Leading Change. Harvard Business School Press, 1996. Originally previewed in "Leading Change: Why Transformation Efforts Fail," Harvard Business Review, March–April 1995.
House, C. H., and Price, R. L. "The Return Map: Tracking Product Teams." Harvard Business Review, January–February 1991, pp. 92–101.
Schein, E. H. Organizational Culture and Leadership, 4th edition. Jossey-Bass, 2010.
Kelley, J. E., Jr., and Walker, M. R. "Critical-Path Planning and Scheduling." Proceedings of the Eastern Joint IRE-AIEE-ACM Computer Conference, 1959. The foundational paper on the critical path method.
Ohno, T. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. The original articulation of pull-system thinking that informs FTTM’s pull-in concept.
Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. Free Press, 1992. The original characterization of heavyweight cross-functional teams.
Goldratt, E. M. Critical Chain. North River Press, 1997. The application of theory of constraints to project scheduling, with extensive treatment of buffer management.
Argyris, C. "Teaching Smart People How to Learn." Harvard Business Review, May–June 1991. The framing of single-loop and double-loop learning that underlies the FTTM "learning cycles" concept.
Nikander, I. O. "Early Warnings: A Phenomenon in Project Management." Doctoral dissertation, Helsinki University of Technology, 2002.
Software Engineering Institute. "CMMI for Development, Version 1.3." Carnegie Mellon University, November 2010. https://resources.sei.cmu.edu
McKinsey & Company. Cited in House and Price [7]: companies lose on average 33 percent of after-tax profit when they ship products six months late, compared with 3.5 percent when they overspend 50 percent on product development.
Detert, J. R., and Edmondson, A. C. "Implicit Voice Theories: Taken-for-Granted Rules of Self-Censorship at Work." Academy of Management Journal, vol. 54, no. 3, 2011, pp. 461–488.
Anderson, D. J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide), 7th edition. PMI, 2021.
lateralworks. Internal assessment database. Engagement data across client programs, 2015–2026.