From basic to specialty, and everything in between

Start With The End In Mind

Every project has a beginning. And every project has an end. If something you’re working on is open-ended or is a continuous improvement initiative, it’s not a project. A defining feature of a project, which might come as a surprise to a lot of people, is that it has a well-understood finishing line.

The vast majority of what engineers and scientists do most often is project work. Even if it’s a project which fits into a broader arc of something which looks less bounded, the work we do is nearly always project-based. We’re always working to achieve something specific or to reach a particular goal.

Yet more often than you might expect, most of us only give a cursory glance to what that finishing line looks like before we set out. We might define the shape of our end point, but it’s not very common to really map out what the destination looks like.

The Finishing Line

By clearly defining what we’re going to achieve, and how we’ll know when we’ve achieved it, we’re a lot less prone to the continual tweaking and improving which have a tendency to make projects run late and over budget. See my last post; The Art of Good Enough.

That’s not to say that every little detail of the project needs to be defined up front (a lot of those details won’t be known until work begins), but key deliverables should be well understood from the outset.

What are the things that the project must do or be in order for it to be successful? What are the things that would mean the project has failed if they’re overlooked? Fleshing out answers to these questions, and making sure everyone is on the same page, is a very useful way of ensuring the finishing line is well understood.

Validation

Perhaps the most important reason (in most cases) for thinking about the finishing line before we start, is because having a clear enough definition of what the end looks like makes it possible to demonstrate that we’ve achieved everything we set out to.

I’ve worked on a project before where my teams’ definition of the end point wasn’t quite aligned with that of our customer (who happened to be outside of our organization). So, when we thought we’d reached the end, the customer thought there was still more to do. As you can imagine, that mismatch led to some difficult conversations.

Ultimately that mismatch also leads to us doing additional work which we hadn’t budgeted for, with time we hadn’t allocated. Clearly, that wasn’t an ideal.

If we’d done a better job of describing our end point, in the beginning, that situation could have been avoided entirely. Or at the very least, we’ve have known about the mismatch before we even started working, which is a much better time to be having that sort of conversation.

Clearly defining the finishing line at the beginning, and agreeing that with everyone who needs to be involved (usually all stakeholders for the project if possible) means that you’ve got something to point back to when the time comes.

A good set of agreed requirements, with an idea of how you intend to prove you’ve met each one, is the perfect foundation for starting a project. Having that in place early has the potential to save a huge amount of work later on.

Before diving into your next project, perhaps it’s worth taking a longer pause than normal. Do you have an agreed upon the picture of that the end looks like? Will you know when you’ve done enough? Will you know when to stop? Are you starting with the end in mind?