Oil and water? Some days, the disconnect between stakeholder expectations and IT capabilities (and sensibilities) seems staggering.

“System availability was 99.83% last month!  That’s up from 99.75% the previous month!”

Sounds kind of good, no? I mean, that’s a high number, right? Right?

Actually, no.  It’s not a very useful number, in and of itself. In fact, I regard the publication of uptime metrics like that as a regrettable symptom of IT focusing on technical aspects, rather than business impacts.  Here’s a discussion of why I see it that way, followed by a presentation of an alternative focus providing much more business value.

So, what’s wrong with a time-honored metric like “the system was 99.83% available”?

• The number is deceptive. Few people can mentally translate “99.83% availability” into a more meaningful real number, such as “system was down for 1.3 hours last month.”  Even fewer can tell you the real difference between 99.3% uptime (also sounds pretty good, right?) and 99.8% uptime.  Both 99.3% and 99.8% look (to the vast majority of business people) at first glance like pretty good numbers for uptime, but the first represents more than three times the number of “down hours” of the second.

• The number is ill-defined. It begs the question of what’s considered down: what if the system is just somewhat degraded in performance? Who decides that it’s down? Who declares that it’s back up? We’ve all seen situations where a technician will insist the system is up, even though no one is able to access it or get sufficient performance to actually use it.

• The number is often not comprehensive in what it includes. Most notably, many shops don’t count scheduled maintenance as downtime when calculating their uptime metric.  When you don’t count scheduled maintenance, you’re ignoring potentially many hours of real business impact per month. Scheduled maintenance can’t be a “free pass” for downtime.

• The number doesn’t compare apples to apples. Just tracking total raw downtime considers all outages to be the same, no matter what the time or situation.  A ten-minute outage at noon may impact your business much more than an hour-long outage at 3 a.m.  An outage that occurs right when you’re running a key campaign to drive people to your site can be especially devastating.

Alternatives

Somewhat better than the “99.83% uptime” style of metric is reporting on the specific number of system DOWN hours or minutes in the period.  It’s when the system is down that there’s business impact, so why not use that as your yardstick, instead of the reverse.  Some call these “impact hours”, in fact.  Stating that the system was unavailable for 20 minutes last week is much clearer (albeit sometimes more distressing!) to most business people, compared to saying it was 99.8% available.  Still, though, expressing the figure as down hours doesn’t address the other problems listed above.

The underlying insight here is that raw outage statistics, whether they’re expressed as an uptime percentage or as downtime hours, are nothing but a proxy for business impact. And not a very good one, for the reasons discussed.

Here’s a radical idea: the goal isn’t simply to report and then reduce your downtime per se.  Instead, you want to assess, promulgate, and then work down, the total business impact of your outages, and to do that effectively, you need to weight your outages by time of day and traffic. And you need to include every single outage in your assessment of business impact, including maintenance.

What’s the clearest expression of business impact?  In a nutshell: DOLLARS. How much did a given outage cost the company, in terms of missed sales and wasted expenses? Yes, there are a lot of factors and assumptions involved in figuring that out, but that’s what models are for.  Make some assumptions and build a model that will calculate the specific dollar cost for an outage, based on information about the outage’s duration, site traffic pattern at the time of the outage, etc.

We did exactly this at an internet site where the revenue stream was on the order of a million and a half dollars a week.  We incorporated considerations such as the following into our model:

• Upon analysis, we realized that any outage resulted in missed subscriptions, site advertising, and ancillary signups for partner services from which the company derived revenue. We needed the model to incorporate an understanding of the patterns and dollar costs for each of these.
• We also realized that an outage also meant that we’d wasted the money spent on external internet advertising during that outage that was driving people to our site. During an outage, external ads of course kept appearing for our site; people would click on those ads and land on our outage page. Ergo, wasted advertising dollars.
• Outages at different times (hour of day, plus even day of week) were vastly different to our site in terms of business impact and cost. Specific time of the outage needed to be a key part of the calculations of business impact.
• Outage impact also depended on whether it was a high-traffic day or not.  A high-traffic day might feature more than ten times the normal volume of traffic and transactions; an outage at that point would therefore arguably cost us ten times as much.
• Not all outages were total: sometimes performance was degraded but access was still possible. We decided to incorporate a “% degradation” parameter in the model for an outage, recognizing that deciding on that percentage would be a judgment call for any outage.
• As noted, most sites don’t count scheduled maintenance in downtime. But that’s still lost revenue. Assessing business impact requires both conservatism and full transparency. We decided to include all outages, scheduled or otherwise, when we published our outage business impact metrics.

Building the model required not just some adept spreadsheet skills, but the up-front accumulation (and regular updating) of various base data to drive the calculations.  Specifically, for each hour and day of week, we had to:

• Collect and average our aggregated historical traffic data
• Collect and average aggregated sales revenue numbers
• Determine how to calculate probable advertising revenue

Once built, our model not only let us state our downtime in terms of true business impact (i.e., total dollars for a given period), but it also provided a ready way of analyzing, up front, the specific cost of a planned outage. Using that as a tool, management could much more effectively assess alternatives and opportunity costs when system interventions to address various problems were being considered.

Here’s a snapshot of the model’s inputs (in yellow) and its outputs, slightly altered for presentation:

From here, it’s a small step to logging and tracking these total estimated costs across a given time period such as a month. (You should anticipate, by the way, that disclosure of the total dollar cost of outages will tend to invoke far more attention and commentary than the old-style percentage figure ever did!  Transparency brings scrutiny. This is a good thing.)

Yes, estimates and aggregations were necessary in coming up with these approximate costs; it’s just a model, after all, with all sorts of incorporated assumptions. And the estimates will never be utterly perfect. But still, they’ll be a far cry better at helping you express the approximate business impact of your downtime than just proudly declaring that the system was “99.83% available” last month.

Lagniappe:

• Publicly visible major SaaS system availability pages:

• • Amazon Web Services
  • Salesforce
  • OpenDNS
  • Intuit Quickbase
  • Clickability
  • Google App Engine

• Evan L. Marcus, “The myth of the nines”, September 1, 2003
• Continuity Central, “Five Nines: Chasing the Dream?”
• Paul Beckford, “Calculating Server Uptime”, February 13, 2010
• Lenny Rachitsky, “Transparent Uptime” blog
• George Ritchie, Serio Ltd, “Introducing ITIL® Availability Management”

The bear says, “You see? It really does work.  Now make yourself light again.” Whereupon the hedgehog quietly retorts, “How about you doing something once in a while?”

Midnight Train

CIO: “We can’t go live in six weeks as you want.  It’s going to take at least three months.”

CEO: “That’s … unacceptable!”

One of the most recurring memes in IT, for me, has to be hearing “we don’t like that estimate”, coming from stakeholders, senior management, etc. Depending on the mood and/or semi-intellectual rigor of the person saying it, the conversation then typically devolves into one or more of the following:

1. identifying and removing any hint of schedule contingency (which is often viewed as padding just to make life easier for IT);
2. mentioning repeatedly the idea of “what if we double the team size to get it done twice as fast” etc.;
3. conducting a scrutiny, one by one, of the bottom-up estimates (”it won’t really take three days to test that feature”);
4. volunteering resources (usually less than qualified) to “help”;
5. insisting on scheduling full-time work for all remaining weekends and holidays between now and the desired launch;
6. making frequent use of the phrase “why don’t you just …”
7. declaring that system delivery must occur by a specific date, no matter what.

A real-world micro-example of estimate pushback: one of my Twitter colleagues tweeted this a few months ago: “Me: it’s six weeks effort. Client: what can you give me in two weeks?” That was obviously tweeted in frustration, and was most likely intended to serve as an example of how incredibly unreasonable the client (or manager, or CEO, whatever) can be.

Yet, at core, and read literally, it’s a perfectly natural question coming from an executive who is looking to explore all the possibilities.  IT people need to learn to anticipate such scrutiny, and have coached and practiced enough with their own team to show that they’ve thought through some alternatives.  That’s collaboration as a key business contributor.  That’s strategy. In fact, showing that kind of maturity is what will take IT beyond being mere order-takers.

So the CIO/CTO’s role as leader here is to inculcate the following mindset in the collective team: don’t assume that these management suggestions are simply ignorant or obstinate. In fact, I’m arguing here that management reactions along these lines are understandable, though admittedly sometimes misguided and excessive.  I’ve been there: I’ve done it myself, frustrated (as an exec) by the estimates the team was telling me.  So now, instead of just getting annoyed at the upper management behaviors listed above, I see both sides.  Even better, I have some recommended behaviors that the IT team can adopt that will help in such situations.

First, and this is key, adopt the mindset that every plan needs to withstand some scrutiny. Expect scrutiny and plan how to deal with it. The answer from IT can’t be “these are our estimates, so you just have to accept them.”  Just as with making any management presentation, you need to anticipate the obvious questions, adjust your plan to accommodate them where possible, and have further answers at the ready.  It’s a back-and-forth, not a one-way. Delivery discussions need to be about ways to provide viable business value given the constraints. It’s a collaborative process, not a confrontational negotiation where one side makes demands and the other side caves in.

Second, spend some time seeing and removing your own (IT’s) flaws.  Specifically, consider flaws such as these, common reasons why estimates become regarded with skepticism once an executive drills down:

• Every task in the schedule, no matter how slight, is assigned at least a day’s worth of work in the plan. IT teams need to doggedly squeeze out the obvious air.
• Easily understandable tasks (ones that the executive has good familiarity with) are being estimated as taking much longer than they have historically. Way before it gets to an executive presentation, the team needs to challenge every number themselves so that this either doesn’t happen, or can be explained with a supportable rationale as to why things are different this time.
• More generally, there appears to be little or no historical basis or metrics used in establishing the estimates. Estimates that are based on facts and data, rather than people’s gut, are almost always more credible.
• Once the executive starts to drill, people cave immediately: “Oh, OK, I guess we could do that in a couple of days, rather than a week.”  Making this kind of admission is throwing raw meat to a hungry bear.  It shouts that your estimates probably had little basis in fact.  Or, that your emphasis on certain must-haves like integration testing isn’t so heartfelt at all.  At the very least, it reveals that you haven’t thrashed through the numbers internally well enough to be able to stand behind them with greater firmness. Believe it or not, and often with all evidence to the contrary, the executive is looking for where there’s strength of conviction, and where there isn’t. Strength of conviction (supported by facts, of course) may ultimately be disagreed with, but it’s usually respected.
• The team and/or project leader shows little or no recognition that there may need to be some kind of interim solution, some sort of early delivery. There’s no “team attitude”, no searching for midway points (i.e., acceptable scope reduction), no exploration of “what ifs”, such as “what if we delivered the system without an administration GUI at first?”  Once again, there’s no substitute for holding internal practice sessions and staging multiple “devil’s advocate” discussions.
• Conversely, there’s no clear “line in the sand” visible, meaning points you stick to no matter what, points that cannot be compromised if the company wants a quality delivery.

The very fact that these reasons for estimate-related skepticism even occur in the first place demonstrates the value-add of such skepticism. In other words, everyone needs to realize that it’s actually OK for management to ask people to dig deeper, to explore every option, because it turns out sometimes they don’t on their own.  It’s OK to be asked, and everyone should expect to be asked.  That’s part of everyone doing their jobs, and, cynicism aside, such active scrutiny is most certainly the job of senior management.

Steve McConnell, in his outstanding book on Software Estimation, writes eloquently on this issue.  He points out that executives typically have certain notable characteristics and well-honed skills.  The first two of these?  “Executives will always ask for what they want.” “Executives will always probe to get what they want if they don’t get it initially.”

Example: a developer once told me that it’d take two weeks to generate a report I needed as CIO. Taken aback, I probed into it with him.  Together we determined that the report I was asking for entailed nothing more than a rudimentary SQL SELECT statement, slightly dressed up. Every time a manager drills down into an estimate, only to discover that there was no “there there”, it feeds his or her unfortunate but lingering suspicion that most estimates are grossly padded. Getting the “win” (beating down the number) spurs them into even more dogged drill-down.

So I’m preaching a several-pronged approach:

• doing one’s homework so that maximum scrutiny has been self-applied long before the estimate reaches the executive;
• sticking to one’s guns to an extent that is both reasonable and facts-based;
• and then actively looking for ways to reach value for all.

One important note, though: there are often bad (but unfortunately common) ways to compromise when discussing project delivery estimates.  Here are a couple of important places not to cave:

• Suddenly deciding that you don’t really need contingency. Until perhaps the last week, it’s usually a huge mistake to assume that the rest of the schedule will go exactly as planned. Contingency in a schedule is not padding!
• Suddenly deciding that you don’t need thorough testing. Forgoing testing is pretty much a guaranteed way to launch an unstable, buggy product that ultimately will cost you much more work (not to mention the customer backlash) than taking the necessary time up front to shake out the problems.

Where’s the CIO/CTO in all of this? Supplying active leadership: educating everyone on the tenets above, coaching, cajoling, reminding, monitoring.  Strong leadership can and does reduce these common “we don’t like that estimate” kinds of proposed “solutions”. In fact, it is the mettle of the mature and successful CIO/CTO that they constantly “upward and sideways” manage their peers and management to get them to understand the cold harsh realities and weigh appropriate and reasonable trade-offs.

Thinking about how to prevent big system project failure has somehow always reminded me of the Will Rogers quote: “Don’t gamble; take all your savings and buy some good stock and hold it till it goes up, then sell it. If it don’t go up, don’t buy it.”

In other words, with big projects, by the time you realize it’s failed, it’s pretty much too late.  Let’s think a bit about the reasons why, and what we can do to change that.

First off, I’ve never seen a big project fail specifically because of technology. Ever. And few IT veterans will disagree with me. Instead, failures nearly always go back to poor communication, murky goals, inadequate management, or mismatched expectations.  People issues, in other words.

So much for that admittedly standard observation. But as the old saying goes, “everyone complains about the weather, but no one does anything about it.” What, then, can we actually do to mitigate project failure that occurs because of these commonplace gaps?

Of course, that’s actually a long-running theme of this blog and several other key blogs that cover similar topics. (see my Blogroll to the right of this post). Various “hot stove lessons” have taught most of us the value (indeed, necessity) of fundamental approaches and tools such as basic project management, stakeholder involvement and communication, executive sponsorship, and the like.  Those approaches provide some degree of early warning and an opportunity to regroup; they often prevent relatively minor glitches from escalating into real problems.

But it’s obvious that projects still can fail, even when they use those techniques. People, after all, are fallible, and simply embracing an approach or methodology doesn’t mean that all the right day-to-day decisions are guaranteed or that every problem is anticipated.  Once again, there are no silver bullets.

One of the problems, as I’ve pointed out before, is that it can actually be surprisingly difficult to tell, even from the inside, how well a project is going.  Project management documents can be appearing reliably,  milestones met, etc.  Everything looks smooth. Yet, it may be that the project is at increasingly large risk of failure, because you can’t address problems you haven’t identified.  This is particularly so because the umbrella concept of “failure” includes those situations where the system simply won’t be adopted and used by the target group, due to various cultural or communication factors that have little or nothing to do with technology or with those interim project milestones.

Moreover, every project has dark moments, times when things aren’t going well. People get good at shrugging those off, sometimes too good.  Since people involved in a project generally want to succeed, they unintentionally start ignoring warning signs, writing those signs off as normal, insignificant, or misleading.

I’ve been involved in any number of huge systems projects, sometimes even “death march” in nature.  In many of them, I’ve seen the following kinds of dangerous “big project psychologies” and behaviors set in:

• Wishful thinking – we’ll be able to launch on time, because we really want to
• Self-congratulation – we’ve been working awfully hard, so we must be making good progress
• Testosterone – nobody’s going to see us fail. We ROCK.
• Doom-and-gloom fatalism – we’ll just keep coming in every day and do our jobs, and what happens, happens.  (See Dilbert, virtually any strip).
• Denial – the project just seems to be going badly right now; things are really OK.
• Gridlock – the project is stuck in a kind of limbo where no one wants to make certain key decisions, perhaps because then they’ll be blamed for the failure
• Moving the goal posts – e.g., we never really intended to include reports in the system. And one week of testing will be fine; we don’t need those two weeks we planned on.

An adroit CIO, not to mention any good project leader, will of course be aware of all of these syndromes, and know when to probe, when to regroup, when to shuffle the deck.  But sometimes it’s the leaders themselves who succumb to those behaviors.  And for people on the project periphery, such as other C-level executives? It’s hard to know whom to listen to on the team, and it’s definitely dangerous to depend on overheard hallway conversations: Mary in the PMO may be a perennial optimist, Joe over in the network group a chronic Eeyore who thinks nothing will ever work, and so on.  There are few, if any, reliable harbingers of looming disaster.

Wouldn’t it be great if there were some kind of codified, external measurement/evaluation tool that could methodically identify the kinds of disconnects that even well-led projects can fall prey to? One that could pinpoint where the true risk areas are as the project evolves, and help people take targeted action ahead of time to address those problem spots?

That’s why I got so excited in a recent conversation with well-known IT failure expert Michael Krigsman, CEO of Asuret, a company that sells “technology-backed services”.  He gave me a look at their forthcoming product, an impressively slick, well-engineered tool that in my view promises to provide exactly that kind of benefit: identifying where and why a project might fail in terms of some of those people/best practices aspects, before it actually does.

In a nutshell, Asuret facilitates a cross-sectional analysis of project participants and stakeholders as the project proceeds. By aggregating the answers to its carefully crafted questions and constructing a number of easy-overview summary charts, the tool then displays astonishingly insightful visual breakdowns that let you pinpoint major disconnects, such as between stakeholder groups and IT, or between actual project-specific and industry-best practices.

Let’s look at an example of what it shows you.  By mapping aggregated analysis results onto charted dimensions of importance and vulnerability, and slicing these charts by department, you can see at a glance in the chart below that there’s a disconnect: e.g., that executives think that the business case for the project has high vulnerability, while the IT participants view it as having low vulnerability.  Early warning sign!  And certainly better (more methodical, more aggregated) than relying solely on what you’ve heard Joe grumbling about in the lunchroom.

In the example, the disconnect looms large: look at the darker circle (representing the participants’ responses to questions regarding the project’s business case) and its different location on the two grids shown below:

Figure 1

This all sounds simple in this brief description, perhaps, but taken as a whole, Asuret’s methodical implementation and targeted, useful results are nothing short of groundbreaking. Perhaps other companies provide a similar product, but I don’t know of any. And frankly, I can’t imagine a better-designed or more perfectly suited product as Asuret to address the issues raised in this post.  I’m really looking forward to hearing more as they deploy and hone their product, because I can think of any number of large projects I’ve been on where this approach would have been revealing and useful.

It’s maybe not the ever-hoped-for holy grail, but it promises to be a small piece of it: an extension of our ability to see things before they happen.  If Will Rogers had been an IT guy, I think he would have been excited too.

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

Occam’s Razor

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.