What are some of the resistance you have encountered from users on related to the usage and regular updating MS Project schedules? Thoughts?
A few of the things I’ve heard repeatedly are:
I used to hear a lot about difficulty moving on resource’s remaining work on a task, to another resource, but MSP 2010’s “Team Planner View” provides a wonderful built-in method for handling that.
The Hammock Task isn’t a built in feature in MSP. It can be done using links to schedule task dates, but it isn’t built in.
MSP doesn’t copy custom fields such as Text/Number/etc… fields to it’s baseline. It can be done with additional custom fields though.
Our resources are not used to updating progress this precisely. In the past they could just say, “I’m about half done” or “I need another week”, but PWA wants them to really look at the estimate, the time spent so far, whether they are on track, etc. Of course, this is why we installed Server, not a defect, but that’s been some of the user feedback.
Users also don’t like e-mail alerts, but without them we couldn’t communicate assignments very easily, as we are a global company with resources across many time zones.
What are the consequences of not providing the updates?
The consequences are that the PM has to contact the person to get a status or discuss it in the team meetings, which is what we want to avoid by using Server. Additionally, we want resources to feel that they really own their estimates and the actual effort, and we lose some of that reinforcement if they don’t update actual effort through the system.
What are the consequences for team members not completing their updates? I am finding that if there is no accountability and consequences then they are less inclined to comply. What are your thoughts?
I still have great difficulty in getting work estimates. I have a small group of developers who understand the concept, but everyone else, including my manager (who, amazingly enough, used to be a PM) still want to give me duration-only estimates. As in: (this may take me an hour, but) “give me a week to get it done”. I don’t know how write a dynamic Project plan that will give me accurate forecasted finish dates with no work estimates. Frustrating…..
It sounds like a people want to give themselves a lot of buffer in their estimates. This can be a challenge.
Hi, Jeffrey – it is frustrating, but worse is that I don’t know how to best capture the information in Project. I’ve been using task type=Work for those developers that give me level of effort estimates along with their availability, and I use task type=Duration for everything else. I feel somewhat comfortable with my forecasts for those developers, but how do you forecast a 1 week duration task when a) you don’t know what the real work effort is, and b) you have no confidence the resource won’t ask for another week, or three?
Should I just make every task type=unit?
I should mention (if you couldn’t already guess), we aren’t terribly sophisticated in our processes; no one cares about my Project plan except me and my staff (and only ’cause I make them). And I’m self-taught, although I devoured Dynamic Scheduling by Eric Uttewaal.
Thanks for listening (I don’t think you can actually help me unless you have a gun I can borrow).
“What are the consequences for team members not completing their updates?” There are no real consequences. If the PM is of a certain personality type, he or she might call out the behavior in the context of a team meeting, but that does not always happen.
Our company has not mandated the updates because we already have so many disparate systems with which employees are expected to interact. Various engineering supervisors have different attitudes about what their people should have to do. PWA updates would certainly help the PM out, but they are not critical, since the PM can still do the updates just as before Server came along.
Sarah, we have faced the same problems. Estimation is a skill that people have to work to improve, regardless of the units they use to express the estimate. We standardized on Fixed Work, Effort Driven because it allowed us to all speak in the same terms, but there’s nothing magically better about this method. I do like it because there is a nice correspondence between the estimated and the actual work. It seems to convey more task ownership when I can see my original estimate and the actual time it took me, right there. If I say “give me a week”, I’ll know if I miss the end date, but I’ll learn nothing about why.
Anyway, don’t give up!
It all comes down to PMs, leads, managers, & etc. resisting taking the tinme to plan and status and re-plan properly. Scheduling is a discipline, and it takes discipline to plan and manage a successful project.
MS Project cannot solve this problem, it is just a tool.