Going Dark

“I’m twenty-five percent complete and on schedule,” reported Peter at the end of the first week of his four week task.  A week later, Peter reported “I’m fifty percent complete and on schedule.”  Some foreshadowing was offered in Peter’s report at the end of week three: “seventy-five percent complete, but I have some other things competing for my time next week.  I should be able to catch up, though.”  Then the bomb dropped on Wednesday, just three days later, when Peter finally had to face his deadline.  “It’s going to take me three more weeks to complete this.  I was going to use the API in the new version, but it’s returning the data in the wrong format and the vendor doesn’t have a patch, so I’ll have to rewrite it to use the old API and …”

I believe the phrase “going dark” originated with Jim McCarthy in Dynamics of Software Development (Microsoft Press, 1995).  As a guide for managing programmers, this classic is valuable still.  Rule number 30, Don’t Go Dark (pp 102-106), describes the hazards of failing to get regular, frequent, concrete evidence of a developer’s progress.  In this age of Agile, Scrum, RAD, RUP and other TLA methodologies, we project managers still allow team members to do this to us.  And not just in software development projects or by programmers.

There may be several different reasons to explain why a team member goes dark.  Maybe they don’t understand how to complete the task nearly as much as they thought they did.  Maybe they have 15 other things to do and this isn’t (from their perspective), the most important.  Maybe they don’t find the task as compellingly interesting as something else they can work on.  Maybe it’s a passive-aggressive way to make a point.  Often it is some combination of these – a less experienced team member, slightly over their head and with a seemingly endless list of must-haves from other managers, so they focus on doing what they can do rather than committing the time that’s needed to focus on this task.

It could be just the opposite, a team member who thinks they know how to complete the task and spends endless time searching false leads and dead ends without converging toward the solution.  For whatever reason, it needs to be recognized and addressed.  Fred P. Brooks, Jr., in The Mythical Man-Month (Addison-Wesley, 1975) documented the consequences of even slight slippages.  “How does a project get to be one year late” he asked.  “One day at a time.”

Regardless of why it may happen, appropriate planning and control protect us from these consequences.  A key task should have one owner, be no more than two weeks duration (about 65 effort hours if the owner is dedicated), and have a clearly defined Done state (see my previous entry).  That covers “appropriate planning.”  Appropriate control is to have an early warning system (which I will discuss in a future post) for when a task will be delayed so the delay can be addressed and corrected before it is a project problem.

Have you had a team member “go dark?”