Why Your Six Sigma Project Tracker Spreadsheet Fails at Ten Projects

A continuous improvement program rarely notices the day its tracker stops working. The spreadsheet that ran the first Green Belt project still opens. What changes is the work required to answer one question from leadership, and that cost climbs with every project added until someone builds the answer in a slide deck instead. Below are the break points in the order they arrive as a program grows from one project to ten and beyond, and what a Six Sigma project tracker must show at each stage.

What a Six Sigma project tracker has to show

The tracker's job is to answer four questions without a meeting: which projects exist, where each one stands, what each one is worth, and who owns it. Answering them for even one project requires the project name, its status (idea, active, completed, or archived), the group or site it belongs to, the project lead, the current methodology phase, the target date, and the benefit claimed so far with its classification. iSixSigma's product guide to project tracking software describes the same job from the leadership side: a dashboard giving "easy access to the status of particular projects, as well as details on the resulting financial impact."

One project: the spreadsheet works

At one project the spreadsheet is fine. One Black Belt owns the file, updates it after each tollgate, and reads it back to the Champion in a weekly summary. Snee and Hoerl, writing from the GE deployment in Leading Six Sigma, recommend that cadence: weekly highlights from the Black Belt to the Champion, and a monthly report to the business leader assembled from what the Champions send up. With one file and one author, the weekly highlight is a glance at the sheet.

Notice what makes it work: one author, one file, and a reader who already knows the project. Every break point that follows removes one of those conditions.

Three projects: status and results split into separate files

The second and third projects bring the first structural failure. Project status lives in the tracker. Financial results live somewhere else: a savings workbook in the format the controller wants, or the benefits section of a charter document. The two disagree within a month, because the person who updates the phase column is not the person who updates the benefit figure, and neither is told when the other changes.

A project can show Improve in the tracker and $0 in the savings file, or Control and a benefit estimated in Define and never revised. Once a benefit figure has been re-keyed between files to reconcile them, no one can say which copy is authoritative. The discipline of classifying a benefit the day it is recorded, covered in Six Sigma Financial Tracking That Finance Will Sign Off On, cannot hold when the record is in two places.

The fix is structural, not procedural. Status and benefit must be fields on the same project record, entered once.

Five projects: every belt tracks differently

By the fifth project the tracker has three or four authors, and each has adapted the sheet. One belt adds a column for the primary metric. Another moves to-dos into a separate tab. A third renames the phase values to match a training provider's terminology. Together the changes mean no two rows describe a project the same way.

The person this breaks is the Master Black Belt. The ASQ Master Black Belt body of knowledge assigns that role the job of creating "guidelines and expectations for project reviews" and performing them "in a timely manner," and separately the job of designing "a system for measuring project and portfolio performance." Neither is possible when the meaning of "phase" or "benefit" varies by row. An MBB reviewing five projects tracked five ways is not auditing a portfolio. They are auditing five spreadsheets.

Standardize the project structure before the fifth project, not after. Fix the phase list per methodology, the fields every charter carries, and the benefit classifications finance will accept, and make it impossible for a new project to start without them. In a spreadsheet, "impossible" means a template file someone may or may not copy. In a structured system, it means the template the project is created from.

Ten projects: no roll-up for leadership

At ten projects the monthly report stops being a summary and becomes a production. Someone opens ten files or ten tabs, copies status, phase, lead, and benefit into a summary sheet, sums the benefit column, and pastes the result into a deck. If the program spans two sites, the summary needs a second pass to split by group. That work repeats every month, and every month it is a fresh chance to copy the wrong cell.

The error rate on that kind of work is documented. Raymond Panko's review of 85 intensive inspections of operational spreadsheets, presented at the 2015 EuSpRIG conference, found errors in 94 percent of the spreadsheets inspected, with cell error rates in the 1 to 5 percent range that human error research predicts. A few percent per cell sounds tolerable until it is applied to ten benefit figures, ten status values, and ten dates copied by hand, then applied again next month. Panko's central finding is that per-cell rates are small but the probability of at least one wrong bottom-line number rises quickly with the number of dependent cells. A portfolio total is exactly that kind of number.

The roll-up leadership needs is short: active projects, projects by status, projects by group, and the portfolio's financial position with hard and soft savings kept apart, for the reasons laid out in Hard Savings vs Soft Savings. The spreadsheet cannot produce it from the project records without a human in the loop, and the human is the error source.

Ten projects: no audit trail

The second failure at ten projects is quieter. A benefit figure on project six moved from $140,000 to $85,000 sometime last quarter. The controller asks who changed it and why. The spreadsheet cannot say. It holds the current value, not the previous one, not the date of the change, and not the person who made it. If the file has been emailed, several copies now exist, and the question of which copy was current on the day of the steering meeting has no answer.

Track changes in a spreadsheet is a partial answer, because the history lives inside one copy of a file that exists in several.

Beyond ten: the program needs boundaries

Past ten projects the program usually spans a second plant, cohort, or business unit. Each group's lead wants to see their own projects and nobody else's. Executives want the whole picture, read-only. The MBB wants the pipeline of ideas that have not started, sized by opportunity, which the ASQ body of knowledge lists as its own responsibility: create and manage "a pipeline of potential projects for consideration." A spreadsheet handles all of this with more files, which is the failure mode this whole post describes. A structured system handles it with a group on every project and a role on every person, so visibility is a property of the data rather than of who was sent which attachment.

What the tracker must show instead

Put the break points together and the requirements are four. Every project carries the same fields, entered once. The roll-up is computed from those fields, never copied from them. Every change is recorded with its author and time. Project structure is set at creation, not enforced by memo.

That list is what SixGrid's All Projects page shows on every project card (status badge, group, lead, current phase, and benefit), and it is what Program View computes from those records: every project grouped by group, a selector that filters every count and stat card to one group or all of them, and money cards that drill down into the projects behind the number. The Dashboard's Organization Overview shows the four summary tiles leadership asks for first (Active Projects, Total People, Net Impact, Portfolio Value) with bar charts of projects by status and by group beneath them. Each project's Settings tab keeps an Activity Log of everything that happened on it. Owners and Admins can publish custom templates alongside the standard DMAIC, Lean, Kaizen Event, PDCA, and A3 methods, so a new project starts with the organization's own milestone and to-do structure in place. For how those pieces fit together from charter to final report, see What Is SixGrid? in the Continuous Improvement hub.

None of this makes a spreadsheet wrong at one project. It makes the tenth project the wrong time to discover the tracker was never a tracker, only a list.