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. But simplicity has its merits, and I’d like to point out a few of these when it comes to resource allocation.
Project management, at its core, is largely about resource allocation, and this gets tricky when you have multiple projects going on, as most organizations do. Almost as much as I’ve seen organizations drop the ball entirely on cross-project resource allocation (essentially, simply pretending that there will be no contention issues), I’ve seen organizations go to the other extreme: they dive into the depths of intense Project Management, in capital letters: taken too far too fast, this approach can spin up to a high level of rigor and overhead, involving often-expensive software packages, precise low-level estimates, diligent collection of actuals, and ornate project calculations of hours burned and hours earned. At the end, there you stand, like Goethe’s Faust, “no wiser than before.”
Let’s talk first about the general problem of resource allocation, then, and the range of possible solutions. First off, I’ll note that running a successful IT department, one that delivers predictably and with high quality, depends on far more than just being able to run an individual project successfully.
A major part of overall success in the IT arena comes down to whether (and how) you’re allocating the right (and enough) resources to the right tasks at the right time. That’s obviously true at a project level, but it’s especially true across projects, as you juggle multiple goals, diverse timelines, and random delays anywhere along the line.
Project management is relatively easy, in other words. The hard part is PROJECTS management. As I’ve pointed out before, the most common and glaring problem I see in companies with IT in crisis relates to an unfortunate tendency to estimate and commence projects one by one, with little thought to resource contention issues. That approach almost always leads to chronic overcommitment and late delivery.
So how do you do resource allocation, in a practical sense? I’m talking about determining contention issues, not task-by-task assignments. That’s where organizations often drop the ball: as I said, they either ignore the problem almost completely (allocating resources essentially by a “seat of the pants” approach), or they go whole-hog into major package adoption and process overhaul. But the seemingly greater precision and granularity of such packages does not guarantee greater accuracy or efficacy, and such organizations can easily founder as fast and as much as organizations that punt completely.
Surprise: there’s no silver bullet
My stance? There’s no ONE answer for what’s the best practical way to do resource allocation in-the-large. It depends. It depends on your organizational politics. It depends on the maturity of your overall software development lifecycle process. And most of all, it depends on you, and the level of your desire/appetite for attaching a degree of rigor to what is by nature an ever-swirling hodgepodge of resources, tasks, projects, deadlines, dependencies, delays, resets.
The Project Management Book of Knowledge (PMBOK, highly recommended) identifies nine different areas of focus, each of which is fairly elaborate. Correspondingly, project management tools cover a spectrum of functionality. You don’t just start using “project management software”; you need to decide, initially and all along the line, just how deep and how broad you want to go.
In fact, the areas of project management and resource allocation can be integrated with task management, reporting, document management, financial projections, collaboration tools, email notification, management escalation, risk evaluation, etc. The list of potential useful and desirable features stretches long.
This results in a futile quest for a kind of Unified Field Theory of IT and project management, where everything can be fruitfully connected to and integrated with everything else. The irony is that while tools approaching this goal do exist, and are getting better all the time, implementing them successfully can be not only very expensive, but is also a massive and risky enterprise-level project in and of itself, both in terms of initial implementation and in ongoing care and feeding. And the outcome? Well, an awful lot ends up being “tightly coupled“, which can lead to problems in and of itself.
These different tiers of solutions are for vastly different problems, as orthogonal as bicycles are to trucks. Yet the persistent underlying and increasing belief remains, as you get more and more ornate with the tool you use, that project management can be wholly deterministic, that you’ll get to the point where the data will predict the precise end date, everything will line up, and so on.
It can’t. It won’t. It’s an illusion. Project management, and especially resource allocation, consists of constantly revisiting and revising the plan, not trying to get absolute certainty about every aspect of it at all times. Rather, the successful IT executive learns to live with ambiguity, uncertainty, approximation, and to work within them. Yet, the spectrum of project management software holds out the (false) promise of eradicating much of that uncertainty.
Tools for resource allocation
Let’s look briefly at the range of project management solutions that you might fruitfully consider, with respect to the all-important aspect of resource allocation across projects. This list is a cursory overview, of course, and is not intended to be comprehensive in any way. For further information, consult the links in my Lagniappe section at the bottom of this post.
- Seat of the pants. Assign work when people seem to have some available cycles.
Pros: simple, intuitive
Cons: completely intuitive, and usually doesn’t scale across multiple projects. Unreliable.
- Build an “approximating” spreadsheet that lets you get a quick overview of coarse-level resource allocation for your portfolio of projects. See example below.
Pros: quick overview, relatively easy maintenance (e.g., monthly)
Cons: requires spreadsheet expertise, and understanding that these are rough estimates rather than precise allocations. Limited scale for large organizations; doesn’t directly feed actuals/results into further planning.
- Installed software packages: e.g., MS Project, OpenProj, Primavera.
Pros: fine products, broad functionality, well-known
Cons: Getting a good, easy overview of resource contention is difficult, plus requires constant care and feeding. With this approach, I’ve seen projects that needed to assign resources to do nothing but work the project management software
- Web-based products: e.g., Serena, Projects On Demand, Zoho Projects, Innotas, Project Insight, attask, Daptiv.
Pros: This rapidly evolving market niche is centralized (SaaS) and innovative.
Cons: has same issues as installed packages. On a larger scale, becomes a huge business change management project to implement
- Large packages: CA’s Clarity, Changepoint, etc. (PPM)
Pros: enterprise-class, high level of functionality and integration.
Cons: high implementation cost in dollars, time, and resource commitment, up-front and ongoing
Here’s an example of an “approximating spreadsheet”, where resources are roughly allocated day-by-day to any of nine simultaneous projects (numbered 1-9, and each color-coded). Note that this is a quick-and-dirty planning/working document, meant to do coarse allocation planning at the start of a month, with actual assignments and microadjustments made as the month progresses. Its principal advantage, beside pure simplicity, is that it quickly forces the planners to confront the ever-present “NUTS” problem, where there are too many projects underway at once for the available resources.
I’ve had great success with the approximating spreadsheet approach in a “bang for the buck” sense, in smaller (less than 100 people in IT) organizations. Once you wrap your brain around it being just an approximation tool, it gets you 80-90% of the way there without having to devote a large portion of your staff’s time to the constant and intense administrivia often necessitated by one of the bigger project management packages. (The example spreadsheet itself is available to download for free in a link in the Lagniappe section at the end of this post.)
But those packages do have their place. In short, though, here’s the key ongoing challenge for project management software adopters (and, of course, vendors): how do you obtain the necessary functionality across the vast spectrum of functionality, without turning everyone into a project data entry monkey? Your project management software needs to be a tool, not a torture device, not a time sink. My argument is that your key goal, in a cross-project sense, is to roughly allocate your resources so that you avoid major contention, and/or taking on too much. And you want to focus on this with the minimum amount of overhead you can, because at an extreme, it will suck up virtually all your time.
So, I’m hardly arguing for “seat of the pants” resource allocation, but I also tend to shy away from the “Unified Field Theory” approaches as well. I’ve been there, and I’ve seen them consume organizations.
Lagniappe:
- [Added as of October, 2017] Digneo, Greg, Zoho Projects: An In-Depth Review. Excellent article discussing not just Zoho Projects, but also other alternatives Time Doctor, Asana, Trello, and Basecamp.
- [Added as of December, 2015] Tomac, Emily Sue and Govani, Grishma, Top 10 Project Management Software
- Wikipedia, “Comparison of project management software”
- Gartner Group, “Magic Quadrant for IT Project and Portfolio Management“
- Wikipedia, “Project Management“
- Wikipedia, “Program Management“
- Wikipedia, “Project Portfolio Management“
- SearchCIO, “PPM: From Efficiency to Enlightenment“
- Downloadable sample allocation spreadsheet, shown above: Resource Planning Tool, EXAMPLE, V2.2, by Peter Kretzman
Good article, Peter. I think one of the biggest hurdles is that highly technical people have a difficult time accepting a system of “loose estimates”, and always want to drive towards more precision and perfection. Even for the people who can learn to view less than 100% accuracy as acceptable, they each draw the line of necessary accuracy at a slightly different point, and end up arguing about how complex the “approximating” spreadsheet needs to be. The debate itself becomes an ongoing resource drain.
Senior leaders don’t like to get into resource management – they want to leave that to their “managers”. But I believe that in order for this to work, a senior leader (CIO) must (at a minimum) define and articulate the level of accuracy he/she expects so that the directors and managers who implement and manage the system can get on the same page about what the goals are.
Another great post! Having worked both in large 2000+ person IT shops and small 20 person IT shops, I can safely say I’ve seen a gamut of project management approaches. PMO office lead enterprise deployments of “large packages” never seemed to get past time entry yielding financials and high level run rates, but no practical use by project managers and leads. Thus, PMs and PLs were forced to come up with their own tactical solutions which differed and weren’t easy to mash together to see any real cross-project resource views. Honestly, and I’ve commented as such in my blog posts in the past, here, using your “approximating spreadsheet” was the most effective way to do light weight capacity planning that had tremendous buy-in and support from the next level of management due to its simple, uncomplicated analysis representation.
Great post Peter. I am glad you are tackling the machinations of this key challenge, because frankly, it gives me a headache. And I think this “headache” aspect contributes greatly to the thirst for the “silver bullet” you rightfully state does not exist.
I suggest organizations should first have an acute understanding of the decisions they are making and then determine the data required to ensure the decision is reasoned and rationale. This decision-mapping exercise helps illuminate which of the many alternatives you identify is best suited to fulfill providing said data to said decision-makers.
The only other thing I will add is in regard to your “Large Package” cons. The high implementation costs can be significantly reduced if the enterprise goes the SaaS route – in those instance when it is offered (such as Clarity).
Steve Romero, IT Governance Evangelist
http://community.ca.com/blogs/theitgovernanceevangelist/
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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!
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.
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.
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!
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!
Would you mind sharing with us a sanitized version of the spreadsheet that you use?
Thanks!
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.
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!
new to this and would like to work with this spreadsheet…can someone offer some assistance? I do not need the QA portion and have DEV/SE resources. First question – i have a lot more than 9 projects. If I add the projects to the project tab, how can I get it to update the planner tab, where the projects asre listed ther? Thx!
tom
Tom,
Thanks for commenting. I’ve made the spreadsheet available as an example of what can be done, but I can’t supply support for it myself. The changes you’re talking about require very strong Excel skills to make. Good luck!
Regards,
Peter
Hi Peter. I am a Resource Manager currently using an Excel workbook to manage resource allocations. I currently manage over 150 staff on over 100 projects. I’m always looking for hints and tips to improve the way I work.
Whilst knowing who you have available and when, what work you have in the pipeline and where your hotspots are (ie supply greater than demand or vice versa), its also important to keep your staff motivated, so I track their skills, aspirations and any restrictions they may have (part time hours, inability to travel etc).
Whilst ensuring their are “bums on seats”, that no-one is on the “bench” and that best margins are made, you get more out of your Team is they are assigned to work they want to work on. Sometimes this is not always possible but if you plan far enough into the future, it becomes an easier task.
If you can point me in the direction of any other sites that may help me improve in my role I’d be very grateful.
Thanks, Lynda
Thanks for commenting, Lynda! I certainly agree that the granular details really matter: who is assigned to what work. My post here doesn’t specifically address that as a critical success factor, but you’re absolutely right. And while it may not always be possible to match assignments with desires, people can definitely tell the difference between a manager/executive who does what he/she can to assign work in that manner, versus one who obviously just regards resources as things to deploy abstractly, fungibly. So thank you for pointing that out.
As for other things to read: check out my blogroll, shown on every page. Those are the sites that I return to again and again. Also, I have “Recommended Reading” as a page, here. The one resource that most comes to mind for your particular thrust in this comment (and, indeed, is the first book I’ve listed as a “must read”) is DeMarco’s and Lister’s book, Peopleware; check it out here.