Who’s deadline is it anyway?
I’ve been rather tardy of late with blog posts; too much else is going on, not least the writing a book Agile Experience Design with Lindsay Ratcliffe to be published in November. Lindsay writes a great article for our publisher on how the design process is no longer fit for purpose, being stuck in the old advertising/ print world with outdated concepts that are irrelevant for the digital world. Not least is the concept of the deadline, working towards this mythical date for the final reveal.
I’ve recently seen several projects where deadlines have caused all sorts of issues. Here’s a theme. The business owner picks a date in the future for the new product to be launched with great fanfare. An agency are engaged by the business to develop the creative concepts. This creative stuff has to happen offsite, and certainly nowhere near IT (who are seen as party-poopers, unable to be visionary, rather doomsayers with their constraints). Aligning the creative and IT is a challenge, but there’s a deadline for the agency to deliver the creative and this fit’s into the IT plan. What happens next is that the creative slips. The concepts are not quite right; the business asks for them to refined. Their deadline passes. IT raises it as a risk on the plan, but the delivery date for launch remains fixed. Finally the creative is complete and signed off by the business who are delighted by the innovative concepts. IT aren’t. They got an unrealistic product vision to be delivered in an unrealistic timeframe with no control over the launch date that has been announced to the market. As the date approaches and difficult conversations are had, who gets the blame? Not the creative team who produced the hoped-for award winning design. They are long gone. It is IT who get the blame, once again failing to deliver on time or on budget.
None of this would happen if designers and developers collaborated. If ownership of both the process and the product was shared. How can we facilitate that sharing? That’s coming in the book. That I ought to get back to writing. To meet the deadline.
This reflects my experience exactly. Although as the owner of a software development business it can be even worse. Recently we were engaged as external contractors to build a website/system and the creative team were from another external company. Of course the creative team slipped, changed their minds, failed to supply digital assets…… And we still had to meet the deadline, many 70hr weeks ensued.
I was at a dinner recently sat next to a senior IBM-er. We talked about Accenture and IBM war stories… He spoke of a time when he was working on a big job alongside Accenture.
Accenture people “When will the architecture design be complete?”
IBM people “When we know that it is right.”
Accenture people “But what is the deadline? This is critical path.”
IBM people “It will be done when we know that it will meet the needs of the client.”
Accenture “Can we just put in the end of the month?”
… etc
It is incredibly hard to play off the right balance between deadlines and work products reaching the right level of completeness.
I think the scary thing is that once a deadline is set on paper, it becomes incredibly difficult to change it if unforeseen challenges arise in the development of the solution.