It’s Christmastime and whether you celebrate Christmas or not, it’s a festive time of year in many parts of the world. I’m always amazed at what people get accomplished at this time of year. There’s shopping to do, work to complete, travel to organize and, of course, the big family meal. When I see how much people get done in the swirl of huge to-do lists I find it humbling. Putting it into a project management context, I can find a little project manager in all of us.

If you are responsible for making the family dinner this year, you’ve potentially got a big project schedule.  You won’t need your PMP certification or to pull out your Prince2 process guide but you’ve got a sequence of events, a budget, and a whole lot more.  Think about this for a moment.  As much as men such as myself like to ignore how much work goes into Christmas dinner, the planning starts weeks in advance:

Guests
You’ll need to decide who to invite.  “Do we invite uncle Harry?  If we do, can we not invite Uncle Bob?  You know how they don’t get along!”  There are big decisions here.  Also, some competitive negotiation will take place behind the scenes.  Who else might want to be hosting the big family dinner this year?  If you have a rotating schedule, then think of that as corporate process culture that people have been following for ages. 

Once you’ve decided on who’s coming, you’ve go to get the word out.  That might be a quick phone call or written invitations depending on how formal your dinner party is to be.  It’s inevitable that some people will have to think about it, especially if they have travel to organize.  So there’s RSVPs to keep track of and a running talley of the number of guests so the appropriate sized turkey can be procured.

Procurement
Purchasing is next.  You’ll need a budget, shopping plans, the big car and maybe helpers. Then it’s off to get the bird (or ham), the vegetables, cranberry sauce, dessert and fixings.  If there are additional plates, pots, pans or gravy boats required, this will have to be on the list too.  You can’t leave all of this too late or you’ll be choosing from the last of the turkeys and who would want to do that!?

Preparations
There are always preparations to make.  You’ll need to do some decorating and perhaps bring up that extra table from the basement and then there’s food to get ready, dessert to make and the house to clean.

The big day
Is it Christmas Day already?!  How did that happen so quickly? Now the schedule shifts from a weekly and daily perspective to minute-by-minute planning.  While the kids are squealing over their new bike, dollhouse or video game you’ve got to be thinking hours ahead.  What time does the turkey have to go in?  What time do you have to start peeling the potatoes so they can be cooked and then mashed?  What time do we put in the vegetables and what time are guest due to arrive? 

All this culminates in a delivery that is virtually down to the minute. “We’ll be sitting down at 6:15,” isn’t an unusual thing for a host or hostess to say to their guests but how many project managers get the minute right on their project delivery?  Not many, I can tell you.  Yet, all of this comes from the backward pass in the schedule; planning backwards from 6:15pm on December 25th to as early as is required to make sure that every predecessor was resolved prior to sitting down.  It’s done intuitively or with a simple post-it list perhaps but it’s nonetheless an impressive accomplishment.  And this year, as it has been for many years before and for many years to come, project managers (sorry, I mean hosts and hostesses) of the Christmas Dinner project will deliver their project on time.

Have a safe and happy holiday everyone wherever you are.

Note: You can download the Christmas Dinner schedule in MS Project format from the picture above at http://www.epmguidance.com/docs/ChristmasDinner.mpp.

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

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:

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!

I was asked recently to help an organization prioritize its enterprise project management deployment. As we’ve often suggested here, the organization had done some homework. They had assembled a multi-departmental team to determine the aspects of epm that they considered important and they had worked over a series of months to articulate their process and to evaluate potential software vendors. They had determined that replacing an in-house timesheet system with a new timesheet system that would improve the time and billing process was their highest priority and had already purchased several hundred licenses of this time and expense system.

Sounds like there was nothing for me to do, doesn’t it? The organization had called me in because the scope of the deployment had recently undergone a significant increase and the head of the team was quite concerned that their entire plan was now at risk. The original scope had included several aspects of epm functionality including, of course, the timesheet but also a complete Enterprise Project Management system for resource capacity planning, schedule tracking and more. The selection of the timesheet system included, in part, the ability to link to Microsoft Project, which had already been targeted as the preferred epm system. The original plan was to deploy the timesheet first over a 4 month schedule then work on the epm deployment in the months following. Somewhere along the way, two things happened to dramatically alter the schedule. First, the timesheet vendor informed the client that a perceived deficiency in the abilities of the timesheet could be solved with the functionality of the epm system and second, almost simultaneously, management had renewed its requests for resource capacity planning information from Project.

The result was to move the implementation of the entire epm system forward and to implement the timesheet system and the epm system simultaneously. I was not particularly surprised to find that the schedule had not been lengthened at all as often happens during ‘scope creep’. The challenge I was asked to solve was to determine if the schedule was still viable and to look over the new scope of work to determine if this was the most effective course.

I mention all of this because the exercise we did together with this client is one that is done all too rarely in deployments of epm systems. We looked together at the final vision of the system from a business needs perspective. I asked the deployment team to identify business decisions they intended to make from the system rather than to identify a list of functions that they thought they would need. By focusing on the intended business uses of the system we were quickly able to list the expected business benefits.

The resulting list was highly relevant to their request. Over a couple of hours we were able to list the majority of the business benefits they were hoping for and the actual business decisions they expected to be better able to make once the system was deployed. Interestingly, virtually 100% of those benefits were focused around the functionality of the timesheet change rather than other epm oriented functionality.

This left us with the problematic functionality that had started the whole change in scope in the first place. ‘Who had reported the problem?’ I asked. The culprit was the chief accountant. An hour later we were meeting with him. Yes, he could confirm that this function was something he desired. However, when I asked how much effort was required to manually (ok, via Excel) manage this function now, the answer was ‘about 5 minutes or so per month’! Needless to say, with such a small improvement in efficiency as our expected benefit, the cost and effort of the whole epm deployment for this one function couldn’t be justified.

The lesson for all of us is to focus on the Return on Investment for each aspect of your epm deployment. What will be the intended business benefit and the intended business use of the system? Make sure you know how going through the exercise of deploying a whole enterprise project management environment will pay you back dividends.

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

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

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

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

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

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

Whose resources are they anyway?

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

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

I’ll share if you share – maybe.

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

My people are all busy beavers – honest!

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

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

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

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

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

I’ve spent the last 24 hours in a project management software exhibition hall here in Toronto, Canada, so you’ll forgive me I hope for harping on what has become a bit of a cliché in our industry.  You know the one I’m talking about – Enterprise Project Management Software.  It must be the hangover from the ERP implementation craze that was the hallmark of the turn of the millennium or something because it seems that every software system available to mankind today is “Enterprise”-something.  Vendors are either selling an enterprise-wide system or they’re selling how to implement it. 

I’ve had literally dozens of attendees ask me questions on what “Enterprise” project management system would be the best.  Almost every product on display has the word Enterprise in its description somewhere but when I’ve asked what about their product made it “Enterprise” enabled, the exhibitors were hard pressed to find a good response.  At the Microsoft booth, a new Microsoft employee asked me if I didn’t think that Microsoft 2000 wasn’t more of an “Enterprise” product.   Even our own firm is touting its’ Enterprise timekeeping system.  Frankly I’m getting a little tired of it.

It’s not that I have anything against Enterprise products.  After all, as I mentioned, we do publish one.  It’s the notion that every project management software tool is an appropriate product to be deployed across the enterprise that has me annoyed.  When I travel to different parts of the world I have the privilege of meeting people who manage some of the largest organizations and some of the largest projects in the world.  For the last 17 years or so that I’ve been in this business, an enterprise-wide-work-for-everyone-universal project management system has been like the Holy Grail.  It’s almost universally desired by management as a panacea for everything you don’t like about the project management business.

“If only we had an enterprise project management system where all the data was centralized, I’d be able to see exactly who is available at any time of the day,” say some.

“Ah, if only we had an enterprise project management system, we’d be able to see our project status in real-time,” say others.

“But if we only had an enterprise project management system, everything would be on-time and on-budget,” think the rest.

What kind of system would it be?
Ok, you may not be that shallow, but think about how great it would be if all project management data from projects done in your organization over the last 10 years was in a centralized database in a format that you could immediately access, that you could see trends and averages in at any time.  Sound attractive?  How about this, imagine that all project managers who are managing projects that have any impact of any kind on either the scope, resources, or schedule of your own projects are using a project management system that automatically ties in with your own and shows the impact as soon as they know about it.

What very few people spend time thinking about is what implications are involved in actually deploying such a system. 

First of all, what kind of system would it have to be.  We’d  need a system that was:

• a) capable of storing data in some centralized format such as a client/server database.
• b) easy enough to use in order to be accepted by the huge numbers of part-time users who would have access to the system
• c) robust enough in its functionality in order to handle the kind of complex analysis that is bound to come from managing large amounts of diverse data.

Next, we’d need to tackle the process.  If you’ve been working on this at all, you’ve no doubt come up against this issue in a big way.  The process by which all the data will be collected, entered, analyzed and distributed through such a system has to be walked through over and over and over again from the perspectives of everyone involved in the process just to make sure data can make it through the system.

Finally, there’s the matter of how it’s deployed at all.  It’s often a case of the shoemaker’s children who go barefoot when it comes to deploying a project management system.  There’s almost never a project management plan for it!

And just what do you mean by an Enterprise Project Management System?
Let’s look at these one at a time.  First with regards to the products themselves.  There’s no point in naming names.  (Please don’t be calling me to ask if I think that “Product A” or “Brand X” is really an enterprise product – the whole point of this is to let you figure out for yourself what’s important.  First of all you’ve got to look at the kind of product you’re looking for.  As I answered to someone today when they asked which was the best enterprise project management product, “What are you thinking of when you ask for an enterprise product?” 

If an enterprise product means simply something that will be used by the enterprise in the widest possible distribution, then looking at an of the easy-to-use desktop products is your best bet.  Make sure you narrow down your search.  Is it scheduling, resource allocation, document management, timekeeping or what that you’re hoping to implement?

If you’re looking more for a system that can be used centrally by a small team of professionals (such as in a project office) to manage all projects in the enterprise, then you’d do best to start your search among the high-end pm systems which were originally designed around mega project environments.

You may rather be looking for a product which will be widely distributed but will maintain all its data in some central repository for reporting purposes.  In this case, your search is not in vain but will take a little more work.  You’ll still need to concentrate on the ease-of-use of the interface such as in a desktop tool but one of your basic requirements will be data storage.  It shouldn’t take long to come up with a short list.

All these three definitions can be deployed with fairly low stress.  It’s the fourth one that causes grief.

If what you mean by enterprise project management software is an environment where the software is widely deployed and where project decisions are taken at different levels of the organization (e.g. resource availability decided centrally, but resource allocation decided locally) and where there are numerous levels of responsibility for data (e.g. the individual project managers manage their own small project but the global impact of all projects is the responsibility of someone at a higher level in the organization and/or if you are talking in terms like multi-project resource leveling, multi-project analysis, hierarchical project groupings and so on…  If you mean something like that, then you’ve got a much tougher challenge.  This kind of product is one which will almost certainly have to come in parts.  There’s got to be some part of the system that is designed to be used by the project office type of project manager.  There’ll need to be a completely distinct interface for end-users who will have only occasional access to the system.  There’s got to be robust reporting, flexible data structures and much, much more.

Getting started
There are a couple of such product combinations on the market today and while theoretically any of them might work, ensuring that the product combination you select can actually be deployed is the next challenge.  You should be able to get your short list figured out very quickly and once you do, here’s the hoop you should be making your project management software vendor jump through:  Have them describe to you (in terms even your management will understand) the process by which data will move through their system.  Be wary of cheap demonstrations.  It’s not difficult to create a demo that gives the simulation of the system working while obscuring key difficulties in making it work. 

A couple of years ago, I watched an organization struggle with a matrix organization problem.  They had divided their project data into individual sub-projects where no sub-project had more than one resource grouping in it or more than one project-phase.  This was so they could group it in one direction for the resource managers and in the other direction for project managers so that each type of manager could manipulate the data within their area of responsibility.  It had taken the organization months to divide up their data this way and they were abjectly miserable.  No surprise.  No one had ever questioned how each type of manager with their own distinct and often conflicting responsibilities would be able to access and manipulate the project data.  No one had used up some inexpensive white board space to map out the flow of data like a process.  The organization’s still struggling with the concept.

Now, I know I’ve said this before, but here it is again:  You’ve got to consider how you’re going to deal with the deployment of your chosen system(s).  If the system you’ve chosen can only deliver its first results once it has been adopted by 100% of the organization, then you’re in for some bad news.  In the majority of cases, project management software implementation projects that are designed as an all-or-nothing approach, deliver nothing.  It can’t be much of a surprise.  The cultural impact of trying to get everyone in an organization to change from anything to anything else at the same time is horrendous.  Look for the small victories.  Make sure that you’re going to be able to get some value out of the product while it’s being deployed.  It’s true that there’s a good chance that you won’t have 100% deployment but the good news is that your system will be delivering some value to the organization even if you don’t.

Finally, work on breaking the trend of not using what you know on your own projects.  The best advice I can give you on how to be successful in implementing an enterprise project management system is to use all the project management techniques while doing so.  Almost everywhere I go, I find virtually no project management being applied to the project on implementing project management software.  Be the first.  Break the trend!

One of my own mentors told me a very long time ago, “You don’t like selling?  Too bad ’cause you’re either you’re either gonna be selling to them or they’ll be selling to you.” 

 There is a disdain for salespeople among many who think of themselves in more of an engineering context but my experience in the project management industry over the years has shown that my mentor’s comments to be more often true than not.  As project managers we are going to need to sell our story often and in many different ways.  Here are just a few project management sales opportunities:

 Selling yourself as the project manager
Audience: The PMO, Senior Management and/or the Client
Before the project even begins, you’ll need to convince someone that you’re the right person for the job.  Do you have the experience for this kind of project?  Do you have a resume of the skills and particular contribution you can make if they put you in charge?  What about the resources you’ll need when you take on the job?  Are you ready to make a pitch to management for the particular tools or assistance or people you might require? T his is your chance to sell that idea to management!

 Selling the proposal for approval
Audience: The Steering Committee
You’ve got the project but is it a project yet?  If your organization does project portfolio management then perhaps not.  Many organizations use a Stage-Gating system that starts before projects get very far.  Are you ready to make the case for your proposal to become a project?  Have you got a business case that lists the Return on Investment, the Strategic Alignment of the goals of this project with those of the organization?  Do you know how your proposal compares to others you may be up against?  How can you make your project look like the most attractive to the steering committee who needs to approve it.

While we’re talking about this kind of salesmanship, we should add the same for each and every stage-gate that the project will encounter.  You’ll need to present more than a barchart to get your project through the gate and into the next stage and that may mean preparing materials and a presentation to show why you’re ready to move to the next level at each review.

Selling the budget
Audience: Senior Management
Ok, you’ve got the project, but do you have the resources?  This is one of the most fundamental challenges for project managers and a remarkable percentage of project managers aren’t ready to make a case for the money they need.  Are you?  Do you have the backup research to say why you need each and every penny that’s in your budget?  How about a trade-off spreadsheet of less money equals less features equals less return on investment?  It’s an easy tool to understand and very few project managers think of doing it.  I’ll put selling the scope of the project and the timeline into this same category although you might have to make separate pitches for each. 

Selling the project for resourcing
Audience: Potential team members and Team/Department Leaders
It’s a miracle!  You’ve sold management on your project and you’ve got the money you asked for and a schedule you can live with.  Now who will actually do the project?  Can you attract the best team members?  Can you lobby the key skilled resources you’ll need?  How about the Team Leaders who might be in charge of those resources?  Have you thought of how you’ll pitch to them to get that particularly key resource?  What’s in it for them?  Why will your project need that person and how will that help the organization as a whole?

Selling any variance or change management
Audience: The Client
As you’ll know if you’ve read articles by me in the past, my favorite project management quote is from Napoleon Bonaparte who said “A battle plan lasts until contact with the enemy.”  That’s almost always true on a project.  When you do get some variance or there is a request for a change of scope, are you ready to pitch the idea to make the change to the client?  Perhaps what would be best is pitching the client to not make the change.  Do you have the materials, the logic, the presentation slides and the story that’s easy to understand and ready to deliver?  Perhaps it’s a time-to-market vs. feature-rich trade-off analysis.  Whatever it is, it’ll need to be easy to graph and easy to absorb.

Selling the end-product
Audience: The Client and/or End Users
Hurray!  Your project is finished.  Or so you think.  I can’t tell you how many project managers get to the end of the project only to find the client reluctant to accept what was created.  “But we made what you asked for,” says the project manager.  The client doesn’t see it that way and the project manager isn’t ready to sell the end result to the client.  Are you?  Have you been getting the client ready for what they’re about to receive?  Have you got materials that you can provide for sign-off, for the benefits that they’re about to get?  I’ll include here selling Phase 2 of the project because it often happens at client sign-off. 

Selling yourself as the project manager for the next project
Audience: The PMO and/or Senior Management
Finally, when the project is over are you ready to sell management on how great a job you did so you can get onto the next great project?  Did you collect data along the way of what you accomplished as a project manager and how you made a difference?  A lessons-learned document that gets widely distributed is a great tool for this.  Share your lessons with others but don’t forget to point out the things that worked along with what didn’t.  It’s a wonderful opportunity to explain the system you created or the tools you shared with other team members.

Regardless of what part of the project management cycle you’re in, the chances that you’ll need to do some sales work as a project manager is almost inevitable.  Do you have the tools and the skills?  Here are a few that I often find lacking when I interview potential project managers and even independent consult ants:

Presentation software
Whether it’s the ubiquitous PowerPoint or other presentation software I’m always stunned at the horrible quality of slide presentations.  Projected presentations are a fact of life.  If you don’t have the graphics and design skills to make your own unique templates, look for some online.  There are thousands of free templates and a low-cost investment in PresentationPro or other template warehouse is worth its weight in gold.  While I’m talking about presentations, learn not just how to use your presentation software but also some basic functionality of graphics software such as PaintShop Pro so you can capture and insert corporate logos or screen shots or pictures of the project.

Public Speaking
I spent about 10 solid years of being trained in public speaking and while that’s more than most people do, I talk to an incredible number of project managers who’ve spent no time at all.  If you can’t speak in front of a small or even mid-sized group, you’re always going to be handicapped as a project manager.  There are great training courses that are not tremendously expensive.  Join Toastmasters or Dale Carnegie or just look online but get a professional to give you some basic speaking and voice lessons!

Word Processing skills Document writing
A project manager has to be able to write a proposal or business analysis report.  Expecting that the spell and grammar checker on your word processor will do all the work for you is a fantasy.  I see a remarkable number of documents that are terribly formatted, poorly written and just plain hard to understand.  If writing is not your thing, you can sign up for a business writing class at your local college.  And, for goodness’ sake, learn the basics of your word processing package!

Even for skilled project managers, there are a few sales tools that you might not often think of but that can be invaluable.  Here are just a few that I see project managers collect very infrequently but that are incredibly impressive when used appropriately:

Data collected to make one of your sales points for any of the sales “opportunities”
Project managers who collect data along the way always do better at presenting it.  If you are thinking ahead to your next presentation then the more empirical data you have available, the more convincing you are.

Competitive Advantage
It is inevitable that when you are selling in one of the opportunities I described above that the people to whom you are presenting will be looking at what you’re presenting in the context of alternatives.  It’s very powerful to have thought in advance of what those alternatives are so you can present the competitive advantages.  You don’t need to talk about the alternatives such as other project.  But, you can still talk about those aspects of your project that would compare well against others.

Competitive Benefits
Aside from advantages, one perspective that even trained sales people often forget are the competitive benefits.  If you think of not just the advantages of your project over another but also the benefits that the organization will realize in your proposal vs. another you’ll already be head and shoulders above whoever else is presenting.

Surveys
There are so many free survey sites such as Zoomerang online but so few project managers use them.  I’ve seen experienced project managers leap ahead by collecting survey results.  The surveys might be for feature comparisons, interface element selections, timing or prioritization by clients or users.  I saw a fabulous survey done once just for icon selection within a software project.  Surveys don’t take a huge amount of effort but their results can make a very big impression!

Whatever the project, you are bound to run into some situation where you’ll need to become a project manager salesperson.  Learning the sales tools and skills even at an elementary level can make the difference between a successful project and one that’s less so.  So – get out there and do some selling!

Article: Deploying a Project Management System
Before we get to the installation, configuration and training on your new epm system, you should be thinking about what it should be doing for you and what you are hoping to accomplish.  This article will look at some of the key concepts in epm systems deployment.

3rd Party PM Tools and why they matter
Focusing just on Project Scheduling is rarely enough for an Enterprise Project Management system.  This article targets some of the 3rd party alternatives that you might want to consider.

Article: Chief Project Officer in a Business Process Reingineering environment
New CPO’s are often created as part of re-engineering the processes of the organization.  It’s a tough place to start because the impetus for changing the business’s processes are already well underway and yet ripe with opportunities to make a dramatic change in the way organization manages projects.  This article talks about how to walk the fine line between the challenge and opportunity of being a CPO in a BPR initiative.