CXO

Beware of when "completed" activities aren't really completed


One of the primary responsibilities of a project manager is to assign work to team members and then monitor the work to see that it is completed on schedule.

It's important that team members understand the work to be completed, the estimated effort, the estimated cost (if applicable) and the estimated completion date. It's very possible that a team member will not agree with these estimates. And he or she may have a legitimate concern. No one likes to be held accountable for estimates on something in which they didn't have a chance to provide input.

I tried to acknowledge this concern by always giving the team members a chance to validate that the estimates were reasonable. If the team member didn't speak up, I assumed the estimates were valid.

After you assign the work, you need to monitor the work to make sure it's completed within expectations. There may be times when you encounter a situation where the team member says that an activity is complete when in reality it isn't quite done. This can happen for the following reasons:

• The activity should have been completed and the team member believes he needs just a short amount of time to complete it. He might say it's complete and then finish it up quickly, rather than deal with the consequences of the activity being late. This is a problem. The first time it occurs, you may need to provide some coaching. If it happens again, you might need to deal with the situation as the start of a performance problem.

• A deliverable is "completed" in draft form but not finalized and approved. The team member may say the work is complete, but when you check the deliverable you find it's incomplete or needs additional follow-up work. This may be a case of the team member trying to get away with the fact that the deadline date was missed. However, it may also be a legitimate misunderstanding of what it means to be complete. Just as with the prior example, the first time it occurs you may have an opportunity for coaching. If it happens again, it may be the sign of something more serious.

To avoid this problem, make sure that there is an approval process for all major deliverables, and that the workplan leaves time for the approval process and for rework based on feedback. Then there is no question that the deliverable is completed, because it has either been approved or it hasn't. The team member can no longer hide a partially completed deliverable, and there can be no misunderstanding as to whether the deadline date referred to completing the draft or having the deliverable finalized and approved.

34 comments
bright-side99
bright-side99

"you may have an opportunity for coaching", isn't that a tad condescending? In engineering, I believe the project managers are trained as engineers, which is why project management is a respected and needed function. In my experience in IT mostly it's a glorified clerical job. The project managers can't get their head around anything technical, let along providing me with coaching on what's involved with a task or how long it should take me. I think if this dicpline is to provide any value the practicioners need to forget about "coaching" people and learn about technology.

Wayne M.
Wayne M.

The best approach I have found is to steal from agile development practices and to divide work into small increments with defined acceptance criteria. First divide any large tasks into small steps so that you can track them on a simple scale of Not Started, In Progress, and Done. There is no need to have meaningless statements of "87.65% Done". Hint, you probably do not want to track this level of detail on your master schedule. You can role this info up manually to provide a percent complete at the higher level. Second, have an unambiguous definition of "Done". This way everyone understands what needs to be done to complete the task. Work is either Done or Not Done, do not accept any partially done work. You will not be able to check every task, so set up a weekly audit and validate one or two tasks with the team. Hint, it is usually most productive to have the team decide the acceptance criteria. The PM can recommend that the acceptance criteria be made more or less rigorous, but let the team own the definition. Avoid the trap of "90% Done." Define small tasks and use a binary criteria of Done / Not Done. Make sure there is a well defined acceptance criteria to determine if "Done" has been met.

donv
donv

Well sometimes programmers are under pressure to complete a task within tight deadlines which is never good. When when you ask if something is complete, you will always get round-about answers. A good way may be to break down tasks into percentages. So for example one task may be 5%, a larger task is 15% and so on. So if a programmer told you he had 20% complete, then you'd know he was completed the first 2 tasks. At least there's a programmer says he's 100% complete, there's no room to move since 100% is absolute. He can always say he's 98% complete. Any one use this kind of method before.

gdeles
gdeles

Reporting complete is a slippery thing. I recently had a project experince extreme schedule creep and group strife when the PM allowed the "done" metric to requriments to be first draft submittal. He was being nice to the BA and being nice to himself by fudging that the project was on time. Hiding the requiments slippage just showed up as the development ending late because they started late. Of course the development team was put at fault for delaying the project. I fixed this relationship by defining "done" for requirments as in ready for development. Rather than zero time left, because realistically there is always some revision to the document. However the task must end. I also fix this problem by asking how much time is left rather thatn % complete. It is easy to lie to your self and other by being at 90% half the time.

Editor's Picks