Why is it so hard to finish things? How to know when to start something new, and when to finish.

When was the last time a project you were working on finished neatly?

Rarely do our projects wrap up nicely, despite our best laid plans.

There also seems to be an inherent cognitive bias in most people (myself included) such that when we think the hardest part is over, our interest in that project takes a dive. It’s around then that we starting looking for the next new thing to work on.

Unfortunately for the user or customer, the first approach at a solution is rarely an optimal experience for them — there’s just too much complexity in the real world to easily capture them in specifications.

But by the time they’ve had a chance to use the system in the real world, and formulate meaningful feedback, the developer / development team / designer / writer / policy maker / physician is already on another project.

Feedback cycles in that “almost done” project now become much longer. If the changes are hard, it’s likely they’ll be delayed until this newer, next project is “over”.

The user (and thus also the business owner) are not happy — they have a sub-optimal product. Meanwhile, the development / design / writing / policymaking / care teams are not happy either — they feel they worked hard, delivered something, and are not getting the credit or appreciation they deserve. On top of that, they’ve got another hard project but keep getting more work from this ‘old’ project!

And for some projects with a lot of uncertainty, or challenges in the first delivery, things can be a lot worse!

Why does this seem inevitable? What causes it to happen on seemingly every project?

Blame our inclination for productivity. You have a certain amount of time and want to be as productive as possible. As a project ends, you have slack effort available. It’s a shame to waste it, and it’s either costing you (if you’re a freelancer) or your boss (if you’re an employee). Naturally, you decide to use it by taking on new projects. And so the cycle begins again….

So what can we do about it?

‘Plan better’ is the usual refrain. While ‘better’ planning is of course helpful, it usually ends up being executed as ‘more’ planning, i.e. burdening the process with more upfront, detailed requirements, more meetings etc.

A more helpful question might be:

How can I get better at finishing well?

Here are the key steps that I use to get projects ‘to done’:

1. Define ‘Done’: Take the time to define ‘done’ well (for you and your team, but especially for the user / end client)
2. Establish That ‘Done’ is a Multi-Step Process: Saying something is “done” usually really means “the first iteration and delivery is done. You should intentionally allocate some time from the core team to “really get it done” — usually at least another two mini-sprints. Setting everyone’s expectations up front goes a long way.
3. Use an Extra Post-Delivery Time to Capture the Learning Dividend: Protect the slack time of the core team/yourself as a “project learning dividend” while you wait for user feedback. Use this time to capture lessons learned from the project and its development. Define metric milestones and set up automated ways to review those. Learn new techniques you suspect may have helped you in this project. Do in-person code reviews to better capture and distribute learning across the team. Beware over-engineering for “future state” things here; instead, capture ideas and pseudocode for future states, but unless it fixes something in the project, don’t add it in yet.
4. Control the Iterations: Be flexible but firm with your user/client about the number of refinement iterations (they may ask for the world here — give them a structure to prioritize what is needed for now, and what is a ‘next phase/project’ issue). If you have a clear definition of ‘done’ (see Step #1), it’ll make this step easier.

As a manager:

• Protect your team’s time to allow them to “finish projects well”
• Help them stay in the zone of the project with the “project learning dividend”
• Energize them for the final sprints. In-person user feedback can be particularly powerful for this.
• Getting things done well is great not only for the user, but for team pride and individuals’ sense of achievement. It can contribute to job satisfaction and retention.
• For team members with multiple ongoing projects, help them understand that completing projects and tasks well is both a way to please colleagues and stakeholders, and an effective way to reduce stress and free up valuable time for themselves.

I’m using this approach for my own projects (yes, I’m trying new things so often that projects almost always take longer than I expect!). For more on that, read my piece on the ‘x-factor’.

What if you are already on too many projects? There are a lot of approaches and techniques that you can use which I’ll address in a later article.

So get it done, and get it done well!