Dealing with non-scheduled time in Project

Question

We build software. We use MS Project. We have projects where someone is booked 100% which really turns out to be 80% with meetings, more meetings, some side meetings, corporate meetings, etc that suck up at least 2 hours a day. So here is the problem.

Example A. We assign Billy to Task A for 8 hours. Project thinks Billy can accomplish this in one day since there are 8 hours in a day. However, Billy has three non-schedule related meetings on this day so it actually takes Billy 2 days to accomplish this task.

Example B. Billy has Task B which takes 6 hours. He finishes it today but had several more meetings and whatnot that took up the rest of the day. Now Project wants to start Billy on Task C when he is doing non-schedule related stuff.

Project deals well with Billy taking time off but blocking out hours/day is a challenge (or I am dense).

Answer 1

It's always good to assume and set a buffer for every team member. If the 'additional' meetings are known and can be reasonably predicted then one option is to represent them in Project plan (e.g. Non-project meeting - 2 hours). Other option is to simply add a buffer time (e.g. 10-15%) in every team member's tasks when you enter them in the plan.

However, just taking a step back, I see any tool as 'facilitating' my project work and not 'dictating' it - it looks like you are too bound with the tool focusing on making the tool work rather than having it assist you. Just my opinion.

Answer 2

You may also think of going lean and ask your organization 'Do we need so many meetings? What can we do to reduce amount and time of those meetings? What can we do to reduce Billy's time spent on meetings?'

Be careful with buffers, they are almost always too small :)

Answer 3

These are easy fixes with several alternatives depending on what makes the most sense.

First option, you can reduce the units per resource on the resource page. So, if you have a person who also performs non project related stuff on an uncertain basis, estimate what remains. No one is ever really 100% available. So, using 60%, 70%, or 80% is appropriate. If you did it this way, then you need to set all of your tasks as fixed unit. Plug in your target hours and project will calculate the appropriate duration.

Second option, if some of those meetings, both scheduled or ad hoc, are project related even in the most remote way, then either up your work estimates to include that work or up your duration. For example, if you have your task as 'fixed work', you plug in 8 hours, extend your duration to 1.5 or 2.0 days, and project will calculate the resource utilization to something less than 100%. Or, make your task fixed duration, manually enter 1.5 or 2.0 days, keep your resource at 70% units, and project will calculate the hours.

I find using fixed duration the easiest and keeping the resources either at 50% for part-time or 100% for full-time. I manipulate the duration such that I am providing enough time for wrench turning (full productivity) as well as all the other stuff that pops up. The down side in doing it this way is you have to watch the utilization for each person to ensure you are not over burdening his/her day. It requires some leveling. But MSProject is quirky and this seems to be the best way to overcome its constraints.

EDIT: When you estimate time for a task and enter it into a scheduling tool, you are taking a non deterministic estimate and choosing a single value, a deterministic value. For example, you may estimate 3 to 8 days for a task with a most likely finish of 5. You cannot schedule a range so you choose a target that represents the level of your risk appetite. Five or six days is reasonable and that is what you schedule. However, that inherently means you have some risk of exceeding your target up to 8 days in this example, due to all kinds of interruptions like ad hoc meetings, your people getting pulled on their other projects if they're shared, unexpected issues, etc. This does not make the schedule wrong, it causes variances against which you have to manage.

The schedule does not run you; you run the schedule. If your scheduling is saying a task starts now but your resource is not there, that is called a late start. Plug it in your tool as actual start date and keep going. Your schedule will NOT come true with a zero variance.

Answer 4

AdHoc meetings are planning killers. I'd say that trying to adapt your planning to the unpredictable will only bring you more headaches.

As long as you have enough proof that those meetings are negatively impacting your team's performance and / or management, wouldn't be possible to review if Billy really needs to attend all these meetings? If these meetings are at company level, maybe the managers aren't aware that those meetings, although useful, can lead to project-tracking nightmares. Has this topic already been broadly discussed?

Besides follow David and Ather's buffer suggestions, I don't see much things to do.

In the project I'm currently working on, we had in the past several meetings across the week with the whole team. On a management level, We agreed that, although they were valuable, we could be more concise and productive having review meetings only with specific attendants rather than several meetings with the whole team.

So, I'd suggest you to make yourself the question: Does all these meetings adds any value into Billy's work to pay off this planning change?

Answer 5

I find out impossible to guess a % overhead and would set one initially, but use Earned Value to better predict through the project how individuals overheads were different. I was also careful to to use this as a hammer to judge if one person was 90% and another 50%. We found that this gave us valuable learning to see how different people were used on and off the project. In most cases everyone's average overhead from earned value was realistic for keep the business running and getting new features developed.

Today I use Agile methodologies that specifically measure the feature output of the team that overtime factors in the team overhead, so this issue and frustration goes away.

Answer 6

I always created a separate task for each team member called "lost time" that they could book time to that they felt wasn't directly related to producing one of the main deliverables or main activities. As a project manager, that gave me something to track each week when actuals came in. I make it clear that billing time to this isn't bad in any way and part of naturally working on a project.

Keep tabs on this and it gives you a handle on the demands on the teams's time.

Also, to address the other aspect of your question, I don't know of any good way of working with MS Project that doesn't have you reconciling the hours of the team as they book them and re-adjustiing the plan manually. If you do this weekly (e.g. ask for hours on Friday, then replan Friday afternoon/Monday morning) it will take 1-3 hours but you will have a very good feel for the project "by the numbers"

Answer 7

I call it the "meeting mania". You have many meetings to organize yourself and be more efficient and effective in your dayly tasks; and you end up having less time or no time to do them! I don't like meetings that much. It makes me fall asleep most of the time; I prefer unformal communication on the floor. Your situation look to me as there is no boss to decide or to make a final decision. To much consultations; not enough quick decisions. A receipy for burnout of the team members. Someone should be put in charge of cleaning up those unefficient process a little.

Answer 8

If tasks have been measured in hours and I know that that entire team will working on the project "part time", I have had pretty good success with reducing the workday for the entire project. However, that does not seem to match your case.