Most consulting methodologies disappear with the practice that sold them. The website goes dark, the templates stay on someone's old laptop, and the method survives only as habits in the people who used it. Project Mechanics followed that path for a while. The consulting practice ended in 2015 and the website stopped working in 2019, yet the methodology kept being used and kept changing. That's why these pages exist.
This page records three eras: the consulting practice, the years when the website outlived it, and the 2020s, when the method was reworked for teams that deliver in sprints and releases and was written down again as the practices on this site.
Three eras
| Years | What Project Mechanics was | What carried it |
|---|---|---|
| 2002–2015 | My consulting practice, run as a d.b.a. | Client engagements and the Project Mechanics website |
| 2015–2019 | A website that outlived the practice | The site, updated occasionally, until its platform failed |
| 2020s | The way I manage delivery work, reworked for iterative teams | Daily use, then the essays on this site, then these pages |
2002–2015: the consulting practice
I founded Project Mechanics in 2002 as a consulting practice, to put into a repeatable form what I'd learned about delivering complex projects. The first real version of the website went up in December 2004. Over the next decade the site and the services changed several times, and most of those changes taught me something I still use.
| Year | What changed | What it taught me |
|---|---|---|
| 2004 | A minimal site: home, methodology, guestbook, site map | I hadn't decided whether the method was something to share or something to sell, and that ambiguity shaped the next several years |
| 2006 | Hosted under a partner's brand, with navigation stretched into lifestyle topics | Reach bought at the cost of coherence. Visitors couldn't tell what Project Mechanics was any more |
| 2008 | Back to the Project Mechanics name, with case studies and web publishing services | In a services business, the person doing the work is the brand |
| 2010 | Repositioned around integrated web publishing, with live social feeds on the site | A busy feed looked active and moved nothing. Activity isn't progress |
| 2011 | SharePoint integration became a major service | Following client demand opens a market and adds complexity. I kept SharePoint as one capability rather than letting it become the identity of the practice |
| 2013 | The site streamlined around project management and leadership resources | Accumulated features hurt clarity. The analytics showed most visitors skimmed, so I wrote fewer, better-structured pieces |
The practice wound down in 2015, when I joined a company full time. I've worked in-house since, and Project Mechanics stopped being a business at that point. It has never been a company or an LLC, only a practice and then a method.
2015–2019: the site outlived the practice
The website kept going without the business behind it. It was rebuilt for phones at the end of 2015, and its content shifted toward requirements, design and building web APIs, which was the work I was doing and writing about at the time. Early in 2019 the platform it ran on failed, and the site stopped rendering anything but a browser-requirements message. I didn't rebuild it on the same foundation.
By then the method didn't need the site. It was in the way I ran projects, and the site had become a record of how the method had been presented rather than how it was used.
The 2020s: from consulting method to delivery practice
Through the 2020s I kept using the method on in-house delivery work, where most teams plan in sprints, ship in scheduled releases and work with a product owner rather than a client contract. The core held up, but the parts written for fixed-scope consulting needed work: phases became iterations, the weekly status report became evidence, and "complete" needed an outcome review behind it.
The lessons came out first as essays on this site. Release decisions, late-sprint hotfixes, outcomes over features, estimating in the fog, scope creep, turtling, measurement that turns into incentives: each essay worked through one problem I kept meeting. Building DevSpark, my framework for AI-assisted development, made the same lifecycle explicit for software agents. DevSpark became the engineering half of how I work, and Project Mechanics remained the management half.
In 2026 I rewrote these pages as working practice. Each one now opens with the problem it solves, gives the steps, decision aids and owners, and links to the essays its lessons came from. The essays stayed where they are; their lessons moved here as method.
What changed in the methodology
| In the consulting era | In the practice today |
|---|---|
| Client, staff and management | Business owner, team and leadership, each owning specific decisions |
| A project manager | A delivery lead who runs the mechanics, alongside a product owner who owns the backlog |
| Five sequential phases | The same seven life cycle states, delivered in iterations with a release clock |
| Weekly status reports | Status by state, with the evidence behind it |
| Formal change control | A recorded scope boundary and backlog ordering against outcomes |
| Complete when delivered | Complete when delivered, then outcome reviewed |
| Single-number estimates | Ranges with a confidence level |
| A list of PMI knowledge areas | Practices codified from specific, linked lessons |
What stayed the same
- The seven life cycle states, from Future through Complete and Cancelled. They describe a project's status whether it's planned in phases or sprints.
- The idea that project management is part mechanics and part art, and that neither substitutes for the other.
- The kickoff as the cheapest moment to settle expectations and decision rights.
- Accountability and authority as the first questions to ask about any stuck decision.
What the history taught me
Coherence beats reach. The partner-brand year brought more visitors and less clarity about what the method was. A methodology that tries to apply to everything ends up defined by nothing.
Activity isn't progress. Live feeds and frequent updates made the site look busy without making the method more useful. The same trap shows up in delivery dashboards, which is why the Portfolio & Program Management practice warns against scorecards that reward activity.
Choose which capability becomes your identity. Client demand can turn a practice into whatever the current market wants. I chose to keep each technical wave as a capability in service of the method.
Accumulation is the enemy of clarity. Each addition to the site made sense alone and hurt the whole. The same discipline applies to process: patch what leaks and remove what doesn't earn its place.
A method outlives its platform when it's written down and in use. The website failed and the practice ended. The method survived because it lived in daily work, and it's written down here again so it can outlive any one job.
Related terms
Project Mechanics, Business Owner, Delivery Lead, Product Owner, Release Clock, Outcome, Confidence Level, Decision Rights, Accountability, Authority