Anticipations versus Expectations
Posted: April 3, 2012 at 5:46 pm
Today I faced one of those delightful project management dilemmas: the missed deadline. It wasn’t my own (thankfully) so I had the pleasure of dissecting this horrible occurrence with the benefit of hindsight and objectivity.
As I’ve noticed whenever I’m asked to do one of these things (and I’ve swallowed my shame of being the cause of more than a few missed deadlines myself after 10 years in the bespoke financial software industry), the core issue is (mis)communication.
When trawling through the emails, the phone call logs, the GANTT charts, and the recrimination, a missed deadline almost always pivots around expectations (from the recipient of the work which has been ‘deadlined’) and anticipations from the deliverer of the work.
I could get really existential and link this to the receipt (RVP) and delivery (DVP) of stock versus payment, a really mundane and essential part of my work at Global Back Office but I won’t.
The person who provides an estimate of time builds this estimate on their anticipations of the future. This is a confluence of prediction and assumption – considering this, how is it that we ever expect an anticipated deadline to ever be met? Experience teaches us to temper our predictions and ignore our assumptions, and many project management and timing methodologies have been developed to sort of dry out optimism and leave us with tasty biltong of a good estimate. This doesn’t happen ever.
Why? Because no matter how perfect the anticipation, and no matter if what is agreed at the outset to be delivered on the deadline, there is an entirely unencumbered beast related to any deadline: expectations!
The word sends chills down my spine. From dashed expectations comes the social science of ‘managing expectations’, the stock in trade of business analysts, project managers and other serial apologisers for the failure of software engineering. Whether you build from scratch, or implement something pre-existing, no matter what the expectations of the client will quietly and confidently self-inflate until what you thought was little balloon of value to be delivered is suddenly crushed by the weight of unmanaged expectations.
Developers anticipate. Clients expect. These aren’t the same thing. They require constant checking, deflating, adjusting and revision. This requires reconciliation between the two. This requires communication. And thus a career is formed.
It’s horrible because it would be much easier if one was removed from the equation. Clients need to have expectations, but do we need to anticipate when developing software and/or systems? I would say NO! This is the mistake. Once we anticipate we communicate that anticipation – which the client quickly translates into expectations. If we don’t anticipate, but rather reflect expectation then can talk about the same thing with clients.
How can you reflect an expectation? And how can you avoid the natural tendency to anticipate time lines? The Agile/Scrum zealots would suggest the answer is to decompose the problem into bite size chunks: stories. This is a good metaphor generally, however the estimation/complexity grading means that anticipation is embedded by design into Agile methodology.
Consider this: Clients don’t care about Software Development Methodology. How can I say this? They are as disassociated from it as a jewellery wearer is from mining. Ask the next woman you meet at a jewellery store if she prefers open pit mining to shaft mining when it comes to extracting the minerals for the ring and you’d see the face that clients give when asked their preferred methodology. The client WANTS something, they don’t really care HOW that something is delivered. We should all be clear on that, because every day we consume goods and services which we have no interest in knowing the means of manufacture. Software should be no different, but developers, obsessed as they are with the inner workings of systems can’t relate to this blithe disinterest in the detail of method.
So… back to how we can address expectations without actively ‘managing’ them. We can’t. They have to be tracked, recorded, prioritised; as you would at the moment. My take away from my work today has been the right thing to do is eliminate anticipation from your production pipeline (aka developer). Don’t estimate – KNOW!
If the client expects to know when the software is going to be delivered then you need to perform an analysis. The output of the analysis, to meet the expectation, is not an estimate but rather the plan to achieve the outcome, which details exactly what the client can expect at each stage in the process. Timing can be provided as long as the client is informed that it is anticipated, and not an expectation. This needs to be repeatedly communicated to clients. Failure to meet expectations is a problem. Failure to predict the future like a crystal ball in forming anticipated deadlines simply can’t be one.
Filed under: Project Management, Rant by Andrew la Grange
No Comments »
Enjoy the article? Subscribe to the feed!
