When project management software is presented by their vendors these days, we tend to hear the ‘core’ subjects: critical scheduling, portfolio analysis, resource capacity planning, risk analysis, inter-project reporting and so on.  If you’ve not been in one of these demonstrations before, you’re missing something.  They’re a sight to behold.  The software sits up on its hind legs, barks and then runs out to get you a cappuccino.  Ok, maybe not quite.  But these enterprise project management system presentations are pretty impressive.

I’ve been in the background of preparing such demonstrations and I can tell you that an enormous amount of work goes into them.  It’s easily understood.  The software vendor doesn’t want to show what the software will look like when it’s delivered, they want to show what it will look like after it’s been adopted, used, updated, personalized and is delivering the great results the client is hoping for.  To be fair, that’s what the prospective client wants to see too.  They want to see a finished product looking like it would if they had completed their implementation.

To prepare such demonstrations an entire fictitious organization must be created.  It’s not enough just to imagine some tasks because, just like a real organization, all kinds of data must relate to all kinds of other data and this means assembling a story.  Once the story is written, the data must be created to match it and then installation and configuration of the software has to happen.  There are also reports, views, filters, and such to be created so that the prospective clients can see how everything fits together.

I bring all this up because what often happens during these presentations is that the prospective client gets very excited about the delivery of a solution that will solve all their problems; the “silver bullet” solution (of Lone Ranger fame) which will always reach its target no matter how far or how small.

The truth is, some of these answers are hard to come by.  I’ve found over the years that the most requested solution by organizations seeking an enterprise project management solution is “Resource Capacity Planning”.  This is unfortunately the first thing (and sometimes the only thing) they ask for and it’s almost always the last thing I can deliver.  It’s not that I’m being difficult, but creating a resource capacity planning solution implies a lot of underlying assumptions to be resolved.  First, you must have 100% of the resource availability. Next, you must have 100% of the resource load which must be organized by task.  These two items are just the collection of the base data required for a resource capacity analysis.  These items alone are so daunting for most organizations that just overcoming the cultural challenges required to get all the data will overwhelm the project.  If we overcome these, we’re still not done.  We need a prioritization process that identifies which work should get first access to restricted resources.  We need a process that will have everyone update the resource availability and requirements on a normalized basis.  We need analysis and reports that make sense of what may be an enormous volume of data.  We need metrics to determine what the reports mean and finally an action plan which fits into our process to take the appropriate action where the metrics indicate.

Whew!  I know… It’s daunting, isn’t it?

In a mid-sized organization, delivering this kind of EPM solution can take up to two years or more.  Some results can be produced much faster but there are some much more interesting aspects to software deployment in the enterprise project management context when we look outside of the core project scheduling functionality. 

First of all, there is a huge range of online training in soft skills.  You can take courses in leadership, negotiation, assertiveness, communications and dozens of other subjects.

If we take a look at communications for a moment, the whole domain of online collaboration is a huge area of benefit.  You can use Microsoft’s Windows SharePoint Services to create online portals for project work.  Windows SharePoint Services is included as part of Windows Server and includes the ability to create event lists, lists of contacts, tasks, file sharing, document management and more.  If you’d rather not install software, you can look at services like Google Groups.  On Google, you can create a private group for your project team and store up to 100MB of files, start discussions, make announcements and share information no matter where people log in from.  You can tie Google Groups with Google Documents and Google Calendars to share a wider range of information.  If the group is small, the functionality may suit you rather well and you can’t beat the price.  It’s free.

If you’d prefer to do something a little more involve, there are a number of content management systems such as PostNuke, Joomla, Drupal, DotNetNuke, and DotProject.net.  These sytems can be installed or hosted almost anywhere and provide a rich environment for creating a communication and collaboration environment.  Data of almost any kind can be stored and, when it’s your own system, you can tweak it and customize it and even add on to it to your heart’s content.

For some the key is managing documents and there are a number of solutions for this challenge as well.  If the requirement is for a small team, both Google Documents and Google Groups offer a lot of functionality for no cost.  If you’re keen to go a little deeper and host the solution locally, you can do basic document management with Windows SharePoint Services.

There are also a number of free document management systems (dms) available for download which include a much richer level of document management functionality.  Examples would be OpenDocMan, Epiware (who also includes tasks and a Gantt chart!) or DocumentManagementSystem (on www.SourceForge.net) .

If what you really need is a centralized location where all your research can be compiled and added to and updated by different team members, then creating your own Wiki is the way to go.  Made famous by the Wikipedia folks, you can install your own Wiki software.  There are dozens of free versions.  Just search for “Free Wiki Software” to see the most current.

These aspects of your project management environment may seem like “ancillary” functionality but make no mistake about the potential for these aspects to deliver a tremendous impact.  Implementing an effective communications process where there was none can seem like the difference between night and day. Introducing a collaborative commitment tracking system can deliver instant focus to a team that might not be co-located. 

One of the most powerful things about these aspects of the enterprise project management environment is that it can be very, very fast to deploy compared, say, to resource capacity planning.

We’ve talked a range of alternative software systems for working on aspects of your project management environment that are outside the core scheduling capabilities but of course much of this kind of functionality can also be found woven within the major enterprise project management systems on the market today.  If you’re evaluating whether to use these commercial systems to work on these other aspects of the project management environment, then make sure the benefits of these areas can be delivered without first getting all the core scheduling organized as part of the same exercise.  Some EPM systems are schedule-centric.  They were designed around the notion that the schedule would be the key element around which all other data and all other functionality would be tied.  No centralized scheduling for these systems means no centralized anything.

There are many paths to delivering effectiveness in your project management environment.  You don’t have to settle for the most obvious.  With so many different tools and services available immediately, it is within your power to make an impact in a very short amount of time.

Here’s a number that I heard recently that, although it didn’t surprise me, is a shocking number to deal with.  It turns out that there are an estimated 40 million people on the planet who use Excel for project management.  As a percentage of the total number of people who must use PCs it’s probably not a huge number but as a percentage of the total number of dedicated project management applications sold, it makes Excel the most popular project management product on the market today.  You have to wonder what the attraction is.

When you look at project management packages in the market it becomes apparent quite quickly that they are feature-rich and require some level of expertise to take advantage of.  How many of us are using less than 25% of the functionality of our pm software?  Have pm software vendors missed the mark?  Are packages like Microsoft Project too complicated to be successful?

Not that long ago, pm software vendors used to think that the fundamental problem in the market was lack of training.  If only end-users were intelligent enough to understand what we could do for them, they’d surely implement an integrated high-end system.  Training, we all thought, was the best answer.  The market taught us differently.  It turned out that users didn’t want to be trained to use more complicated systems; they wanted systems that were easier.

The first wave of this has really reached its maturity level.  The domination of Microsoft Project as a desktop tool was largely successful because of how quickly end-users could produce their first results with the product. 

The next wave of pm software is underway.  Now, enterprise systems from numerous vendors are splitting the end user experience between a fully functional desktop tool and a much, much easier to use web-based interface.  It’s true that these systems involve more work to deploy but the end-results can be in an organization which must manage multiple projects with numerous resources  The newfound interest in the Project Management Maturity Model lends itself perfectly to these systems as the model is all about moving from ad-hoc project management to an integrated process.

But this leaves out the 40 million people using Excel.  There’s still a huge market for project managers who are most effective when working in an ad-hoc manner and have no desire to operate in an integrated view.  While meeting with Fujitsu Consulting last week, one of their managers coined the term “Agile” project management.  I very much like the concept.  There is no doubt a significant market for a project system that is even simpler than Microsoft Project Standard.  It would have to be low-cost, stunningly easy to use would have to be able to go from insert disk to useful output in a period measured in minutes, not weeks.  I know there are already products trying to target this market (Milestone comes to mind.) but these 40 million+ users are still not finding something that makes a sensible return on investment for them and I’m sure we’ll be seeing more attacks on this end of the market over the next year or two.

Now, lest someone worry that I’ve given up on my long-standing interest in enterprise project management, fear not.  But I’ve always believed that systems should serve a purpose and this category of ad-hoc project management is still not being adequately served.  Enterprise project management and moving to an integrated system only makes sense if it returns sufficient value on the investment of time and effort to deploy it.

I was asked lately how to find the great reports and dashboards that Microsoft shows in its sales demonstrations.  Happily, Microsoft makes those example files available online for anyone who has Project Server 2007.  The reports are based on Microsoft SQL Reporting Services which has a wide range of reporting functionality.  You could, for example, create reports which are scheduled to leave the report file in a particular area and then automatically send an email notification to someone that it’s ready to be viewed.  The files are best looked at as examples of how to get SQL Reporting Services reports into Project Server 2007 and how to connect those reports to the Project Server 2007 Reporting Database.

You can see the links to these files on the new Download Tools Page.

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.

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.