We got a new project manager once.  Within days he was printing a
Microsoft Project schedule on the big HP color inkjet plotter,
the one with a four-foot
wide roll of paper in it.  It took two people to spread it out and
hold it in front of one of the windows with the outside light shining
through it. They looked like doctors pondering an X-Ray of a patient
with a troubling disease.

Soon we had our first project status meeting with the new manager.
For each of the hundreds of items on the schedule, he asked for
status. Finally, it came around to me.

pm: "Wayne, item 57."

me: "Done"

pm: "When did you finish it?"

me: "I don't know, two, maybe three weeks ago."

pm: "You don't know?"

me: "It was a lot of code ago.  It was probably done about two weeks
ago"
pm: "Ok, we'll say two weeks." (makes a note on his printout of the
schedule).  "How long did it take you?"

me: "A few hours every few days over the course of a month.  It
wasn't contiguous time."

pm: "How long would you say?"

me: "I really couldn't say.  We jump around a lot when developing."

pm: "You don't know?"

me: "I could make up a number.  Do you want made-up numbers?"

pm: (Visibly irate) "No!  We need real numbers, not made-up
numbers."

me: "Ok..."

pm: "I just need a number."

Finally I understood.  ''I just need a number.''  Now I knew what
game we were playing.  I felt embarrassed that it took
me this long to figure it out.

me: "Ah, ah, ok.  3 days."

pm: "3 days?"

me: "Sure.  3 days."

pm: Makes a note on his schedule, looking relieved.  "Great.  Ok,
item 58, when was that done?"

me: "Let's say, December 17th, 2.5 days.

pm: "Great.  Item 59?"

me: "How about January 15th, 4.75 days?"

pm: "Thank you."

This is called DeathByScheduling, one of the ManagementAntiPatterns.

  --WayneConrad

-----
Once you've succumbed to playing this game by making up "real" numbers
to satisfy the the holy Pert chart,
you're well along the slippery slope toward the WestmorelandEffect.

-----

I find it bizarre that people still think that complex problems can be solved in linear contiguous time. Like you can block out precisely how long to work on this problem and that problem. This is similar to when managers NegotiateEstimates by ''allocating'' two weeks to work on something that would normally take three weeks. So, it will only have two thirds the quality. I guess this is all a throw back from assembly line days when work was pretty much linearly contiguous.

Another fun one is filling out time sheets to the tenth of an hour. Since this usually accompanies policies that require employees account for every minute on the job, the time sheets end up with slots entitled, "Filling out time sheet." I think that's a pretty good indication of massive failure.

I find it hard to write time sheets because I might spend an hour during the day working on two problems simultaneously. Do I mark that hour down twice--which is important if each problem belongs to separately time budgeted projects--or once because I'm being paid by the hour? I can't honestly even just give half an hour to both because usually I switch between tasks during compiles or long test cases; if I was only doing one of the two tasks, I would just be sitting there idle anyway.

In the end, I think this all boils down to DeathByMetrics. Staying fluid and using your head is the best way to navigate any situation, but that's too tough or scary for a lot of people. -- SunirShah

----

Of course it was absurd of your manager to ask what happened, since you didn't know. What if we break down complex problems into small tasks, and we work on only one at a time? Might we then actually know what we're doing?  Not that I'm heavy into MicrosoftProject, but I ''have'' seen lots of developers learn how to break complex stories down into predictable tasks. Then we factor out the overhead and measure velocity. How can we put these two notions - DeathByScheduling and IterationPlan - together? --RonJeffries

----

My experience with an MS Project chart printed out in a tiny font on an entire A-sized HP Design''''''Jet:

The chart had horizontal lines one for each sub-module; these collected to form each module.

Each module ended with a vertical line going down to the single project "The UI Frame".

When the time came, we discovered the vertical lines occupied as much time as the horizontal ones: IntegrationHell with that common UI Frame.

--PCP

-----

We've found that these MS Project charts are most useful as props for conversations about how we expect the project to unfold.  As marching orders they always seem to have too much wishful thinking --DaveVanBuren