Part 2 : Tasks Management; Who does What to What Level, by When?

In the previous post I listed 27 activities other than "Task Management" or getting the work done. It's a long list, but the length of the list shouldn't be confused with the time needed to be dedicated to them. To be clear, completing tasks will take up 90% of a team member's time. Tasks are the majority of work on a project. Completing tasks is essential to completing projects.

Luckily all Task Management can be broken down into a simple formula: “Who does what to what level and by when”. The “who” must be specific. It’s not enough to have a task to be done by “Resource 1” or “Team Member”. Tasks also require a scheduled completion date. This “when” is important so that the person(s) doing the task know when it is needed to be completed for the success of the project. The “does what” and “what level” must be defined not only so that the correct product is created, but also that the solution is not over engineered and time and money wasted on unnecessary “Gold Plating” of the product.


Who...

Clarity on who is doing a task is important. Each task needs to be assigned to an individual person. This can become complicated when multiple subcontractors are involved, but individual assignment needs to be done for two reasons. Firstly people need to know what work they are expected to do now and in the future. People can’t be expected to manage their workloads without this. Secondly individuals vary widely in their abilities and if the estimates are based on another individual’s ability then the schedule is wrong and deadlines improbable. For example; some computer programmers are up to 20 times [2] more effective than others. This variance of abilities differs between industries, but will always exist. Due to this variance in abilities and the simple fact that people need to know what is expected of them, clarity on which individual person is doing what task is important.


…does What to What Level...

The output of a task or the “does what” and “to what level” defines the deliverable for a task. It’s important that the output is created, and it is equally important that the deliverable is reported once completed. Unfortunately for the team member, the best person to initially report on the completion and the quality of a deliverable is the team member(s) undertaking the task. The level of reporting differs between projects, but regardless of the industry or methodology; tasks are not completed until the output is measured and reported.

The reporting of a task complete is important for monitoring of the project and the effect the completion will have on dependent tasks and the rest of the project. No project tasks are as simple as flicking a switch “on” or “off”, so the measuring of the task output is important to ensure that the task really was complete. This may be as easy as “1024 rows uploaded to the database” or the original level of quality may specified “30m³ concrete tested and approved by on-site inspector”. The quality of the output needs to be specified and then managed by the team member.

In addition to the completion reporting, team members will often have to report progress on tasks as they are undertaken. This differs widely with PMs and the type of project. Progress indicators all have their problems, however they are just indicators to gauge the likely hood of completion and judge impact of the task on the rest of the project.

Project team members are on the project to create deliverables. It’s also their responsibility to make sure the deliverables are at the required quality level and that the deliverable and quality is reported once complete. The team member responsibility for “…does what to what level…” is just shorthand for “a task is only complete when it’s completed to the correct quality, measured and reported.”


…by When.

Scheduling has turned into a profession. There are certified estimators, and on large projects there are people whose sole task is to maintain schedules. Over the last two decades, some of the grunt work has disappeared with software like Primavera and MS Project. Even though the planning work has reduced, the “by when” of the task management formula is still just as important for individual team members.

The deliverables of a project are typically broken down into work packages and tasks. The tasks typically should be 4 hours to 5 days long. Any shorter and they generally should be grouped into another task, any longer and they pose a risk to the project. “Calling a courier” isn’t a good task, but “verify and deliver contracts to vendor” is. “Create new maintenance planning system” isn’t a good task, however “investigate requirements for equipment register component of maintenance planning system” is. Task that are too short introduce too much overhead, and frankly team members are involved for their expertise and should not need to report every switch pulled. Equally, it becomes difficult to judge the “doneness” of long tasks. Long tasks often remain at “90% complete” for 90% of the time and as such they pose a threat to their overall project. As a project team member, expect to be working to a list of tasks that have due dates 4 hours to 5 days from their start dates.

In addition to each project being devolved into many tasks, each task often interrelate; if task B depends on task A, then the delivery date of task A will certainly effect task B, and probably C, D, E and F. If Task A is late, then it is likely that Task F will be late and the project as whole late. To be more specific, the “by when” of all project tasks are important. In fact the due dates of early tasks are often more important as they indicate how well the rest of the project will perform and whether the project receives continued funding. Knowing when a task is due and delivering on time is a critical responsibility of a team member.


Task Management

Managing projects by “who does what at what level and by when” is a little surprising to some. Devolving your work life to Resources, Tasks, Due Dates and Results can appear a little cold. However it does simplify things, instead of spending hours in meetings “discussing issues” you’ll be walking away early with an action list with just 4 columns; Who, What, What Level, By When.


Completing tasks is essential to completing projects. However making sure the tasks are the right tasks, and are completed correctly is why Risk Management and Good Governance are so essential on projects. I'll cover this in the coming third part of this series.




References
[2] Peopleware 3rd Ed, Page ?,Tom DeMarco