Project Management Institute


a key to enterprise project management


by Chris Vandersluis, Contributing Editor

I’VE SPENT THE LAST 24 hours in a project management software exhibition hall here in Toronto, Canada, 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 holdover from the ERP implementation craze that was the hallmark of the turn of the millennium or something because it seems that every software system available to mankind today is “enterprise” something. Vendors are either selling an enterprisewide system, or they're selling how to implement it.

I had literally dozens of attendees ask me questions on what enterprise project management system would be the best. Almost every product on display had the word “enterprise” in its description somewhere, but when I asked what about their products made them 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 produce 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 17 years or so that I've been in this business, an enterprisewide-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.


Chris Vandersluis ( is president and co-founder of HMS Software, based in Montreal, Canada. He is a member of PMI and the American Association of Cost Engineers. He has appeared in publications such as Fortune and Heavy Construction News, and is a regular columnist for Computing Canada magazine's project management column. Comments on this column should be directed to

“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 so you could see trends and averages 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 are the implications 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 capable of storing data in some centralized format such as a client/server database; easy enough for the huge number of part-time users with system access to use; robust enough in its functionality to handle the 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. When it comes to deploying a project management system, it's often a case of the shoemaker's children who go barefoot. 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 regard to the products themselves: You've got to start by deciding what kind of product you're looking for. (There's no point in naming names, so please don't call 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.) As I answered today when someone 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 simply means something that will be used by the enterprise in the widest possible distribution, then looking at an easy-to-use desktop product is your best bet. Make sure you narrow your search. Is it scheduling, resource allocation, document management, timekeeping, or something else 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 project management systems, which were originally designed around mega-project environments.

You may instead be looking for a product that 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.

These three definitions can be deployed with fairly low stress. It's the fourth one that causes grief.

When you talk about enterprise project management software, do you mean an environment where the software is widely deployed, and where project decisions are made at different organizational levels (resource availability decided centrally, but resource allocation decided locally), and where there are numerous data responsibility levels (individual project managers manage their own small projects, but the global impact of all projects is the responsibility of someone at a higher level in the organization)? Do you use terms like multiproject resource leveling, multiproject analysis, hierarchical project groupings, and so on? If you mean something like that, you've got a much tougher challenge. This kind of product is one that 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.

It's not that I have anything against enterprise products. … It's the notion that every project management software tool is an appropriate product to be deployed across the enterprise that has me annoyed.

Getting Started. There are a couple such product combinations on the market today and, theoretically, any of them might work. The next challenge is ensuring that the product combination you select can actually be deployed. 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 vendors 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 a company struggle with a matrix organization problem. The firm had divided its project data into individual subprojects where no subproject had more than one resource grouping in it or more than one project phase. This was so the company 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 individual areas of responsibility. It had taken the organization months to divide its data this way, and everyone was miserable. No surprise. No one had ever questioned how each type of manager with his or her 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 is 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 deliver its first results only after it has been adopted by 100 percent of the organization, you're in for some bad news. In the majority of cases, project management software implementation projects that are designed as all-or-nothing approaches 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 percent deployment, but the good news is that your system will be delivering some value to the organization even if you don't have that 100 percent.

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 of implementing project management software. Be the first. Break the trend! ■

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network July 2000



Related Content