Should you implement an integrated project management system across the enterprise or go with the best of breed?  Does this mean the enterprise pm model all over?

It’s not a new topic.  The idea of integrated enterprise-wide systems has persevered since long before the term ERP was coined.  Management must have some genetic memory of times when companies were all small enough that the patriarch who would manage them would know everything about everything going on in their shop. 

Business has moved on from that comfort level and now, even in mid-sized firms, project activity tends to move so quickly that it is difficult for anyone to keep up with developments across a myriad number of projects.

The desire for an enterprise-wide project management is almost universal now.  Management perceives that having the data for every project in a single database managed in one way would provide almost real-time knowledge. 

The big ERP vendors noticed this of course.  There seemed to be nothing more compelling to senior management types than the idea that all data in the organization would be linked from one spot.  From a project that seemed delayed, a manager would be able to see a range of perspectives, showing the impact on production, on inventory, on profits, on hiring, on resource availability and on the capacity to take on more work.  Marketing would be able to determine at a glance the delivery dates for existing clients and the capacity to do work for prospective clients.

Not just the ERP vendors but just about every project management vendor has a demonstration talking about this subject and the demo data is persuasive.

Well, if this is the case, why hasn’t virtually everyone switched to some centralized ERP structure?  What props sales of products like Microsoft Project?  Why do third-party software vendors who offer only one or a few aspects of this total solution continue to thrive? 

The answer is simple but disturbing.  First of all, it has become glaringly obvious to those who have selected corporate-wide ERP-type solutions that it is very difficult to be everything to everybody.  Getting compliance up and down an organization is tougher than just instructing people to comply.  Although management is often sold on the corporate-wide system concept, the middle-managers who are actually generating the work and the data that drive the company can often show that they can be productive only when they can use tools that are suited to the particular purpose. 

Project management has many facets and one type of tool isn’t often suited to take care of all of them. 

Imagine an organization where some project management occurs at the strategic level, looking forward in global terms to the kinds of projects the company should consider working on.  In this same company,  the IT department does its own project management, supporting resource-centric management of huge numbers of projects.  Yet another group in the same company is doing shutdown management of the plant – creating a 5-6 day project where the opportunity cost of the shutdown can exceed $100,000 per hour of lost production.  Nothing counts here but the schedule – how quickly can the plant be up and running.

Could one product support all these projects into one database?  Maybe – but should it?  The data is so different, that merging it together even at a summary level makes almost no sense.  This holds true not just for a single company with diverse scheduling needs but for all kinds of firms in different industries.

No surprise then that even the largest ERP vendors are trying hard to verticalize their markets.  No longer the omnibus project solution, partners like SAP and Oracle at the high-end and Microsoft at the low-end are finding a new, hot interest in partnering with smaller players.  Software publishers of everything from document management to timesheets are linking up with much bigger partners to provide a more rounded project management solution.  This is being fueled in part by a newfound interest in the large enterprise software vendors in the project management marketplace.  Microsoft’s latest entry, Project 2002 Server coupled with Project Professional has moved it up a level into the enterprise pm space from its huge desktop presence.  SAP’s latest version of PS, has it moving off of a strictly cost-oriented project perspective down into more of a project scheduling perspective. 

This has many players moving into more and more niche markets.  Market software vendors who have been around for years find themselves working back into vertical markets even when they have been trying to diversify.  They’re back in aerospace, or back in construction, or back in engineering – selling tools and services in areas they know best and linking those tools to other aspects of a total solution.

It brings us back to an age-old conversation – should you choose best-of-breed software or an integrated solution? 

The attraction to an integrated solution seems obvious at first glance.  There is one vendor, all data is tied together in one convenient location and can be maintained and analyzed at one time.

As we’ve said in this column before however, getting that data out of the system in real terms isn’t always so easy.  There can be many barriers to completing the deployment of an integrated project solution.  The easy ones are technical, getting the database and network to cooperate.  The tough ones are often the cultural barriers to having all data in one place managed in one way.  Not everyone will share accurate data when it’s to be managed centrally and the resulting structure is almost certain to be less effective than linking multiple systems.

It is these cultural corporate barriers that foster a best-of-breed solution.  Department or division level managers are willing to cooperate if they buy-in to the tools selected.  Tools chosen by people close to the actual work are almost always better suited to their purpose.  Determining how the data from these tools will integrate to the corporate systems could be more productive than spending time trying to convince these managers and their staff to adopt centralized software which is not perfectly tuned to their needs.

Project Management tools are fundamentally either analysis based or commitment based.  Which one is right for you?

When we talk about Project Management Systems, it used to be that we were only talking about Critical Path Methodology Programs.  These are programs, which are primarily scheduling tools.  These days, we could be talking about any number of categories of software in the project management arena. 

I’ll not start trying to mention all the different categories of tools that are referred to as project management software but attendees at the annual PMI Symposium can get a feel for the diversity from the plethora of vendors in the exhibit area.

If we are talking about project planning or the management of a project that is underway, pm tools are going to fall into one of two major categories.  

Analysis tools
The first includes all analysis tools.  This includes most of the popular planning and scheduling systems that can be found on virtually every project manager’s desktop around the world.  Analysis tools such as CPM schedulers can be very important.  We need very little information to make their analysis engines work.  Fundamentally a task identifier, a duration and a logical sequence are enough to get a critical path schedule showing the earliest and latest dates when tasks will logically occur without affecting the targeted end date.

As important as this is, it is key to remember that this method of planning was designed over 50 years ago specifically for projects that were huge, where there was only one of them at a time and where resources were considered to be unlimited.  It goes without saying that most project environments now are not like that.

Still, it is no doubt important to see what the logical sequence of events should be regardless of how many projects are involved and, perhaps when many project depend on each other for resources or through interdependencies, then the logical sequence of tasks becomes even more important and certainly the calculated analysis of the schedule becomes key.

Commitment tools
It’s perhaps a strange term for a category of project management tool and I don’t know of anyone else using it but the category is real enough.  Imagine that instead of analyzing when a task should happen, you simply commit to doing something.  An agenda is a commitment tool.  Even if you are only making promises to yourself, you have made a commitment.  You enter something you promise to do and when it’s due to be completed.  If the promise involves someone else, you usually mark that down too.  Adding an issue to an issue management system, is using a commitment tool. 

Ok, you say, but I don’t use the analysis feature of my scheduling package, I simply drag the activity bar to its desired location, isn’t it now a commitment tool?  No. You are using a tool, which has as its core design feature an analysis engine and you are trying to use that tool to track commitments.  The problem is, unlike your agenda or, better yet, a project issue manager; an analytical tool is not designed to track your promises and your success or failure to meet them.  Don’t believe me?  Trying changing the status date or time now for a project in most schedulers and watch the bars magically move forward to today, thus changing your promise automatically.

There are many project management tools on the market now, which are not analysis oriented, and they are finding an important niche in a wide range of organizations.

Can’t I have both?
But can’t you use both types at once?  Can’t you mix commitments and analysis at the same time into one tool?

A number of vendors are trying but the mixture of these two types of data has the potential for enormous mischief.  The problem is that the data looks almost identical.  If a scheduling algorithm shows a task identifier, a description and some dates, how does one tell that from a task that has been promised for that date regardless of whether the analyzer says so or not?  Yes, you can mix data from different systems, but trying to mix data from an analysis engine all the way down to your daily agenda is rarely successful.  Software has been made to try it before from the largest vendors around and while it can work technically, the data doesn’t hold well together practically.

So what should I choose?
You shouldn’t be faced with a huge choice her to abandon one tool type or another.  While the data doesn’t merge together well for practical purposes, you can still get tremendous benefits from seeing and using both when used distinctly.  The trend in new tools is definitely away from analytical tools and more towards commitment based systems.  In order to be efficient, you’ve just got to make sure you interact with each type appropriately.

Everyone seems to be talking about enterprise project management software.  Chris Vandersluis takes a look at a key element of an implementation plan for enterprise-wide pm software.

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 hangover 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 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 17 years or so 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:

• a) capable of storing data in some centralized format such as a client/server database.
• b) easy enough to use in order to be accepted by the huge numbers of part-time users who would have access to the system
• c) 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!

Article: Batteries not included
When people used to buy large-scale project management systems, buying the training was just part of the cost of doing business.  The cost of training compared to the cost of the software was a fraction.  You might spend only 10% of your software investment on training of your personnel on the proper use of the project managemnet system.  As project system have become cheaper the percentage people expect to pay on training has stayed the same but it buys much less training.  This article looks on the phenomena I call “Batteries not included.
Read more…

Article: EPM and tools for everyone
There are so many tools that can be applied to the project management paradigm that you’ve probably got several on your desktop right now that you’ve never considered.  We’ll take a look at a few options in this article.