How To Use Microsoft Project: Task Type

One of the more confusing aspects of Microsoft Project is Task Type.  Task Type can be set to "Fixed Units", "Fixed Work", or "Fixed Duration" for each task.

How to Set Task Type

You can set task type in a couple ways:

1. If you select a task or tasks and go to task information (under project in the menu or right click and its there as well) you will find task type in the advanced tab.

2. If you go to window and click Split when in the GANTT chart view, you get a Task Form at the bottom where you can set the Task Type.

  If you select all your tasks, you can set the Task Information for every task to the same Task Type – this will lead to less confusion when you are adjusting your plan because all the task types will be consistently set.

Effort Driven

There is also a check box (which is checked by default) that says that tasks are “Effort Driven”.  When this is checked, it is assumed that work stays constant even if you adjust the other two measures.  So for example, if you change a 40 hour task from 1 week duration to 2 weeks duration, project will keep the 40 hours of work but decrease the number of resources required to compensate (only 50% of a resource in this case).

This may not be what you want and I find particularly with using Fixed Duration having this turned off is highly desirable because want to adjust the work, not the units.  For example, what I want is to tell project, “I want to schedule this task with 1 person for 2 weeks” and have it calculate work to be 80 hours.  If I adjust the schedule to be 3 weeks, I want the work to increase by 50%.  Similarly, if I am working in Fixed Duration and I double the resources, I want the duration to stay constant and for the work to double.  This will only happen if “Effort Driven” is turned off. 

How Task Type Works

Any task can be adjusted using three measures: Units, Duration or Work.  Because each measure is dependent on the other, at least one of the other two must be impacted.  By changing the task type, you are telling project which measure you are going to adjust and which measure should be automatically re-calculated.  Below is a chart that shows how Project reacts based on the task type:

 

Field that you change	Field calculated if the task is Fixed Units	Field calculated if the task is Fixed Work	Field calculated if the task is Fixed Duration
Work	Duration is recalculated	Duration is recalculated	Units are recalculated
Duration	Work is recalculated	Units are recalculated	Work is recalculated
Units	Duration is recalculated	Duration is recalculated	Work is recalculated

Basic Tips for Using Task Type Efficiently

Here are some basic tips to using Task Type efficiently and to avoid confusion:

• Pick the task type that makes sense for you and use it consistently.  I tend to think in Duration with Effort Driven turned off first and what I want is to calculate the number of hours (and therefore cost) required to do the work.  Other PMs like thinking in work instead and want to adjust the schedule instead.  Pick an approach before you start and be consistent with it.
• You can switch the task type without impacting your plan.  Therefore, feel free to change the task type for the specific scenarios below.

Scenarios to use Specific Task Types

Fixed Duration

I used Fixed Duration when I have a good understanding of the schedule and the team and I want to calculate cost/effort.  A good example of this is doing a plan for requirements gathering interviews.  I know that I have 2 weeks of interviews, 1 week of documentation and 2 days of client review and I know that I need a Business Analyst and a Technical Architect in each one at 100%.  Fixed Duration works really well because I can adjust the schedule really easily and the work effort is calculated for me.

Another good use for Fixed Duration is % allocations for overhead resources.  Project Managers for example tend to be used on an overhead basis for the duration of the project on a fairly constant basis.  If the project takes longer you will need more project management.  It’s also easier to think of assigning a PM at 30% to a project for the entire duration than to say, “I need 85 hours of project management for this project).  With Fixed Duration, you can simply assign the PM for the entire duration and adjust the % allocation and the work effort is automatically calculated.

Fixed Work 

A good use of Fixed Work is when you want to try and fit a fixed amount of hours into a fixed schedule.  By fixing the work, you can adjust the number of resources you need to impact the duration.  For example, let’s assume you have 1280 hours of work and you want to try and jam that work into a fixed 8 week period.  With Fixed Work turned on, you can set the allocation of resources to 400% in order fit the fixed amount of work into a duration you wish.

Fixed Units

I generally find that using Fixed Units is my least desirable option simply because in most real world scenarios adjusting the number of resources required is the most flexible option.

One scenario where Fixed Units might be appropriate is for department planning.  In a department, the number of fixed units is constant (the number of full time employees) and as a Director you want to know how much work your team can produce.  What tends to happen in these scenarios is the queue of work is constant and the duration flexes – you end up telling the poor person at the end of the priority list that their project won’t get done until next year.

In this case, setting Fixed Units would allow you to lock in the resource pool based on the size of your department and then adjust the work to calculate the resulting schedule.  Based on the schedule, you would then be able to tell your stakeholders how many projects can be done in the coming year.

I hope that provides some guidance on how to use this key function in Microsoft Project – I have found even very senior Project Managers do not fundamentally understand how Duration, Effort and Units work together and how to model them in Microsoft Project.  If you understand the conceptual framework and the rules that Microsoft Project uses, you will find that there are less errors in your plan, less confusion and less tearing your hair out when you find Project adjusts your numbers in ways you didn’t intend.

Project Planning in an Agile Project

Tate Stuntz has an interesting post on his blog arguing that Project Plans are obsolete and hard to maintain when doing Agile projects. In my experience on agile projects, project planning and Gantt chart making definitely has to change, but there are still ways I think you can make MS Project and Gantt charts work for you in an agile context. Here are my recommendations based on my experience:

• Learn to use MS Project efficiently (see my previous post for recommendations). I've seen PM's take 2 weeks to build a project plan - if this is you then trying to work this way in a 2 week iteration cycle means you're not moving fast enough. You have to be at the point where you could re-boot your project plan in a matter of hours so that you can adjust quickly.
• Use MS Project for planning and not for tracking. If you're working with short iteration cycles, you'll see improved tracking by simply management by walking around. In addition, measuring project velocity is more valuable than percentage complete since in an Agile project the finish line is not always defined.
• Use a project plan for iteration planning at a macro-level and not for iteration tracking within an iteration cycle. What I like doing is maintaining a project plan with a simple list of user stories in each 2 week iteration. That allows me to track dependencies between user stories pretty easily. At review time at the end of an iteration, we discuss the next iteration with our stakeholders and reset expectations by re-forecasting the plan (which takes no more than an hour of work). That gives stakeholders a good understanding of what we currently see as in and out of scope and when features may be coming up. This is highly valuable and I find is critical for buy in for stakeholders - if the response from the team is simply, "we can only see to the end of the next iteration cycle" this tends to make business users very nervous.
• If you need pretty Gantt charts, one of my favourite methods is to use Visio - it provides pretty Gantt charts for presentations without the fuss of Project.
• I tend to use the whole team as a big pool for planning iterations. This gets you out of the micro-detail of having to assign one user story to one person, another user story to another person and so on. If I have 4-5 developers on a team, that gives me 70 hours x 4-5 developers for a total iteration budget of 280-350 hours. I can then do a good estimate of each user story that includes planning, development and QA with the team. We simply add up a bunch of these stories into the budget and that becomes the iteration. The way to do this in MS Project is to take your steps and instead of assigning individuals assigned to each task and running them in parallel try simply taking a generic role of "developer" and assigning them at 500% to every task in sequence. You can then tell how much time you're going to spend across the entire team without having to fuss with all the micro-dependencies.
• For preliminary planning, use low-tech Gantt chart tools such as whiteboards, post-it notes, etc. I can create a Gantt chart without MS Project using a white board, some markers and post-it notes. This works great without the overhead of the tooling getting in the way. If you want to preserve it, simply take a digital photo of it and store the picture.

I think if you follow some of these techniques as a Project Manager, you can still sleep at night without feeling completely out of control and yet move faster and leaner. In addition, you can use project planning to help sell the concept of Agile to stakeholders who aren't as comfortable with the XP style of development and give them the comfort of a traditional project plan without locking yourself into the traditional bureaucratic approach to Project Management.

How to Use Microsoft Project Efficiently

I've worked with a lot of project managers who don't really know how to use MS Project efficiently. I was trained well on MS Project because in the consulting business, you have to be able to build million dollar project plans in days for sales pitches. Our PMO figured out a number of ways of using Microsoft Project more efficiently.

Here are my recommendations:

1. Get rid of the GANTT chart by dragging it to the right. Use the extra space for some additional columns.

2. Go to Window and click on Split. This will bring up the Task Form dialogue box at the bottom. You will find that entering data in the task form is much more efficient and visible than any other method.

3. Go to Tools->Options and click on Schedule. Change the Default Task Type to Fixed Duration and click off the box marked "New Tasks are Effort Driven". The reason is that when you're estimating, you'll find in most cases its easier to think in duration and allocating a % of a persons time across that duration than thinking about person hours. For example, instead of thinking of a task taking 25 hours, its easier to think about a task taking 3 days at 100%. Its also easier to think about a task as taking 2 people x 3 days, especially if you're days are 7.5 hours (do you think of a task as taking 50% of a week or 18.75 hours?)

4. Don't put in any absolute dates in your plans. Make all your dates based on dependencies except for the basic project start date.

5. For tasks that you want to go in parallel, use the SS predecessor type to make sure that multiple tasks start at the same time.

6. Go to Format->Text Styles and click on Item to Change. Select Critical Path and change the colour to something obvious (I use BOLD RED). This will help you in making sure that every task has the appropriate predecessor set - if it doesn't, you'll notice that the critical path stops half way through your project plan. It should highlight tasks from the beginning to the very end of your project.

7. Lets assume you have a project plan that is way past your target timeline and you want to now parallel your effort by adding more people. Many project managers will start creating streams of tasks in parallel with complex dependencies. But here is a simpler way if all you want to know is how many people you need to complete the work on time - simply take your tasks, change them to fixed work and increase the percentage to 400%, 500%, etc. until you get your timeline in the ball park. If its 500%, that means you need 5 full time developers to get the work done.

NOTE: the one draw back to this approach is that it doesn't tell you when each task will be done. But in my experience, this is not that useful as development projects tend to have 50 tasks that can largely be done at any time over a longer period and you simply spread the load across a pool of developers until the work is done. If there are specific tasks that are dependent, then set them up as a seperate stream. But if its simply a pool of tasks that need to get done this technique is much faster and simpler to manage.

8. Don't allocate overhead resources to tasks (e.g. your PM, your TA, your QA lead, your stakeholders, etc.) unless you have very specific requirements. In most cases, you can estimate an overhead resource at a % allocation across an entire project phase. For example, I'll allocate a PM at 30% for the duration of the project, a TA for 20%, etc. This again is a bit of a cheat - if you want to plan that a PM is going to be busy at 100% on Wednesday and 20% on Thursday and 40% on Friday, then this technique fails. In my experience, this is not the way overhead resources work and in the end having your project plan reflect this micro-detail is not worth the work to maintain it.

9. Here are a few ways to calculate contingency:

• Click on Insert Column and pick Cost1. Right click on it and select customize field. Then click on Formula and type in Cost*1.10. This will calculate contingency at 10%. If you want 25% contingency then use Cost1*1.25. Make sure that Calculation for Task and Summary Rows has Rollup selected and Sum.
  
  NOTE: There is a bug in Project 2003 where it sometimes does recalculate fields properly. If you notice this, then go to Tools->Options->Calculation and click Calculate Now. This will recalculate the field.
  
  


• Create a task called Contingency and set a price for it. This is good for setting an arbitrary contingency amount.


• Create a task called Contingency and assign a resource called Contingency at sufficient hours to drive up the price. The advantage of this approach over the one above is that it means your total hours assigned also has contingency built it and your hourly rate stays consistent with what it would be without the contingency assigned.


• Create a task called Schedule Contingency and set the duration to an amount of time with no resources attached. Bury the task where you think the schedule risk is going to occur - I usually put it into the QA phase of the project as this is the mostly likely area where you'll need the contingency.

10. Save often. I've had too many cases where Project crashes and there is no automatic recovery. In addition, there is only one level of Undo in Project 2003 (this is fixed in 2007) so if you make some significant changes its tough to revert them.

11. Use the keyboard as much as possible. Learn keyboard shortcuts. Don't drag things around when you can copy and paste. Don't use your mouse to indent when you can click on Alt-Shift-Right Arrow. Typing in predecessors manually instead of clicking on the link task button in the toolbar generally is faster.

Hopefully, that will help speed up your MS Project work dramatically. If you work this way, you'll find that planning with MS Project is feasible. If you're doing it the traditional way by dragging grantt bars around you'll find a major speed improvement working this way.