Category: Articles

Home Articles ()

Article: Training the Project Professionals

7251961I’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.


Article: Integration is always at the lowest common denominator

MSB08_Wilbur_04I’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.

Article: Are you baselining?

72762531Are 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?

Article: Project Management and Web Portals

7252413I’ve written at different times in this column about the impact of the web on enterprise project management systems.  Until now, most of that talk has been about how the availability of a web interface would attract additional users through an easier and more accessible interface.

There is an emerging movement in this regard however, which is starting to revolutionize how we think of project management data and project systems usage.  It has come about as the result of web-development from the original static html pages to a content-management paradigm where the design of the system is kept independent of the data that now usually resides in one or several databases.  In these types of systems, non-technical personnel can keep a web site full of current content and can provide a dynamic system in which many users can contribute.  This has led to a huge market called the enterprise portal web market that in and of itself is hot news.

When we apply this concept to project management, however, we find a great match of functionality to requirement.  Many project management tools have now extended their original web interface concept to provide a project management portal type of structure.  What this means in practical terms is that a project manager can provide a sort of mini-website specific to the project management office and even to specific project teams as a natural extension of information sharing.  Functionality expected in a project portal starts with an ability to add URL links to the menu structure.  This means you can immediately extend your web interface from basic schedule management to anything else you have a link for.  Additionally, document management is a common function and this means you have a stable centralized place to store all project management related documents that can be made easily accessible to all team members.  This alone can produce tremendous improvements in efficiency.

We’ve seen a coming together of several tools from different vendors.  Welcom has its WelcomHome, a dedicated project portal product.  Primavera’s recent acquisition of Evolve promises additional portal functionality from the existing web-based functionality itself. 

It is Microsoft, however, which holds a fascinating position.  In its most recent incarnation, Microsoft Project includes technology from its Sharepoint Team Services product.  Sharepoint is itself a portal product.  Microsoft Office Sharepoint Server (MOSS), the big brother to SharePoint Team Services tackles the large enterprise portal market.

With Microsoft publishing products in both the enterprise project management and portal arenas, there is no doubt that there is huge potential here for a powerful environment. 

With Microsoft Project and Microsoft Server rooted firmly in the architecture of SharePoint, even more functionality looks like it will be heading down this route. 

In the Microsoft environment, we’ve got the potential to start leveraging all data whether that is lists oriented, document oriented, data oriented or project schedule oriented.  This gives Microsoft the potential to take a serious advantage in merging these technologies to provide a significant efficiency advantage.  Microsoft Enterprise Server 2003 in particular looks like it will include much of this portal technology by default.

Aside from Microsoft, there’s no doubt that many pm software vendors will be looking to adopt portal functionality as part of their offering in the near future.

This movement towards centralizing access to data in a user-friendly interface rather than trying to integrate all the data together into one system will likely alter how project management environments are created. 

Article: Start with the simple things

7265201I’ve had a few wonderful opportunities lately to talk to high-tech CIOs about what costs them the most time.  I had thought I’d hear about project management and resource management issues.  ‘We need a better scheduling algorithm’ or ‘We need a better resource-leveling engine,’ I figured I’d hear.  Not so.  The CIOs I’ve met this month in my rather non-scientific survey talked about the simple things.

“I’d just like to know if my people are working on what we planned,” said the CIO of one of our federal departments here in Canada.  “We need to be able to track how much time our people are spending on productive vs. non-productive work,” said another CIO, this one from the IT department of a major engineering company in the UK.

When you look at this in retrospect, it’s not too surprising.  The 80/20 rule probably applies here as it does in so many things.  Twenty percent of the enterprise project functionality can deliver eighty percent of the value.  That’s certainly possible in organizations with a very new project management structure.

I get the chance to talk often to organizations about how they should proceed with their deployment of enterprise project management methodologies and I’ve always been a big fan of a graduated approach.  This allows the organization to ease-in to the change in culture while enjoying the first benefits of the project system.  These IT professionals have confirmed that this is the best plan. 

In the opinion of the CIOs I’ve just met, it seems that the most critical elements of a project system to implement are the abilities to a) inform workers what work they have been assigned and b) track where time was spent.  This being the case, many organizations are electing to look at implementing the timesheet aspect of their project system and a simple task allocation or information system to get things started.  For many organizations, just seeing where the hours are being spent is an eye-opener.  Executives are often shocked at the amount of productive time is being spent on actual project work.  I often hear expectations from management that over 80% of their employees time is being spent on project work.  Once the actual data is in, they are often amazed to find out that the number is closer to 50%.  That’s not to say that employees are shirking work.  It’s much more likely that the corporate infrastructure itself is at fault. 

“It seems silly, but the most important thing for us is to find out what work has actually been accomplished,” I was told by one CIO.  “Despite the fact that we’ve not implemented a complete enterprise project system yet, we do know what people should be working on.  Just tell me what we’re actually doing and I’ll be more effective.”

These sentiments don’t, of course, eliminate the desire for integrated project management.  That is almost universal.  Virtually all of the CIOs I talked to identified enterprise resource capacity planning as their most desirable, yet missing management function. 

So, for those of you who are still working on your enterprise project management implementations, take heart.  You can still make great strides forward by implementing the basics. 

Article: Keeping score is now a project task

scorecardMore and more these days as I visit project management offices across the country, I end up talking about scorecarding and balanced scorecarding.  These terms are part of a popular trend in management at the moment which is based on the simplest of management principles.  Scorecarding refers to simply setting goals for certain results in the business and then tracking those results on a regular basis.  (See? I told you it was simple).  The notion of balanced scorecarding carries the notion one step further to include four related categories with the corporate vision into a single scorecard.

The scores for such a process come in two flavors.  The first are subjective scores.  A manager might be asked, for example, to rate on a scale of 1 to 10 the degree of alignment of his current project with corporate objectives.  The second type is objective, something us project management types are much more comfortable with.  An objective measure is something that comes from hard data.  For example, this task finished 10% later than planned.

The process of scorecarding is of itself remarkably productive.  The simple act of looking at an objective and determining the degree of completion with that objective establishes a natural structural tension between where you are and where you want to be.  It also keeps the staff focused on what is important by continually bringing them back to the objectives being measured.  This type of thinking is, of course, no surprise to project managers.  Tracking results against a plan is the very core of project management thinking.  What is interesting, I think, is that this kind of thinking is now extending into every aspect of an organization and the objectives being measured now extend well beyond a list of tasks in a project to encompass almost every aspect of the organization.

To, I am sure, no one’s surprise, these processes have been automated into a range of products and customized software which target the scorecard entry and the display of results across the enterprise with view to providing management with advanced indicators of what is working and what is not.  Moreover, these systems are able to standardize the entry of data and the speed at which it is entered.  Reports for virtually everyone in the process from the lowest to highest employee give instant feedback on where you stand with the objectives you had, what your score is in different areas and how it compares to previous periods.

So, what does this have to do with enterprise systems?  Well, there’s not much one can do about automating the subjective scores, they’ll always have to be entered by hand but the objective scores is another matter altogether.  Implementers of scorecarding systems look with a hungry eye to centralized data systems such as the corporate ERP or HR systems.  The data in these systems provide great sources of information that can establish without argument the score for a particular category.  The movement towards enterprise project management systems is now providing a new and exciting source of metrics which can deliver automatic results to the scorecard system.

As interesting as all this is, there is something else to consider in a scorecard or balanced scorecard environment and that is what you should be scoring.  Choosing the metrics which represent the elements of the organization which most affect results takes the eye of an experienced expert.  So move forward with an open eye when you’re looking to keeping the right score.

Article: Softskills Sofware assistance

7621529When 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  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 .

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.

Article: EPM is spelled PMO


“How do you pronounce ‘EPM’?” I asked one of our consultants recently.

 “Enterprise Project Management?” he replied.

 “No,” I said. “You pronounce it P-M-O.”

 It has become more and more common in recent years for us to have to deliver this message to prospective clients considering the implementation of an Enterprise Project Management System.  It’s no wonder that most consulting firms who deliver EPM system deployment assistance also manage extensive requests to implement Project Management Offices.  “Do you have a PMO?” has become one of our most immediate watershed questions.  Those who answer no are usually not in a position to take immediate advantage of an EPM system.  Those who answer yes often have established some of the basic pre-requisites that anyone should be looking for before putting down money for their favourite EPM Software.  Here are a few of the key pre-requisites we look for when a client calls and asks us to implement an EPM System.

Do you have a PMO?
I might as well start here given it’s how I started the column.  The existence of a project management office is almost essential to a successful EPM deployment and here’s why.  Every EPM system essentially brings many project managers and project resources together into a centralized project management environment.  All their data will now be centrally stored.  The data may be centrally calculated and analyzed.  The benefits being sought by those who buy EPM systems are typically centralized benefits; things like resource capacity planning and inter-project impact reports and organization-wide project variance analysis and corporate reporting.  All of these things can be wonderful, but they are imply some level of coordinated action.  The data must be saved by everyone in the same period of time.  The data must be analyzed in the same manner.  The data from project 1 must be able to integrate at some level with the data from project 2 and so on.  This simply doesn’t happen by accident and while EPM tools have the capacity for coordinated action, they can’t make people behave differently. 

What each EPM system absolutely needs is a centralized place where standards can be maintained and where the enterprise project management system can be maintained.  It requires someone who will be looking for others to comply with the central system and will ensure that data that is received is both complete and acceptable to the standards that have been set.  Imagine if there was no common understanding of how to define resource assignments or even how to name resources.  Some project managers would enter them as skills, others as individuals, others as departments.  It would be chaos.  Imagine if some project managers updated their projects every week, others every month and still others only at the project’s outset and completion; you’d never know when you could produce an accurate organization-wide report. 

A flag-bearer for standards
While we’re talking about standards, there has to be someone central who will be their champion.  Even if these practices and procedures somehow got produced from the end users, who will be their keeper?  Some will say “We’ll all keep them but that leaves no one accountable to ensure the practices are being followed.  Standards are essential to an EPM system even if that system is completely manual.  Some people get concerned that this centralized person will have too much authority but this too can be managed within the standards.  The notion that a group of people can be accountable is silly.  People will do whatever they think is best but creation of standards doesn’t happen randomly.  This can only be done by someone central.  Moreoever, you’re going to have to think about the future.  Even one standards and practices have been adopted there will be changes.  When a change must be made, who will create it, update it, get it accepted by everyone and then ensure that it is written into corporate policy?  Again, this doesn’t happen from a random end user, it requires someone whose role it is to support those standards.

Project Management Practices and Procedures
One of the most common things we encounter when we’re called by a prospective client is a lack of centralized process.  When we ask to see a list of accepted practices and procedures for project management, we usually get a blank stare.  It’s not enough to have a PMO and a centralized Standard Bearer for the process, you’ve actually got to bite the bullet and create and agree on those standards.  Our usual recommendation is to start with the most minimal number of procedures possible and then let the list expand over time.  Some clients will try to create the ultimate über-list of practices and procedures and end up with a 700 page tome that no one will ever read because it’s too confronting.  Starting small but getting a high degree of consensus is by far the preferable plan.

One way or the other though, you’re going to have to agree on a few basics:

  • First, how you’ll name things.  Naming conventions for projects, tasks and resources is absolutely essential
  • That you’ll store your projects centrally in whatever tool or repository you’ve chosen.  A firm agreement has to be made on what data must be saved and what data need not be.  Without this agreement and someone who will monitor compliance, your EPM system is going nowhere fast.
  • Frequency of updates.  It makes no sense to have some data updated every week and some updated every year.  Make an agreement on what the frequency should be for different kinds of data.

Support for the Technical Infrastructure
I can’t possibly list all the weird and wonderful infrastructure problems we’ve encountered at client sites.  We’ve been called in to help with a centralized server-based project management system only to find that it’s not installed on a server at all, it’s been squeezed onto someone’s laptop and every time they reboot, the system becomes unavailable to everyone.  We’ve seen server-based systems that aren’t listed in the IT department’s list of secure servers because some department installed them on their own.  The installation went fine, but the server will never be available because the IT department allows only authorized servers through the firewall.

Whatever centralized tool you select, you’re going to have to make sure that it is supported by the people in your organization who do such things.  Server-based project management tools are not like tools from 10 or 15 years ago.  They depend on a ‘stack’ of technology.  A database server, a web server, a firewall, an internet connection, a browser, the client operating system, an identity or security server and more.  When an update to your EPM system arrives, it may well require updates to all kinds of elements of the ‘stack’.  Someone needs to be accountable that the system and all the technology that it depends on is maintained and monitored.  There will be regular maintenance and monitoring required and that won’t happen with some random user.  It requires someone who will report back to the PMO that the system is working properly or that maintenance effort is required.

Implementing an Enterprise Project Management environment can lead an organization to a tremendous increase in efficiency.  When the economy is challenging, being more efficient is in high demand.  But, not having the pre-requisites ready or not considering what might be required to make an EPM environment successful can make an efficiency project very costly both in time and money.  Ask someone with experience to make sure that you’ve prepared properly before embarking on your EPM deployment.

New Blog on TimeControl

Here at HMS we’ve decided to publish a brand new blog that’s specific to our TimeControl timesheet software.  The TimeControl blog is at and will include tips, techniques, frequently asked questions and other information about how to get the best out one of the best recognized and extensive timesheet systems in the world.

Stop by the Blog to see what we’re doing there.

Article: The challenge of evaluating EPM software


It happens to me all the time.  The mail arrives and in it is an RFP.  They’re three dreaded letters around my office and I’ll tell you why.  The “Request for Proposal” is a construct of purchasing departments designed to compare vendors with similar products to sell.  The RFP is supposed to list in exacting detail exactly what kind of proposal the client requires and the respondents are expected to prepare their proposal and give the best possible price to the client.  The client evaluates all the proposals together and then knows who can give the best possible solution to them.

It works great when the client is looking to buy army boots or kitchen knives or storage containers.  It’s virtually useless when used to purchase an enterprise system and here’s why:

First of all, let’s take a look at how we assemble the RFP.  The beginning and end of the document are boilerplate.  They list the process of how to respond and the legal terms of what responding may mean and what you must or must not agree to.  In fact, most of this is not that useful, since if you are the winning bidder, you’ll need to go a whole new round of terms negotiations with the contracts people but either way, this is not our big concern.  No, it’s the bit in the middle we want to talk about.

In the middle we’re supposed to have a list of those requirements in ‘exacting detail’.  The client must assemble the various parties involved to see what they would like in our new enterprise system.  Perhaps a committee is convened or a series of focused workshops to work through all the implications of each requirement.  Perhaps there is a long period devoted to developing the business requirements that will resolve to system features.

 If only…

In fact, what’s more likely is the project manager assigned to this project will have a short meeting or perhaps two during which he or she will make a request that the participants represent their departments by listing all the features that are important to them.  Each person goes back to their group and sends an email saying “This is your only chance to have any impact on what we’ll need in the new enterprise system.  Speak up now or forever hold your peace.”  The departments respond in an uneven fashion.  Some department members give the request serious consideration and submit a long list of things.  Others give only a perfunctory response.

The project manager now assembles these items into a spreadsheet and adds a few columns: “Priority”, “Comment”, “Included”.  The end result looks like this:

For each Priority enter:
M: Must have
I: Important to have but not essential
N: Nice to have
For each Included enter:
Y: Yes, this is included in your product
N: No, this is not included in your product
E: This could be included by adding additional effort which has been identified, scoped and priced into your proposal
Feature Priority

Gosh, it looks good so far, doesn’t it?  The spreadsheet fills out quickly.  For the more organized clients, on the internal copy (the one not sent to the RFP respondents) is a column called “Weighted”.  This is where the relevant score weighting for each item is entered.

 The project manager now merges line after line, categorizing them perhaps to make sure there are no big feature holes.  In the end, what is received is a remarkable list of features that looks just like every EPM system brochure on the market today.

Now, the vendors get this list and scratch their heads.  God knows, I’ve done it plenty.  They look at the list of features listed and try to make sense of why some features are listed 2, 3 even 4 times but each worded a little differently.  They try to reconcile some features which seem diametrically opposed to each other.  They ask questions for features which seem deliberately vague like “The system must automatically transfer data with our internal LIMS environment”.  Invariably the acronym LIMS is not explained and the details of what the expectation may be are not available.

But there is a profound problem with this process.  Have you spotted it yet?  The RFP is describing the solution not the problem.  It’s a massive disconnect and no one ever talks about it.  The purchaser or the project manager assembles a list of every feature all his or her users can come up with and presents that list to the vendors but what is not at all clear is whether the delivery of those features will make the lives of anyone at the client company any better.

So, what happens?  Vendors go through an exercise of preparing a hundred-page or sometimes a multi-hundred page response.  The client receives several of these.   The selection committee reviews them all.  They all say the same thing: “We can deliver every feature you’ve described.”  Sometimes vendors tick off every line item with a “yes”, even the ones that don’t make sense or are in complete conflict with other line items.

The hapless readers must wade through these documents trying to determine which vendor makes sense.  The weighting scheme tells them what features are more or less important but the scores after everything is done are very close.  The biggest impact on scores?  The neatness of the work.  I know, it sounds childish but ask around and see if it’s not true.  The vendor with the most colourful, neatest, easiest to read response always scores well.

Now a short list is assembled and a couple of vendors are invited to do demonstrations.  Typically the meetings are a couple of hours or less.  In the most frustrating cases, the client asks that the demonstration look exactly like what their system will look like after it’s purchased, configured, populated with data, customized and enhanced.  This obviously can’t be presented.  But, the meeting is important because it’s the first time the vendor gets to meet the end users and ask “What on earth is it you need to accomplish?  What are you suffering from?  What is the problem?”

In the end, purchasing decisions are often made one level above the selection committee anyway.  An executive makes that decision not based on a requirement analysis but on the recommendation of a trusted advisor, or a friend or colleague who once bought a similar system.  Will it work?  Sometimes and sometimes not but it’s a certainty the system purchased was not done based on what the company is struggling with.

“But that’s the best purchasing process we can come up with,” I’m sometimes told.

I truly doubt it. 

If you’re considering moving to a new EPM system in the New Year, I’ve got a couple of recommendations for your purchasing process.

First, start with the problem, not a description of what you think the solution should be.  List the business challenges that you are finding it difficult to overcome.  They can be articulated in terms of business decisions that you find difficult to make or business process inefficiencies which you wish to improve.  Saying “the system must help us decide to increase or decrease our future resource commitments with sub-contractors but delivering resource capacity planning such that we can see a projection for the next 90 days of resource requirements and resource capacity.” is incredibly more powerful than saying “The system must have resource capacity planning reports.”

A vendor who understands the business challenges will feel more latitude to craft a response which may be more creative and, even better, in ways that you’ve never imagined.

Next, put less attention on the vendor demonstrations and more on vendor references.  Probably the most valuable thing you can do during this process is arrange to visit the sites of other clients of the vendor.  A vendor salesperson demonstration will always look sharp but a real client will almost always be honest enough to explain the parts of the deployment that went great and those which were more challenging.

Finally, make sure that management gets on board with this process early and stays involved.  There’s little more debilitating than having a selection group work at something like this for months only to find out that none of their work will be considered when someone from senior management makes the final decision.

Happy buying!