Most project management frameworks say they can be adapted to any scenario, but in practice it's just not true. I’ve worked in hundreds of companies and in very few have I ever seen a framework implemented fully. On the rare occasions I have, it’s been cumbersome, process-driven, and inflexible. Difficult to adapt to changing user requirements quickly, even under Agile, which is supposed to be the point.
The problem with frameworks (and maybe I’m committing an ordinal sin here) is they attract the wrong kind of people. Inflexible, process-orientated people. People who care more about the system ticking over than the customer being satisfied.
The second problem is that they assume the delivery team and the customer are the same thing. They don’t factor in budgets, outcomes, or customer expectancy. Agile in particular is written like there’s an endless investor bankrolling an endless backlog. Waterfall is at least honest enough to expect an end and a completion date, but it still doesn’t have the flexibility to deal with multiple, conflicting, or outright hostile stakeholders.
When you’re in consulting, you see all the cracks at once...
- Customers changing outcome goals halfway through but still wanting the budget spent.
- Budgets running out and the whole thing has to pivot.
- Nobody clear on who owns what of the products developed. What if a consultant develops a nifty little undocumented automation to speed things up?
- The consultancy under pressure to burn budget by a certain date, or spend as much money as possible.
- Customer employees setting up gateways ("security need to sign that off"), deliberately slowing things down.
- The IT contracted out to a third party who won’t touch a thing without a work order.
- People disappearing on leave unannounced.
- Timezones — never knowing who’s working where or when.
- Consultants making changes on request without the PM being looped in.
- And sometimes you’re dropped into a failing project halfway through and told to make it a success.
None of the frameworks cover any of that.
So Bootstrap Project Management is about three things.
-
Outcomes. Getting sign-off from the customer on completion and milestones. Satisfaction is the target. Not completed tasks. Not polished products. If they sign, you delivered.
-
Minimalism. Only use what you need and what works. Tools, project documentation, all of it — keep it stripped down.
-
Flexibility. The project must be ready to pivot, driven by change, and able to absorb undocumented changes without falling apart.
In practice, it means: whether you’re starting fresh or taking over halfway, you lock down outcomes and how the customer measures them. Translate those into KPIs. If it’s already halfway through, you figure out what’s signed off, what’s left, and what needs to be renogiated. You run kick-offs with each stakeholder group — customer, internal, partner — and you find the key decision maker in each. You document what each one actually wants out of it. Then you build the plan, but the plan isn’t fixed. It’s a living thing. Outcomes as milestones, granular enough that anyone can see who owns what. Customers get a lighter plan, milestones only, but it includes what they and their third parties have to deliver.
If the budget looks like it’s going to run out, you tell the customer straight and you renegotiate. If an undocumented change pops up, you file a retroactive change request and you get sign-off that the customer accepts the impact. And when something is signed off — contract, email, whatever — you lock it down. That part of the project is done, finished, no more work on it.
And I don’t care if someone wants to adapt this to Agile or Waterfall or anything else. The second you start bolting those frameworks on, it stops being Bootstrap. It stops doing what it’s supposed to do.
Bootstrap Project Management is about survival. It’s about delivering in the mess that real projects actually are. Outcomes signed off, customer satisfied, no wasted drag. That’s it.