Skip to content

Defining “Finished”: Don’t Leave Trash In The Forecourt

We recently had some (relatively minor) repairs done on the roof of our house. If you’ve ever had to arrange repair work on a house, you’ll know that the process can be tricky. It’s necessary to find a credible and reputable tradesperson, and then actually get a quote and arrange a date. What is made worse, of course, is when it comes to roofing problems there tend to be peaks in demand. When there’s stormy weather and rain, roofers are in sudden demand!

Following a few phone calls we found a suitable roofing firm, who were really easy to deal with. They turned up when they said they were going to, did the job with minimum disruption to us, and then left. They took photos of the work, and even alerted us to some other potential maintenance issues we might want to consider. This is pretty much everything you could hope for when it comes to having work done on a house!

And Then They Were “Done”

Several bags of rubbish/garbage piled in an urban setting. There are at least 11 bags visible, mostly big black bin liners, with the occasional smaller white shopping bag.
(Image credit ©sdf_qwe — yayimages.com #48587870)

Shortly after they had finished for the day and left, we received a message from the owner of the company confirming the work was complete and attaching an invoice. He also let us know that the rubbish they’d left behind would be collected in the next few days. That’s pretty important to us, as they had included removal of the rubbish in their quote, and as a ‘zero car’ household, it’s difficult to get rid of bulky waste.

This got me thinking about what the term “finished” actually means. I know there’s all sorts of debate about ‘definition of done’ in agile and I just don’t want to open that can of worms. Here, I’m speaking more generally about how different perspectives can exist on what ‘finished’ or ‘done’ actually means.  For example:

  • For the workers, the job might be considered ‘done’ once they’ve successfully repaired the roof and have sent photos to the boss (they are likely subcontractors, and they get paid on completion of the job).
  • To me, the job isn’t really done until the rubbish is cleared away and until I’m convinced that the repair has worked (i.e. until I’ve seen it survive some heavy rain). 
  • The boss might not consider the job ‘done’ until the invoice has been paid.

This got me thinking about the delivery of a change to a product or service, and how it might be useful to expand what ‘finished’ means there too…

Perspectives On “Finished” Are Key

It doesn’t matter whether you’re incrementally and iteratively delivering changes, or whether you’re delivering change in a linear fashion, there will come a time when a particular change has been implemented.  Yet ‘implemented’ in isolation rarely means ‘finished’.  For example, it’s quite possible to ‘deliver’ a new feature on an IT software system, but if that isn’t operationalised into a process, with adequate communication and training, then it probably won’t be consistently used…  That’s before we even get into the need to understand and measure what benefits it has achieved!

As with so much in business analysis, perspectives are key.  Perhaps a question to ask is “how might our service-users, consumers and stakeholders define what ‘finished’ looks like?’. This will vary by context, but might include:

  • Processes and procedures are updated
  • Training is complete
  • Transitional support has been provided for an agreed period
  • All key maintenance documents are updated
  • All key design decisions have been documented
  • A benefits management plan is in place
  • Etc…

These are just a few examples, and what’s relevant in your context may differ.  Even taking the examples above, the size and depth are likely to vary depending on what is delivered. A small incremental delivery of a feature on an existing IT application might require a tiny tweak to process documents, recording a 5 minute training video, being available for a single day to ensure things ‘bed in’ and then ensuring that a few key help guides are updated. This might represent a couple of hours worth of effort, if that.  If you’re delivering change in an incremental and iterative way, then it follows that you should update all knowledge artefacts in an incremental and iterative way too…  Frankly, they can be updated in whatever way works as long as they are actually updated!

Don’t Conflate Rigour With Bureaucracy

One thing that always confuses me is the tendency for tasks which don’t involve writing or deploying software to be seen by some as somehow ‘bureaucratic’. Is updating and communicating a business process (so that people actually know how to use new software) bureaucratic? I don’t think so. Ultimately, if valuable change is going to work it has to be correctly delivered and correctly embedded and it has to be maintainable. One out of three won’t cut it!

All sorts of dysfunctional games can emerge where teams are incentivised to ‘get stuff over the line’. The questions to ask are : “which line?”, “who defined it?” and “where the right people involved in defining it?”.

If the impetus is genuinely just to deliver stuff and disappear, then fine, that’s easy. We can all chuck stuff over a fence every two weeks and hope for the best. But surely, as a community of change professionals, we’re far beyond that mode of operating these days? And if we are, then we really ought to think about what ‘finished’ means… else we risk leaving the roofing rubbish in somebody’s forecourt…

With more of a focus on the different perspectives of “finished” we can ensure that valuable change sticks, is maintainable and works better for everyone. Surely that’s something to strive for?


What are your views? Please add a comment below, and let’s keep the conversation flowing!

If you’ve enjoyed this article don’t forget to subscribe.


About the author:

Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.

To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com

Blackmetric: Logo. Word "Blackmetric" with a ruler beneath it

© Blackmetric Business Solutions, published exclusively on www.adrianreed.co.uk. May not be republished on any other site without permission.

1 thought on “Defining “Finished”: Don’t Leave Trash In The Forecourt”

  1. Adrian, on one hand, the perfectionist in men says that the definition of “finished” should be part of the goals of the project. For example, if the goal of the project is to decrease the cost of processing an insurance claim by 15%, then the definition of finished includes not only the new software, but also the training, the measuring of the increased efficiency, new procedure instructions, and so on.

    On the other hand, the anarchist in me says that “finished enough” is all we need. That by defining “finished” up front, we risk over-specifying and causing unnecessary work to be done.

    The rationalist in me says that everybody has to be made aware of the full extent of what has to be done if the project is to be considered successful.

    Have I finished this comment? Probably not.

    —- James

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.