What Does It Take To Get Some Really Useful PM Software?

Project management and software should be one of those intersections that represents a marriage made in heaven. There are lots of details to manage, lots of math to calculate and lots of facts to keep in one place, so software seems like it should be a no-brainer. To judge from the number of software vendors that exist in the project management ‘space’, you would have to assume that on some level that is actually true. Yet the sad reality is that today, after doing what I do for more than 25 years, I’m no closer to saying that there is a really amazing, incredibly valuable, indispensable project management software package that I simply can’t do without.

Actually, I’m no closer to being able to manage better with software than I can on paper. According to a couple of respected consultants that I know (who admittedly belong to an older generation that came of age before software was actually really popular) that’s a really good test of whether or not you’re a good project manager. In their eyes, if you can manage on paper then you know your stuff and can probably graduate to software. Even if you accept that view, slightly patronizing as it is, it doesn’t solve the problem of what software you might actually want to graduate to.

From where I sit today, I’ve had the opportunity to explore virtually every project management software solution in the marketplace at some level of detail. Some I’ve reviewed, others I’ve used to manage projects and a select few I’ve actually doled out hard-earned cash to buy. I’d love to say that for the today’s project manager there are a host of capable, robust applications to use in managing projects. Unfortunately, I’d be lying if I did.

Of course, the first thing we need to do is get to the bottom of what we mean by ‘project management software’. The software part is easy enough to figure out, of course. It’s the bit about project management that is more complicated. By far, the most common flavour of such software is focussed on schedule management more than it is project management. It lets the project manager define activities, establish dependencies, assign resources and print out lots of brightly coloured pictures of what their project looks like. Different flavours focus on project tracking, on earned value management, on contract management or on the prioritization and monitoring of portfolios. Others focus purely on collaboration, communication and document management. Heading down the food chain, there are a number of products whose sole function is the creation of a pretty picture: they enable let you build a Gantt chart, while having only the most rudimentary information to do so.

So what’s a project manager to do? With so many options in the marketplace, how do you decide what’s good and what’s not? How do you navigate the promises of software vendors to know what you should be looking for, and how do you decide what will actually work for you? And when you get to the organizational level, what needs to happen to get the payoff that enterprise project management software promises? How do you cut through the hype and figure out what is actually going to work?

The first and most critical step, and this is true of buying any software solution, is actually knowing what problem you are trying to solve. Part of the challenge of selecting reasonable project management software is that there are truly a plethora of offerings, and they do so many very different things. The solution to manage project schedules is going to be very different from what is required to support team collaboration, tracking budgets, sharing documents, ensuring quality or managing the development of project management deliverables.

The second step, and possible the harder one, is finding a solution that actually does what you want. You can be clear about requirements, and you can be thrilled and excited by the documentation that promises you will never experience another sleepless night looking after your project. Caveat emptor still applies: believe those claims only when you see them play out in a way that actually works for you. Don’t be sucked in by brochure-ware that says what the software is supposed to do; conduct the investigation necessary to understand how the software works, and to evaluate whether its expectations align with what you need from an automated solution.

The final step, and the one where most individuals and particularly organizations fall down, is establishing the procedures and protocols for how you are going to use the software. This is what graphic designers call ‘establishing a workflow’ – knowing what to do when, and seamlessly tying together your personal process with the capabilities of the tool. There are a couple of pre-requisites here: we need software that works the way it is supposed to, and we need to be clear about our own process of how we manage (which is the point that my crustier colleagues were trying to make when they said you should be able to manage on paper before you use software). Unfortunately, both are challenges for their own reasons.

I’m not going to get into a critique of all software packages on the market, but the general statement that many of them are flawed is both true and likely to generate a number of indignant emails. Protests aside, this doesn’t change the reality: today’s software is built based upon some pretty strange assumptions. Whether it’s an organization implementing the project management module of SAP or Oracle Financials, or an IT department trying to implement Planview, or a project manager trying to use Microsoft Project, the first question that has to be asked is ‘what were they thinking when they built this?’ That’s not to say that the developers were incompetent; literally, though, they may have had something else in mind from what you think to be reasonable or appropriate.

A recent example is a customer that had, on the whole, a very reasonable request. They have an incredibly expensive piece of equipment that is used in the manufacture of high technology products. Given the costs involved and the challenge of meeting customer demands, they endeavour to keep this operating as much as possible – literally around the clock. Given that the resource is available 24/7, they need a schedule to reflect that reality. Sounds simple, but in a product like Microsoft Project that’s a harder problem to solve than you might imagine. The basic setup of the resource is simple enough: assign the resource to a 24-hour calendar, and then assign effort in hours. Three days use of the equipment should require 72 hours of effort. Define this in Microsoft Project (any version, it doesn’t matter) and you’ll have an activity that starts on April 1, finishes on April 3 and uses 24 hours a day. The duration, however, will be 9 days.

The inherent problem is that while start and finished dates are calculated based upon the resource allocation, the actual duration is determined based upon the number of hours per day defined in the software options. While duration would seemingly be best calculated by subtracting the start date from the finish date of an activity, Project doesn’t do that. And there is no way short of writing a macro in Visual Basic to make it do that. Don’t believe me? Send me an email, and I’ll send you the sample that proves it. And while I’m highlighting Project, it’s not to unfairly pick on Microsoft: they just happen to have the greatest market share of any stand-alone scheduling software.

The second prerequisite is how we actually use the software. While many of us develop our own processes, habits and conventions for using software, once we take it to an enterprise level a number of other problems emerge. The goal of enterprise software is relatively clear: shared understanding of schedules, work and resources. Once multiple projects are tied together, but are managed by different project managers, the challenge comes from knowing what information is accurate and current, what information is still being defined and developed and what information is out of date.

Unless we apply the same rigour to project management software that we do to accounting, for example, enterprise software will always be mistrusted. Virtually every enterprise project management software implementation of which I am aware has foundered – at least initially – because of this. One implementation of an enterprise scheduling package (and I had many examples to choose from) ran headlong into problems because project managers were expected to define dependencies and resource allocations, and the staff assigned to activities were expected to report their time to the same software. While this is entirely the point of using such software, the consequences were that this reporting resulted in activity changes. As one person indicated that they hadn’t done all the work they had expected to, or that completing an activity would take longer than originally planned, the end date of the activity became delayed. That delay impacted other activities, both in its own project and in others. Schedules started to move (as you would expect) and the project managers panicked because they no longer indicated the dates that they felt were ‘right’. The end result was that they stripped out the dependencies and resources, and every single activity was fixed in time – simply so the schedule wouldn’t move. This didn’t change reality, however; it only changed the representation of reality that the schedule was supposed to provide.

The point of this column isn’t to dismiss the software that exists on the marketplace out of hand, or to say that it is all inadequate. I do, however, want to highlight the challenges associated with selecting and using a software package to manage a project. Software is built on a variety of assumptions, and we need to understand what those assumptions are. We need to work around them in defining how we use the software. Once collaboration across multiple projects and project managers occurs, we need to be extremely clear on how the software is to be used and the techniques that we apply. Failure to do so results in a complex, cumbersome and expensive mess that doesn’t reflect reality. If our software doesn’t reflect the reality of the projects, then we aren’t going to use it. If we aren’t going to use it, then we’re back to using the piece of paper that we started on. At least it represents technology that we all understand.

Leave a Comment