Deploying an enterprise pm system is the current hot thing – What’s more effective? Creating the perfect process then deploying across the entire enterprise in a Big Bang or phasing-in a less mature process bit-by-bit?

I find myself on the meter a lot recently.  It’s not something I’ve done for quite some time but the trend of businesses of all sizes to deploy enterprise project management systems has our staff asking me more and more to get involved in the early stages of these implementations.  In particular I often now seem to find myself working with organizations on the strategic plan for deploying an enterprise project system.

If you’re just getting started to working on an enterprise-wide pm initiative, you have lots of company.  One of the first things you’re going to have to be clear on is that most significant challenge in moving forward in the early stages is not the selection of the right tool or the adoption of the ideal pm process; it’s the understanding that what you are involved in is a significant change-management project.  While I’ve talked about this before in this column, it’s worth mentioning again I think that the culture impact of an organizational change towards management by project in a centralized fashion is no small thing.

That being said, the way most of these projects go in the early stages seems to start with the striking of a project team and asking that team to then make a plan.  The first debate is almost always when I seem to arrive and that’s on basic deployment strategies. 

People who have been around the pm game for awhile will most often want to take this golden opportunity to step back and review or even create a proper project management process.  “Tools are a secondary conversation,” they’ll say.  “Something to be chosen only after defining the process on which those tools will be applied.”

It’s hard to argue.  I’ve been in the pm software business now for almost 20 years and I’d have to say that adopting a productive pm process and then applying the right tool seems much more sensible than choosing a tool without a clear understanding of how it will be applied.

The proponents of this plan would have a committee work on developing the right process in a sort of laboratory where ideas could be worked on without affecting the projects already in production.  Once the process was finalized, the right tool would then be easier to select and the deployment would now be done in a rapid fashion, moving personnel as quickly as possible, perhaps even simultaneously into the new process and new tool as defined.

Well, as good as that sounds, there are a few inherent problems with it.  I’ve been in several organizations now watching people attempt to do this very thing and here are a few of the challenges they’re facing.

First of all, life does not occur in a laboratory.  The project personnel who are working in the front line aren’t likely to adopt something that comes out of a lab without getting buy-in themselves.  In fact, the whole idea of an enterprise pm systems scares the heck out of some of those people.

Recently while talking to a project manager in the telecom industry I asked what he thought of the changes that were reported to be coming.  “I can’t see that stuff making any difference,” he said.  “I use my own system of managing a project; I’ve had great results and I’m not likely to change the way that I manage so some suits in the head office can get reports minute by minute on what I’m doing.”

While I was at another firm, this one in the aerospace industry, the person in charge of the enterprise pm system deployment tried to explain her difficulties in getting a corporate-wide WBS adopted.  A few short questions later and it had become apparent that the scope of people involved in her quest spanned 4 divisions of the firm.  She had no one supporting the project from further up than the manager of her own division.  Personnel in the other 3 divisions, in the absence of management directives from their own managers, were being polite in listening to her but had no intentions of ever adopting her proposals.  In the meantime, the implementation of a pm tool where data could be centralized was paralyzed with the inability of the organization to get over this coding question.

One of the other phenomena I’ve noticed in these kinds of deployments is that no matter how much time the central committee spends trying to write the ideal pm process, the plan lasts until the first day of deployment.  Inevitably, as soon as the process is out in the field and seeing the use of actual personnel on actual projects, the process needs to be adjusted; sometimes completely reworked.

So, despite all the evidence from my purist sentiments that cries out to get the process right first before deploying in a big way, I’ve got to vote with the phased-in approach.

A Phased-In approach starts the actual deployment much quicker with a smaller group of people or a subset of the total number of projects.  In this scenario, the time spent on the global process is minimal.  The idea is to get a system going that looks like it will be able to handle the needs of the whole organization and start producing some benefits with it quickly.

Because the process is poorly defined in such a deployment, you’ll have some teething pains that will require more effort in the early days.  You will have to budget more time, more assistance and maybe even more money for the early adopters of the system.  But these amounts will still be a tiny fraction of the cost of adopting the entire system in a Big Bang approach.  You’ll need to pick strong early adopters because you’ll be developing the process on the fly as you work the system through the first pilot projects. 

The great news about this plan is that management can start seeing results early.  The presence of more assistance in the early days from the deployment team almost makes this a certainty and getting more management support makes a world of difference as you work through the organization deploying to more and more people.

There are decided advantages and disadvantages to each approach.  I think it’s probably true that the Big Bang approach is more likely to get closer to the initial vision of the enterprise pm system.  The phased approach has a good chance of reaching some level of organization satisfaction and thus complacency before the ultimate vision is reached.  Yet I think it’s also true that the Big Bang approach has a much more likely chance of going absolutely nowhere; stalling somewhere in the definition phase, without getting people to agree on how to move forward even to the first step.  The phased-in approach starts almost immediately and thus the company has a much higher chance of realizing some returns on the investment of time and energy that any such project involves.

Either way, remember, you’re dealing with change and change invariably causes upset even when it’s ultimately a change for the good.  Plan for that and you’ve got a good chance at making your enterprise pm system a success.

With both Microsoft and SAP taking a newfound interest in enterprise project management, an all out battle between these software behemoths seems inevitable.

There’s a battle brewing in the project management software arena and we’re just seeing the beginning of it.  Not long ago I spoke in these pages about the movement of Microsoft with Project 2002 into the enterprise project management space.  This had previously been the domain of only a select few project management software vendors who had quaintly become known as “high-end vendors”.  You know who I’m talking about; the Welcom’s, Primavera’s and Artemis’s of the world.  Well, less you were worried that Microsoft will be left an open field, there are other software giants also interested in the booming enterprise project management software market.

SAP, who’s impact on the ERP market in a relatively short time has been remarkable, has also taken aim at winning the hearts and minds of project managers everywhere.

Although the target seems the same, the approaches of these firms are quite different.

First of all, the notion of enterprise project management software is hardly new.  The very first project systems created on mainframes were directly targeted at enterprise work.  It’s true that the projects that would warrant project software in the early 70’s had to be mega projects in order to afford the software, hardware, implementation consulting and training costs required to make one of these systems work yet the analytical results went directly to management.

The increasing affordability of computing power and, in particular, the acceptance of Windows brought project management from a centrally controlled project management office to virtually anyone interested.  Even where no central project management existed, organizations could now enjoy some of the benefits of project management software because it was so easily accessible to end users. 

In the last few years, however, increasing interest in returning project data and analysis from individuals into the corporate pool has resulted in a newfound interest in centrally maintained project management.  Thus the interest in project management software that could bring these project individuals back together.

Microsoft’s latest release is directly targeted at this desire.  It’s only natural of course.  Microsoft has been amazingly successful at capturing the desktop market for project management software.  The ease-of-use in Project has made even scheduling neophytes able to develop professional looking schedules with a minimum of training.  Microsoft has been under increasing pressure for the last several years to make Project better able to deal with issues like multi-project, central resource pools, enterprise reporting and portfolio analysis.  The now almost universal use of the Internet has pushed for more collaborative functionality; all of this designed to bring project managers together. 

SAP however, has been under pressure also.  Their P/S module was designed to provide everything management would desired in project management analysis.  Fine – if you were in management.  The P/S system however, did not start out  with the end-user ease-of-use which Microsoft had so enjoyed.  The advantage of P/S, users were told, was its direct integration into all other aspects of the ERP system.  A project in P/S would typically have a tiny number of tasks – more like cost centers or cost accounts than the tasks one would think of in an end-user’s schedule.  SAP’s deployment of the system was greated with predictable results.  Financial management people seemed to like what they saw.  The system did have the high-end reports they desired.  Project schedulers and PMO’s were less happy.  Many fought to keep their existing scheduling systems.

Like Microsoft, SAP has made advances.  In this case instead of coming up from the desktop end-users towards the enterprise, SAP’s latest P/S module targets more toward the end-user.  Speaking to representatives from both firms can be fascinating.  They could share many of the same PowerPoint slides.  Both groups are directly targeting the enterprise project market and each has the advantages and disadvantages of their legacy systems.

SAP carries the stigma of being management’s system and not the system of the end-user; of the employee.  SAP must convince the end-user project managers that their tool can handle the capacity in an easy-to-user manner and they start from a reputation (whether fair or not) of being user-hostile.

Microsoft carries of stigma of not having been a serious project management tool.  Professional project managers have carried a long-standing opinion of Microsoft Project as a tool for inexperienced or unskilled project planners.  Microsoft must overcome those considerations and convince senior project personnel that they have the capabilities to handle enterprise-level use.  Microsoft must also convince management that Project is now of enterprise-level quality and can be integrated into core financial and production systems.  All of that being said, Microsoft carries the huge advantage of market penetration.  They can honestly say that they have sold more project management software than any other firm ever.  Microsoft clearly controls the desktop market.  It has become a universal axiom that virtually every major firm owns Project.  Microsoft has already won the project management market in numbers, now it will attempt to expand the influence of Project further into its clients.

Less you were worrying about all the other software vendors I’ve not named.  The initiatives of these two firms does not imply that other pm software publishers are out of business.  In fact, many will enjoy the likely spin off effects of huge interest being focused on the project management software industry.  It does mean, however, that you’re likely to see many vendors taking a more focused or niche approach to future development.  The contest of controlling the mainstream or generic project management software market has very little room for more players.

Who will win?  The jury has been barely convened and is certainly not out.  Each of these software giants have allocated tremendous resources at making this category of software key to their expansions. However, with the vast majority of end-users already using its tool, Microsoft has what must be the lesser challenge of expanding existing use rather than SAP’s challenge of expanding Financials into a new category.  

Still, just the efforts being expended in this contest is bound to have good fallout for project managers as more and more resources will focus on bringing project management to the enterprise level.

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.

It’s what everyone wants but almost no one gets: Enterprise-wide resource capacity planning.  Just what makes getting this accomplished so difficult?

I’m sure I hear it at least once a week (during a trade show, twice an hour), what organizations are asking of their project management system boils down to enterprise-wide resource capacity planning.  Now I know that everyone has a little of the “grass is greener on the other side” syndrome where you think that your organization must be the only one in Christendom who hasn’t figured this out yet but the good news for you is that you’re not alone, very few organizations really have a handle on this aspect of management.  The bad news?  You’re not alone.  Many organizations are faced with a lack of power in this area of management.  I mean if you knew that some area of the world had project environments where this was always well handled, we could send people there to see how.  They could document the way it was accomplished and we could bring the lesson back to where you live to make sure it was implemented immediately.

Unfortunately, the shear number of organizations who are asking for this solution makes it clear that most organizations have not yet resolved this issue. 

Now, hold on.  If you’re one of those firms who really have figured this out, don’t be scrambling to your email to let me know that, yes, this is working fine where you are.  I know some organizations have successfully implemented resource capacity planning.  It makes it all the most frustrating for those of us still struggling with the concept.

So what do we mean by enterprise-wide resource capacity planning anyway?  This term, while a mouthful, refers to the ability to see the resource availability and resource load of all resources in the organization and the projected load of future tasks and projects.  If you can accomplish this, then you should be able to insert a prospective project into the equation and instantly see if a) the project is feasible and b) the impact on other projects of doing the project.

Sounds simple doesn’t it?  Yes, in principle it is very straightforward.  It’s in practice that the exercise becomes a challenge.  “The technology?” you ask.  Nope.  Virtually all of the enterprise project management software vendors address this type of functionality to some degree.  The problems are rarely encountered there.  The most significant roadblocks are usually in the practices and behavior of the participants.  Here are a few areas that become a concern.

Whose resources are they anyway?

Who gets to control the resources in a multi-project environment is often one of the most contentious issues.  Many organizations use a matrix structure where any given employee will have a resource or line manager to whom he or she reports as well as multiple project managers to whom he or she will report based on project work.  A matrix organization is expected to generate some structural tension for staff as project managers vie for complete control over a person and the resource managers are expected to provide an element of balance so as not to burn every resource out on a given project.

Ok, no problem so far but this affects greatly how enterprise resource capacity planning works.  With many project managers competing for given resources, all kinds of tactics can be employed to get and keep the resources they want.  Resource managers can become just another competitor trying to get access to an employee’s time.

I’ll share if you share – maybe.

The basic premise of enterprise-wide analysis is that you’re looking at all the data.  After all, what would be the point of doing a resource plan when you’re looking at only 80% of the resource requirements and 80% of resource availability?  Especially if you didn’t know what 20% was missing.  The problem in new enterprise resource management implementations is that some project managers will be concerned that if they share their real internal data, the rest of the competitors for resources can take advantage.  For example, they might see a lull in the requirements on a given project and scoop up those key resources then not give them back in a timely manner.  If the process for this is not rigorously established (and it rarely is in new implementations), then some project managers see a huge disincentive to share.  If there is anyone who ‘opts out’ of the enterprise analysis by withholding his or her data, it can reduce the value of the entire analysis.  In a large high-tech company in Montreal, I recently challenged a group of 25 senior project managers to point to anyone else in the group with whom they shared actual project data.  0 for 25 was the result.  If people won’t share data, there won’t be any enterprise analysis.

My people are all busy beavers – honest!

In a similar vein, showing any underutilization of a resource to the rest of the project mangers can leave a project manager worried that they’ll lose that person.  Consequently, project managers who are ‘forced’ to share their data will sometimes pad a project’s requirements to show that the key resource they’ve acquired is in use 100% of the time.  There are always a few key resources in an organization that are critical to many projects.  They possess that unique combination of knowledge and skills that are at the core competency of the organization’s products and are always in high demand.  These resources can make or break a project’s schedule and often are the bottleneck that determines just how many projects can be accomplished in a given period of time.  It is, of course, these very resources that a project manager will want to get first and keep the longest.

Okay, I know I’ll be beaten, but please – not with my own data!

I’m not saying it happens where you work, but – it some places I’ve visited – there are project managers who have attempted to play fair and have given the new enterprise system complete access to their innermost honest data only to find themselves called on a carpet shortly thereafter to explain the ’significant problems’ with their project.  The evidence for these problems?  Why the project manager’s own data of course!  When a corporate culture has been used to seeing data only after careful preparation and are now plunged into seeing the raw product while it is happening, it can make managers do strange things.  If this happens once or twice, project managers will run for cover carrying their data with them.  Avoiding this requires preparing the ground in advance, talking to the management to ensure they react appropriately to the different quality of data they may now have access to.

So, is it impossible?  No – not at all.  The intense almost universal desire for enterprise capacity planning has driven software vendor after software vendor to provide better functionality to deliver this analysis.  If you are working on an enterprise-wide implementation now, the key is to not expect the software to do all the groundwork.  You’ve got a corporate culture to change and you’ll need to change it a step at a time.  Paving the way with new procedures and practices, setting up training not just for users but also for management can go a long way towards ensuring that the resource capacity planning analysis is used for the purpose it was intended and not to shoot the messenger.

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.

It’s this year’s hot topic – “Collaborative Project Management Systems” – but what exactly does it mean and how should we deal with the wave of collaborative pm software tools that are arriving on the market?

I mean it’s like saying you’re American but you just can stand for Mom or Apple Pie.  Project Management is a collaborative process so it surely goes without saying that every project manager is in favor of a collaborative project management tool. 

The problem is, that project management software vendors are in the market too and now that someone has coined the phrase, it seems that 100% of project management systems are now “collaborative” project management systems.  Just how do you go about telling one apart from another and determining what collaborative functionality is important to you?

The first thing to deal with is to take a step back from your Internet-wide search of pm collaborative tools and think for a moment about where you and your project team need to be collaborating better.  Collaboration can take a variety of forms. 

Perhaps your projects are weak in the area of informing project team members, clients or sponsors about project information such as project progress, changes in strategy or targets etc.  In this case, bulletin board type functionality or group email functionality might be important.

Perhaps you feel that a two-way feedback from team members to each other and/or to the project manager or client needs improvement.  In this case an ability to chat on-line or to see who is currently available in an instant messaging type functionality might be of interest.

Perhaps you are moving a high volume of documents back and forth throughout the group and the management of key documents is what is slowing you down.  Ok, so it’s document management functionality that you could use.

Perhaps the statusing of your project is arduous and some kind of update tool from the end users to the project system would make you more effective.  Ok, then an on-line statusing and/or timesheet system would be what to look for.

Some clients have come to me and said, “But I need all of that!” why don’t I just buy an integrated-enterprise-wide-collaborative project management system?” 

Of course in some cases we will find weaknesses in how a project organization collaborates at all and in this case all of these types of collaboration might be critical but it’s worthwhile to note that regardless of the functionality available from these collaborative tools, there is always a culture-change component to changing the way you manage your business. 

For each of the scenarios above you can easily imagine how making such functionality available could inhibit the project process. 

A wave of on-online chatting for example, with everyone talking to everyone about everything they think hour by hour with the project client joining in to experience perhaps for the first time the angst that can overwhelm a project team in mid-stream.

Or perhaps an ongoing stream of instant messaging requests that keeps a team member from having an uninterrupted thought throughout his or her day.

Changing the way we do business is something that has to take into account the shear momentum of how things are being done now.  Change causes upset.  It just does.  Even if that change is for the better.  There will be people more or less interested in change but the comfort of knowing how things are done today makes many people reluctant to abandon that method of doing business in favor of something else.

The best way to go about taking advantage of some of the new collaborative project management functionality is to start with what needs the most help.  I was recently at one of the larger pharmaceutical supply companies in North America and found to my great interest that they had done exactly that.  This firm had determined that document management was the most critical area that required improving.  With all the regulatory requirements in the pharmaceutical industry, regulatory documents must often travel across countries, time zones and endure for a remarkably long time in good condition.  Also, the security of these documents is critical to a successful regulatory ruling.  It was the project management group but what they ended up selecting after a review of a number of project-specific tools was a document management system that was not originally designed for project work at all. 

Of course that’s not for everyone and many of the project specific tools seem to be credible products but the point I’m making is that you’ve got to decide for yourself what element of your corporate culture you need to change before trying to automate it.  Once you do, you’ll need to make a plan (I know, I know, project managers hate to plan their own systems) to implement that change that includes training, evangelizing and the use of course, of the software itself.

Services are a key factor in the success of pm software vendors.  With the trend towards certification how will clients know who has the skills they require?

I thought I’d spend some time talking about one of the most significant elements of technology deployment in the project management sector – services.  In numerous project management software vendors, the revenue from services outweighs the revenue from software sales.  Perhaps that’s a good thing.  After all, as I’ve said in these pages more than once, the difficulties in implementing enterprise pm software almost always has more to do with culture change than with feature implementation.

In virtually every enterprise-level implementation of project management software, a significant level of consulting-type services is required.  In some organizations, the skills to implement the selected system is available internally but in many cases, organizations look outside of themselves to find these skills.  The requirements can be extensive.  A consultant for the implementation of a project management system requires skills in: business analysis, project management methodology, technology, finance, human resources and, of course the product or products being implemented.  These skills are rarely all found in a single person so you’re looking at a collection of resources required in order to successfully implement the project system in question.

Just as with any human resources search, one of the first questions to be asked deals with the qualifications of the consultant whether he be internal or external and herein lies a problem.

There really isn’t a hard and fast qualification that ensures that you have found the right person.  It’s not to say that there are no qualification measures around. In fact, there are perhaps too many.

We should start, of course with PMI.  The PMP certification is certainly gaining popularity in North America and even overseas but what exactly does it mean when you’ve got your PMP certification?  Well, that you passed the exam, of course, and that you were able to identify sufficient proof of project management experience in terms of points to qualify.  Yet, there are many people who have passed their PMP who do not feel qualified to manage a significant project.  Even for those who do feel confident enough to manage a project, having the PMP certification does not necessarily mean that they have any knowledge of enterprise project systems.  The other skills we mentioned above, business analysis, for example, might be completely absent in someone who had passed their PMP.

Ok then, what other standards are there?  ISO has the 10006 standard and you’ll find elements of project management in the 9000 and 14000 standards.  Yet, the ISO registration is not an individual qualification.  Being ISO registered indicates that you have established a stable process.  That’s great but doesn’t indicate how to select the proper resources to implement project management software.

There are other courses of study.  Many universities are now giving courses in project management.  I’ve sent several of my own staff on such courses to ensure that they understand the basic building blocks of the industry.  On occasion I’ve been fortunate enough to even lecture such students.  Yet, it is clear from just speaking to these students that their training in university alone does not prepare them for implementing project systems.

Many product vendors in the project management software industry have certification programs for the consultants who train and install their products.  Choosing one of these people is a good bet that they know the product being implemented and how to train you to use the features in it.  The problem is that such consultants are often light on the other perhaps more significant skills such as business analysis or HR.

Knowing just about the product itself or just about project management theory isn’t enough.  There has to be some perspective on the big picture.  Some firms have gone to the specialists in business re-engineering, the big accounting/consulting firms.  Companies like EDS and Deloitte and KPMG are providing consultants with strengths in business analysis and finance but who are not as strong in project management methodologies.

And if that all wasn’t enough, we’re about to have yet another certification to deal with.  As we told you in these pages last fall, Microsoft is working on extending the reach of Microsoft Project into the enterprise project management systems arena following its acquisition of Enterprise Project from eLabor.  Microsoft’s Project team is a small, tight group and, if they had to follow the model of the other enterprise-level project vendors, they would have to expand instantly by as much as 10,000% in order to provide the after-sales services that enterprise-level purchasers of pm tools require and expect.

Microsoft is, instead, turning to its 3^rd party solution providers, offering training and some level of certification in order to help interested clients determine the qualifications of the implementers.  With a focus on enterprise sales, 3^rd party consultants for Project will need to spend more time and energy on project management process and methodology than has been the case thus far.

That Microsoft will be turning out “Microsoft Certified Project Solution Provider” experts isn’t huge news in itself.  The issue is the huge volume of MS Project users and the rush of newfound “experts” that this volume will attract.  Last year Microsoft sold millions of copies of MS Project, soaking up over 80% of the established project management software market.  Consultants who are attracted to the format will become more and more plentiful as time goes on.  The sheer weight of the numbers of consultants in products like MS Project threatens to overwhelm the numbers of more experienced project managers who one might find in an association like the PMI.

For clients looking to bring in outside assistance, the plethora of certification programs now emerging has the potential to become more of a hindrance than a benefit.  Certainly any client looking to bring in experts from the outside would be well advised to spend the time required on due diligence of the experts’ credentials.  References of successfully completed projects will carry more weight than certification at least for the near future.

For those of us in associations like PMI however, the opportunity to be a leader in the field is significant.  Perhaps we’ll see closer ties between the methodology aspect of PMI and the technical aspects of the tools available to project managers over the coming months and years.  Perhaps it’s an opportunity for strategic alliances in the future to ensure that the skills and lessons learned by project management professionals over time aren’t lost in the drive for easy to use project management tools.

Critical Path Methodology has formed the heart of most of today’s modern project scheduling systems.  Is it time for something new?

 Many of us remember what it was like; Aerospace and Defense were spending money on a scale never before seen in peacetime.  Construction and infrastructure projects were beyond comprehension in their scope and vision.  It started in the 50’s and lasted until the end of the 80’s.  It was the era of the mega project.  It started with a post-war world and saw us through the cold war and the placing of a man on the moon and the birth of the modern computer.  It saw power projects that harnessed rivers and atoms and for project management as a discipline, it was a time of coming of age.

Project management has been around of course as long as there have been projects.  The Pharoses used some kind of project management on the creation of the pyramids and I’m sure every great project has seen some kind of management since the dawn of time.  But never before in the history of the world have so many great projects happened simultaneously.  No, history will record the birth of the discipline of project management in the middle of the last century – circa 1950.

The birth of CPM
For those of us who were able to work on some of those mega projects, you can remember how they were organized;  First of all, there were lots of activities.  I mean lots.  There were effectively unlimited resources.  Those resources were expected to work across multiple years to accomplish their task.  Time was the only constraint and the pressure to finish early, finish on time, not to be late drove everything.  If you were in aerospace it was the “space race”.  If you were in Defense, it was the “arms race”.  If you were building infrastructure to accommodate the new world it was about finishing fast enough to just keep up with demand. 

It was into this world that Critical Path Methodology was born.  It was miraculous.  For the first time, we could look at a project and know just what tasks we had to focus on in order to avoid delaying the project.  We learned about forward and backward passes and early vs. late dates.  There were variants and innovative displays.  Gantt had his bar chart and the US navy came up with PERT.  It was all designed to focus on one thing – “Don’t be late.”

Early computerized CPM systems
The application of computers to this calculation methodology was a natural.  With all the calculations to do, it seems obvious.  In fact, as computers have evolved, one of the first business applications to appear in each new iteration has been a project management system.  Computers were tailor made to handle the arduous yet clearly defined calculations, enabling project teams to adjust their forecasts as fast as events occurred.

Yet these systems were created in the world of the time.  Project Management Systems they were called and, indeed, they were in the project management category but what we all knew we meant was that these were CPM scheduling systems.

Those first systems didn’t look much like the graphical, easy-to-use systems of today.  The earliest systems on mainframes and mini-computers were originally loaded with punch cards.  Even once “on-line” systems became available they looked more like an airlines reservation system than today’s point-and-click.  The fundamental algorithm though of those original scheduling systems is essentially unchanged over the years.  Even as systems became available on PCs they showed the bias of the times.  Early project scheduling systems didn’t do resource leveling.  It was a later invention.  In fact, with some systems, the resource calculator was sold separately as an add-on.  Resource-limited scheduling?  It was an afterthought.  Remember, resources on a mega project were essentially considered unlimited.  There was no thought of scheduling all the way down to the individual level.  Resources were considered at best as disciplines or categories.  Graphical reports were considered a luxury that not everyone wanted or needed (Can anyone say “Primavision”?).  These days we talk about resource calendars and split activities but there was nothing like that in the thinking of the time.  I remember the first system I worked with having 8 calendars – Whatever would I do with all those calendars? I wondered.  Baseline changes were also something not originally conceived.  No one much cared how the mega project had originally been planned.  All that counted was when it would be finished.

The PC-based software that got its start in the early 80’s is still very much a part of today’s market.  And, while those products have advanced with the times, for those of us who have seen those products since their first versions, we can see the traces of their original design.

Yes, it was a different time but the software we see today had its start there and for the most part, the changes we’ve seen over years in that software have been an evolving theme rather than a re-thinking for the times. 

Welcome to a new world
The world that project managers face today is a far cry from that of the 50’s through 90’s.  It is a function of today’s economy.  Today’s MTV generation lives in a world where 10 year long projects are remarkable exceptions.  Where an individual is more likely to be working on multiple projects at one time – even multiple projects in a single day.  It is the world where time to market, shorter run times, design/build, RAD (Rapid Application Development) rule – and it is skewing everything we know about project management.

While the world was changing for project managers, the world of computers was changing too.  We tend to think a lot about the impact of Windows on the current landscape and of course with that thought about Microsoft must come a thought about MS Project but when you look at the core, the most significant changes in project management products have been interface-driven.  After all that was Windows’ claim to fame.  It made the PC interface so easy that a whole new category of user was able to adopt it and become proficient with must less training.  Changes in project management software have been focused on these areas.  On-line tutorials, user-friendliness, flashy, sexy, fun to use software make for more sales.  Yet, the basic concept of the vast majority of these products continues to be based around the old CPM model.

Microsoft tried to break out of the model a couple of years ago.  There’s a famous (infamous?) white paper written by someone at Microsoft from a few years ago describing how MS Project version 3 “de-emphasized” the CPM model.  It may be true, but if you do a calculation of schedule in MS Project, guess what algorithm is used.  No – at its heart MS Project is still a CPM product.

Sure, there have been plenty of additions and enhancements in all of the project management products popular today.  Some of them are remarkable.  Projects can now be huge and many high-end tools do multi-project scheduling.  Forget about 8 calendars and a single baseline – “unlimited” is the latest limit described by almost all PM software vendors on such functions.  There are hierarchical resources and integrated costing functions and risk analysis and so on and so on.  It’s remarkable but at its heart, most of these systems are still built around that original CPM algorithm. 

The CPM algorithm requires a few key elements in order to automatically calculate a schedule: It requires a list of tasks.  For each task, a duration or a method of calculating the duration must be given.  If there is a logical sequence to the tasks, this must also be defined and, given this information, a CPM calculation can tell you the earliest feasible date each task can start (and finish) and the latest date it can start (and finish) without delaying the project as a whole.  Resources may be defined along the way but basically the resource calculation is laid on top of the CPM dates and scheduled from there.

It sounds fine but remember the algorithm was designed in a period where the only driving criteria was “don’t be late”.

“And now, for something completely different”
Imagine a world where the driving criteria for successfully completing a project is the availability of highly skilled individuals.  A world where even the technology a project is based on will change multiple times over the life of the project.  (Sound familiar?)

I question whether the Critical Path Methodology algorithm is a useful method of analysis for many of today’s projects (Wait.  If you’re one of those Critical Chain advocates – please don’t be writing me explaining how different it is – I don’t believe that’s the answer either.)

In a world where skilled individual resources move from project to project over a period of hours – perhaps we need a whole new way of thinking about project management software.  It would have to be a completely new paradigm.  Something starting not with a list of tasks perhaps but with the capabilities of the resources and technology available to us.  Perhaps the projects and tasks one commits to and the schedule that becomes possible should be driven around available technology capacity and skills rather than the other way around.

There is a great focus at the moment on the Internet and the Web and how marvelous it is to be able to work across a world-wide network.  The focus is all too much on the interface for my tastes.  It makes for sexy press and I’m sure I’ll end up being a user or proponent of some of these systems.  I don’t doubt that there is merit in many of them; but it is a variant on a theme.  Being able to look at the same old paradigm in a web-browser is not a shift in thinking no matter how many new people will play with it because it is simpler to use. 

There is room in the project management software market I think; room for some innovation; room for something completely different.

There are a couple of firms, some new and some old who are touching on some of these new areas.  Some of these solutions are innovative but many were not ready for prime time.  I’ll be looking for developments from these firms throughout the year to see if they can get over the initial teething stages and get something into the market that addresses the new world we’re working in. One thing for sure, when there is a need in the marketplace, someone will find a way to fill it.  When I find some answers, I’ll let you know.