Applying the Manifesto of Done to project management

Project management methodologies come and go, but the underlying principle of PMing itself remains the same: how do we move the project to completion? how do we solve existing problems? what's our horizon for anticipating new ones? On the other hand, the Manifesto of Done is a short, pithy statement of intent by "members of the cult of done" on how to achieve done-ness, a kind of continual state of simultaneous productivity and calm, in your working life and beyond.

Like any pithy statements, it can be ruined by being made more verbose, so I thought I'd give that a go and try to apply it to how I see my role in everyday PM tasks. Having rammed together these rather dubious raw ingredients, I can now present to you:

The project manager's guide to Manifest Done-ness

This is a consideration of the Manifesto of Done, to work out what practical steps you might take based on it. I present each point in turn, followed by my interpretation of their practical application in projects.

For reference, I refer to "features" as part of feature-driven development, as the smallest deployable units within a project.

1. There are three states of being. Not knowing, action and completion.

Once you're ready to start a feature, start it. The is no state of knowing-without-action. Shelving indefinitely is a symptom of failed processes; fix them.

2. Accept that everything is a draft. It helps to get it done.

Prototype early, experiment and stage your work so others on the project team can see it. If there are team members likely to get distracted or react negatively, only include them when an agreement needs to be reached. Otherwise, build boldly and iterate gladly.

3. There is no editing stage.

A prototype which fulfils the specification and satisfies all your constraints - including code review - is a likely candidate for completing the feature. You should build your prototypes accordingly, as a good prototype can and should become the finished product.

4. Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it.

Only document research as much as you really need for the next piece of work. Don't worry about what you don't need to worry about. Specify just in time.

5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.

Projects are a bit less forgiving about dropping features than the Manifesto of Done would like! Nonetheless, if a feature is blocked, then this is unacceptable to the project and the priority is to unblock it. Logjams are there to be cleared, not to be leant on as a support. Expect to nag and be nagged.

6. The point of being done is not to finish but to get other things done.

The most difficult phase of a feature's life cycle is not finishing it, but specifying it in the first place, so it can be finished with the minimum effort. At the same time as the completion of the current feature following straightforwardly from its specification, turn anticipating the next feature into a motivation for completing the current one.

7. Once you're done you can throw it away.

Once a feature is done, it's done. Don't revisit a feature everyone has agreed is done. Later events don't undo that decision by the project team. A bug on a closed feature is itself a new feature.

8. Laugh at perfection. It's boring and keeps you from being done.

Web projects rarely finish. Audiences don't care about launch dates. Launch the minimum you can: people won't miss what isn't there. Always plan for and have a vision for a phase 2, and a phase 3, and so on.

9. People without dirty hands are wrong. Doing something makes you right.

Contributing means moving a feature forwards. Contributing means breaking the logjams. Everyone commits to keeping features moving towards completion.

10. Failure counts as done. So do mistakes.

Discovering, diagnosing and then discarding a bad idea is hard work and a job well done. If a feature turns out to be a bad idea, redundant or just impossible, terminate such bad features with a glad heart.

11. Destruction is a variant of done.

Deciding a feature is unnecessary before you even start it is the best way to complete it. Be ruthless about what the project doesn't need.

12. If you have an idea and publish it on the internet, that counts as a ghost of done.

If discussions or reviews consistently don't yield "featureable work", ask why. A review prior to determining features, is itself work done; why aren't your reviews considered features in their own right? Celebrate every "done" equally.

13. Done is the engine of more.

If you limit your work in progress - and you should - then every completed feature means you can start another feature. Pushing the project forward, feature by feature, is everything.

A final note on not being a project manager

You might not be a project manager. I too am not a project manager. PMs have skills to make them comfortable with an interruptive comms-and-thoughts cycle I can't quite cope with: you might say I'm happier on the maker's schedule than on the manager's schedule. But below project management, yet above the actual writing of code, lies process management: ensuring individual items of work, of which a project ultimately consists, are treated with the respect that they and the project deserve.

I can't recommend highly enough that, PM or not, you should consider improving your process management skills. It makes you a better developer, certainly: but it also makes your projects healthier projects. Apply the manifesto; focus on done; consider the practical steps I've outlined above. Your project, and eventually your client, will thank you for it.