Regards, Shim.

Cheers,
MAP

Cheers, Shim.

You’re right – we all wander around definition of doneness. The problem which hardly seems solvable for me now is a general definition which would suit (at least) most of projects.

I was a part of a number of projects which Chaos Report would qualify as challenged but for a team and (most importantly) for a client they were successes. However most of them had ‘done’ definition attached, which was specifications. The problem was there wasn’t enough work put in creating good specs, so the definition was half-assed.

And then I’ve seen it a number of times that definition of doneness is changing over time. Apollo 13 had some mission to accomplish but no one remember what was it. It has changed to “save people’s lives” after the accident.

But then again there are projects, like New Wembley, which fulfill planned goal – building huge stadium in this example – but can’t be unequivocally assessed. I guess for the client it was a success. After all contract was constructed in a way they paid what they expected to pay and they got what they expected to get. On the other hand I don’t believe the main contractor consider it as a success, considering huge loss on the project and lawsuits which followed it.

To summarize: I don’t think we’re going to find criteria which would be widely accepted by the community. There would always be some doubts and comments.

While I agree in general terms with your comment I wonder how many organizations you ACTUALLY know that would be happy to commit themselves to a clear definition, such the ones your propose. My experience is that software development in commercial organizations lacks that level of articulation, the result of which is that projects can be declared as a success or failure based on the whim of this executive or another. After all, what is the Chaos report if not a collection of subjective views by certain stakeholders, based on their own interpretation and subjective experience?

Glen Alleman is a harsh critique of IT Software Development projects, and as sad as it is, he is 100% correct. My experience demonstrates that projects run in that domain lack that level of robustness that allows the articulation of what success ought to look like, with all the ranges and variances that define its acceptable boundaries. And until such time that this is universally accepted we will have to discuss the merits of such reports as the Chaos reports and others like it.

Cheers, Shim.

I suspect we agree on the concept (i.e. that it is necessary to have clear criteria defining the range of success failure). Where we seem to differ is on whether or not it is ok to take any criteria (for instance the one employed by the Standish Group) and use those criteria for the purpose of credible analysis. And I’m happy to leave this point unresolved given that I simply can’t accept a definition that uses %100 as success and anything less as ‘not’ success.

In most projects (at least the ones I’ve been ‘lucky’ enough to get involved with) there is lack of clear articulation of what ‘success’ looks like (what Glen might call ‘done’) and a lack of boundaries, ranges, or thresholds for that ‘done’. From my experience, organizations, IT departments and business stakeholders do not want to engage in a serious discussion regarding what success ought to look like as a) it is time consuming and requires some mental thinking; and b) it provides an easy way out to apportion blame should things go belly up.

So until such time that I (and I suspect you and others) are able to add that level of clarity and accountability, we will be at the mercy of surveys based on executives’ subjective appreciation of reality, and the picture of that subjective reality (as we all damn know) is far from being pretty.

Cheers, Shim