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 forecasts delivery a month later than a stakeholder wants. The request from leadership is familiar: shave three to four weeks off somehow. I see three common patterns here:
Calendar‑first decisions: the date is set before the work is properly understood. Milestones are pencilled in, then the plan is asked to comply.
Compression: “we’ll find a way” stands in for actual re‑planning. The promise is brought forward without consideration of any of the detail.
Status optics: shorter timelines read well in updates. They create the appearance of decisive progress; estimates are marked down, risks are relabelled, and testing is squeezed down to nothing. The real cost is just hidden at the end of the plan where rework happens and the actual launch keeps getting delayed month by month, until it actually delivers two month after the original forecast
When “shorter” is the goal, delivery teams start negotiating with reality instead of with the sponsor. It can look decisive but it rarely is. 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 it doesn’t work everywhere: you cannot “add eight people” to get a baby in one month.
Crashing a realistic plan 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, slow you down, create re-work or inconsistent levels of quality.
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 as much as they are often easier to understand. Some are simply habits. Challenge your logic, begin downstream work where assumptions are firm, and accept you are increasing the risk of rework.
Questions Before You Agree To “Be Creative with Dates”
How are we measuring success two or five years from now, beyond the go‑live date?
Is reducing the timescale worth risking those long‑term outcomes?
Watchpoints
Planning and estimates
Do not mark down estimates without justification
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.
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 compress the critical path by wishful logic. Change the work, or leave the dates alone.
Decisions and Governance
Do not bundle decisions. Small, fast choices beat large, delayed approvals.
Product
Do not erase the MVP boundary.
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.