Deployability: A key to enterprise project management systems

 7253069Every year I spend days in project management software exhibition halls, so you’ll forgive me I hope for harping on what has become a bit of a cliché in our industry.  You know the one I’m talking about – Enterprise Project Management Software.  It must be the hangover from the ERP implementation craze from years ago because it seems that every software system available to mankind today is “Enterprise”-something.  Vendors seem to all be either selling an enterprise-wide system or they’re selling how to implement it. 

I’ve had literally dozens of attendees ask me questions on what “Enterprise” project management system would be the best.  Almost every product on display has the word Enterprise in its description somewhere but when I’ve asked what about their product made it “Enterprise” enabled, the exhibitors were hard pressed to find a good response.  At the Microsoft booth, a new Microsoft employee asked me if I didn’t think that Microsoft 2000 wasn’t more of an “Enterprise” product.   Even our own firm is touting its’ Enterprise timekeeping system.  Frankly I’m getting a little tired of it.

It’s not that I have anything against Enterprise products.  After all, as I mentioned, we do publish one.  It’s the notion that every project management software tool is an appropriate product to be deployed across the enterprise that has me annoyed.  When I travel to different parts of the world I have the privilege of meeting people who manage some of the largest organizations and some of the largest projects in the world.  For the last 30+ years that I’ve been in this business, an enterprise-wide-work-for-everyone-universal project management system has been like the Holy Grail.  It’s almost universally desired by management as a panacea for everything you don’t like about the project management business.

“If only we had an enterprise project management system where all the data was centralized, I’d be able to see exactly who is available at any time of the day,” say some.

“Ah, if only we had an enterprise project management system, we’d be able to see our project status in real-time,” say others.

“But if we only had an enterprise project management system, everything would be on-time and on-budget,” think the rest.

What kind of system would it be?

Ok, you may not be that shallow, but think about how great it would be if all project management data from projects done in your organization over the last 10 years was in a centralized database in a format that you could immediately access, that you could see trends and averages in at any time.  Sound attractive?  How about this, imagine that all project managers who are managing projects that have any impact of any kind on either the scope, resources, or schedule of your own projects are using a project management system that automatically ties in with your own and shows the impact as soon as they know about it.

What very few people spend time thinking about is what implications are involved in actually deploying such a system. 

First of all, what kind of system would it have to be?  We’d need a system that was:

  1. Capable of storing data in some centralized format such as a client/server database,
  2. easy enough to use in order to be accepted by the huge numbers of part-time users who would have access to the system and;
  3. robust enough in its functionality in order to handle the kind of complex analysis that is bound to come from managing large amounts of diverse data.

Next, we’d need to tackle the process.  If you’ve been working on this at all, you’ve no doubt come up against this issue in a big way.  The process by which all the data will be collected, entered, analyzed and distributed through such a system has to be walked through over and over and over again from the perspectives of everyone involved in the process just to make sure data can make it through the system.

Finally, there’s the matter of how it’s deployed at all.  It’s often a case of the shoemaker’s children who go barefoot when it comes to deploying a project management system.  There’s almost never a project management plan for it!

And just what do you mean by an Enterprise Project Management System?

Let’s look at these one at a time.  First with regards to the products themselves.  There’s no point in naming names.  (Please don’t be calling me to ask if I think that “Product A” or “Brand X” is really an enterprise product – the whole point of this is to let you figure out for yourself what’s important.  First of all you’ve got to look at the kind of product you’re looking for.  As I answered to someone today when they asked which was the best enterprise project management product, “What are you thinking of when you ask for an enterprise product?” 

If an enterprise product means simply something that will be used by the enterprise in the widest possible distribution, then looking at an of the easy-to-use desktop products is your best bet.  Make sure you narrow down your search.  Is it scheduling, resource allocation, document management, timekeeping or what that you’re hoping to implement?

If you’re looking more for a system that can be used centrally by a small team of professionals (such as in a project office) to manage all projects in the enterprise, then you’d do best to start your search among the high-end pm systems which were originally designed around mega project environments.

You may rather be looking for a product which will be widely distributed but will maintain all its data in some central repository for reporting purposes.  In this case, your search is not in vain but will take a little more work.  You’ll still need to concentrate on the ease-of-use of the interface such as in a desktop tool but one of your basic requirements will be data storage.  It shouldn’t take long to come up with a short list.

 

All these three definitions can be deployed with fairly low stress.  It’s the fourth one that causes grief.

 

If what you mean by enterprise project management software is an environment where the software is widely deployed and where project decisions are taken at different levels of the organization (e.g. resource availability decided centrally, but resource allocation decided locally) and where there are numerous levels of responsibility for data (e.g. the individual project managers manage their own small project but the global impact of all projects is the responsibility of someone at a higher level in the organization and/or if you are talking in terms like multi-project resource leveling, multi-project analysis, hierarchical project groupings and so on…  If you mean something like that, then you’ve got a much tougher challenge.  This kind of product is one which will almost certainly have to come in parts.  There’s got to be some part of the system that is designed to be used by the project office type of project manager.  There’ll need to be a completely distinct interface for end-users who will have only occasional access to the system.  There’s got to be robust reporting, flexible data structures and much, much more.

Getting started
There are a couple of such product combinations on the market today and while theoretically any of them might work, ensuring that the product combination you select can actually be deployed is the next challenge.  You should be able to get your short list figured out very quickly and once you do, here’s the hoop you should be making your project management software vendor jump through:  Have them describe to you (in terms even your management will understand) the process by which data will move through their system.  Be wary of cheap demonstrations.  It’s not difficult to create a demo that gives the simulation of the system working while obscuring key difficulties in making it work. 

 

A couple of years ago, I watched an organization struggle with a matrix organization problem.  They had divided their project data into individual sub-projects where no sub-project had more than one resource grouping in it or more than one project-phase.  This was so they could group it in one direction for the resource managers and in the other direction for project managers so that each type of manager could manipulate the data within their area of responsibility.  It had taken the organization months to divide up their data this way and they were abjectly miserable.  No surprise.  No one had ever questioned how each type of manager with their own distinct and often conflicting responsibilities would be able to access and manipulate the project data.  No one had used up some inexpensive white board space to map out the flow of data like a process.  The organization’s still struggling with the concept.

 

Now, I know I’ve said this before, but here it is again:  You’ve got to consider how you’re going to deal with the deployment of your chosen system(s).  If the system you’ve chosen can only deliver its first results once it has been adopted by 100% of the organization, then you’re in for some bad news.  In the majority of cases, project management software implementation projects that are designed as an all-or-nothing approach, deliver nothing.  It can’t be much of a surprise.  The cultural impact of trying to get everyone in an organization to change from anything to anything else at the same time is horrendous.  Look for the small victories.  Make sure that you’re going to be able to get some value out of the product while it’s being deployed.  It’s true that there’s a good chance that you won’t have 100% deployment but the good news is that your system will be delivering some value to the organization even if you don’t.

 

Finally, work on breaking the trend of not using what you know on your own projects.  The best advice I can give you on how to be successful in implementing an enterprise project management system is to use all the project management techniques while doing so.  Almost everywhere I go, I find virtually no project management being applied to the project on implementing project management software.  Be the first.  Break the trend!