Rohland de Charmoy

Deadlines – customers love them, developers hate them.

Ok, so that was a slight generalisation, however in my experience customers tend to set fixed deadlines without any significant consultation with their development team. This causes countless issues as expectations are misaligned right from the start. Often in a scoping meeting I hear some variant of the phrase: “We need the project launched by [insert ridiculous date here]“.

Case in point – I had a meeting last week with a prospective new client where we discussed quite an interesting project. When we got down to the specifics, the client specified the deadline for roll-out was early December. Now, given that the project is quite meaty, has no formal specification (no sweat, Agile rocks) and that there would most definitely be a lead time, I knew it would be impossible to get anything decent out by then. So, only one thing to do – attempt to level expectations! In doing so, I could sense the customer’s disappointment fill the room, killing all inspiration and excitement about what we had just discussed. This was followed by the rather predictable question: “So what do you think we can achieve by early December?”.

I hate being in this position. Clearly, I have only had 1 hour to digest information which the client has had months/years to think about (often with critical domain knowledge). How can I possibly give any kind of accurate indication of what can be achieved? Of course, my experience counts for something and I have some kind of feeling about the project, but I know if I attempt to answer the question, we will be treading on dangerous territory. For example, if I vocalised my guesses (guesses, not estimates), I know the client may potentially end up using this as fact and then hold me accountable when two months down the line we don’t have the relevant bits complete. If I don’t candidly discuss my guesses, I end up looking like an inexperienced idiot. Conundrum. My only recourse is to somehow convey to the client, that in the software development paradigm, it is extremely difficult to shoot from the hip in estimating timelines and cost for a software project. At this point, a lot of what is being discussed goes over the clients head (understandably), they don’t understand why it is so difficult for me to give them some kind of indication. Specifically, it perplexes them why I cant estimate ball park figures relating to total project timeline and cost. So, I end up throwing out a few numbers, knowing full well that my guess is subject to the Cone of Uncertainty, something the client may forget about and perhaps blame me for later. Did I mention I hate being in this position?

The point I am trying to make, is that deadlines, much like budgets, always seem to be this fixed line in the sand. Cross it, and face the wrath of the client. Nevermind that the deadline/budget was a guess to begin with and that the client was warned about it. Deadlines and milestones should have the ability to shift as the project progresses. They really should just resemble some date in the future where all parties believe everything should be complete. I understand that business needs to set some boundaries, for example, if a new product is being launched, there are a number of projects (software, marketing etc.) that all need to culminate with a launch date. However, too often everything is left to the last minute and pressure placed on certain parties (us) to deliver. No-one really works well under sustained pressure so the result is always sub-optimal. In the case of the project discussed with the new client, I knew we could develop something by the beginning of December but that it would end up failing in the operational environment as severe short cuts would need to be taken. A premature release to users would ultimately lead to a situation where quick fixes/updates would need to patched onto an already shaky solution as operational issues arise. Suddenly, after a further two to three months, the result of quick fixes and updates to this shaky solution becomes the final solution. Not the most ideal plan.

All in all, I don’t think we can ever get away from deadlines and project constraints, but I do think all parties agreeing to a deadline should view it as a relatively fuzzy date in the future. At the very least, if the date needs to be fixed, consultation with key parties is critical before a deadline is even decided upon. The deadline should be reasonable. It is critical that you not succumb to the pressure of sitting in front of a new customer and force your team into a short sighted decision. It is always best to be candid and constantly remind the customer of the risks involved in planning a software project poorly. Budgets and delivery dates are sensitive topics because they always constrain quality. As a developer, I don’t enjoy delivering solutions to a customer when I know that with a bit more time we could have delivered something spectacular which would ultimately give the overall project a significantly better chance to succeed. We need to educate customers in this regard as many of them have never been responsible for a software project (especially SMEs) and don’t understand that quality is a critical factor in planning a project’s budget and delivery date.

On a lighter note, I’m sure we have all been in a situation similar to the one below. I particularly enjoyed drawing the parallel to the common software development milestone known as the “product shipment date”. Yup, been there.