Shim Marom’s post on (low) value of industry reports launched an interesting discussion in comment section, which I took part in by the way. The point we reached was how we define whether the project is completed or not.
And here we come to the definition of done, term which I learned from Glen Alleman.
On Time, On Budget, On Scope
A definition which you will hear most often is project delivery on time, on budget and on scope. And there comes a problem. If we overrun a budget for ten bucks are we still on budget or not? What about thousand? Or hundred thousand? Depends on project, right? So what about 0,1% budget overrun? 1%? 5%? Where is the border between success and failure?
Note: I haven’t even started with time or scope.
While this definition sounds nice it hardly responds to typical complex project environments.
The Story of Changing Goal
I love the Apollo 13 story. Not only because it is a great story about heroes, but also because it is a great story to learn about project management. If I asked you what was the original goal of Apollo 13 mission probably no one would answer correctly. But well, they definitely hit the space for something more to become a base for a Hollywood movie or to coin one of the famous quotes (one of famous misquotations actually). The thing we remember is that Apollo 13 mission’s goal became saving astronauts’ lives. And we all consider it a huge success.
Were original goals accomplished? No. Probably neither of them. The money was spent however. Probably more than planned because of unexpected problems. But over the course the goal has changed.
Recently I’ve read similar story about Sir Ernest Shackleton’s Antarctic adventure. It is 18-month long story about fighting for people’s lives. And again initial goal, which was crossing Antarctic continent, was rendered invalid just after several days and the main problem became coming back home in one piece. Thanks to his commitment and determination Shackleton was successful in rescuing every single man from his expedition. Considering conditions a stunning success.
Was Shackleton able to pass the Antarctic? No. Failure then?
Maybe You Tell Us About Real Projects…
You may say that those stories aren’t about typical IT projects which we deal with everyday. Yes, these are extreme examples but the same pattern we see very frequently, but in a bit different scale. Hey, that’s what embracing change is all about. We try to adjust the course of our projects to make them better respond to clients’ needs.
After all I don’t believe all projects you took part in were specified perfectly at the beginning and carried through relentlessly to the end according to unchanged plan. My wild guess is only few of you had a chance to work on at least one project which looked a bit like that (and yes, Glen is probably among those few).
Clients often deliver some wishful thinking as requirements, and then vendors go through them only roughly and come up with a generic document which describes fuzzily what should be done. No surprise the real goal appears to be changing over time as everybody realizes all the assumptions and gaps in initial plan.
Definition of Done Is Changing
OK, so goals are changing over time. So is definition of done. We usually do a crappy job defining done. But then we’re even worse in adjusting the definition along the way. We change expected costs and schedule. We change scope. Do we change our definition of done as well?
I mean unconsciously we do, that’s for sure. After all we’re able to follow our gut feeling and tell this project was a success and that was a failure. We know that major schedule slip will be quickly forgotten if delivered software exceeds expectations. We know that being on time on budget and on scope isn’t a reason to boast when the client doesn’t use the system at all for some reasons.
So yes, we should know what done means in each and every project. And no, we won’t have a single, universal definition which we can use against all our ventures. It is a very individual thing.
That’s by the way the reason why the industry reports on state of projects will be criticized over and over again. There just aren’t universal measures which would be widely acclaimed.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
8 comments… add one
When you say “definition of done” you seem to mean definition of success. Assuming that is what you meant, I agree that this may vary according to the organization that you are doing the project for. Knowing when you are done is important to defining that success.
For small businesses cost is usually the most important factor. For corporate america, schedule seems to be the most important. Scope and quality are often sacrificed to meet the other constraints.
Success is a happy customer. Knowing what will make your customer happy is the most important constraint to optimize.
I think Bruce hit the nail on the head. You seem to be talking about the definition of success, more than a definition of done. Is a [software] project ever truly done? I suggest that it isn’t.
In Scrum, Ken Schwaber talks about the Definition of Done as it relates to a product increment. This makes sense given that the scope of a function or feature can be defined explicitly.
However, I don’t think that a definition of done for an entire software project could – or realistically should – ever be established in this era of Agile software development.
Cheers!
Pawel,
One thing I would suggest adding to your definition and that would be setting boundaries around ‘done’ such that it clearly states what variations around the %100 mark will be accepted as success. Stating what ‘done’ looks like and only accepting %100 as being success is wrong, not to mention unlikely ever to be achieved.
Cheers, Shim.
Bruce,
I think definition of done and definition of success are interchangeable to some point. If you completed a project according to some plan but your client hates it are you done? If the client is happy despite the product still has some serious flaws are you done? Didn’t think so.
But of course you’re right with success/doneness criteria. It depends on environment. That’s by the way why I don’t really like on time, on budget, on scope definition even though I tend to use it on occasions.
Alex,
In terms of software development process Scrum keeps the old-school pattern but just apply it in small doses (short iterations). It means we are using definition of done as we were, the only difference is we usually apply it to iteration and not the whole project.
By the way in Scrum and Kanban we also use definition of done against single tasks so we bring it one level deeper.
But then we should never forget definition of done on the high level, even in agile projects. After all we aren’t building software just for the sake of building it. We build software for some client who pays us for that. And they don’t do it for fun – they’re trying to solve some business issue.
So no matter if you acknowledge that or not there is such thing as high-level definition of done in agile projects. You may not be aware of it – so much the worse for you.
Yes, agile does much to make our lives easier even if we don’t have completely clear definition of done. Yes, agile helps us whenever ‘done’ is changing rapidly over time. But no, agile doesn’t render definition of done irrelevant.
Shim,
I believe the margin is added as we accept that done can change. I know a lot of examples of projects where at the end we looked at the thing and we thought “yes, we are done” even though it wasn’t exactly something we would have envisioned at the beginning. I assume you know that feeling well too.
This is by the way how many clients look at their projects. They don’t decide about their satisfaction basing on feature coverage or something equally artificial, but basing on how well the outcome of the project deals with business problem.
And since the definition of what the outcome of the project is will (almost always) change over time we will (almost) never be 100% done with what we expected on the beginning.
On time, on budget, on scope (OTOBOS) normally translates to mean ‘within the set tolerances for time, budget and scope’. So you can be overrun by ten bucks and still be ‘on budget’, if your budget tolerance allows you to go over by a certain amount.
OTOBOS is a good basic measure for success, but that’s how a project manager would define it, not necessarily the customer. The customer is often interested in value. Essentially, if you don’t define success or completion with the customer at the outset of the project, you’ll never know if you have reached it.
Elizabeth,
Yes, exactly. Being OTOBOS is a good measure. And yes, it works more for a project manager than a customer. What more, it is abstract enough hence it’s used to compare different projects. Yet it is artificial. As every universal measure it works only to some point as it doesn’t reflect project’s specifics.
And of course we treat being on target (time/budget/scope) with some tolerance. But then how much tolerance we can allow? 10%? 20%? If so, is 20,01% overrun is still OK or not?
If we go for absolute measures, whatever they might be, we’ll always face the same issues. And if we go with gut feelings, which would often reflect very well success and doneness of the project, you’ll see crowds objecting against any comparison made on such ‘data’.
The point is, and we agree on that, definition of done is specific for each project and should be agreed with the customer. We shouldn’t however expect it would give us some standard data to use in industry research reports.