MS Project - My Rules

I get annoyed, quite easily, as you will notice when you read my blog. Something that annoys me is the incorrect use of MS Project. I say incorrect, but I have no official training or expertise in the product, I just know how "I" use it.

I have three simple rules when using MS Project.

Timesheets

Timesheets are the pain of many peoples life.  The idea of being managed on a minute by minute basis is not the ideal way of life for many employees.  However, as a Project Manager it is a useful tool to be able to cost your project.  The question to ask in this article is... 

"How do you keep track easily?" 

I keep a note in my notepad of the tasks I need to, or have performed within the day and next to them, I write down a numeric figure to represent the number of hours that I have worked on that particular task / project.  I keep it simple and round the figures to the nearest 15 minutes. 

I have seen that some people keep their electronic timesheets open all day.  I think this take discipline and most people do not seem to be able to do this on a day to day basis.   

I find that if you do not complete the timesheets on a day to day basis, it is very easy for it to become a very difficult task and often people make up times and tasks just to fill their 8 hours of the day.  This of-course has the knock on effect to our project budgets. 

So, I pose the question to you.... "How do you keep track of your day to day timesheet?"

Project Planning

As a contractor, I have found that there is no standard tool for planning my projects. I can understand this as every project is unique and different companies work in different ways in terms of planning and reporting.

When I tell people that I am a project manager, they often jump to the conclusion that I am an expert with the well know software package, Microsoft Project. Well, I can say that I can use the software, but it is sometimes too much to use for smaller projects and too difficult to use for some larger, more complex projects.

In terms of reporting from MS Project, I like the way that the project can be broken into phases and a percentage complete can be marked against each task within a phase to give the Phase Percentage Complete, which in turn is used to calculate the Project Percentage Complete.

A tip that my first Project Management mentor taught me was to NEVER mark a task as a percentage complete, other than 0% or 100%. Something he installed in my thinking was that a task is either complete, or it isn't. If you want to mark the task as a part-completed, he told me to add sub tasks and mark each of those as either complete, or not. This way you can see a true reflection of the tasks that need to be monitored.

I find sending out a project plan is a little difficult. Most people,other than project managers, do not have MS Project, or even a viewer installed on their machines. This usually results in me printing the plan to pdf, which usually does not work very well. For this reason, I tend to use Excel to define the high level project plan and to show the progress. This was a tip passed on to me from an Australian college at a previous workplace. It is clear and simple, plus everyone in the company tends to have MS Excel installed.

What tools do you use and how do you share your project plans and progress?

Lead by big brother

Recently I have taken over a project at a company, which is in Partnership with another company. The other company seems to be the big brother in the relationship and tends to enforce its policies and procedures down to little brother.

The project I am running was not suitable for little brother and so the project had been running for 6 months with little progress at my company, but had been almost completed at the other company. I came in to fix the project and get it going (my favourite type of project management role).

The main problem was the design of the solution. It worked for big brother, but it did not work in the company I was working in and would basically prevent 4200+ users from using not only their email/calendar, but also many of their business applications.

The design was completed and tested at the big brother company and was minimally tested at my company. This meant that the full extent of user types was unknown and more importantly, not tested. This resulted in many changes to the initial design and caused many political contentions and delays in the project proceeding.

The only way to deal with this was to stop the project from my end and to look at each problem to find a solution. This would then result in a 3 week delay to the schedule for a redesign and a new code to be written.

We are now just 4 months into the roll out of the project and have completed 80% of our target. The initial project was supposed to last 6 months to roll out to 4200 users, but we have rolled out to almost 3500 in 13 weeks.

Sometimes it is of greater benefit to stop a project to understand why it is failing. Fix the problems, design the new solution and start again. This has had a positive affect on the morale of the people in the project team and the acceptance of the business change to our customers.