Fog Creek Software
Discussion Board




Are deadlines bad for business?

I've just come out of a project status meeting. There is an area I am responsible for that the plan says will be tested and working by next tuesday. To be honest, we only finished writing code and getting it to build last week, and frankly I think the chances of meeting that dealine are slim to none.

The problem was that, despite my continued insistance that I couldn't give any assurance we would finish on time, the project leader was not willing to contemplate the idea of us being late. We talked about changing the way we worked, throwing more resource at the problem, changing the scope of this release, and my over pecimistic tendancies. But never seriously entertainted the idea that we would miss a deadline.

My point it this: I thought the reason for having milestones and project tracking was to enable early diagnosis of problems. Which would, in turn, allow them to be fixed sooner rather then later. Instead, we have a situation where the plan simply cannot move. The scope, the quality of the software, or the number of people crowded round the same monitor trying to fix the same bug might change, but the relase date doesn't. In the end, I think we're going to spend more money, have a poorer system and not deliver what we said we would, all so that we can pat ourselves on the back for having met a dealine.

Am I right?

Daniel
Tuesday, June 17, 2003

Yes you are.

Send someone an a4 piece of paper detailing what you just wrote, but make sure you spell it out in ££.

It would not hurt to add a couple of links to some 'authoratative' articles (both techies and suits) showing how throwing money at a late project is always a bad idea. Copy it to two or three folk, and you will get your deadline changed.
(Havard Business Review, Business Week, McKinsey Journal etc)

For better effect,  attach a copy of the minutes from the meeting where this dud refused to shift the deadlines.

tapiwa
Tuesday, June 17, 2003

Some days you eat the bear, some days the bear eats you.  It happens.  You assume you know what is most important, maybe so, maybe not.  It may be that if you don't deliver something by "7/1", the project, team members or managers will be the boot. 

Never assume they can't.  I watched a company spend $2.2 million on a project only to cancel it a month before production because they would not spend another dime on a promise.  80 developers and managers were given their two weeks notice in a status meeting. 

A word of advice from a country boy, if you are known as a pessimist, (some call themselves "realists), you are on a short career path.  At first you are listened to, then recognized for being right, then people will start to ask if you are right because you are good, or because you make it come true.  Then they stop asking. 

Offer solutions.  Any idiot can point out a house on fire, what they want are people with a fire hose, or a least someone willing to save the dog.

BigRoy
Tuesday, June 17, 2003

Hear hear BigRoy!

tapiwa
Tuesday, June 17, 2003

When did the plan say that you would start testing?


Tuesday, June 17, 2003

Cheers BigRoy, that sounds like good advice to me.

The plan said development (which includes unit testing) would be done by friday. Then we had just over a week for running some more formal tests. Which, for 4 APIs, is ok.

In the end, we pretented that we met the last dealine, and now everyone is trying to pretend that we will meet the next one.

Daniel
Tuesday, June 17, 2003

"My point it this: I thought the reason for having milestones and project tracking was to enable early diagnosis of problems. Which would, in turn, allow them to be fixed sooner rather then later. Instead, we have a situation where the plan simply cannot move."

My approach to managing is that you have your choice of "deadline" or "features". You can fix one, but not both. The best you can do with a fixed deadline is to constantly prioritize what's most important of the things left to be done. Most people understand and accept this.

The agile management process in XP basically says you should have a shippable product every few weeks (i.e., it's stable and the intended features are working, not necessarily that it's 100% feature complete). It might not be a bad idea to adopt some of its ideas, so that you don't get spanked at the end with integration and QA issues.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, June 17, 2003

Deadlines are good for keeping scope in check. Without a deadline, it's hard to keep a project from spiraling out of control as people try to add new features. With a deadline, you can say "that sounds great, but do you think it makes sense to try and get it done this month?"

I've worked on projects that had no meaningful deadlines and I've worked on projects that had really serious hit-this-or-we're-toast deadlines. The latter are much more stressful, but the best projects I've worked on have all required the team to meet a firm deadline. (A note on cause and effect: usually, they've been good projects because someone was really eager to get the software and we had a strong sense of direction pushing us to finish it. The deadlines themselves would have been hell in the absence of those two factors.) The projects I've worked on without deadlines have generally suffered from a weak sense of direction and nobody really clamoring to use the app when it was done.

Beth Linker
Tuesday, June 17, 2003


Like it or not, getting a product out the door by a certain date is reality. Sometimes, if you get there second you might as well not go at all.

Consider the case of a company that releases "suites" of tools. All the tools have to release at the same time. The deadline is about as fixed as it gets. You cannot be late.

Deadlines aren't bad in and of themselves. They are simply another factor in a project release that has to be managed properly. Some projects have more flexibility when it comes to release time. Others are totally fixed and have to look to other tools such as playing with the project scope.

I'm all for setting deadlines, but a smart developer has contingency plans in place for situations such as this. Does your team have alternate plans in case the wheels fall off the canoe?

I also agree with the comments of others here. You've raised your concerns. Good first step. Now the team needs solutions. Can you provider any? It's never a bad idea to have someone on the team always thinking about the worst case scenario. What if you're right and you do miss this deadline? Perhaps you could come up with that contingency plan?

DingBat
Tuesday, June 17, 2003


Here's a thought:

Maybe your team lead's bonus (or certainly, his raise, and ABSOLUTELY, his belief that his raise) is based on hitting a ship date.

When management (or even coders) have raises/bonuses/promotions based on things like a certain ship date, you get insane behavior as it becomes more and more clear that it ain't gonna happen.

In the worst case, you have people willing to ship a buggy multi-million-dollar product out the door, just so they can get that extra $5,000.

The best managers will admit that the quality is poor and they have to pull it ... and, sadly, this means they are punished for doing right.

JMHO ...

Matt H.
Tuesday, June 17, 2003

"A schedule is like wood blocks. If you have a bunch of wood blocks, and you can't fit them into a box, you have two choices: get a bigger box, or remove some blocks. If you thought you could ship in 6 months, but you have 12 months on the schedule, you are either going to have to delay shipping, or find some features to delete. You just can't shrink the blocks, and if you pretend you can, then you are merely depriving yourself of a useful opportunity to actually see into the future by lying to yourself about what you see there."

From Joel's article

http://www.joelonsoftware.com/articles/fog0000000245.html

UI Designer
Tuesday, June 17, 2003

"In the end, I think we're going to spend more money, have a poorer system and not deliver what we said we would, all so that we can pat ourselves on the back for having met a dealine.

Am I right?"

No, you're wrong. You will MISS your deadline, and you will miss it by more than you would have done if you accepted you were going to miss it and rescheduled. You will ALSO spend more money have a poorer system and not deliver what you said you would.

When in the situation that you won't hit a deadline. Re-schedule, remove some features and figure out a deadline you CAN hit.

Mr Jack
Tuesday, June 17, 2003

That's kind of my point MrJack.

We missed the development time deadline, but nobody admitted it, we just reduced the scope and said that it didn't include unit testing.

Now we're going to miss the next deadline because one way or another we have to do the testing. But seeing as I can't get them to move the deadline and we can't move the scope either, the only other option is to let the quality of the release go down.

Naturally, having project tracking and milestones is a good thing, but given a situation where we're in a tight spot. My argument is: that it would be better to release good code late, than bad code on time.

Daniel
Tuesday, June 17, 2003


Woah now. That's different. To me, dropping unit tests isn't reducing scope, it's abandoning your process.

Sounds like your team is pulling the quality lever, which is something you don't really want to do. I suppose there still could be reasons for this. Can you give us an idea of why this deadline might be so fixed in stone?

DingBat
Tuesday, June 17, 2003

You're right, I shouldn't have described dropping unit tests as a re-scope. Really, it's a case of moving the goal posts. Or changing what the deadline means rather than moving it.

I don't know why there is such a resistance to moving deadlines. It's a very big heavy engineering company and I guess they see an IT project as being just like a building project. Also, the project leader is purely administrative, and has probably been told to deliver on time no matter what.

Daniel
Tuesday, June 17, 2003

There is nothing you can do without support from your management to fix this situation. You will have to do some education. Getting people to read books about things they don't care about may not be so easy, but little effective things such as showing and explaining the scope/time/quality triangle might help your management understand the dynamics involved.

Big B
Tuesday, June 17, 2003

>It's a very big heavy engineering company
>and I guess they see an IT project as
>being just like a building project


You are implying that large building projects are always on time and on budget? :-)

hahahahahha

rolls on floor laughing.

Matt H.
Tuesday, June 17, 2003

Daniel,
Buy a hardcover version of "Mythical Man-Month", read it yourself, lend it to your project mates, probably to the project leader.

Excerpt: "Assigning more resources to a project that is late makes it even more late."

Johnny Bravo
Tuesday, June 17, 2003

Deadlines are about the only thing that actually encourages developers to drive towards the finish line. A crappy service delivered is infinitely better than an undelivered service.

anon
Tuesday, June 17, 2003

Are deadlines bad for business?

Not necessarily, but bad management and bad tech leads are ALWAYS bad for business. ALWAYS.

Here's the problem in a nutshell. Most serious developers will always, invariably take 110% of the time allotted to do a defined task. The usual thing done is to over-engineer a product, to invent features, to obsess over adequate but "not pretty" code.

I think when managements lean hard on developers to make big pushes to get products out the door, that's where the pressure generally comes from. They know that you/I/we will take "forever" if not pushed.
So, the bottom line is that developers usually have absolutely no credibility in many environments for setting schedule expectations, especially at the end. It's always assumes that you're doing too much of the wrong stuff.

I'm not even saying that it's right or fits, just that this is a common practice and a common expectation in most management.

HOWEVER... the corollary to this "development time will expand to fill all available time" principle is the principle that management that has either wasted time or dramatically underscoped the time to take to do something, will invariably blame the developers instead of admitting blame itself.

I've seen leads and managements masturbate themselves for months doing project plans and Visio charts while a group of developers, funded to do the project, were largely idle or half occupied because no leader could bother himself to engage his brain for an early push.

THEN... as the deadline looms in 3, 2, 1 months... and then the weeks and days matter... the leads and managers panic. Oblivious to the fact that they squandered precious time that was freely available before, they now blame bad, low character, worthless software people for being "non responsive" and the like.

Heads may roll, and developers may be fired. Of course, we are the immature juvenile assholes who sandbag and take too long. So we always deserve it.

Right.
(as the other person here says: "you think I'm kidding - I'm not".)

Bored Bystander
Tuesday, June 17, 2003

The mantra that I use for deadlines is "fast, cheap, good, choose two".  In this case, you can have a product on time either by expending more resources (money or time) or quality. 

Given that the deadline is in less than a week, I don't think you can spend enough time or money to avoid sacrifice some amount of quality, so the question is how much software quality are you willing to sacrifice?

Colin Evans
Tuesday, June 17, 2003

>My point it this: I thought the reason for having >milestones and project tracking was to enable early >diagnosis of problems. Which would, in turn, allow them >to be fixed sooner rather then later.

You are right. So why didn't you alert management that the project would be late when you missed your first milestone?  If you had, then perhaps something could have been done.  Now there is not enough time to do
anything.

Essentially, your team has been lying to management about the status of the project and they may very well get upset.  It is quite possible that the deadline could have been changed if the problems were reported a
few months ago but now, why should anyone trust the team?

I had one manager that did not want any bad news on the status reports and he also fudged the milestones. Not surprisingly, the project got in trouble and he was replaced.  No one can fix something unless they
know it is broken.

John McQuilling
Tuesday, June 17, 2003

[The mantra that I use for deadlines is "fast, cheap, good, choose two".  In this case, you can have a product on time either by expending more resources (money or time) or quality.  ]

In fact, in some cases I'd say "choose one". :)

DingBat
Tuesday, June 17, 2003

"We missed the development time deadline, but nobody admitted it." If you don't communicate these things, then nobody's gonna know why the train fell off the tracks, and since it was your responsibility to keep it there, it'll fall on you.

If you have to change the scope or skimp on testing or move the deadline, people need to know that you're doing it, and they need to know why. You don't "own" the project, you're just managing it. The people that own the project are the ones that need to decide how they're gonna handle the situation.

Create a small internal website that has various information about the project, including it's current status. You can use clever progress bars with colors if that helps. Then send regular e-mails communicating the status of the project to all the stakeholders.

Mythical Man Month
Good book, you'll probably find more of your developers have read it than management types. I nearly fell off my seat when my manager used the term "Man Month" in all earnestness.

You can have it feature filled, good, fast, or cheap, pick any 3 (or some variation on that phrase).
This axiom is a good tool because it resonates with a lot of people. They instantly understand that "you can't have it all." Just be careful which items you include... they may just want to throw more warm bodies at it.

You're getting a lot of good advice in this thread. Kudos to the JOS forum community.

www.MarkTAW.com
Tuesday, June 17, 2003

Your big problem is what to do, is isn't it? You already know management's plans are wrong. You want advice on how to educate management as to the need for extensive testing and refinement before release.

Try writing a short report on the topic, referencing McConnell and other good authorities, and then walking in on all senior managers and giving that to them.

Educating intransigent senior management is one aim - notoriously difficult .The second aim is to ensure there is an unambiguous document record of your assessment that premature release will generate customer error reports.

If they don't listen to you, customers will find all sorts of errors and you will be blamed for the poor quality of your work.

.
Tuesday, June 17, 2003

. - but he's already admitted that they didn't communicate earlier that the project was off schedule. That's when they should've.

I also think preaching to upper mgt. and telling them they're going about things all wrong is a sure way find yourself like I am - sitting at home in your underwear applying to jobs while surfing the JOS forum and IMing my friends.

www.MarkTAW.com
Tuesday, June 17, 2003

> Create a small internal website that has various information about the project, including it's current status

If you start doing that now (when missing deadline is imminent) and haven't been communicating properly until now - that would probably end up making you the fall guy.... "he doesn't have time to meet his deadline, but he does have time to make web sites when the deadline is imminent"

Start communicating - yes - but keep it simple and low tech.  Do it better next time - yes.

I think it makes a huge difference as to how far you are about to miss it by.  If you are about to miss it by a country mile, it's a whole lot different that if you are about to miss it by a few days or a week.  If the latter, then you need to find something to cut, some change in the plan, etc

S. Tanna
Tuesday, June 17, 2003

S. - Yeah, that was really an early or mid project thing to do. If there's a week before launch, there's really little to do but get it done as well as you can.

In another thread someone mentioned that CIO bonuses were determined by the number and complexity of the projects that went in to production.

I was going to say that it's better to release crappy code than release an overschedule, over budget, and under featured product, but thought the prevailing wisdom here would shoot me down. More people here being 'enlightened' than the average manager, but the fact is, for your career, being able to put "delivered product on time, on budget, and with all the features" looks a lot nicer than "removed some of the features that had to be removed and delivered the product late."

You should also know that you're (a) not alone, and (b) not in the minority here. A lot of projects are run this way.

www.MarkTAW.com
Tuesday, June 17, 2003

Good Communication, Rescoping, Education.

The thread clearly thinks you should have been doing these things and that one of the results of not having done them will result in a Blamestorming session. Bad boy, Daniel.

Informally document your current problems, what steps you take from now to address them and the results. No more than a page.

Then…..learn from them and don’t repeat them! Take the lessons with you to your next project.

The project status website idea is a good one. Steve McConnell recommends it in his Software project Survival guide. (some of which is available on http://www.construx.com/survivalguide ).

Justin
Thursday, June 19, 2003

*  Recent Topics

*  Fog Creek Home