MS Project: Few basis questions on tasks management

Question

1. I have seen different managers entering preferred Duration in days and some in hours. Is there any best practice?

2. I have seen many manager will update "% complete" to update a task progress. Is this perfect way to capture process?

3. Someone told me, If you have a task with more than 40 hours, break it down further into smaller tasks. It may not be possible. Right? Having said that, I have seen tasks in MPP with over 200 hours. Is there any best practice here?

Answer 1

Others have answered Q1 & Q3 well; I'll add only the observation that my girlfriend is working on projects with a 10 year duration; most of my projects are measured in < 2 months. We're going to give different answers to those questions and it is entirely appropriate that we do so. You must consider total project duration and Organizational Process Assets in the answers.

"I have seen many manager will update "% complete" to update a task progress. Is this perfect way to capture process?"

If there were anything that were "perfect" then project managers would be paid minimum wage.

% complete is an opportunity.

• If you define % complete when you define the work package, then you can update the % complete and gain an understanding of progress.

• If you work in one of the areas where % complete is obvious (e.g. "Paint this 10x10 wall), then you're lucky.

I don't work in that kind of area - my projects involve a lot of software integration, which makes it effectively impossible to determine the hours spent or the physical percent complete. Subject Matter Experts spend the majority of their time discussing problems, and there is generally no way to tell when they're done until they're done. I also work primarily in a time & materials contract environment where the cost of labor is not the primary concern.

In this kind of arena, where % complete is effectively impossible to determine, then the key is to define and agree on the definition. I use the work breakdown structure dictionary for this purpose. Every work package should have a definition of % complete.

An example: for many documentation tasks, we have a convention that when you start the task and set up the document, that is 10% done. When you have the first draft ready for coordination that is 30% done. When you submit to the customer for review & edit that is 60% done. When the customer accepts the document it is 100% done.

Another example: For one class of reports, we use 50% to indicate that the report is complete and in peer review, and 90% to indicate that it has been submitted to the customer for review & edit.

A counterexample: When I'm sitting in a meeting and I hear a project specialist say something like, "OK, there has been some progress, so let's just advance this task by 5%...." I get sick to my stomach. At that point I have zero confidence in their schedule, their variance, their earned value management, their risk management, etc. They are managing the project by gut and rumor and concealing it with fancy % values.

Answer 2

1. I know of no best practise in respect of this (doesn't mean it doesn't exist!), but as far as I am concerned I mix and match depending on my needs. If the task is 2 hours long I put in 2h rather than 0.25d. If the task is two days long I put in 2d and not 16h. Use whatever you are comfortable with.

2. This is very common and leads, I believe, to a lack of clarity as it is quite difficult to estimate percentage complete for all but the most trivial of tasks. I always use Work, Work Completed and Work Remaining, reviewing frequently to track progress in a task, and let MS-Project work that out as a percentage. This works better because people seem more able to be able to estimate how many hours work there is left to finish a project, so if that is the question you ask you automatically get a) the derived percentage complete but more importantly b) an instant review of the overall duration of the task, which may have moved from the planned values.

3. MS-Project doesn't care whether your task is 40h long or split into subtasks. It is a matter of personal preference. Sometimes you need to deal with individual subtasks on a granular level, so split it up, and sometimes you only need to work at a macro level, so leave it at 40h. It doesn't automatically somehow become better practise just by splitting the task(s).

Answer 3

1. I don't think there is a definitive answer on whether one should use days or hours. My suggestion is to use whichever makes the most sense to you and the stakeholders to whom you report. The schedule and its performance baseline are tools for you to use to gauge how healthy you are. The methods you use needs to make sense to your mental model so you can answer those questions that will be asked. Personally, I like to keep effort and duration separate so as not to confuse anyone...including me, so I use days for duration and hours for work.
2. I use all three ways of estimating progress and remaining work. Physical %, work %, and % complete for duration. All three answer the question of when you will finish in a different way so all three metrics are strong indicators and can indicate differently. If you depend on only one, then you may over- or under-estimate your finish.
3. Break down your work so you can manage it. This could mean that you would need to break down work to very low levels for some packages while remaining high on others. The question you need to answer is: the level at which I broke this package down can I answer how progress is being made and where my risks are with a decent degree of confidence. And, you have a trade off here: the lower level you break the work down, the higher your costs are in tracking. The higher level you break the work down, the less insight you have on what's going on. I do not follow any type of rule, such as duration no more than x days or work no more than y hours. I break it down until I'm comfortable and have the resources to track it.