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.
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
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.
- 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