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

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.

By: Ron Rosenhead

Ron Rosenhead — Thu, 25 Feb 2010 14:41:37 +0000

Good post Peter. I have long since argued for pragmatic project management and I like this approach. It gets people going and you can amend it as you go along.

Incidentally, I think project management is relatively easy (especially with your suggestion) however it’s the people that make it more difficult……

Ron Rosenhead

By: Peter Kretzman

Peter Kretzman — Mon, 22 Feb 2010 15:30:34 +0000

I don’t think the nature of the tool — SaaS or otherwise –has much to do with the inherent complexity involved in a multi-department rollout of a PPM package. I’ve witnessed clients struggle with exactly that, despite their platform being a “Web 2.0″ tool. Not only was the tool less user-friendly than it could be (although certainly better than some traditional packages), but all the typical problems –communication, acceptance, custom tweaks, etc.) reared their heads. A tool or approach that works acceptably in a “bottom-up” mode doesn’t necessarily scale to a larger, top-down view, otherwise people could simply use MS Project on their own and everything would be fine. The whole point is cross-project resource allocation, and simplicity.

There’s actually nothing about an approximating spreadsheet which says you get no input from the team. In fact, it’s critical that team members participate in the resource allocation, not just a single manager. It’s a top-down, approximating, upfront approach, meaning it requires close knowledge of what people both are currently working on and what they need to work on.

Thanks for commenting.

By: Pankaj

Pankaj — Mon, 22 Feb 2010 09:30:31 +0000

Great article Peter. Web 2.0 tools could fill the gap of simple yet robust tools for project management. They’re part of the shifting paradigm, where software is designed for end users rather than IT. Change management shouldn’t be a very big issue, at least in small companies, since adoption is usually bottom-up (needs of local teams driving adoption) rather than a top-down corporate initiative.

An approximation spreadsheet has the downside, it mainly only a project manager’s tool with no inputs from the team.

By: Peter Kretzman

Peter Kretzman — Thu, 18 Feb 2010 17:16:52 +0000

VERY perceptive comment, Kris. Yes, that debate about how complex the approximation needs to be can be a drain. And it’s the leadership of the CIO that needs to set the standard and expectations for it.

By: Peter Kretzman

Peter Kretzman — Thu, 18 Feb 2010 17:14:54 +0000

Thanks for commenting, Steve. Yes, all other things being equal, the SaaS route is looking better and better lately. That said, my other (main) point is that the approach itself (“the Unified Field Theory”) is costly and time-consuming in and of itself, and requires a good deal of organizational change management and commitment. The mapping exercise you suggest is one way of eliciting/confirming that commitment, which of course needs to be ongoing.

By: Peter Kretzman

Peter Kretzman — Thu, 18 Feb 2010 16:38:02 +0000

Thanks, John. The blog post of yours that you reference above was a good one. I would point out, though, that I distinguish between general capacity planning (also done in an “approximating” style) and then actual resource allocation, which is more granular. The first was covered in my post on “The Practical CIO: Difficulties in project prioritization & selection, part 2”. There, you’re just trying to get a general idea if all the envisioned projects can fit roughly within the “factory capacity” you have available. Here, in this post, I dive into ways to actually allocate the resources, again with an “approximating” approach but more granular than the capacity planning model. The more formal PM packages will push you even further down into granularity (20% of Bob’s time on project A, 80% on project B, etc.) — and my point is that this is often meaningless precision and/or changes so often as to make the estimation process a serious time sink.

By: Peter Kretzman

Peter Kretzman — Wed, 17 Feb 2010 17:33:57 +0000

Thanks for commenting, Roger. I think my post caused some misunderstanding; in an attempt to clear this up, I added a sentence at the end of my first paragraph, making it clear that the post actually argues FOR a simpler approach than the “Unified Field Theory” embrace-all approach of the larger project management/PPM software packages.

And nowhere did I intend to imply that I specifically advocated breaking down a single monolithic project into smaller ones in an effort to simplify, and I definitely didn’t argue that doing that sort of breakdown actually makes things more complex — I think that your strong involvement (and outstanding work) on this kind of issue may have influenced your reading of my point here. Rather, I’m saying that multiple projects are just a reality in today’s IT world, and allocating resources across those projects (avoiding contention, skirting the danger of overcommitment, etc.) is a thorny problem no matter how you slice it.

By: Roger Sessions

Roger Sessions — Wed, 17 Feb 2010 16:59:47 +0000

Great post, as always. And, as always, I disagree on a few of your points. The first is not a point you make, but one that people might easily misinterpret from your post: “Anyone ever tell you that a simpler approach can often work better than a more complex one? Whoever it was, it probably wasn’t a project management software vendor.”

I totally agree that a simpler approach will rarely work better than a more complex approach, but an approach focusing on the simplicity of the end product will almost always deliver a better product than one that ignores the complexity of the end product.

So I agree that we shouldn’t be looking for simple methodologies. But we should be looking for simple deliveries.

The other point on which I disagree is: “Project management is relatively easy, in other words. The hard part is PROJECTS management. ”

I understand what you are saying here, but let me express my concern. I believe that a substantial overall simplification in a system occurs when you break down a single monolithic project into a number of smaller, autonomous projects. Doing so creates numerous projects from one project. Your statement will lead some to believe that you have increased the overall project complexity in doing this. In fact, if you do a good job (if I may be so bold to suggest, if you follow my guidelines for doing this) then you will end up with N projects to manage each of which is much less complex than 1/N. Even when throwing in the extra overhead for the coordination management, you still end up with a large savings in overall management complexity.

Let’s say, for example, that the original single project had 100,000 Standard Complexity Units (SCUs). If you do a good job of splitting this up into five smaller projects, it is likely that none of the smaller projects will exceed 10,000 SCUs. Adding them together gives 50,000 SCUS. Throw in another 10,000 SCUs for the project coordination still only brings the project up to 60,000 SCUs yielding an overall savings of 40,000 SCUs. Since SCU’s (I believe) translate directly to cost and chance of success, you have also reduced the overall project cost by 40% and increased the chances of success by almost 60%.

So it isn’t that I disagree with anything you say, more than I caution readers in extrapolating from what you have said.

Thanks!
- Roger Sessions