Random Acts of IT Project Management

Project Management for Information Technology

When Am I Done?

Posted by iammarchhare on 12 May 2009

The question of “done” comes up quite often.  Ask a developer when the coding for the module is done:

PM: Is the module done?

Developer: Yes.  I finished it yesterday.

PM: Good!  So, it works with the user interface that Jo is working on.

Developer: Well, I don’t know.

PM: So, I thought you were done.

Developer: Well, I coded it.

PM: Did you test it?

Developer: No, but it’s otherwise done.

PM: Well, how do you know it’s done if you haven’t tested it?

You laugh.  Unfortunately, entire projects can be like this as well.

Sponsor: Is the project done?

PM: Yes, it is in testing now?

Sponsor: Well, if the customer isn’t using it yet, how can it be done?

PM: Well, the important parts are done.

Sponsor: But, how do you know it will pass testing?

These scenarios depict the problem of “done”.  Done should be done, and the measurements need to be clear and defined.  “Done” is not some vague feeling.

This doesn’t mean WBS tasks should be a micromanaged checklist of activities to check off.  Each task should be a work package that is identified with inputs and outputs.  Each task should be no less than 1 day in duration, and typical work packages are under 80 hours in duration.  Of course, the larger the project, the larger the work packages may need to be.  It requires a balance between a WBS where tasks can be adequately tracked and having so many tasks that people don’t know which they are really working on.

However, there needs to be a definition of when the task is done.  Scope needs to be clear throughout the project.  Perhaps, a generalization of when a software module is complete:

  1. The test cases are clearly written out according to the functional and technical requirements, along with responses for invalid input and approved by the testing engineer.
  2. The code is written and compiles without error (don’t assume).
  3. The module has been tested and passes its test cases, including those for invalid input.
  4. The module has undergone peer software review and all high priority recommendations have been implemented.

Note the inputs and outputs in each of these.  This is vital.  Notice that each has a qualifier: approval, no compile errors, passes test cases, implementation of peer recommendations.  Safety gates keep low-level scope creep to a minimum.

Setting up and communicating rules for “done” will reduce confusion later and stop additional ridiculous “tasks” (really activities) on a WBS.  Team members should be encouraged to provide any additional rules that may be specific to the project or the environment they are working in.

Note that if, using these guidelines, developers are still hesitant in giving estimates for completion of work packages (tasks in WBS), then identify if the requirements and approach are clear or if there is something missing.

Using work packages allows developers to get the job done without micromanaging them.  Give them a target, and have them aim for it, rather than telling them how to do their jobs.

Setting up and communicating appropriate rules for “done” with a project will similarly reduce nasty surprises at the end of the phase/iteration/project.

Advertisements

Sorry, the comment form is closed at this time.

 
%d bloggers like this: