Comments on: Simple, more practical approaches to actual resource allocation

By: Peter Kretzman

Peter Kretzman — Tue, 30 Aug 2011 06:47:48 +0000

Per Ashwin’s request above, as well as a number of other people who have contacted me privately, the spreadsheet is now available for download, via a link added to the Lagniappe section of this post. Please be aware that it is an example only, and is supplied with no guarantee and no support. Please let me know how it works for you!

By: Peter Kretzman

Peter Kretzman — Fri, 26 Aug 2011 19:03:02 +0000

Well, seeing that this post is now the most popular post on the blog (recently ascending to the #1 spot), I probably should look into doing that. I’ll see what I can do.

By: Ashwin Rao

Ashwin Rao — Fri, 26 Aug 2011 13:47:54 +0000

Would you mind sharing with us a sanitized version of the spreadsheet that you use?

Thanks!

By: Peter Kretzman

Peter Kretzman — Fri, 13 May 2011 12:12:27 +0000

Well, as my post said, using a spreadsheet to do simple “squint across your thumb” resource allocation will definitely require someone with relatively honed spreadsheet skills. Without such skills, probably the worst thing you could do is find a template somewhere and just start using it; there’s bound to be customization and changes required to the template. If you want to move beyond using mere gut for resource allocation, though, you’ll have to learn a tool. My point in the post is that spreadsheets may be simpler to learn and adapt to your needs than a much more elaborate project management tool.

Thanks for commenting!

By: jacopo

jacopo — Thu, 12 May 2011 07:28:51 +0000

Great post, very inspiring.
now, I am not looking for a free meal but I am just not a XLS guru.
Would you be able to suggest where to look for if we want to try a spreadsheet likes yours? is there any template available around?

thank you!

By: Peter Kretzman

Peter Kretzman — Wed, 13 Oct 2010 03:32:30 +0000

Thanks for the question, Pankaj.

I think this largely depends on your organization, and the answer also depends based on whether you’re talking about task-level allocation or project-level allocation. With 200 resources, coupling them tightly to a project can seem limiting, but I’ve also seen that reduce dependencies that are otherwise too hard to assess and juggle. I’ve generally seen, at a TASK level, that it’s important to have a resource assigned and dedicated to just one task at a time (read: no more than one per day), if at all possible, assuming that the tasks are not too granularly defined. My other point is that someone, somewhere, does need to be assigning each resource their tasks at that level, no matter what you’re doing at a higher level in terms of resource allocation.

My article basically came down on the side of using simple allocation whenever possible, rather than getting tied up in contorted knots trying to split and juggle resources: in other words, be able to know that you’ll have THIS resource working on THIS task for THIS day. Again, if the tasks are appropriately defined and “meaty”, that shouldn’t involve too much “not working sometimes”, which of course is always a valid concern.

By: Pankaj Kumar

Pankaj Kumar — Tue, 12 Oct 2010 21:23:26 +0000

Hi Peter!

Nice article. I was looking for a “Allocation approach Vs Assignment approach” and came across this article. I am evaluating whether I should just care about overall allocation at project level and loosely coupled resources so that then can use their effort for more than one task or should tightly coupled them with the task(project is large and needs around 200+ resources). The trade off for first approach is I need to let go individual allocation and forcasting. If I will stick with tightly coupled then I need to allocate 200 resources for task that they might not be working sometimes also.

I am trying to figure out if I can use simple allocation method.

By: Cynthia West

Cynthia West — Thu, 30 Sep 2010 13:34:06 +0000

Great article, Peter,
I am always telling my customers and prospective customers that purchasing a software solution alone will not work. The team must have ‘people, process and product.’ By people, I mean leadership of the management team. You can’t simply buy a product or solution and throw it out there without good leadership, which includes a thoughtful communication plan, etc. By process, of course I mean deciding how you will use the software. In our case, there are multiple ways of performing functions, so it’s a good idea to have your process written down and explained to all. By product, you must have the right tool for the job. Buying a high end system when your team has a CMM ranking of 1 won’t be a good fit.

Thanks for providing rational advice!

By: Peter Kretzman

Peter Kretzman — Sat, 06 Mar 2010 01:18:29 +0000

Yes, I’ve seen this kind of tunnel vision as well. And, of course, it’s the people aspect of implementing PPM that’s the hard part, no matter what level of tool you use. I’ve chosen to put the time and effort behind evangelizing the need for PPM as an approach, rather than touting the advantages that a specific tool will bring.

By: Ajay

Ajay — Fri, 05 Mar 2010 23:01:05 +0000

Good post, Peter. My PPM experience is mirrors some of the ones you have mentioned in the article.
As interesting issue I once faced with a client was that the PMO director of a < 100 person shop would not consider a spreadsheet based solution lest the CxOs think that the PMO is not serious about PPM. They went ahead and spent the money to get a more "robust" solution with training et al…go figure. As usual sometimes the "people aspect" triumphs rational thinking.