Which traps is your program in?

Too many open fronts

Twelve strategic initiatives for an organization that finishes three a year. Each one has a sponsor, a budget line and a kickoff deck; none has the people it needs.

A roadmap of starts

The roadmap shows when things begin, never when they end. Progress is reported as "launched," so starting feels like delivering.

Everything is priority one

When every initiative is critical, none is. Teams quietly set their own priorities, and they rarely match the sponsor's.

The small reasonable yes

A demo for the regulator, a request from a key client, a quick win for the board. Each addition is too small to refuse, and nobody counts the total.

The new sponsor's pivot

A new executive arrives and wants their mark on the program. The direction changes, the reasons don't.

Two versions in parallel

Instead of choosing, the program builds both: web-first and mobile-first, the old process and the new one, "for a while." The while never ends.

Zombie initiatives

Work that nobody stopped and nobody funds properly. It keeps running "just in case," consuming people, infrastructure and attention.

The switching tax

People spread across four or five commitments spend more time reloading context than doing the work.

Full queues, slow flow

Everything is in progress, so everything waits for something else. Lead times stretch, even though everyone is busy.

Speed mistaken for direction

Velocity charts go up, demos look great, and the program is no closer to its outcome than six months ago.

The solution as a requirement

The program is launched as "a new portal," "a data platform" or "an agent," not as a problem to solve. Once the answer is the scope, nobody can ask whether a smaller answer would do.

Everyone's wish list

To get the business case signed, each stakeholder receives one item in exchange for their support. The scope becomes a peace treaty, not a design.

Platform before product

The program builds infrastructure for needs nobody has yet: the generic engine, the reusable framework, the API every team will one day consume. Today's users wait for tomorrow's.

"While we're at it."

The most expensive four words in IT. The team is already touching the system, so the adjacent change looks free. It never is: it brings its own tests, data, dependencies and stakeholders.

Matching the rival

A competitor ships something, and it goes on the list without anyone checking whether your customers want it.

The compliance umbrella

Some requirements are truly mandatory. But once "regulatory" becomes a password, everything shelters under it, and nobody dares ask which article of which text actually requires this feature.

Changes without a price

New scope is accepted in a workshop, recorded in a backlog, and never shows up in the date or the budget. The plan stays green. The ship gets heavier.

No non-goals

The program says what it will do, never what it won't. Anything not explicitly excluded is fair game, and every steering committee reopens it.

Descoping as failure

Removing a feature feels like breaking a promise to its sponsor, so nobody proposes it. Programs add scope easily and remove it only in a crisis, when removal costs the most.

The test that gets explained away

The performance test fails, pilot users struggle, the migration rehearsal takes three times longer than planned. Each result gets a reason, and none of them gets to change the plan. The admiral stops the test, and the ship sails anyway.

"Our program is different."

Every program feels unique from the inside, so nobody looks at how similar programs actually went. Daniel Kahneman called it the inside view: we plan from our own story, not from the evidence of everyone else's.

The estimate as negotiation

The first honest number is "too high," so it gets reworked until it fits the budget envelope. Then the negotiation runs the other way: teams blamed for "missed points" learn to pad, and estimates quietly inflate. Either way, the number stops being a forecast and becomes a defense.

No room for the unknown

The plan covers every known task and nothing else. Contingency is either missing or quietly spent in the first quarter on things that were known all along.

Scope, date and budget, all fixed

Locking all three leaves quality as the only variable. It gives way silently, and the bill arrives after go-live.

The date came first

The deadline was announced before anyone planned the work, and the plan was then built backward to fit. Everything looks feasible, because it was designed to.

Building before designing

Like the Opera House podium, work starts before the key unknowns are solved, to show progress or to secure funding. Early speed becomes late rework.

The long window

Years of build before the first real user. The longer the window, the more time the world has to change underneath the plan: new regulations, new leaders, new technology.

False precision

A Gantt chart detailed to the day for month eighteen. The precision suggests a certainty nobody has, and makes every deviation look like a failure.

Plans per team, not per program

Each team has a credible plan. The integration between them, where most of the risk lives, belongs to no one's plan.

Sunk cost

"We've spent too much to stop now." The money already spent becomes the reason to keep spending, long after the business case stopped making sense.

Nine women, one month

People added late, when the program is already behind. Each newcomer slows down the experts before speeding anything up.

Staffing by availability

The team is made of whoever was free, not whoever was needed. The program gets the people nobody else asked for, and is then surprised by the results.

Hiring in a hurry

The ramp-up plan needs thirty people by June. Interviews get shorter, the bar quietly drops, and onboarding becomes "read the wiki." A bad hire made in a week takes a year to undo.

Outsourced thinking

The integrator designs, builds and understands the system. The internal team manages the contract. When the contract ends, the knowledge leaves with it, and the company owns a system it can't explain.

Conway ignored

Melvin Conway observed in 1968 that systems mirror the communication structure of the teams that build them. Draw the teams one way and the architecture another, and the org chart wins every time.

The hero

One person knows how the critical system really works, answers every escalation and works every weekend. Everyone admires them. Nobody notices that the program now depends on one person's health and goodwill.

People sliced into percentages

Thirty percent on this program, forty on that one, the rest on run. Two managers, three stand-ups, no real team. Each slice pays the full cost of switching context.

Culture change by memo

An agile transformation is announced, values go up on posters, new job titles appear. The budget process, the approval chain and the leaders' behavior stay exactly the same. People believe what leaders do, not what they say.

The best engineer becomes a manager

The program loses its strongest engineer and gains a manager with no training, no support and no time. Both jobs suffer, and so does the person.

Management by pressure

Deadlines are pushed down, mistakes are punished, and questions are seen as resistance. People stop raising problems, stop proposing ideas, and eventually stop caring.

No owner

Everyone is consulted, nobody decides. The question circulates between committees until the deadline decides for everyone.

The HiPPO

The highest-paid person's opinion settles the matter, whatever the evidence. Teams learn to guess what the boss thinks instead of finding out what is true.

The trip to Abilene

Everyone agrees out loud and disagrees in private. The decision is unanimous, and nobody believes in it.

Too many gates

Architecture board, security review, budget committee, steering committee, each meeting monthly. Every gate adds weeks of waiting for a few minutes of decision.

Bikeshedding

C. Northcote Parkinson described a committee that approves a nuclear plant in minutes and then debates the bicycle shed for an hour, because everyone understands a bike shed. Programs spend hours on logo colors and minutes on the data model.

Every decision is a one-way door

Reversible choices, like a library, a screen layout or a test approach, get the same scrutiny as irreversible ones, like a core vendor, a data model or a contract. So the small ones are slow, and the big ones get rushed to catch up.

Waiting for certainty

One more study, one more benchmark, one more opinion. Information keeps arriving, and certainty never does.

The boomerang

A decision taken in March comes back in April because someone missed the meeting, or simply didn't like it. Nothing is ever really decided.

Meeting amnesia

The decision was made, but nobody wrote it down. Six weeks later, three people remember three different versions.

The silent veto

Everyone agrees in the room, and then nothing happens. The decision is respected on paper and ignored in the backlog.

Too abstracted

A generic engine to handle every future case. Rules stored in metadata, configuration on top of configuration. It promises flexibility. In practice, the simplest change now needs the one person who understands the framework.

Over-engineered

Event sourcing for a back-office form. Twenty microservices for a product with three hundred users. A service mesh before the first customer. Each choice is defensible on its own; together they multiply the moving parts the team must master.

Built for the dream scale

Architecture sized for a hundred million users when the business plan targets one hundred thousand. Sharding, multi-region and caching layers that cost months now, for a load that may never come.

Gold-plated everywhere

Five nines, zero downtime and the strictest security profile demanded for every component, including the internal reporting tool. The bar is set by the most critical system, never by the actual risk.

Not invented here

An in-house framework, a homemade workflow engine, a custom identity server. Building it is exciting. Maintaining it for ten years, with the people who built it long gone, is not.

Unknown or fashionable stacks

The new language or framework is exciting, often fresh from a conference, and nobody on the team has ever run it in production. Learning happens on the critical path, with the deadline watching.

The grand rewrite

The legacy system works, but it is ugly, so the program will replace it with the perfect one, all at once. Fred Brooks named this the second-system effect: the successor carries every idea the first one had to leave out. Meanwhile, the old system keeps changing, and the target keeps moving.

Never good enough to ship

The architecture phase is extended once, then twice. Nothing reaches production until everything is right, so nothing is learned from real users until it is far too late to change course.

Blind to production

Designs validated on a laptop and in slides, never under real load, real data volumes, real network failures or a real 3 a.m. incident. Production behavior is discovered at go-live, when it is most expensive to learn.

Misunderstood and misused

A powerful tool used against its grain: a cache treated as a database, a message broker used as a workflow engine, an ORM fighting the data model. The technology isn't wrong. The way it is used is.

Waiting for the tools

A ticket to get a test environment, another for database access, a third for a firewall rule. Each takes days, and each blocks a developer who was ready to start.

Waiting for a signature

The work is done, and it sits until the next architecture board, security review or change committee. A few minutes of review, weeks of queue.

Waiting for another team

You need one small change in a shared service. It goes into their backlog, behind their own priorities. Your sprint ends before their next one starts.

The relay race

The analyst writes, the architect designs, the developer builds, the tester tests, the ops team deploys. At every baton pass, context is lost and questions pile up. Five handoffs, five translations of the same need.

Ticket ping-pong

"Can you clarify?" "See comment above." "That's not what we meant." A question that would take two minutes face to face takes two weeks through a ticketing tool.

The unread document

Forty pages of specifications that took a month to write and nobody reads end to end. The real decisions get made later, in a hallway, and never make it back into the document.

Meeting overload

Recurring meetings that outlived their purpose, status meetings where people read out what they could have written, and invitations sent to twelve people "just to keep them informed." Calendars fill up, and the work happens in the gaps.

The reporting tax

The same status rewritten four times, for four committees, in four templates. More effort goes into explaining progress than into making it.

Doing it twice

Requirements misunderstood, defects found late, features rebuilt after the first demo. Rework is the most expensive waste, because you pay for the work twice and for the delay in between.

Manual toil

Manual deployments, manual regression tests, data copied by hand between systems. Every repetition is slow, error-prone and quietly exhausting.

The status is an opinion

The color is chosen by the person accountable for it, based on how they feel about next month. Nobody asks what evidence sits behind it.

One shade lighter per level

The developer says red, the team lead reports amber, the program reports green-with-watchpoints. Each step softens the truth a little, with good intentions, until the top of the chain sees a different program from the bottom.

The catch-up plan that can't catch up

Every slip comes with a recovery plan, and every recovery plan assumes the team will suddenly go faster: fewer bugs, quicker decisions, no sick days. The status stays green on the strength of a velocity nobody has ever seen.

The silent rebaseline

When a milestone slips, the plan is quietly redrawn. The program is always "on plan." It just isn't the same plan as last quarter.

Activity instead of outcomes

Percentage of tasks complete, story points burned, documents delivered, hours spent. All of it can be green while nothing works end to end.

The 90% syndrome

Every workstream is 90% done, and has been for three months. The last 10%, integration, data, performance, real users, is where the real work hides.

Goodhart's law

When a measure becomes a target, it stops being a good measure. Once the milestone dates are what gets judged, milestones start being declared "achieved with reservations."

Red is punished

A red status triggers audits, extra reporting and senior visitors. The team learns that red costs more than the problem itself, so red is avoided until it can no longer be.

The steering committee as theater

Sixty slides, a packed agenda, no decisions. The meeting is designed to reassure, not to decide.

The vendor's green

The integrator reports green on its contractual scope. Every supplier is green on its own part, and nobody owns the color of the whole.

Each team on its own bank

The program is split by team, vendor or system, and each part has its own plan. The integration between them belongs to everyone's plan, which means no one's.

No walking skeleton

Months into the program, there is still no single flow that runs end to end, from the user's screen to the last back-end system and back. Every component exists; the journey doesn't.

Big-bang integration

All the parts are connected at once, in one "integration phase" near the end. When something breaks, nobody can tell which of the twenty new connections caused it.

Contracts only on paper

The interfaces are described in a specification document, signed months ago. Nobody tests them automatically, so each side implements its own reading of the same page.

Same word, different meaning

For one system, a "customer" is a person; for another, a contract; for a third, a household. "Date" means booking date here and value date there. Every team is right in its own context.

Environments that don't match

Integration is tested in an environment with different versions, different configuration and a tenth of the data. It works there. Production is another country.

Migration in one weekend

Moving years of data is planned as a single cutover, rehearsed once, if at all. It takes three times longer than the window allows.

Dirty data, discovered late

Duplicates, missing fields, values nobody can explain. Real data only meets the new system at the first full rehearsal, and every rule written against clean test data breaks.

Performance after sign-off

Functional tests pass, the business signs off, and then the load test runs for the first time. The architecture decisions it would have changed were made a year ago.

Security at the end

The penetration test is scheduled two weeks before go-live. What it finds can only be fixed by delaying the launch or accepting the risk.

Go-live as the finish line

The program's definition of done, its budget and its success criteria all stop at go-live. Everything after belongs to "the business" or "run," which means to nobody in particular.

Users meet it at training week

Real users see the system for the first time a few weeks before go-live, in a classroom, with demo data. Their feedback arrives when nothing can change anymore. Change management is reduced to a communication plan.

Operations, not invited

The run team discovers the system at handover: no runbooks, monitoring added at the last minute, an on-call rota built over a weekend. They will own it for ten years; they met it on Friday.

The big-bang cutover

All users, all features, all data, on the same weekend. The bet is that everything works at once, because the plan left no room for anything else.

No way back

There is a plan to go live, and no rehearsed plan to go back. When the first serious problem appears on Monday morning, the only option is to fix forward, under pressure, in production.

The team leaves with the guests

The program team is disbanded, reassigned or out of contract the week after go-live. The people who understand why the system works the way it does are gone just when the questions start.

Benefits nobody measures

The business case was written to get funding, then filed. Nobody took a baseline before the start, so nobody can say what changed after.

The zombie legacy

The old system was supposed to be switched off "three months after go-live." Years later, it still runs for one report, one team, one edge case, and the organization pays for both.

Workarounds become the process

Users route around what doesn't fit them: an export to a spreadsheet, a shared mailbox, a manual step. Soon the real process lives outside the system, and nobody designed it.

IT owns the program, nobody owns the outcome

The sponsor's attention moved on the day after the party. The system has an owner; the result it was built for does not.