Summary
Stopping Feature Creep: Feature creep often starts with good intentions but massively inflates life cycle costs and failure rates. Every added feature casually approved on a Friday afternoon will be paid for in maintenance, variant testing, and unpredictable risks after the start of production. Learn to systematically name the operational price of an idea, hand the decision back, and steer true innovation rather than over engineering.
The project was finished. The bill was only starting.
A request arrives at half past four on a Friday and sounds reasonable. One more diagnostic function, three weeks of work, the customer would love it. Nobody in the room objects, because nobody wants to be the person who kills a good idea. So it goes into the plan, and because it is small, it never gets logged as a change.
That is how feature creep happens.
Not through one bad decision, but through twenty small ones that were each defensible on their own.
This article is for engineering and project leaders who recognise the pattern and suspect the bill turns up somewhere other than where the decision was made. Anyone hunting for a better change request template will be disappointed. The form is not your problem.
The Test Bench Where I Learned This Myself
I was the developer, and I wanted to do it properly
Long before I carried leadership responsibility, I was a test bench software developer. Nobody pushed additional scope onto me. The scope came out of my own head, which is exactly why nobody stopped it.
What I built was technically elegant
The test bench ran on new cards that communicated over a bus I had developed myself. Every card carried a small intelligence of its own and could run its functional checks independently. That sounds good. It also worked.
Why it felt right at every single step
The idea behind it was a modular kit. Develop it cleanly once, then combine it freely, so the thinking went. Every engineer knows that feeling: you are not building for today, you are building for the next ten years. Nobody writes an invoice at that stage.
The first bill came through unit cost
The technology was so complex and above all so expensive that the cost per test bench ran very high. Not in development, where everything stayed inside the frame. What became expensive was every single unit built afterwards.
The second bill came through the modular kit itself
The modularity I had designed for brought a large overhead with it. Every combination had to be mastered, documented and verified. The effort I wanted to save through the kit came back through maintaining the building blocks.
The third bill arrived years later
Whenever a technical fault occurred, only a handful of experts could trace it at all. That is the line item nobody writes into a plan, and across the service life it is the most expensive one. A system only three people in the company can diagnose is not a technical advantage. It is a concentration risk with a manual.
What I took from it: build for the use case
Whatever gets created, it has to be developed against the benefit and the use case.
A football is made of leather, it gets kicked, shot and pumped up with air. Engineers could long since have built a perfect sphere, with even mass distribution and a calculated surface. What for? Stitched leather is enough, and for children’s football a plastic ball is enough. The perfect sphere solves a problem nobody has.
What this has to do with the software defined vehicle, and what it does not
I am not involved in SDV projects today, and that belongs in this article for the sake of honesty. What I bring is something else: deep leadership experience close to electronics and software development, and from it a feel for when software is still inside its frame and when it is being over-engineered. Time and cost are measurable quantities. They have to be analysed, interpreted and tracked, otherwise enthusiasm ends up deciding.
No sales conversation. If I am not the right person for you, you will hear that in the first five minutes.
What the Data Says About Scope Growth and Life Cycle Cost
Scope creep is the normal case, not the exception
The Project Management Institute found in its 2018 Pulse of the Profession that 52 percent of projects completed in the previous twelve months experienced uncontrolled changes to project scope. Five years earlier the figure was 43 percent. The trend points upward, and it points in an uncomfortable direction: scope discipline is weakening while projects grow more complex.
(Source: Project Management Institute, Pulse of the Profession 2018, survey conducted October 2017.)
The decision lands long before the bill does
Cost accounting treats it as established that roughly 80 percent of cost is committed by the end of the design phase, because the design largely dictates material, manufacturing route and effort. German-language cost management literature puts the figure at 80 to 90 percent of manufacturing cost, committed before production even begins.
Translated into your Friday afternoon: the three weeks of effort are not the price of the feature. They are the down payment. The remainder gets paid off over years, in unit cost, verification effort and maintenance, and out of a different pot than the one you decided from on Friday.
(Sources: ACCA, Target costing and life-cycle costing; Springer, Target Costing und Product Life Cycle Costing als Instrumente des Kostenmanagements; concept origin in Fabrycky & Blanchard, Life-Cycle Cost and Economic Analysis, 1991.)
The largest cost block appears after delivery
Lientz, Swanson and Tompkins published a survey in Communications of the ACM back in 1978: 120 organisations approached, 69 usable responses. Their finding was that maintenance and enhancement consume the bulk of systems and programming resources. The follow-up study of 1980 covered 487 organisations and confirmed the picture.
A second finding from the same work matters more for this article. Asked about the most important management problem, respondents did not name defect fixing. They named user demands for enhancements and extensions. The problem was the same almost fifty years ago, it has only acquired a newer name.
(Sources: Lientz, Swanson & Tompkins (1978), Characteristics of application software maintenance, Communications of the ACM, 21(6), 466-471; Lientz & Swanson (1980), Software Maintenance Management.)
And what poor quality costs appears in no change request
Cost of poor quality sits at 15 to 20 percent of revenue according to ASQ and Juran, reaching up to 40 percent in weak organisations and staying below 5 percent in world-class ones. Every additional feature raises the number of possible failure points, and it does so disproportionately, because the combinations have to be verified as well.
(Source: ASQ and Juran, Cost of Poor Quality.)
Voices From Practice
Valentine Nelaev has run projects in oil and gas for more than 18 years, a sector with different cycles and the identical scope question. His feedback sits here because scope discipline demands precisely what he describes: clear and direct answers rather than comfortable ones.
“Every question I posed received a clear, direct, and well-considered response, and each matter was discussed in meticulous detail. What particularly impressed me was that even the most unexpected and challenging questions were met with thoughtful, insightful, and genuinely interesting solutions.”
Valentine Nelaev, Project Execution Expert, EPC, 18+ years in oil and gas
Which Corner Paid in Your Last Project?
Everyone knows the iron triangle of quality, time and budget. What it does not show is the fourth quantity: life cycle cost, which only starts running after start of production. Eight questions about your last project, no points and no grade. At the end you see which corner actually paid, and you get one question per corner for your next approval.
Four Gates Before Every Approval
Scope discipline is not a question of toughness but of sequence. These four gates run through in a few minutes and prevent the Friday afternoon effect. They complement the SMART method and prioritisation, both of which assume somebody is bounding the scope in the first place.
Gate one: benefit and use case, not capability
The first question is never whether we can build it. It is who uses this feature specifically, how often, and what happens if it does not exist. When the answer stays general, the feature is not justified, it is merely enthusiastic. That is the football rule: stitched leather rather than a perfect sphere.
Gate two: which corner pays, named out loud
Quality, time and budget sit in a fixed relationship. When scope grows, one of the three pays, always. The only question is whether you say it out loud or let it happen quietly. Usually quality pays, because it reports after start of production, by which point nobody connects it back to the decision from Friday.
Gate three: the bill after start of production
Four items worth estimating before approval. First the unit cost multiplied by the volume across the programme. Second the maintenance effort per variant, meaning documentation, validation and regression testing on every later change.
Third diagnosability, measured by how many people in the company could find a fault in it five years from now. Fourth commitment, meaning everything you can no longer switch off without upsetting the customer.
Gate four: who is even allowed to add scope
In most organisations anyone can effectively add scope and nobody can remove it. Define a named role that may commit, and put every commitment in writing. A commitment in the corridor is not a decision, it is an obligation without funding. Holding that clarity across the matrix between Germany, Slovakia and India rests on the same principle as your escalation path.
And the sentence that says no to a good idea
A bare no moves nobody, it only makes you the brake. The sentence that works runs roughly like this: we can build this. It costs three weeks, moves the prototype build by four and raises unit cost. Which of the committed features do we drop for it? That hands the decision back where it belongs, and you have still said no. How a no with a clear baseline works sits in my article on goal setting.
You leave with a phrasing you can use, not with a proposal.
Where Scope Discipline Alone Is Not Enough
When unplanned scope keeps appearing, the cause is rarely a missing form. Check first whether your team can delegate at all, because a leader who decides everything also decides every added request personally and usually too fast. Check second whether status reports carry the truth, otherwise you are dealing with the green melon effect and notice the overload only when the start of production wobbles. And when your calendar has no room left for strategy, the scope question is only the symptom.
Gauri Gole has worked with me over several years on training initiatives. Her review sits here because it names the capability this whole article turns on: recognising what actually matters and leaving the rest out.
“His strategic thinking, forward-looking approach, and ability to identify what truly matters make him a pleasure to work with.”
Gauri Gole, entrepreneur and training partner
How scope discipline fits into a wider leadership system is visible in the Accelerate Now programme and the mentoring method. Terms from this article are defined in the leadership glossary, and the full toolkit sits in the methods overview.
FAQ: Frequently Asked Questions About Feature Creep and Scope Discipline
Q1: What exactly is feature creep?
Scope that grows after project start without a matching adjustment to date, budget or quality target. The decisive word is uncontrolled. A deliberately agreed extension with an adjusted frame is not feature creep, it is a decision.
Q2: How do I spot feature creep early?
Through three signals. Scope shows up in status reports that appears in no change request. Internal milestones move while the customer date stays untouched. And estimates start with the word actually.
Q3: Is over-engineering the same as feature creep?
No, and the distinction is worth keeping. Feature creep mostly comes from outside, from customer requests or from sales. Over-engineering grows inside your own team, out of the legitimate wish to do it properly. My test bench was over-engineering, and that version is harder to stop because it is always well argued technically.
Q4: How do I say no without becoming the brake?
By not saying no at all. Name the price and hand the decision back. We can build it, it costs three weeks and moves the prototype build, which feature do we drop for it. Framed that way you are not braking, you are making visible the choice nobody wanted to make.
Q5: Who should decide on scope changes?
A named role, not a committee and certainly not chance. Who it is matters less than whether everyone on the project would give the same name. If three people answer differently, you do not have a scope problem, you have a role problem.
Q6: What if the customer demands the added scope?
Then it is not feature creep, it is a commercial question. Take the request, price it fully including life cycle cost, and hand it back. The trouble only starts when somebody agrees out of politeness before the price exists.
Q7: How do I estimate life cycle cost without solid numbers?
With ranges rather than point values.
Unit cost and expected volume are already in your calculation. Maintenance effort can be estimated from comparable variants in the past. A rough estimate recorded in the minutes changes decisions. A perfect calculation nobody has changes nothing.
Q8: Does this apply to software in the vehicle as well?
Especially there, because software creates the impression that added scope costs only development time. In reality every function costs permanently: validation, variants, regression testing on every release, diagnosis in the field. The research on maintenance has been consistent since the late seventies and has never reversed.
Q9: How do I stop my own team from building too much?
Not through prohibitions, through the first question. Who uses this feature and how often is a technical question engineers enjoy answering. Bans only produce workarounds and damage the motivation to bring ideas forward at all.
Q10: What do I do with a feature already built that nobody uses?
Measure first, then decide. Check actual usage, check contractual commitments, and calculate the annual maintenance cost. Removal is often more expensive than expected because other functions hang off it. That is precisely the point: commitment forms immediately and dissolves slowly.
Q11: Does scope discipline not conflict with innovation?
The opposite holds. Capacity sitting inside unused features is missing for the next real innovation. Innovation does not come from building everything that is possible, it comes from having resources free for what matters.
Q12: Is a better change process enough?
The process is necessary and rarely sufficient. It only bites once somebody is willing to state the price and hand the choice back. That capability is leadership work rather than paperwork, and it can be learned, for instance through executive coaching or mentoring for team leads.
About the Author: The Intersection of Three Worlds
Most providers are either a coach or a consultant. They know projects from accompanying them, not from carrying them. I have worked in all three worlds.
Executive leadership: 25 years of operational automotive DNA, 150 million euro of revenue accountability, an engineering site with 40 engineers built from a greenfield.
Executive coaching: ICF PCC certified, more than 1,000 coaching hours.
Intercultural transformation: four years as the accountable leader in Slovakia, two years in Pune, alongside experience in Germany, China, Mexico and the United Kingdom.
The over-engineered test bench in this article is my own mistake, not a client's. That is exactly why I recognise the pattern early today. More about the path is on the page about Andy Balbus and in the case studies.
Results or Excuses?
Every additional feature nobody named and nobody priced still gets paid for. You pay it in unit cost across the whole programme, in verification effort on every change, and in cost of poor quality that ASQ and Juran place at 15 to 20 percent of revenue. The most expensive feature is the one whose faults only two people in the company can find five years from now.
In 30 minutes we take your current added scope apart, name the corner that is quietly paying, and you leave with a sentence that hands the next good idea back without losing the person who brought it. I bring the view from leadership, coaching and cultural change at the same time.
After start of production the same decision costs a multiple: a 30-minute Reality Check
One calendar link, no preparation required.
You can also reach me through the contact page. How the formats connect is visible in executive coaching, in intercultural mentoring, in the legacy programme for owners and in Your Power Within. For leadership without formal authority there is mentoring without authority, and for strategic influence mentoring at director level. If you want to dig into root causes, start with breaking down silos, the extended workbench, the translation tax and the chief firefighter syndrome. The conflict architecture, the Gemba Walk, active listening, the GROW structure, the team charter workshop, remote leadership and my article on the first leadership role round out the set.
Systematic Leadership does not end with a phone Call.
Follow Andy for more Perspectives and Insights.
Leave a Reply