An Introduction to Project Acceleration
Speed is seductive, but it is not the same as success.
In this post, I unpack crashing and fast‑tracking. This note defines both, shows where they help, and frames the questions to ask before using either.
Pressure On Dates Rarely Improves Outcomes
I have lost count of the number of times a realistic plan lands a month later than a stakeholder wants. The request is familiar: shave three to four weeks off somehow.
Leaders often want things shorter, not better and not necessarily realistic, simply shorter. I see three common patterns:
Calendar‑first decisions: the date is set before the work is named. Milestones are pencilled in, then the plan is asked to comply.
Compression by assumption: “we’ll find a way” stands in for actual re‑planning. The detail is deferred, the promise is brought forward.
Status optics: shorter timelines read well in updates. They create the appearance of decisive progress. The cost is hidden in the middle of the plan where rework happens.
When “shorter” is the goal, delivery teams start negotiating with reality instead of with the sponsor. Estimates are marked down, risks are relabelled, and testing is squeezed. It can look decisive. It rarely is. The work does not get smaller because the calendar does.
The plan can sometimes be made tighter with clear trade‑offs but shaving time without changing scope, risk, quality, or resources is not a plan.
Crashing
Crashing adds people to shorten effort‑driven tasks on the critical path.
But there is a truth that is simple, and uncomfortable. You cannot “add ten people” to get a baby in one month.
Crashing a realistic plan invites rework, stress, and a jittery go‑live that damages trust. It raises cost and only helps when tasks can absorb extra hands. If the bottleneck is a single subject matter expert or a constrained tool, throwing more people at the task will not help, it will probably do the opposite and slow you down.
Adding people also increases coordination overhead. If you crash, do it where tasks can be split cleanly, and pair new joiners with experienced team members for faster acclimatisation.
Fast‑Tracking
Fast‑tracking overlaps tasks by challenging dependencies.
The main downside though is that it raises the risk of rework. Finish‑to‑start links are not sacred. Some are simply habits. Challenge your logic, begin downstream work where assumptions are firm, and accept you are increasing the risk of rework. Use robust change control so you do not erode quality while you chase speed.
Questions Before You Agree To “Be Creative with Dates”
How will we measure success two or five years from now, beyond the go‑live date?
Is reducing the timescale worth risking those long‑term outcomes?
Those questions create pause, and often unlock better negotiation on scope, resources, or phasing.
Watchpoints
Planning and estimates
Do not mark down estimates without justification. Optimism buys short‑term peace and long‑term discomfort.
Do not hide or cut contingency. If you need it, name it.
Do not over‑promise dates for optics. Publish credible plans with visible trade‑offs.
Do not ignore vendor lead times. Contracts, access, and environments have their own calendars.
Quality and testing
Do not shorten testing windows casually. A calm, positive go‑live requires time for stabilisation, quick wins, and confidence building.
Do not trade documentation for speed without a plan to recover it. Missing artefacts slow audits and support.
People and coordination
Do not assume new hires are instantly productive. Onboarding time is real.
Do not stretch overtime beyond short, strategic bursts. Fatigue creates mistakes and poor decisions.
Do not multitask your way to speed. Focus finishes work; context switching elongates it.
Scope
Do not make “silent scope cuts”. Be explicit about what moves out and who agreed.
Do not compress the critical path by wishful logic. Change the work, or leave the dates alone.
Decisions and Governance
do not spring decisions on your SteerCo. Signal decision points early so approvals land on time.
do not bundle decisions. Small, fast choices beat large, delayed approvals.
Product
Do not launch features nobody asked for. Prioritise value now, not theoretical value later.
Do not erase the MVP boundary. If you promise iteration, plan it.
Cost and risk
Do not believe crashing is free. Extra people cost, and coordination time is a cost.
Do not defer risk treatment. Faster projects need clearer risk ownership, triggers, and contingency.