http://www.sqlservercentral.com/blogs/brian_kelley/2011/05/13/project-management-dedicated-vs-shared-resources/

Printed 2014/04/21 07:29AM

Project Management: Dedicated vs. Shared Resources

2011/05/13

As an infrastructure type person, I typically represent a "shared" resource. What that means is I'm not dedicated to just one project, but am usually working multiple projects at any one time. I have been a "dedicated" resource, even as an infrastructure type, but lately that's been very, very rare. I've also been a project manager, courtesy of the US Air Force, where I spent 3.5 years in a project management slot during my 4 year career. Along the way I picked up the obligatory federal acquisitions certification (level 1) and learned quite a bit about how to manage projects and understand how resources can impact timelines, especially as tasks slip. One area that I see in the industry that some project managers (or folks asked to act as project managers) struggle with is the difference between a dedicated and a shared resource. If you're a technical type and you suddenly find yourself also acting as a PM, keep in mind the difference between the two. If PMs struggle with it, so will you, if you're not careful.

The Dedicated Resource:

When you have a dedicated resource, that person is working on your project alone. You get to allocate all of his or her project time. Typically we say this is 32 hours for a 40 hour week but I've seen some organizations push this as high as 36 hours a week. Why 32 hours? Sick time, appointments, administrative functions (like filling out time sheets) and other non-project work that's just a part of doing business. If you plan for 40 hours out of 40 hours, you've already set yourself up for failure. When I see a technical person start functioning as a project manager, this is one of those tried and true practices that they usually aren't aware of. But regular PMs should know this rule by heart.

The Shared Resource:

This person is not just yours. Other projects have claims on this resource, too. Therefore, when and where this person's hours will be available must be negotiated. You can't assume anything. This person's time available to your project may change over the course of your project and it may change many times, depending on how this resource is shared. Again, you can't assume anything. This is where that big gap starts: PMs assuming they have a shared resource's time when it wasn't previously negotiated.

Why There Is a Difference:

This should be obvious, but apparently it's not. If a person is a dedicated resource, you can allocate his or her time however you want. If a task slips, then, yes, the dependent tasks will slip as well, but at least you know this person will be working the task and you don't have to do much to account for the changes in schedule. If the task slips two days, then this person's tasks that follow all shift two days, too. Note: I'm not including vacation and other communicated unavailable time. You had better plan to deal with this if you have a slip.

With a shared resource, this isn't so easy. If a task slips (even if it isn't critical path, because all critical path effectively means is it will definitely affect the overall project's timeline) then any dependent tasks where you have a shared resource will slip, too. However, how they slip is completely dependent upon how many manhours each task is expected to take and the availability of the resource when those tasks can finally be worked on. A two day slip on a task, because of a shared resource's availability, could mean you have a significant change in task completion dates because that shared resource becomes less available for your project than when originally scheduled. You can't assume two days = two days. You must actually check.

Modern Project Management Software Helps with This:

Most modern project management software allow for a PM to enter in a resources availability over time, and this means if the 2nd week of July you're on vacation, the PM can put this in to the project information and tasks roll out accordingly. That takes care of the dedicated resource's time off the project situation. It also, if you negotiated a shared resource's availability, allows you to plan for the changing amount of time a shared resource has for a given day/week/month of your project. If you specify tasks based on manhours (or estimated work) instead of the default of duration that I've seen a lot of folks using, then as tasks slip, the project management software will show you (but it won't comfort you when you cry) how dependent tasks are affected. But you have to use the tool correctly.

I Just Had a Slip and I Really Need that Shared Resource:

My simple reply: too bad. You don't automatically get him or her. You have to negotiate to get more availability from that shared resource. If you share the same boss, then you know who you need to talk to. But if the shared resource works under a different boss, you need to go talk to the shared resource and/or his or her boss. Just because you and your boss think your project is a priority doesn't make it so. The organization determines the priority. Typically, the management of the shared resource is very aware of what the organization's priorities are. That's because their people tend to be on most, if not all, of them. This is especially true of infrastructure folks. So realize that if you have a slip, you might not get more of that resource. And you might not get another resource to help, either.

We Disagree about Priority and I Really Need that Shared Resource:

You've gone to the shared resource's manager and he or she has said, "I'm giving her all she's got, Captain!" but you really need the resource (or another, additional resource). What then? You escalate. If there is a disagreement between two departments about priority, then it's going to take someone higher up, typically where the two department branches eventually merge together under one manager, to break the deadlock. This should be done together if possible. Escalating together means you're both on the same team trying to do what's best for the organization. Escalating without enganging the other department could be seen as disrespectful and is a blow to teamwork. Now if the other group won't escalate, then you do what you have to do. But otherwise, try and raise it to your respective management together.



Copyright © 2002-2014 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.