Artificial Deadline

An artificial deadline is one imposed by management (either by fiat with no other justification, or in response to strictly internal concerns) rather than one based on customer expectations or legal requirements, or a deadline negotiated fairly between the stakeholders and the team.

An artificial deadline does not materially affect the end product.

A non-artificial deadline: The customer wants the product by July 31st.
An artificial deadline: I need to answer this phone call by the end of the day.

Note that practically any artificial deadline can be justified. The point is its importance relative to other deadlines.

Contrast with RealDeadlines.

Examples include:

Requirements to finish a product by a certain time on the fiscal calendar. In many cases, this is done either to support the revenue targets/promises of a business unit, and/or to fulfill a requirement in the business unit director's PerformancePlan?. The director might be in trouble with his/er boss if the goal isn't met. The design team might legitimately say ThatsNotMyProblem, but when negotiating with your boss it is often the case that his/er problems become your problems, by definition.
Deadlines imposed to spur productivity, by prodding/forcing developers to put in extra overtime.
A negotiated deadline that slips for reasons beyond the team's control, but which management then insists still be met (saying ThatsNotMyProblem - when the boss says it, s/he often means it) can become an ArtificialDeadline.

Sometimes ProjectManagers create ArtificialDeadlines just to put more pressure on the programmer so they get more work out of them, often even without telling them that the deadline is artificial. This strikes me as an AntiPattern. For one thing, it's unethical not to tell the programmer the (whole) truth, and the ProjectManager will lose a lot of credibility when the programmer, after spending an all-nighter to finish the thing that "has to be finished by the end of the month", finds out that wasn't really necessary at all. Second, it often doesn't even work, because PeopleDontThinkFasterUnderPressure. -- FalkBruegmann

There's also a tendency to create artificial haste when people pick a date for THING to be done. Now, I'm not saying this is bad - sometimes there are reasons. We booked the TV advert slots then, we need to have this in the shops for Christmas, we have a tie in with BLAH which launches then. Often, though, someone picked the date. Ohhh.. this looks like about 3 months' work. Hey we could have it done by next July/February/whenever.

There then begins what was called the FuzzyFrontEnd? by SteveMcConnell. Meetings need meetings to plan them and then more meetings to spread their results. Projects are proposed, formal proposals drafted, reviewed, redrafted, approved for submission, submitted, approved, funded... and suddenly a developer has 3 days to do all the work in before that "deadline".

I'm currently looking at a project which has no real urgency need. But somehow tasks are getting assigned to anyone free (regardless of prior exposure to the code involved) with 36-hour turnrounds requested... How did we get here? Because someone picked a date out of the air...

-- KatieLucas

"A non-artificial deadline: The customer wants the product by July 31st."

Note that this actually could be an artificial deadline. If you can talk to the customer and get the deadline moved, then it is artificial. If you can't talk to the customer, or if the customer won't move the deadline, then it is a real deadline.

A situation such as "I promised the customer the product would be ready by July 31st, so they've scheduled a demo." is a way of converting an artificial deadline into a real deadline. Conversion of artificial deadlines into real deadlines is a mark of poor management.

Deadlines tend to be as fixed (real) as they have dependent "PromiseDominoes?" in their chain.

Said another way, if nothing will tip over as a consequence of moving a deadline, the deadline is to that degree plastic. It may even be arbitrary. When moving a deadline starts knocking things over (I have employees that go into training in June and the customers have been promised a working casino by August and the shareholders have been promised profits by November, so slipping the "deliver working prototype by June 1" deadline actually means something).

Occasionally, we get arbitrary deadlines that nonetheless have real corporate consequences. Smith tells New Jersey regulator, Jones, that we will have GadgetFoo? working by December for installation in their jurisdiction by next summer. Jones prepares to have verification procedures scheduled for January based on this. Our credibility as a company is now hanging on delivering GadgetFoo? to New Jersey regulatory guys by late December. If we blow this, Jones will tell his staff that our submissions can "bloody well wait" and to process submissions from our competitors first.

In this case, there are no customers waiting, but later, when there are customers waiting, and the regulatory domino experiences "capricious latency" we will get flak from the customers, even though we, arguably, are not at fault.

The fact that, internally, there are plenty of arbitrary deadlines whose only purpose is performance report inflation, doesn't help, as this creates a ProjectManagerThatCriedWolf? condition.

Without knowing what's in the promise chain, it can be tough to know the difference.

-- GarryHamilton

ArtificialDeadlines only bother you if you have a sense of responsibility to begin with. C.f. PeopleWhoIgnoreDeadlines. -- DavidFlater

What is the implication of the term "Artificial Deadline"?

There seems to be an implication that anything beyond a hard and fast customer deadline is artificial and of no value. What about intermediate milestones, ranging from those on a wall size GANTT chart to XP or Scrum development cycles. I have a discomfort with the disappear for 6 months and meet (or not meet) the RealDeadline approach.

-- WayneMack

CategoryAntiPattern