This seminar has been given at PMI and other project management events all over North America and now you can view it right here on EPMGuidance.com. This on demand webinar is free right here on the site. Go to the Improve Resource Capacity Webinar to see the whole seminar.
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 sheer 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 managers 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.
In 1966, the original Batman TV series came on the air. It lasted only 120 episodes but it changed a culture in ways that last to this day.
In the world of Batman and Robin (played by Adam West and Burt Ward), there was a ‘bat’ solution to everything. No matter what the problem, Batman would have the solution. The Batmobile, Batboat, Batplane, and Batcave all had their place. And if you were someone who needed help, no matter how difficult, how could you reach Batman? Well, with the Batphone of course! Pick up the Batphone and help would be on the way.
Commissioner Gordon would turn to the Batphone when things where hopeless, which occurred of course every episode. It didn’t matter how difficult the challenge, pick up the Batphone and in 22 minutes (plus time for commercials) the villain would be vanquished and Gotham City returned to peaceful status.
Every solution in the Batman world was made to look like a Bat. Handcuffs? Bat shaped. Utility belt? Bat logos. Grappling hook? Of course — looks like bat wings. To my surprise, looking back at images of the Bat phone it looked upsettingly normal. A red phone with a dial (remember those?) I’m not sure why it had a dial. It only called one place: The Batcave, where salvation was at hand.
As nostalgic as it may be to think of phones with dials and the old episodes of Batman, it’s really not the point of today’s article. It’s been 40 years since the Batphone was retired, but people make calls to Enterprise Project Management (EPM) consultants every day hoping the Batphone will work for just one more call.
Their villains are varied. Some are technical; they need to upgrade from version x to version y. Some are architectural; they need to make their internal EPM system talk to users in the outside world. Some are cultural; the users refuse to use the system. And some are procedural; the process they’re following doesn’t seem to deliver the result they expected.
No matter what the challenge, the request for the consulting firm is the same: Can you fix it in 20 minutes?
It’s a situation that a surprising number of EPM users get into — a situation where they urgently need assistance to get them out of a difficult situation. It’s often an emergency and the solution is required by management yesterday. The people who make these calls (I get a couple each week) are not feeble-minded. They are highly intelligent, capable, accomplished managers.
There is no Batphone, of course. I wish there were. I’d use it for all kinds of personal challenges. And so the people making these calls are rarely satisfied with the answers they get. So, let’s take a few moments and talk about how people end up in such a tight spot that they feel that need to pick up the red phone and how you can avoid being one of them.
First let’s talk about how people get into trouble while doing an EPM implementation. There are a couple of common causes:
This is, by far, the most common error in an EPM deployment. It’s not to say that every deployment must be large and difficult. That’s certainly not always the case. But, perhaps because of wishful thinking, it’s incredibly common to underestimate what it will take to get the benefits from an EPM deployment. The first error in underestimating is picking the target. Some people pick the installation of the tool as a successful project. It’s not, of course. Some people pick the first use of the tool or the first report that comes out of the tool as the target. That’s not it, either. A resolution of whatever problem(s) the EPM tools were chosen for is where you need to target. That means that the culture has changed, the training is complete, the usage is in production, the tools are working, the data is there. Yes, that may be a big thing — but if you’re one inch short of that goal, you’ve still got nothing. (Well, almost nothing, anyway.)
For those of us in the technology business, we’re most guilty of this and really, most of us know better. Yet, somehow, the temptation to believe that the availability of technology means the problem is resolved is hard to resist. So many organizations we visit say some variation of “but we’ve already installed EPM Software, why are our personnel still overloaded? As I’ve said for some time, making enterprise project management work is a combination of people, technology and process and a good deal of change management thrown in for good measure. That doesn’t arrive automatically when the software DVD rolls through the door.
This, too, happens very often. After all, the people who best understand the benefits of an enterprise project management system are most likely those who are struggling to analyze the vast amounts of data that come from an environment with many projects and many resources. Enterprise project management is most popular when an organization tries to reconcile a complex set of conflicting priorities and a myriad combination of skills and experience. You would think that management would naturally be involved in such a project but it’s often not the case. The challenge of changing the corporate culture from a single project mentality to an enterprise project mentality is almost impossible to overcome without them and yet all too often management is bypassed due to a worry that they will be unable to appreciate what it will take to get an EPM deployment completed.
There is no one who wishes that an EPM deployment will take a long time. And it’s common to hope that the project can be accomplished in days or a couple of weeks rather than the months that is most common. There is also a common challenge of not getting the resources for an “internal” project such as EPM as readily as a client-based or commercial project. For these and other reasons, it’s common to make a project schedule with resource requirements that are woefully insufficient.
If you’ve read anything I’ve written, the chances are you’ve seen this before. Project managers are susceptible to the “shoemaker whose children are barefoot” syndrome. The result is a common lack of a project charter, an approved budget, a tracked schedule, dedicated resources and all the other accoutrements for their own project that are common to all the other projects they manage.
Ok, that’s how people so often get themselves in trouble. The benefits expected by management from the deployment of an EPM system usually come directly from business challenges. It’s the promise of solving those challenges that bring management to approve the expenditures for software, hardware, infrastructure and possibly even services. The most common of these challenges may sound familiar:
It may not be clear what the resources are being spent on, but it’s very common to find that resources are overloaded. A more complex problem is finding that some resources are overloaded and others are under-loaded, which often indicates a mismatch between skills and experience available vs. those required.
It should be obvious that critical projects should finish when they’re planned, but life seems to interrupt such plans. This may be due to conflicting resource requirements, choosing too many projects that require too many of the same skill, or just bad prioritization. Sometimes organizations will think it’s a lack of skill of the project manager but in a multi-project, multi-department matrix environment, the more likely culprit is organizational in nature.
What holds true for the schedule can equally apply to costs. In high-tech as well as many other industries, the most variable component of a project’s cost is the amount of labor applied to it. Take a lot longer with the same people and you’re adding costs to the project. A stunning number of white-collar projects still remain untracked. They’re planned but the actual cost per project is not recorded.
In a competitive economy, being first to market can make the difference between survival and oblivion. So, for many organizations, making sure that your project management is at least as effective as your competitors is important.
Sometimes no answer is worse than a bad answer. If you’re in senior management this is particularly true. If you know the results are bad, you can apply your skills and the resources at your disposal to the problem at hand. If you know something is wrong but can’t tell what, you’re handcuffed. There’s no way to know where to try to fix something.
How do I keep out of trouble?
You don’t want to ever get to a point where you feel you need the Batphone. So, what can you do with your EPM environment to ensure that you don’t end up there?
Okay, everything we said in the first section is obvious:
What else can you do?
First of all, start the project with an appreciation that at some point in the future, you’re going to want to use the Batphone. You are. Knowing that, one thing you can do is to budget for assistance that you have no current plan for. We recommend that our clients budget 10% to 20% of the project for “unallocated requirements”. “What’s that for?” we’re always asked. “You’ll tell us later,” we always answer. It’s common to not use all that money. But it’s also incredibly common to use some of it. Having a skilled expert already allocated and budget for your project makes a huge difference later.
Start with the expectation that the plan and the people will change. My favourite project management quote is from Napoleon Bonaparte, who said, “A battle plan lasts until contact with the enemy.” It’s true of EPM plans, too. Given that an implementation is likely to last several months, the chance that some personnel will change in the plan is enormous. So, plan for redundancy.
EPM systems evolve. It’s common these days in an enterprise application to think of the “total cost of ownership”. I think we should include the total application lifecycle in our EPM project plans. Have you thought about what version of a tool you’re about to implement? Did you think about what other tools it depends on? How about the regular update/upgrade of those tools? Did you do customizations? How about customized training? Did you think of how those things will migrate to a new version should you deploy one?
Plan for redundancy of your experts, also. If you have a single consultant working for you, what will happen in a few months as you move to a new phase of your implementation or introduce a new key member of your team? Will that consultant be available? (Consultants move from one project to the next so the answer is often, “no”.) If you work with a consulting firm, have you talked about how they can preserve the work of their staff to have others replicate it, if necessary?
One of the most common and easiest-to-fix challenges comes from poor documentation. It’s the easiest element to short-change but the existence of such documentation can make the difference between going back to a written reference and looking around for the Batphone. It’s also not enough to write a document and stuff it into a drawer somewhere. Documents should become part of an ongoing record and your EPM process might reference them as part of a regular review process. Here are some of the documents for an EPM environment that I think are most critical:
I don’t know what it is about the original business case that makes it so unattractive, but it’s the most common thing to lose track of and in many respects, it’s the kernel of why you have an EPM environment in the first place. The business case notes what the expected organizational benefits are; what does the organization expect from the EPM system? When we get a Batphone call, one of the very first things we ask is, “What is the system expected to be delivering for you?” We don’t just ask the administrator. We also ask management, the users, and the business beneficiaries. The most common answer is a different answer from each party. That’s because the original business premise has become lost.
In the last version of roles and responsibilities, we often resolve to an individual’s name, and it doesn’t take long before the role that that individual plays in the EPM system is forgotten. Keeping a roles and responsibilities document will allow you to adjust the parameters of who does what in the EPM process as the organization naturally goes through personnel changes or even organizational structure changes.
This is often forgotten when we get down to procedural guides. People are left with the “What-to-do” steps in a procedural manual but not the context for why those steps are important and what we do with the result of each step. A process guide and, best of all, a visual flowchart will let future managers understand what the system provides and make it much easier to adapt the system in the future.
When you choose your EPM system and any third party tools you may have selected along the way, let future generations know what your decision was based on. We’ve gone into organizations 5, 7, or even 10 years after a system was deployed and seen a system with several tools associated with it and asked “Why are you doing that? It would be much easier doing this!” The reasons for those decisions are nowhere to be found. In some cases the client has spent years doing something in an extremely complicated fashion that could have been so much easier given more current versions of existing tools. They can’t make an easy decision to change a tool or use a more current version because they no longer have access to why they chose to do something a certain way years ago.
Finally, you really need to use the Batphone. Ask around. Don’t ask just one consulting expert and don’t get just one possible solution. Ask your colleagues or others in industry who they know who might take a Batphone call, and talk to at least two of them. It’s a good reality check to see how one expert vs. another might deal with your problem. Remember, Batman may have been amazing, but there are many superheroes to choose from!
Over the years the most successful Enterprise Project Management deployments I’ve been involved with have always had a strong executive connection. In comparison, those deployments which have been the most difficult, have been those where our connection to senior management was kept at arm’s length. It’s made me do some thinking about what causes executives to be more or less involved and what recommendations I can make to organizations at the very earliest stages of an EPM deployment with regard to what kind of executive involvement should be required.
Let’s talk first about how it could possibly come to pass that executives wouldn’t be intimately involved in an EPM deployment. After all, EPM stands for Enterprise Project Management. Shouldn’t there be someone who is representing the enterprise in the project? You would think so. But, in many organizations there are numerous reasons why executives would not be involved.
The first and most likely reason is a lack of understanding of what project management is all about. Old school executives sometimes have little project experience and what experience they do have leads them to think of project management as a very tactical, in-the-field, type of exercise and not at all a strategic exercise. When the need for enterprise project management arises they are often surprised that recommended initiatives require a lot of time, a lot of effort and a lot of money and certainly don’t think their personal involvement should be required.
Project Management infrastructure projects are often thought of as overhead and, while upper management often has a great desire for the results of such systems and processes, they are rarely keen to invest in them. This isn’t helped by how the project management industry must ‘sell’ such projects internally. In a Quality Assurance (QA) manufacturing example, it’s common to recite hard savings dollars for what can be achieved by improving quality by a couple of percentage points. Project Management doesn’t have this luxury. Project Management savings are always a cost-avoidance savings and much harder to prove directly. As a consequence, project management projects take a lot more internal effort to sell than some others.
Another common pitfall is to think of an EPM project as primary a technology project. “If we buy this software, we’ll have enterprise project management.” As I’ve said in my column before and as has been echoed by virtually everyone in the project management industry, this simply isn’t true. Enterprise project management products like Microsoft Project Server and its associated products or Oracle Primavera EPPM or almost any other EPM system are platforms from which the automation of enterprise project management can occur. They can be thought of as the tools or the medium through which EPM benefits will arrive but they are not, in and of themselves, the solution. A successful enterprise project management solution must be crafted with processes, the skills of the personnel, practices and procedures, standards and often, with technology that is designed to empower those processes, people and procedures to make it more efficient. However, there are many project management software vendors on the market and their message talks about the benefits clients have achieved while using the EPM tools purchased so perhaps it’s not surprising that some executives believe that the tool is the solution.
Some executives do sign on as an executive sponsor for EPM projects and are generally upset when someone like me arrives to announce that the project will require their commitment for 6 to 24 months. “How could this not take more than a few days of training?” they ask. This often comes as a result of a complete misunderstanding of the fundamental nature of an EPM project. Once they understand that the deployment of a working EPM environment will include changes in process, in day-to-day procedures, in the way resources are allocated and even in how projects are selected, it’s not uncommon to have senior management take a step back to regroup. Several times I’ve been called into a company a year or more after meeting them for the first time to find that the company has a newfound respect for what they need to do and have now marshaled their forces around doing an EPM deployment completely and properly.
This is all too common. I get numerous calls every year from personnel within an organization who are working in a project management capacity and who can see an urgent and significant need for enterprise project management yet who have no executive support for the project. They hope they can work under the radar and quickly create an enterprise project management environment before anyone notices and then present this new process and system to management nicely wrapped with a bow. This is the ‘throw it on the wall and see if it sticks’ method and it is almost never successful.
Those who try to establish an enterprise project management environment without the support of their management run headlong into all the things that require senior management before they’re out of the gate. EPM after all is often done to improve resource capacity planning, improve portfolio management, improve inter-project impact and improve intra project collaboration. Almost none of this can be changed without the intervention of management. Also, those who are most interested in this kind of approach have significant project management challenges that they are trying to address. It’s inevitable that those project management challenges are centered around other departments and personnel who have a vested interest in not changing.
In a matrix organization for example, it is common to see conflict between the resource managers and the project managers. “If only we could be more projectized,” becomes the battle cry of the project managers and it is at this point that someone like myself gets a call asking if we could quickly (on the order of a few days) assist them with creating an enterprise project management environment. These exercises are sometimes labeled as “Proof of Concept” projects and the first thing we tend to ask is, “What are you trying to prove?” The best thing to do with these kinds of projects is to bring management in on the conversation early and expose the causes of project management not being as effective as possible and to make a plan together on doing an enterprise project management deployment.
Some executives can see the depth that an enteprise project management implementation can represent and consider the project a career risk to involve themselves. So, when the project management office or the middle management who have been tasked with creating an EPM come to the executive suite looking for support, it can be hard to come by. This is often the result of a lack of understanding of how key executive involvement is in making this kind of deployment a success.
There’s no one right answer to that question. Each organization I’ve encountered has a different structure, different personalities and different requirements. What works in one organization sometimes doesn’t work at in the next. So, it’s impossible to say “It’s the Chief Information Officer who must always be the executive sponsor.” and have that be accurate for every company. Here are a few things about executive involvement in EPM projects that I’ve found over the years to be common among most if not all organizations I’ve encountered.
When we define which resources will be involved in the enterprise project management exercise, it’s critical to have executive commitment from someone who has authority over everyone involved. I’ve got plenty of examples of this both in successful and unsuccessful attempts.
In an EPM deployment I was involved in many years ago, we were working with the blessing of a senior director of a high technology engineering company. It started out with great excitement from both ourselves and the project management office of the client. We should have been less excited and more insistent on who was implicated in the whole exercise as we found out about half-way through the deployment that this senior director while highly committed himself, was only one of five such directors who controlled the personnel who were implicated in the deployment. When we pointed out that we’d need consensus and support from all five of the directors, the project ran into trouble quickly. Attempting to petition the VP of Operations turned out to be unsuccessful as three of the five directors felt they would lose control of their groups if the EPM project were go to forward and were petitioning the VP at the same time as we were. In the end, we had to settle for a reduced scope and a much longer period before the company could start enjoying the results of the enterprise project management environment we’d created together. The client ultimately would be satisfied but we were not. It was a good lesson in not getting too caught up in your own enthusiasm.
In another project I am still involved in, we were working on the EPM environment in organization’s IT department. I met the CIO during our very first meeting and he understood what would be required of him right away. Within a few weeks, the very first stages of an EPM environment was established in the IT department he controls. It started producing some results immediately and the organization has expanded the effort over the last five years to make the system more and more valuable. Now the organization is moving towards portfolio selection and we are working with them again at the most senior levels of management. There was concern from the project management office and even the CIO that there might be resistance from the senior executives to involve themselves in the process when we scheduled our first meeting but the concerns were unfounded. It turns out that the executives were ready to accept the responsibilities that I outlined to them. We consider this client to be a big success story and they have been references for us for many years.
Trying to tone down or minimize the effects of an EPM deployment is ultimately not productive. I’ve seen many people try to minimize the implications of an EPM deployment to management to get at least some support. This is often because the people who are trying to garner support from the executive suite are concerned that the project will appear too complex, too expensive or too risky to get any support at all. The theory is to get some support to do something, no matter how minimal and then hope that the environment can be expanded over time. I’ve always found that working with the executives to show them exactly what is required of them and if necessary, educate them on what will be affected is much more productive. After all, executives typically don’t get to be executives if they’re stupid. For all the concern I’ve heard over the years over how when I meet some executive or another they may not understand what I’m trying to say, it’s never happened. The executives I tend to meet are interested, highly intelligent and ready to take action. What they are not is endowed with unlimited time. So, I make sure to make my point succinctly, ask for what we need and not put demands on the executive that can be handled elsewhere. However, I also don’t pull punches in terms of how long it might take to get return on investment or how long until the ultimately goals are reached. In my experience, when executives know what’s required of them, they tend to rise to the occasion.
Are you working on an EPM deployment right now? Are you wondering how you might involve your own executives in deploying enterprise project management? Perhaps you are a senior executive and you are wondering what you can do to help ensure a successful EPM deployment. Here are a few tips that may be valuable:
Finding the friendliest executive isn’t always where the search should stop. We look for a couple of criteria to ensure we’ve got the right executive involvement. First, we look for the person who has authority over the resources that will be implicated. If the EPM project is for the IT department, that’s usually the CIO. If we’re talking to a matrix organization, we may be looking for the Director of Operations or the CEO. A “committee” of executives is usually a red flag unless there is a clear chain of command over who will make decisions within that group. If the group is made up of several executives who are all peers we’ll ask for someone who manages the group to attend also. So, sufficient authority is first. Next, this someone has to understand and be committed to the benefits that the EPM project represents and the effects that may result. If there is no desire to change the way resources are allocated then a desire to change resource allocation to be more effective is moot. So, getting that onto the table immediately is important.
This might be the single most important factor in making and EPM deployment success. This is not to say that technology is not important but when management appreciates that what we are about to do is change organizational behavior and that some of the factors involved may reach deep into how all kinds of aspects of the organization will function, we get a huge level of respect for the project and much better support. After all, if EPM is desirable, it’s because there is a need to change how some fundamental business decisions are made. These decisions might include how resources are hired, or how projects are selected and almost certainly how projects are prioritized. In an organization that does projects (as any organization interested in EPM would be), this ultimately affects almost everything.
Just like popular contests, sometimes the best thing you can do is reach outside yourself to take advantage of others who may have a perspective that would be appreciated. We’ve always found that one of the most productive things we can do with an executive is to set them up to meet other executives of their stature. Executives typically really appreciate being able to talk to others like them who have or who are facing similar challenges. There are restrictions in some cases of course. You typically can’t have senior executives of direct competitors talk and those in certain industries like defense have some restrictions but in almost all cases you can find other executives who will take the call from your executive over what worked in an EPM deployment. Not sure where to find such people? Your local PMI (or similar organization) chapter is a good start. Listen for stories of those who have completed successful EPM deployments and ask if your VP could talk to their VP. You’ll be surprised at how cooperative most people are. If you’re already looking at technology such as Project Server or Primavera, ask your vendor to set up a call with a client who has had a successful deployment. They obviously have a vested interest in getting your executives hooked up with executives who have successfully completed an implementation. If you do this, don’t get too hung up on what version of which tools got implemented. It’s the overall process of executive involvement that needs to get communicated.
Try to avoid the pitfall of thinking that just the tools without the process will fix your enterprise project management challenges. Some executives I meet are enthralled with thinking that the delivery of project management software constitutes the working solution. To those people I usually ask this:
“If I were to go to the local Do-It-Yourself store and ask for a kitchen,” I’ll say, “and someone were to bring out a big box of wood, nails, glue, paint, and tools would they have delivered?” I think not. They might have delivered the potential for a kitchen but I wouldn’t be able to immediately make myself a sandwich. To do that I’ll need the wood, nails, glue, paint and tools but I’ll also need some skills, some knowledge, a plan and some time. Now, could I figure out myself how to make a kitchen? Sure, given time and a lot of patience. But, if I want a kitchen a little quicker, I might consider working with a contractor to help.
Ultimately, having executive support from an executive with the authority and the commitment to make your enterprise project management deployment a success is a critical success factor, but you really knew that already. After all, in any major project in your organization you’d have that executive sponsor as a natural part of how you manage projects. It’s only easy to forget because it’s an internal project and in so many cases, we forget to apply what we know about project management to our own internal projects. In this case, make an exception and get the right executives onboard as you move forward with your own EPM deployment.