A couple of years ago there was a brief flurry of product announcements of new software systems which would seamlessly (don’t you love that word?) marry the functionality of traditional project management systems with every employee’s To-Do list. The products (including one from Microsoft itself) were short lived and we’ve not seen their like since. Recently however, I’ve noticed a number of requests for such functionality returning and thought it might be worthwhile to take a moment to give the idea of such systems a reality check.
First of all, let’s get a basic definition sorted out. When people refer to “project management systems” they are typically referring to project scheduling systems such as Microsoft Project, Primavera etc. It’s true that these products are in the project management category but it’s a little unfair to consider the functionality they deliver to be a complete answer to all project management issues. After all, there are many other elements to project management than just the schedule. Contract management for example is a huge component of any project management environment as is team management, communications, client meetings and so on.
Still, the first software ever delivered for project managers was scheduling software and so long as we keep straight what it can and can’t do, it’s not too harmful to call it project management software.
Virtually all of the scheduling software on the market today is based on a type of calculation designed about 50 years ago and honed over the years by various project management practitioners. It’s called the Critical Path Method or CPM for short. I won’t bore you with the textbook details but suffice it to say that the purpose of CPM is to determine the shortest period possible for the project to be completed in. There are also a range of other algorithms which could be considered but this is the predominant calculation used for all major scheduling tools on the market today.
Combined with the Critical Path calculation is usually some kind of resource leveling calculation which identifies where you may be short of resources or what the schedule impact would be of not hiring additional resources.
Ok, so what does this have to do with the price of eggs? Only this: These algorithms were designed for mega projects years ago when the notion of a project was hundreds or more likely thousands of workers in a few identifiable categories working on thousands of tasks over years of a project. There are even textbooks of the era that suggest that the minimum duration of a task should be measured in weeks or months rather than days or hours.
Why is this a problem? Two reasons: First, the world has changed and is changing faster and faster as time goes on. Projects are typically much shorter. The era of the mega project if not gone is in hiding. Project management is no longer the purvue of only the large defense/aerospace or huge construction organization. Now everyone would like to do it. Not only that, but the amount of disposable time available to everyone is much less than in times gone by. Managing your to-do list in your Day-timer is now mandatory to get through your day.
Secondly, it pegs existing project management software into one category: Analysis. No matter which way you turn, no matter how user friendly the next version of Microsoft Project or any other vendor, in the end scheduling software is designed to perform and display the results of a calculation. This is fine if you accept the software for what it is; take your results and then go off to make your own decisions. This only becomes a problem when we take the results of a complicated analysis and try to marry it with an action-item system.
You may be seeing the problem by now. When we take the results from a scheduling system and try to use them to determine tomorrow’s to-do list, we skip the “eyeball” analysis which comes from every supervisor who, in his or her head, analyses a thousand minute variables before tasking employees with a particular piece of work.
For example, it may make perfect sense to a scheduling system that in a given week Mary should do the analysis on project 1, then move to project 2 and work on the documentation there, then move back to project 1 and finish off some testing. But a supervisor may elect to have Mary finish project 1 in its entirety because the dynamics of pulling her off the project team prematurely may upset everyone on the team. This kind of human element is impossible to design into an algorithm but may be perfectly obvious to everyone involved.
If you’re reading this, thinking you’ve just invented the human factor algorithm and if I just knew about it, everything would be fine, hold that thought. A much more significant factor is something I call ‘level of resolution’. A scheduling system has a perspective of weeks or months or even years in creating the schedule. Can you imagine filling in your agenda for a task to do 2 years from now? It would seem nonsensical, yet that is essentially what a scheduling system does when it does resource scheduling.
The reason that no one puts it into your agenda is that the likelihood of that task actually happening on that day 2 years from now is extremely low. Even when we take a one week perspective your agenda won’t hold up. Don’t think so? Let’s take a show of hands. Put up your hand if you worked on something today that wasn’t on your to-do list when you started today. Look around. See a lot of hands in the air? Me too.
It’s an insidious issue though because the data sure looks the same between both types of systems. We can match due dates, descriptions, resource requirements, almost everything together… The problem is level-of-resolution. The data just doesn’t belong together.
Still, waiting for the magic solution? Sorry, this time there’s not one to be had. I believe that we’ll see a new paradigm of project management systems in the next couple of years which take a view other than just algorithmic or at the very least, move on beyond the Critical Path Methodology calculation to something which is designed for today’s kind of projects. Perhaps then we’ll see systems which can move into the level of daily to-do list from the level of project without incident.
Until then there’s still a lesson to be learned here which is universal. If you are looking to integrate systems together, you’ve got to do more than map the common fields in the separate databases. You’ve got to look at the data in its own context and see if it fits.
– – –
