The executive connection: white paper

This white paper is part of our "From the trenches" collection. It describes the importance of having executive involvement for a successful Enterprise Project Management (EPM) deployment. It describes reasons why a company might choose to not involve an executive in the deployment, how executives should be involved in the deployment, and tips on how to effectively involve an executive in the deployment.

To download the Word version of this white paper, see The Executive Connection.

To see more white papers, see "From the Trenches" white papers.

The Executive Connection

Over the years the most successful EPM 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.

No executives? How is that possible?

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.

Lack of executive knowledge of EPM

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.

EPM – that's a technology project

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 the associated products that make up the Microsoft EPM solution are a platform 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.

Certainly I'm committed (for about 10 minutes)

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 marshalled their forces around doing an EPM deployment completely and properly.

We didn't tell the executives

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 on 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.

I'd like anyone to be responsible for that (but me)

Some executives can see the depth that an enterprise project management implementation can represent and consider it 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.

How should executives be involved?

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.

I speak for those involved

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 that 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 to go 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.

I understand what is required of me

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 ultimate goals are reached. In my experience, when executives know what's required of them, they tend to rise to the occasion.

Next Steps

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.

Find the right executive

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.

It's a change management project

This might be the single most important factor in making an EPM deployment succeed. This is not to say that technology is not important. But we want management to appreciate 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. When management understands that, 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.

Use a lifeline — phone a friend

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 Microsoft Project Server, ask your vendor to set up a call with 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.

It's not just the tools

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.

About the Author

Chris Vandersluis is the president and founder of Montreal, Canada–based HMS Software, a Microsoft Certified Partner. He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca

If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (http://www.epmguidance.com/?page_id=39).