I’ve been very encouraged in recent months at all the organizations that I’ve come into contact with that are making a real attempt at multi-project management.  It’s no surprise that enterprise-wide project management is a hot button right now.  The economy is tight and virtually everyone is trying to do more with less.  Also, the nature of business these days is that multiple projects are the norm rather than the exception.  With resources being commonly restricted (I mean no one has a complete spare project team just standing by in their offices, waiting for you to pick a project so they can start doing something), enterprise resource capacity planning has become the universal holy grail.

Despite these significant efforts in many major companies around the world, I’ve been asked more and more lately how to handle one of the most delicate aspects of multi-project management: prioritizing the projects.

In a lecture I gave recently I was speaking about the challenges of creating a centralized project management office only to be stopped cold by a comment from the floor.  “We’ve done all that,” said one CIO of a large Canadian company you’d recognize if I mentioned it.  “We’ve successfully created an enterprise project environment, loaded the data and now have produced enterprise resource-capacity planning reports for 3 months.  The challenge we have is that when we send the list of projects to management to prioritize, they all come back ‘Priority 1’”.

He’s not alone.  In working with companies from all over the world this year, I hear this comment has become all too frequently.  Is it surprising?  Not really.

There are several issues with this aspect of enterprise project management.  First of all, who wants to have the job of informing a senior manager that their project has now been designated as a lower priority?  Not me.  Not anyone, really.  So, as a consequence, when the issue comes up, there are few volunteers in the project team keen to tackle the challenge with management.  It’s easier in some ways just to keep going.

Next, there are plenty of disincentives for management to not elect their project to be anything but the highest priority.  Just like the challenge for project managers who contend for resources, the person who says their project is anything but the top priority is guaranteeing it will be delayed or even late.

When there’s a client involved, the conversation is even lest attractive.  Now, selecting a project for a drop in priority means contacting the client and dealing with a delay.  The impact may have legal implications and who wants to be bearer of that news?

Marketing will have a hand in things too in many organizations.  There is nothing with such high priority as your next client and a project for tomorrow’s client always seems more important to marketing than yesterday’s news.

When project managers go to management with their corporate-wide data and explain that there are only so many factors to manage and either the amount of work, the number of resources or the schedule has to give, the most common response is: “Well, we can’t hire staff – hiring freeze.  We can’t delay the schedules, everyone is counting on us to deliver on time and we can’t change the workload, those are our contracts.  You’ll just have to have your people work harder.”

For some managers, no presentation of empirical data seems to make any difference.  The consequence is that all projects are rated highest priority and everyone suffers.

Is there a solution?  Of course.  The secret to implementing culture change at this high a level of the organization is to be patient.  Starting with presenting some VP a list of projects and a red pencil isn’t going to be productive.  A better place to start is by outlining the problem to management without asking at first for a solution.  By highlighting the lack of project prioritization and the resources now being spent on what must be low-priority tasks, you may find a friendlier face for accepting an enterprise system in the first place.  Then, while working on the implementation of an enterprise system, start working on training exectuvies in the prioritization process.  Expect that in most cases, it won’t be complete in a couple of hours.

A skilled project manager will be able to paint a picture for management which first of all, shows that not making a priority decision is, in fact, a decision.  Also, the theoretical impact of project prioritization can be made to look very attractive.  Just about every project management software vendor has a demonstration which shows the impact of multi-project prioritization – it’s a key selling features for almost everyone.  This kind of demonstration can be part of your executive training and key to making the point that sooner or later, someone will have to deal with this decision.

Once you’ve got the ball rolling, implementing a new process without looking at real data is probably easier.  You’ll need to deal with ho to assess a project and some measures for setting a project priority which is just a subjective feeling.

Some key indicators for each project, which you might consider in your own process, are: the length of time project has already been underway; the amount of money spent on the project to date; the project performance in terms of cost and schedule variance; project return on investment to the organization once the project is complete; legal implications of delay; categorizing work into bill-for and internal; risk assessment of the ongoing project work and; the impact on other projects. 

Get the process documented and get the various managers to agree to it altogether.  It’s important to get agreement across the board because if one senior executive won’t play, then the incentive for everyone else to do the same will become astronomical.  There’s still going to have to some handholding when you get that first enterprise project list to deal with, but at least you’ll have paved the way.  If you can get buy-in for the basic process from senior management, you’re well on your way for that final stage in enterprise project management.  If not, you’ll still get benefits but the primary purpose of the system is likely to be thwarted.

I’ve had the opportunity lately to do some actual in-the-field consulting, something I thoroughly enjoy.  This year I’ve been able to work with quite a number of clients on a much broader-based enterprise-wide project management environment.

It brings me back to my roots but I’ve also come across a phenomena that is very new to me but that I would have never predicted 25 years ago as I was getting into the project management software industry.  As we’ve worked on all the aspects of implementing a corporate-wide project management system lately, a surprising obstacle has been the professional-level full-time project planners. 

This is a bit of a shock for me since these are the people who I know best.  In the early 80’s when companies were moving from mainframe-based project systems down to PC-based systems and companies who could have never afforded a mainframe system were looking at project management software for the first time, full time project managers and project planners were our client.  They had the knowledge and skill required to take project data and move it into a project management system.  These people were usually co-located in a project management office of some kind.  When it came to establishing a corporate process that includes project management, the professional project managers were always involved.  They were, after all, the very kind of people who had helped develop standards like the Project Management Institute’s “PM Body of Knowledge” (PMBOK).

So, why on earth would I consider anyone in this category as an obstacle?  These are often the same people who are the driving force behind a movement to enterprise-wide project management.

The problem stems from the very thing that makes these people such a key resource – their experience.  Professional Planner have, almost by definition, been at this for a long time.  They’ve had to invent, establish and maintain project standards even when no one else in the company was interested.  When projects had to be managed, these people had to do so centrally.  The idea of an enterprise-wide project management system was very attractive to them – almost a holy grail of sorts.  The idea was that individuals would be able to access a central system and update it with all manner of data in a variety of categories.  Having access to this data in a more timely and (more importantly) easier to gather manner was highly desirable. 

Ok, now fast forward to today.  Project Management has entered the lexicon of every business school in the world.  If you have no understanding of project management as a manager, you’re in big trouble.  The old-school planners should be tickled – right?  Well, no.  They have suffered an increasing irritation of people entering their domain who don’t think of projects the same way.  The ERP contingent has been thinking of projects from a primarily corporate financial perspective!  The desktop planning contingent (can you spell Microsoft?) have permeated the market with easy to use planning software so easy to get going that anyone who can type with one finger can generate a professional-looking schedule.  To these people anything is a project!  The IT people have even taken an interest in the subject, daring to think of themselves as project managers.  Terrible!

So, now management expresses a desire to move to enterprise-wide project management as a discipline.  The old-school professional planners are, of course, included in the conversation because they know more about project management methodology than anyone.  I get called because of our long-standing experience with implementing enterprise project management and, guess what?  The pro’s are finding themselves not in charge of the implementation but only one of several categories of users in the conversation.  They have become the clients rather than the internal consultants. 

It’s natural, of course, if you want to work across the entire enterprise, you can no longer think of only the professionals, the one of a thousand people who use project software 8 hours a day.  You must think of everyone involved in the project management process.  This includes the professionals, of course.  But it also includes executives, resource managers, team members, even clients, sponsors, suppliers or anyone else who forms a part of the project.  When you really think of the implications of implementing across the entire enterprise, you’ve got to think of everyone.

When you’re implementing coordinated project management across the entire enterprise, everyone involved wants to ensure that they’re particular concerns are met.  The team members who might use the system only a few minutes a day want to be sure it’s not a burden and not too complicated.  The pro’s want to know they can get access to the data and perform all manners of analysis.  The executives want access to better decision-making.  Resource managers need to know they can see the load on their people and forecast future requirement adequately.  Finally, the IT department (aside from their own project management requests of course) need to make sure that whatever is implemented will not require excessive support or be too much of a burden on the network.

To make this work, virtually everyone will have to compromise a little.  Just getting along with everyone else is often a challenge, never mind having to find a common way of working on something as critical as project management.  Yes, sadly, that means everyone – including the professional project managers.  They may find some of the analysis that was so important to them when they worked alone something that they need to sacrifice.  I was debating this with someone recently.  “How will the resource algorithm work in this particular tool?” She asked.   My response surprised her. “What difference does it make?” I said.  “If you can get all the project data into one place, managed by one system, reported on together, you’ll be so far ahead of what you’re doing now that the analysis you’re speaking of will pale in comparison.”

It brings me back to the fundamental challenge in any enterprise project management implementation and that’s compliance.  The tools, process, strategy and culture have all got to promote working together or none of the technology will have the chance to make any difference.

I’ve been in a lot of corporate meetings lately discussing various aspects of delivering an “integrated” project management environment.  Don’t get me wrong, a corporate-wide integrated system is a wonderful thing to desire.  There’s no doubt that the idea of pushing a button on a screen and finding that every element of data across the company is tied to every other element in just such a way that the answers I desire are immediately available in every detail seems fabulous.

The delivery of such wonders, however, usually requires a little more thinking.  As you might imagine in the project management world, it is often a combination of tools that deliver the total functionality desired.  I know, I know.  Many ERP vendors have done a fine job not only in selling the idea that one tool delivers all solutions but in advancing their solutions to have their software actually do so.  The problem comes when deployment starts and in the field we discover a need for other tools to become a part of the “integrated” solution.  Often a scheduling tool such as Microsoft Project or Primavera will be part of the conversation; sometimes it’s a specialized tool for managing costs or risk or issue tracking. 

In every one of the cases I’ve come across in the past few months, all the vendors involved have been quick to point out how their tools are linked to whatever ERP or Finance system is in question.  Unfortunately it’s not always so easy.  Everyone is telling the truth of course.  The links being described or even demonstrated do work.  The issue is that they work in the demonstrations based on a range of assumptions that are not always made clear. 

It’s a truism that systems can only integrate at the lowest common denominator, but for some reason, that is not obvious to everyone who works on integration projects.  Recently, for example, I was asked to describe how the data from a high-level costing module of an ERP would move its data to the more detailed database of the scheduling tool.  The tools had been selected long ago and there was no problem with either.  During the deployment, the Finance group had worked on the configuration and deployment of the ERP system and the Project group had worked on their scheduling tool.  The decisions of each group on the configuration of the data were valid and justified.  The problem was, they weren’t coordinated.

For the desired system to work, the company would have had to managed data in the ERP at the same level that scheduling was doing.  This involved tens of thousands of tasks and hundreds of projects.  In theory, Finances system had the capacity.  In practice, it was unwilling to manage at that level of detail.  The result?  Data could be consolidated and rolled up from the project system but could not be “de-constructed” and moved down from Finance. 

For any integrated implementation it’s crucial to look at how systems and their data must be configured in order to integrate at a later date.  There are often trade-offs and compromises to make that are easier to do the earlier you make them.  Remember, just knowing that a link between systems exists makes systems integrateable.  It doesn’t mean yours are going to integrate unless you follow all the unspoken assumptions.

Are you baselining?  I know, it sounds like some drug-related crime, doesn’t it?  It’s actually one of the most fundamental aspects of modern project management and a stunning percentage of project managers don’t do it.  So this month I thought I’d dedicate the column to the elusive art of baselining.

So, what’s a baseline?

First of all, what is a baseline?  Everyone agrees it’s a snapshot of your project which is frozen now for use as a comparison later but consensus ends there.  A snapshot… of what?   What does the snapshot contain?  If it’s changeable is it really a baseline?  All sorts of questions arise when we introduce the concept.

The most common kind of baseline is for the project schedule.  Most project management tools include the ability to save the start and finish dates of each task into something called a baseline.  Ok, we’re just into the schedule so far, but which start and finish dates are we talking about?  The early dates? The late dates? The resource-scheduled dates? The constraint dates? The critical-chain late dates? Target dates that have been contractually agreed upon?

It’s enough to give you a headache, isn’t it.

The short answer is, it depends on how you want to manage your project.  The most common dates that would be saved in a scheduling tool would be the early dates.  But, if you’re doing resource-constrained schedules, then the resource-scheduled dates makes the most sense.  If you need to do reporting to a client, then a target date will be more attractive.  In short, you’ve got to decide before you start what you’d like to use as the basis for comparison. 

Now, we’ve just talked about baselining the schedule but there are some organizations that will also baseline the costs.  They will do planned vs. actual expeditures.  Or, you can baseline the cash flow as you might for an Earned Value project in the defence sector or you can baseline the resource assignments vs. the resource usage showing how close your original plan was in the way you consumed your resources or you can baseline the risk for each task.

The point of all of this is to have something against which you can compare later.

Can you change it?
People who just get started with baselines often think of them as an inviolate set of records and that’s only partly accurate.  What happens if a new task is added to the project?  Should it be baselined?  The obvious answer is, of “course” but here’s a harder question: What if adding that new task means that other tasks will now not be able to meet their original baseline?  Should you be allowed to change the baseline on those tasks in order to avoid a task variance that’s sure to ensue when you only think about the original work?

It is very common in many project environments to have an authorized change of scope in mid-project.  Even when the project is for an external client it isn’t uncommon for a client to ask for the project to change.  So, what do we do with the baseline not only for the new tasks but also for the tasks which may be affected by the change?  Most project management tools allow you to create a baseline only for certain tasks or to track multiple baselines.

If you are‘re-baselining’ in mid-project, then there are a couple of principles to think about.  First, what will you do with existing tasks that have actual results?  Will you use the actual as the baseline or keep the original baseline to compare later?  Next, you want to be sure that the original, original baseline is maintained for comparison later.  No matter how many ‘approved’ changes there are, it’s certain that one day down the road, someone will want to compare the completed plan with the original intent.  By the same token you want to be able to identify each authorized change in scope separately.  When management asks ‘what was the original plan of just the new scope?’ you want to be able to answer. 

Finally, the process by which someone gets to change or create a new baseline should be understood by everyone.  I can still remember one of my first clients who explained their re-baselining process.  “Whenever we’re more than 10% variant, we rebaseline,” the project manager explained to my incredulous ears.  Sure enough, while I was working at this company, senior management from the head office asked to see the current plan for a 4-year old project’s “original-original” baseline.  The original plan had been $400,000 and the current plan was well over $4,000,000.  It had creeped up a few thousand at a time every couple of months until it reached the current staggering number.  The project was cancelled a day or two later.

Doesn’t everyone already do this?
There is a surprisingly high percentage of users who never baseline their project.  They make a plan and then adjust and update the plan according to changing conditions.  What they can’t do is compare the current plan to the original.  There are many project management environments where the idea of comparing against the original plan is very unattractive because the corporate culture is to not be managed at all.  Now, no one admits to that being the reason.  Instead you get something like “We’re a design-build company so we are always changing the scope” or “The project moves too quickly to stop and take a baseline” or “It takes too much work to keep up with the variances in the project and it’s just a distraction”.   Whatever the reason, without a baseline, these organizations are unable to compare their original project plan with how it ultimately turned out and so measuring project performance is close to impossible.  These organizations will often have a recurring problem with projects enduring scope creep and missed deadlines and budgets.

Ok, I’ve got a baseline… now what?
The whole point of doing baselines is to compare them against the current plan later.  Regardless of whether you’re comparing dates or costs or resources, what you should start with before you even record the baseline is an idea of what kind of report you’ll need on a regular basis to identify the variances and, much more important what you’ll do when one happens.  The best practice is to define a series of thresholds and some kind of process that is triggered when the threshold is exceeded.  It can be as simple as a project review by a senior manager but some kind of process should happen when the number is exceeded.

Let’s wrap up
The attractive displays that most project management tool vendors will show you are almost always based on some kind of baseline being established and that’s no accident.  The variance reports that show the current plan vs. the baseline are exactly what both senior management and project managers look for when they want to intervene and make a difference.  A few months ago I met with a company who regularly do a very repetitive project.  The project is a little different every time but the basic elements are all the same and so they’ve gotten used to doing it the same every time.  “Where is the baseline to compare against the last few times you’ve done the project?” I asked.  They all looked at each other.  There was no such data.  The current plan had no baseline.  “But it always takes the same amount of time,” grumbled one of the managers.  “Why bother comparing?”

“Because using a baseline gives us something to target; something to push against,” I replied.  “And, pushing against the target is the best way for us to be as efficient as possible.”

After all, isn’t that what project management is all about?

My friend Eric Uyttewaal, the author of numerous books on project management and the use of Microsoft Project has written a great article on how to interpret the results you see in your bar chart.  “How Gantt Chart-Literate Are You?“ is a good read.  Enjoy. 

2010 is an Olympic year in Canada.  Every time the Olympics come around, I must admit, I get emotional about those athletes who have given so much of their lives to participate in the greatest sports spectacle of our generation. I have a daughter who swam competitively and, as many parents do, I was struck with awe by the amount of effort she dedicated year after year to improving herself in her chosen sport. I’ve had the privilege of being at two Olympic Games. At my first, in Montreal in 1976, I worked at the games helping to raise the flags at different medal ceremonies. It meant hanging out a lot with people who had just won medals and had a profound effect on me. In 2000, I was able to take my wife and daughter to Sydney where we enjoyed the games as spectators. The perspective was very different. Perhaps having a teenager who goes to practice 7 times a week (2 mornings, 5 evenings) for 2 hours or more at a time, gave me a different look at the games but it struck me that the games aren’t so much about who wins. It’s true we obsess over medals but of the 10,000 athletes or so who are participating this year in Athens, only 500 or so will win medals. The other 9,500 have devoted years, in some cases more than a decade of their lives, to intense personal development and will have little or no hope of winning a medal.

When I bring this back to the project management industry and the organizations that I work with who are deploying enterprise project management systems and processes, the parallels are evident. Deploying epm isn’t trivial. Being successful in an epm deployment has a lot to do with treating the project seriously and being ready to do what it takes.

We have no trouble counseling a teen that to succeed in sport will take dedication and hard work but all too often we diminish the work required to make an epm deployment work.

Year after year we talk to mid and large organizations who wish to implement an enterprise project management system. It’s not just me, but many, many sources of information who outline what will be required to make epm work. Yet, somehow, time and again, someone in management characterizes epm as a technology project or as a simple software installation. The impact that changing how project management works might change the character of the entire organization is rarely identified. Yet many organizations in the past 20 years have become project driven. Project management has become a mainstay of management thinking and project management is definitely a horizontal industry.

Projects affect everything about an organization; where the money is spent, how effective the organization is at delivering new products, how fast revenue can be generated, how resources are allocated and much, much more. The idea that the installation of some new software will instantly transform this broad-reaching process from a silo-oriented single-user process into one where diverse employees and departments collaborate is optimistic at best and dangerous at worst.

We should take a page from those Olympic athletes who have planned and strategized and (let’s not forget) worked for a long period of time to achieve their goals. The question, you’ve got to ask is, ‘Are you ready to do what it takes?’

It’s the latest, hottest topic in the project management workspace – “project portfolio management”.  At one time, what we meant by portfolio management was simply the management of multiple projects at one time.  The old term “multi-project” management referred to doing critical path and resource analysis and reporting of multiple projects grouped together.  Nowadays, the term often has an expanded meaning to include the authorization process of the projects themselves, a topic which is particularly interesting not only to me but also to executives everywhere.

When you think about all the statistics we’ve quoted in these very pages about projects that fail, I’ve long held that half the battle in improving these statistics is in affecting what projects were chosen in the first place.

If you’re a project manager, you might think that you have no influence over choosing projects; that they’re often handed to you with unworkable conditions as a fait accompli.  Nothing could be further from the truth.  Implementing a project approval process or “gated” approvals is the kernel of project portfolio management and it’s almost always initiated by the project office.  We don’t need to implement rocket science here.  Let’s start with the basics.

First, let’s establish an approval flow for new projects.  The first phase or “gate” could be the authorization to create a detailed plan.  This makes some sense as creating a detailed plan takes effort and/or money and expending effort is something that is almost always approved by someone.  The creation of a simple form whether on-line or on paper in which some basic criteria are established such as expected return on investment and alignment with business objectives. 

Once the detailed plan is created, it might have to be attached to a form with identified risks, bottom-up estimate of schedule, effort and costs. 

The combination would provide a baseline from which to measure if the project passes this approval.  Being approved through this second “gate might allow the project to begin execution.  Approval might include a calculation of return on investment based on the updated schedule and costs.

Regular reviews of the project status could be implemented in the same fashion, allowing the project to be ongoingly evaluated against a dynamic economy and changing business conditions as the project progresses.

A simple gated approval process can make a tremendous difference in a number of different ways.  First of all, just going through the process identifies risks and assumptions that might otherwise be ignored.  Management might have an assumption that a new product could be developed within a certain amount of time and for a certain amount of money.  The ground-up estimate might show that the product can’t make it to market in the time required to pay back the results expected.  Another common assumption is that key skilled personnel will be available when we need them but in the high-tech world there are often a very small number personnel that are so key that they can form a bottleneck to new project schedules.  Doing a skill assessment in our baseline and comparing it to existing projects will likely reveal the problem.

It’s no wonder that project portfolio management is such a hot button with management in this tighter, less forgiving economy.  The good news is that starting portfolio management by implementing a very simple approval process is possible with minimal effort in almost every organization.

The lesson was brought home to me in an unusual setting. I was speaking to a chemical expert who specializes in commercial swimming pool chemicals. He was explaining how the chlorine in the kills the bacteria which carry the bad bacteria. Until you reach the critical mass of chlorine, he explained, zero chlorides have been used and no bacteria destroyed. Once you hit the critical mass, all the targeted bacteria in the pool die and then you have to maintain the minimal critical level of chlorine to keep the pool safe.

What does this have to do with enterprise project management systems deployments you ask? Everything. Take a recent case in point that we’re working on right now. This is a CRM system deployment. The client has (not unusually) completely underestimated the total effort required to deploy the system. They’ve elected to put in a minimal budget with the thinking that their own personnel will be able to carry the project forward at a leisurely pace. The budget had very little room for experienced and expert assistance and was mostly focused on functionality training. Internal technical personnel were also budgeted for the smallest possible amount of time perhaps thinking that the internal personnel would be as efficient as a consultant who had done many of these implementations.

I’m sure you can see where this going. The budget for both external and internal technical expertise was quickly expended and, while the CRM system is installed and has some elements of the functionality working, there are large areas of the product which cannot yet be used because either they aren’t at all functional or they have not been configured with the necessary templates. Underlying architecture is also an issue. In one case the web server required both an upgrade and additional configuration and in another an incomplete installation of Microsoft Exchange had to be tackled. The end result is that the system does not yet have sufficient forward momentum to ensure it’s viability as a corporate system. What will happen here is that either the company will let the system limp along until something better comes along, or the system is abandoned or until it applies a bunch more resources and money to the project (perhaps even more than would have been required originally since they’ll be trying to rescue a project that’s already underway).

Sound familiar? I hope not. But this is exactly the scenario we often see in the enterprise project management space. The amount of effort required to validate the infrastructure, install the software and (most of all) configure the final system is underestimated about 90% of the time. A compounding issue is that the level of expertise and experience required is also almost always underestimated. The result is that systems do get installed but have elements that are not working and too little time to configure the system to deliver the results that were expected when the deployment was authorized.

There’s not a panacea for such deployments. Educating management, if possible, can reduce the heartache. If you are involved in an enterprise project management systems deployment, then determining the minimal working system may be a critical step in your planning. Aside from defining the complete deployment requirement which may be daunting to management, determine also, what effort would be required for a ‘viable’ deployment. One which, even if not all the functionality was deployed, would realize enough business benefit to be worthwhile. If you do, then the system will still be around to expand on later. If not, then you might end up with one more system to be rescued or replaced and all your efforts wasted.

Tower of Babel

One of the biggest challenges we have when we arrive to implement enterprise project management (epm) is the wide range of definitions of what is meant.  The problem is compounded when we fold systems into the conversation.

Depending on your perspective, enterprise project management might mean very different things.  If you are the CFO, then epm could mean tracking project costs in a consistent manner across all projects or might mean just being able to categorize costs by project.  In this case, focus rests on the centralized accounting systems or a new ERP system which becomes by default the epm system.  Appalled?  Don’t be.  For organizations which have not been able to do this before, having the actual costs per project is revolutionary. 

Other aspects of project management that people think about include resource capacity planning, inter-project reporting, portfolio management, earned value analysis, integrated annual budgeting, matrix reporting, schedule tracking, resource contracting and team collaboration or team communications. 

For some organizations, epm means just being able to track the detailed labour actuals on a project-by-project basis including details down to the task level.  In this case, a corporate timesheet becomes the central epm system. 

‘Where is the project plan?’ you ask in shock?  In this case it would be managed at the most summary level.   

For people like me who are somewhat project scheduling purists, this seems at first glance to be just awful.  When I think Enterprise Project Management, I imagine integrated corporate project schedules and centralized resource pools and cross-project resource capacity planning.  But this just betrays my own bias in the conversation.  For each organization wishing to improve their ability to deliver projects, the leverage will be found somewhere different.  I have been asked virtually hundreds of times for a timesheet system not to ‘integrate’ into the project management system but to ‘be’ the project management system.  When I bring up planning, it’s not unusual to hear the following from a senior executive:

“Yes, formal integrated scheduling would be fine but, you know, before you showed up, projects were underway.  They’re underway right now, as we’re speaking.  This is happening despite the absence of a centralized planning system.  We have a good handle on the planning, what we can’t tell you is where our people are.  If we could just know from week to week what effort we’re actually spending on our projects our control would be so far ahead of where we are now it’s unimaginable.” 

The first time I heard that was years ago and it stopped me in my tracks.  My purist view wasn’t so important anymore.  What counted is getting the right metric into the right hands. 

So, when you’re looking at creating an epm system, don’t fret that you’re doing it wrong or that the last project management software vendor showed you aspects of project management that you’re now sure everyone is doing.  Look at the different aspects of what you can control and start with that area that will deliver the biggest return on your investment of time and effort. 

As the notion of enterprise project management becomes more prevalent in the industry, we’re starting to see epm approaches divide into one of a small number of camps.  As I’ve said a number of times in this column, there are many perspectives of project management in an organization and lots of different approaches to how to empower each of those perspectives.  One of the major choices that a new project management office has to deal with is who will be responsible for the data itself.

 It’s a basic tenet of systems analysis that for each piece of input data there can be only one person responsible.  If there are multiple people responsible for a single entry of data, managing the quality of that data becomes very difficult.  So, when we see Project Management Offices get set-up for the first time, one of the key challenges is to decide if the role of the PMO personnel is to collect, analyze and report on project data or if there role should be more as a coordinator, bringing the data of many individual project managers and even individual team members into a cohesive collection of data.

In the first scenario, the PMO will look for a high-end centralized project system.  Project managers will put the bulk of the project management data in directly or with the assistance of schedulers.  The individual team members will see reports out of the centralized system and there input to that system will be either as a part of meetings or, perhaps through their timesheet system.  This type of system will typically have advanced functionality for critical path scheduling, resource leveling, skill scheduling, multi-project analysis, risk analysis such as Monte Carlo analysis and extensive reporting capabilities.  Sounds great of course, but this type of product will work best in the hands of skilled project scheduling workers.  We see this type of tool in environments where there are a small number of projects which are very large and complex.

In the second scenario, the role of the Project Management Office is designed as a clearinghouse for work which is being managed in a much more decentralized manner.  In this case, team leaders or project managers of much smaller elements of projects work on their own project data.  The team members are given direct access to the system and interact with it to find out what they are working on and to update the schedule with their own progress.  This type of system is oriented more around collaborative functionality.  There will be tools for individuals to customize their own views, to see system announcements and online discussions, to get alerts for project changes, to add collateral data to the project such as documentation, issues progress notes and more.  There is usually less emphasis on reporting in this type of system because the system itself is typically available to everyone.  Instead, you’ll find more emphasis on personalized online views.  We see this type of approach in an environment where there are numerous projects which share resources.  A matrix organization would find this type of tool a good fit.

Again, this sounds great.  This type of product will work best in an organization where the individual project teams are empowered to function more independently but still interact with the rest of the organization for elements such as shared resources or portfolio prioritization. 

Which is the right approach?  It’s a trick question of course.  For each organization, you’ve got to look at what the key business drivers are.  There’s a definite tradeoff.  The centralized system will bring a lot of data together where it can be managed in the hands of highly trained individuals.  The reports and analysis will likely be first class.   The problem may come in the ownership of the results by the team members who are affected.  In the decentralized system, individuals are likely more empowered and the project management is done closer to the actual work.  The challenge becomes getting sufficient conformity and compliance to have the consolidated data make sense.

One key to staying effective is to make sure that your project management office is organized to correlate with the organization’s approach.  A common problem is to find a PMO who wants to be centralized in an environment which is de-centralized.