The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Project Manager Role

What do you think of the idea of having a "goal" date for technical people and a "Comitt" date for business people?

In general, I think it's a real good idea - Coders tend to forget details of the project plan, so Work Breakdown Structures need a "buffer".  But on some level is also feels a bit manipulative.

"Critical Chain" by Goldratt has some real good details on this.


Your thoughts?
Matt H. Send private email
Monday, October 11, 2004
 
 
Matt,

I don't really understand the distinction.

Could you give an example?
Ged Byrne Send private email
Monday, October 11, 2004
 
 
Ged:

  Your developers make the plan and promise to have the thing done by 1 July.

  You go to the business and promise 1 August.


  Then, in every developer meeting, you manage to the "strech" or "goal" date.

  It sound nifty, but I would guess that eventually the developers would think they could "slack and still be okay, because our deadlines aren't real anyway."

  I'm struggling with this.  I certainly don't want to hand comitt dates to the business that I am uncertain of, and the history of software projects says we are going to forget something, the customer is going to change his mind, a killer bug is going to show up the day before go-live, etc, etc, etc ...
Matt H. Send private email
Monday, October 11, 2004
 
 
Interesting idea, but isn't there an implicit agreement between the devlopers and the business that the deadlines will slip, especially as they add features, and the first release will be buggy as hell and the second release will contain both new features and bug fixes?

I.e. Doesn't everyone know the process as-is is fucked, and the product of a disfunctional relationship, so everyone accepts that and acts accordingly?

Anyone who manages to pull off the date expected is considered a miracle worker. Also, won't either side get wind of what the other side is being told?

And what happens on the first launch date? The programmers will be expecting business feedback, especially if they did a good job.

Just playing devil's advocate/thinking out loud here.
www.MarkTAW.com Send private email
Monday, October 11, 2004
 
 
If you keep your commit date secret from your developers then the next time round they're going to ignore pretty much any solidity in any milestone you set.

If you set the commit date with the full cognizance (and agreement) with the development team then you have a far better chance of making it.

Depending on the management, I'd be just as open with the business case.  People on the whole are not idiots, the more information they have the better they can make decisions.
Simon Lucy Send private email
Monday, October 11, 2004
 
 
I think having two dates - one for the developers and one for the business - that imply the same thing will blow up. At best, when the two groups figure out that you've been talking about different dates, they won't trust you any more.

What are you tring to achieve with the two dates?
Kate Send private email
Monday, October 11, 2004
 
 
Keeping two dates:

The problem is that you need a 'commit' date up-the-line to management.  You also need a 'work-to' date down-the-line to the developers. 

There's LOTS of uncertainty in both dates, to begin with.  As work is accomplished (and the design evolves, heaven help us) the commit date should move only occasionally.  The work-to date can move lots, until it impinges on the 'commit' date.

The goal is to keep the developer's motivated and working, and to defuse the 'work expands to fill the time allowed' syndrome.  Another goal is to maintain some 'slack' time (which upper management does not seem to understand, BTW) which you can use to extend tasks that take longer than originally planned.

Ideally, some tasks will take less time than planned, which can add to the 'slack' time available, and others will take longer than planned, which take away from the slack time left.  Again Ideally, everything averages out in the end.

In practice, everything seems to take longer than originally planned, and then the goal is to manage requests for additional time.

Either way, you don't want to be moving your delivery date every week with upper management.  You want to re-negotiate your delivery date on a quarterly basis or so (assuming a 1 year project).  You also don't want upper management taking your slack time away, as they may assume you don't need it, and it will allow them to REPORT an earlier completion date than is realistic.

Thus the need for at least two dates.  Now, some developers need to be given a tighter date than is realistic, to motivate them to produce.  Not the most mature developers, of course, but some do.
AllanL5
Monday, October 11, 2004
 
 
IMO it's a good idea to have the gap between date_1 and date_2. The point is if it's going to be a secret to development team, of it is not.

May be better not, but anyway, the feeling has to be that date_1 is really the final one, it's a serious date. Everybody must 'forget' about the date_2. Only the manager have date_2 in mind.


The time gap can be good for:

· If things go fine: taking care of (light) bugs, polishing small UI/doc things, giving free time to developers who took extra-time

· If things go average: taking care of bugs, finishing some feature

· If things go awfully: extended time for pain!
Ross Sampere Send private email
Monday, October 11, 2004
 
 
It sounds like a gimmick that won't solve the real problem.
NetFreak Send private email
Monday, October 11, 2004
 
 
I manage with these two dates. BUT the difference is accounted by slack time. So we target the first date, and use the duration a slack for emergencies that come up. Everyone knows about both dates. For teh developers the first one is the *real* target.

Note, to make this effective you need to make sure you do not pad slack into individual elements/tasks.

 ~ ~ Dave

Monday, October 11, 2004
 
 
Having managed myself this way, it can be very motivating to try to keep the 'slack' time intact.  When 'slack' time starts decreasing, I immediately notice.  When I complete something early, and thereby add to the 'slack' time available, I find that very motivating.
AllanL5
Monday, October 11, 2004
 
 
Yeah, thinking this through a bit, and reading through the posts here, the best thing would seem to be to keep a date with the programmers internally that's earlier than the business date. The business may or may not know about this internal date.

Of course, we all know that there's never enough time to do everything, so if the business' date is already unreasonable, then your date is even more unreasonable, and *you're* the tyrant, not the business.

Your job is to insulate the developers from the business, and not necessarily the other way around. Okay, yes you insulate the business from the programmers too, but don't tell your programmers that.
www.MarkTAW.com Send private email
Monday, October 11, 2004
 
 
I've seen it done both ways. Both work, but I'd be honest with everyone about what the dates represent.

Development should have a delivery date; if it's missed, find out why (bad estimate? scope creep? under-resourced?).

I like to have at least a few week's of slack between the internal delivery date and the external general availability, but make sure that the staff knows missing the delivery date is a problem.

Also, if you refer to the development staff as "coders" you're either 1) insulting them, or 2) hiring the wrong people to do the job. There's a whole lot more to developing software than just coding, and the tone of your post hints that you don't understand it at all.
Tom H
Monday, October 11, 2004
 
 
"Yes, software developers are more than "just" coders.  They design a complete solution, not "just" writing software to spec."

IE, I agree with everything Eric Sink has written on the subject. :-)
Matt H. Send private email
Monday, October 11, 2004
 
 
"Tom, you crack me up"

If coder was insulting, this could also be taken as insulting.  I'm sorry - it really wasn't meant that way ...

I _Have_ come off insulting before and not ment it and gotten in trouble.  Sorry ...
Matt H. Send private email
Monday, October 11, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz