subject: Hidden Reasons Why Things Don't Get Done [print this page] People are reluctant to report a lack of progress on a task even when they don't have everything needed to do it. The fear is that the truth about why they didn't get it done will not be acceptable. I know when team members that are late on tasks start avoiding me that this is probably their fear. Most of the time the problem that they are having with getting it done is common and correctable once it is identified. These are still hidden, so it may take somecoaxing to identify them.
Here is a list of the most common hidden reasons why tasks do not get done and what to do about them:
Work is not welldefined- The resource is confused by the task description but does not want to look stupid. This could be cause by any of the following: The task needs to be decomposed further and the resource assigned to the original task will only be doing part of it.
The task is assigned to the wrong resource.
Requirements for a deliverable need more elaboration.
The task may not need to be done at all. It is not applicable.
Don't know how to do it This is often the case in IT where the technology changes quickly. I am not talking about incompetence here. One cannot get a person with 3 years experience with a tool that only came out last month. A resource does not want to look stupid, but they may be the best person available. Training or allowing time for the learning curve is the way this is often resolved. Assigning the task to someone else is another alternative
Don't have everything needed There is a previously unidentified dependency on something else. This could be another task, a tool, equipment, or specifications. Sometimes resources just need help identifying what they need. Simply asking them what they need and then providing it usually resolves this.
Higher priority work- When resources are shared they are reluctant to tell you that some other project, customer, or work effort was more important than yours. That may be the case however. It is important not to take it personally and escalate within the organization if needed. If the organization deems the other work more important, then you adjust the schedule accordingly. If not, then the resource gets corrected about today's priorities.
More complex than expected- This often happens in projects. The resource did not realize the complexity until they started doing the work. There were constraints that they did not realize existed. Resources may be embarrassed to admit this because it makes them look like they don't know what they are doing. Getting a new estimate and revising the plan is the usual remedy.
More volume than expected- The work is well understood, but the volume of things to be worked on is much greater than expected. This is so common it even happened toBob the Builder.:) This could be a case of scope creep (see below) or just underestimating.
Scope creep- A stakeholder asks the resource to do more than planned or the resource gold-plates their work. Quality standards will help with the latter and encouraging honest and open communication will prevent the former.
Technical issues- This is very common in IT projects because the technology being used is often not very mature. Tracking these in an issues log until they are resolved is the technique used on most projects. Publishing this issues log lets the team and all the stakeholders know what is being done about the problem. This is not usually hidden if the team knows there is a process for dealing with it.
Being able to identify these help you deal with them in your current projects and being able to discuss them openly with your team helps them find ways to prevent them in the future.
