Introduction
Here's some notes on how I work with MS Project 2013 - they may be useful to you if you use Project and are useful to me as an aide memoire.
There are currently two sections:
Project is a great tool but sometimes it's flexibility can complicate what should be simple activities.
By following these guidelines I can quickly create a schedule, manage it's resource profile and more importantly find it easy to manage going forward.
Make Fixed Work the Default Task Type for your Tasks
When you're planning out a project you generally know for a task the effort (work) involved - because you and your team have estimated it.
So that is a given - so it makes sense to set your tasks up to be Fixed Work (on the Advanced tab).
Doing this means if you increase or reduce resourcing (adding or removing people, changing their availability percentage or working hours) the duration will change as you would expect but the work stays the same.
Similarly if you change the duration you will find the resourcing changes but the work stays the same.
You can setup Fixed Work as Project's default (Project-> Options).
Use Resource Usage to Check Allocation of Resources
The Resource Usage view is great for checking your resources haven't been duplicated due to typos (assuming you're not using a pool) and that you have optimised your schedule i.e. your resources are being kept busy.
Define Milestones
It's easy to define KPIs that aren't meaningful i.e. KPIs that aren't SMART and it's just as easy to define milestones that aren't meaningful.
I try to:
- Ensure the milestones meanings are clear and unambiguous (ref 'definition of done' debates) - you can describe them if necessary using the Milestone's Notes field.
- Have enough of them to help ensure we can demonstrate we are on track - they need to be spread throughout the project.
- Have interim milestones for long running activities.
- Define the milestones such that we can confirm objectively they are complete (having a milestone "System Design 50% Complete" is meaningless - but having a milestone "System Design (Sections 1,3,5) Signed off" isn't).
Projects has views (and filters), that allow you just to view your milestones - a useful way to easily see if they match the criteria above and can also be useful for pasting into a status report.
Holidays
I enter bank holidays in the project calendar (these then appear on the timeline).
I enter team members' holidays as constrained (must start on) fixed duration tasks rather than putting them in team members' calendars (working time).
The benefit of using tasks rather than team members' calendars to record holidays are:
- They appear on the Gantt - so the reasons for a task being delayed by a holiday is clear - if working time is used only one resource's holidays (or the projects) is shown on the timeline - pretty useless.
- The hours involved appear on the Resource Usage view - if working time is used the resource will appears under utilised for their holiday's duration and that can cause confusion.
I tag these tasks with one of Project's unused predefined fields e.g. 'Flag1' so that I can easily exclude or include them from filters / views.
If you track budget through Project creating these tasks can mean the cost of these holidays are added to your budget - if you don't want this you can put the holiday tasks in another project or set up a cost table (with nil costs) for the resource and link it to the task in the Resource Usage view (use column "Cost Table").
If you use another system as your master source for holidays then you can write a Project VBA macro to automate the creation of these holiday tasks from your other source.
Check your Plan for Anomalies
It's easy to make a slip setting up a task in Project and for it (and it's consequences) to go unnoticed,
We see this with Excel where, for example, an incorrect formula or overtyped formula can cause issues.
Part of the reason this happens is that the information is hidden and hence the errors go unnoticed.
The trick is to make your config visible so you can spot these issues.
I just use a simple table view of tasks and add in columns for things that are significant to planning but that aren't typically displayed like Work, Task Type (Type), Auto. or Manual Scheduling (Task Mode), Constraint Type and Constraint Date, Cost table.
Scanning down this view from time to time lets me quickly spot and correct errors and re-verify constraints.
Doing this is even more useful if you are taking over someone else's plan.
Reporting
We know that we need different levels of reporting for different stakeholders e.g. a developer might want to see a relatively detailed view of activities around his area, a project board will want a high level view.
We also know how important it is for the information in a report to be specific and relevant.
Milestones are the traditional way to report to a project board - along with a short commentary (including any decisions to be made) and details of significant issues and risks, any changes and details of costs and dependencies.
Assuming we have our milestones setup correctly, extracting milestone information for a report is just a matter of setting a view or filter and cutting and pasting - assuming you are not using Project's built in reporting.
If you want a level further down you can use different views/ filters to give what you want.
I often use two filters to give me two tables of tasks - e.g. for a project where I was reporting fortnightly:
-
Work Scheduled up to this Period (Work due)
Includes incomplete tasks that were due to complete by the date of the report and completed tasks due to complete in the past fortnight. -
Work Planned for Next Period (Remaining work)
Only includes those tasks that are due to complete in the next fortnight.
The fact that the time periods are constrained means the tables are typically fairly short and easy to understand and they give a good objective view of project status.
The second table wouldn't report on a long running task that was due to complete in say three weeks.
The omission of reporting on this type of long running task might be seen as a risk as it might be significantly behind and therefore needing discussion. This hasn't been a problem on the projects I use these tables on because I keep my tasks short (see Milestones above).
FAQ
Why don't you used Fixed Unit and Effort Driven rather than Fixed Work - this is supposed to fix both the resourcing and the work?
Answer: Effort driven does look useful but it suffers from some issues:
1. It only fixes work when you are adding extra resource, so for example if you have a task with one resource assigned and you extend it's duration it WILL increase the work - I find this inconsistency annoying.
2. If you do vary resource or duration it will ask you what you want to do AND the default is always to vary Work - so that's an extra step, to confirm what you want to do, that you have to take every time.
With Fixed Work you get the question but it correctly defaults it so you never need to answer it.