72762531I hear it all the time, at least a couple of times a week, “We’d like an Enterprise Project Management System.” Given that I spend a lot of my time speaking with project personnel in Fortune 1000 companies it’s pretty clear that this desire for a global perspective on project management is almost universally desirable. It’s easy to see why any executive would be keen for such a system. The new economy has dictated a movement away from large mega-projects with their attendant Project Management Offices where project management would be easy to manage from the top down. What today’s business world favors is a large number of smaller, more maneuverable projects, each controlled by small number of employees and often sharing resources with many other projects. It’s highly effective from a communications, motivation and flexibility point of view (that’s what is critical in today’s fast-paced economy) but it’s a killer to manage from an executive perspective.

Well, with all this desire for an enterprise system, it’s no surprise to find that virtually every project management system on the market is suited for “enterprise-wide” use. At least that’s what they say on the box. The funny thing is, this demand for centralized access to project information was not created last week. It’s been with us since the early 90’s at least. There are a number of project management products which really can lay claim to enterprise-wide functionality yet, week after week, companies ask me if there’s any hope of them actually finding one they can implement successfully. The disconnect between happy enterprises and the number of products which claim to be able to make them happy has to make you wonder.

The problem certainly isn’t that all software publishers are liars (although I’m not promising that we’re not) or that all project management products really don’t have enterprise-oriented functionality or that there are no differences between these products. I review project management software all the time, and there really are some differentiators which would make some more suited for enterprise use than others.

Most project management systems can now be implemented with a client/server database as their repository. I think this ability is critical to having any chance of bringing enterprise project data together. This was once the purview of only the largest, most complex systems but it’s now almost universally available. Systems which had this enterprise architecture used to be difficult to use and thus difficult to deploy across the enterprise but Microsoft’s standards for ease of use have changed that for everyone. Desktop planning systems like Microsoft project are the most widely distributed project management tools in the marketplace. It is now almost a given that every company will have Microsoft Project somewhere in their office.

So what’s the problem? We’ve got database connectivity, ease of use; that’s it then isn’t it? Well no, unfortunately it’s not. The problem with bringing these users together is more fundamental than a database selection or ease of use. A visit I paid this week to one of the world’s largest insurance companies exemplifies the point. This company has over 2,000 project managers spread across the enterprise. Some of them are working within business units which have chosen a particular project management tool, some are working in a more independent fashion. There are thousands of copies of MS Project in the office, it is the most widely held project management tool and yet virtually every day, someone in the company is lobbying for why the company should accept the product they’re using as a corporate standard. With all the users to be wooed, project management vendors swarm the reception desk on a regular basis with their latest wares, upgrades and offers. The company has now determined that despite having some very skilled project managers, that the company executive is handicapped by not being able to report on all project work at once or to be able to influence the project process by injecting management perspective data such as project priorities. Management has now allocated a significant budget to resolving the problem and so possible alternatives are being considered.

Proposed solutions come in a variety of formats. There are still the venerable project management firms now with new updated products. These companies have the most years of experience with implementing systems across the enterprise from the early project management software days when an enterprise often referred to a mega project. There are tools which claim they will automatically deliver an enterprise wide system because they are so easy to use that everyone will adopt them. The problem is that while ease of use may guarantee the widest deployment, being compliant does not make you integrated. Finally, there are add-on or layered products trying to bridge functionality. Their pitch goes like this; “Keep your Microsoft Projects. We’ll operate as a layer underneath them automatically imposing the centralized standards that are essential to delivering an enterprise system.” It’s this latest group that has the most insidious approach and it’s that group of products that I was asked about this week at the insurance company.

I had for my friends some bad news though. There is no easy path between an independent desktop planning system and centralized control I told them not matter how important management decides that is. The problem isn’t technical. Technical solutions for bridging these kinds of products have been around for a long time. The problem is cultural.

When you ask management what it is they mean by an enterprise system, the answers are almost always the same. They would like to bring project data together into one source in order to do reporting and analysis across the enterprise. When you ask individual project managers why they insist on sticking with a desktop planning system, their answers are also universal. They want ease-of-use and an ability to manipulate the data quickly on their desks to reflect what they want to track today.

These goals are almost certain to be in conflict. In order to be able to gather data together and analyze and report on it, we need to impose some standards. For example, I can’t use the code ME to refer to Mike Edwards, Mechanical Engineer and Maintenance Engineer (i.e. Janitor) in three different projects if that data will one day be brought together. If I do, Mike, the engineers and the janitors will all make up the same histogram bar in a resource analysis – it won’t make sense. If I want to bring this data together, I need to impose controls across the company.

The bad news is that the degree to which I need to impose those controls is the degree to which end users will wish to abandon use of the product. It goes directly against the maneuverability that attracted them to their favorite tools in the first place.

So, is there hope? Of course. I’m often caught quoting Napoleon Bonaparte with my favorite project management quote, “A battle plan lasts until contact with the enemy.” I’m sure however, that Bonaparte didn’t mean that we shouldn’t plan.

My advice for the insurance company was to reset its goals. Think process, not product is my suggestion. If you need to impose standards, impose the very fewest that you can think of. Don’t stress over getting every minute change in a resource plan to reflect into a top-level project resource analysis. Work instead on the broad strokes; project management training, project reporting standards and good planning practices and let the managers manage.