Author: Chris Vandersluis

The Executive Connection in Enterprise Project Management

Written by Chris Vandersluis on February 24, 2010. Posted in Articles. 3 Comments on The Executive Connection in Enterprise Project Management

executiveconnection When I write about enterprise project management implementations, I tend to speak often in articles I write about making sure you have a good executive sponsor or support from the executive branch of your organization, (but it’s rare for me to talk about just how executives get involved in an epm initiative). Let’s correct that today.

Senior management can be either a help or a hindrance to an epm project and the deciding factor has everything to do with the preconceived notions the executive or executives in question bring to the table. Let’s take a look for a moment at the possible states in which you might find the relevant senior executive for your epm deployment.

What Senior Executive?

In some organizations, there’s a challenge in just identifying such an executive. It’s not that there’s not senior management involved, but the notion that enterprise project management is something that the enterprise’s executives need to involve themselves in is foreign. So, the project management staff struggle to find someone who will champion their cause in the executive suite. This can be complicated by the very common organizational challenge of having the Project Management Office designed as a dotted-line responsibility with really no direct chain of command over where they fit.

Why Isn’t It Done Already?

By far the most common challenge I encounter when talking to senior management is a gross underestimation of how big a challenge en EPM deployment might be. An appreciation of the processes that must be either created or adapted, the number of people within the organization who will be affected and the degree to which an epm deployment can change basic business practices is often lacking. I can’t possibly describe how many times I’m asked if the epm deployment could be completed within a week or 10 days. Or, after having given a proposal for several months of work that I’ve been asked. “Ok, so what could you do within 5 days?”

Didn’t I Buy Software for That?

Often the preconception from senior management is that epm is a tool issue and if they’ve signed the purchase order for the software then epm should have arrived already. This preconception isn’t helped by software vendors who call their tools “EPM”. Microsoft sells a product called Microsoft Project and another called Project Server but the combination is referred to as the Microsoft EPM Solution or just EPM for short. It’s easy to get an executive who confuses the two conversations, one being for the software, the other being for the whole concept and have him or her say “But I bought EPM already.”

That’s an Overhead Project

This may well be true but the implication is that an epm deployment must be done in spare time rather than being a strategic initiative. The problem with this is that the resources, the time and the money that will be required to give the project a fighting chance will be either impossible to come by or (more likely) will get reallocated at will in mid-project.

I’m Fully Committed to the Project… (for the next 10 minutes)

I see this quite a lot. There’s an executive in the kick-off meeting for the epm implementation who indicates that he or she is “fully committed” to the project. But, when I ask them how long they expect they’ll need to be involved the response is measured in days. When I tell them they’ll probably need to have active regular involvement in the project for 6 to 24 months I often get a jaw-dropping shocked look.

Let’s Get it Right the Second Time

It will sound odd, but I’m often quite happy to arrive at an organization for their second try at deploying enterprise project management. It’s not like I’m delighted for the first failed attempt but often an organization that has tried to implement epm unsuccessfully takes it much more seriously the second time around. When I arrive at such an organization and meet an executive who saw how the project didn’t work the first time, it’s often much easier to establish a partnership.

Ok! So those may be the most common preconceived notions that we encounter with executives, and if you are an executive or know an executive you may even recognize yourself or others in the descriptions above. That being said, how do you go about getting appropriate executive support for your implementation?

Find the Right Person

Sometimes just finding the right executive is more than half the battle. It’s possible that given your organizational structure that you’re stuck with whom you’ve got, but in some organizations there may be more than one executive who could be approached as the sponsor for this project. Choosing one with more experience or a willingness to understand the complexity of the project can make a huge difference.

It’s a Change-Management Project

There are two easy pitfalls to avoid. One is agreeing when senior management qualifies the project as a “training” project. The other is to not agree when they try to qualify this as a “software” project. Neither is true. The big challenge with deploying epm is not the training or the software. Both of those are a few days of work. The challenge is the change-management aspect. Implementing epm, if successful, will change how people work. It will fundamentally change how certain business decisions are made. It’s when senior management really understand that how they approach the project is immediately very, very different.

Use a Lifeline – Phone a Friend

One of the best things you can do is find a way to connect your executive sponsor with a counterpart in another organization that has successfully deployed epm. If you’re looking at software, the software vendors will hopefully be able to point you to some good references. If not, then networking with your other project management colleagues and asking for assistance in doing a site visit can make a world of difference.

Ultimately the most important thing you can do to get proper sponsorship is something I’ve recommended in different ways many times before. Treat your enterprise project management project like a project. I know, it sounds strange right? It’s not. Make sure your project is aligned with corporate strategy. Make sure it has a budget. Do you have a charter? A schedule?

Doing the project management things you already know how to do in your own project infrastructure always makes the most profound difference of all.

Don’t forget to leave your comments below

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected].

Enrolling the Reluctant Enterpriser

Written by Chris Vandersluis on January 27, 2010. Posted in Articles. 3 Comments on Enrolling the Reluctant Enterpriser

reluctant1 “Resistance is futile” was the battle cry of the evil Borg from Star Trek. Sometimes I’m sure there are PMOs that wish they could be as convincing to fellow colleagues who are resisting the deployment of enterprise project management and enterprise project management systems.

Getting the job of deploying an enterprise project management environment is not the best news for some people who have to complete that project within an organization where there may be a great deal of reluctance to change how projects are managed. Almost every week I’m in some meeting where a frustrated project manager is asking my advice on how they can convince the rest of the organization to embrace the new project management thinking.

Where Could We Go Wrong?

If you have just been assigned such a project, then the first thing to know is a few of the pitfalls.

I talk to a lot of people about project and timesheet systems, given the business I run, and one of the most common pitfalls has to do with enterprise project management software. “If you build it, they will come” is a common theme from those purchasing such software. I have met with numerous CIOs who have already concluded the purchase of a centralized project management tool and then call me to ask if I can “make it work” for them. I have to ask why they purchased the product. The answer inevitably is “Because it will help fix our project problems”. I have to ask if there is a design for how this particular tool will fix those problems, if there is a list of the ‘project problems’, if there is a process in place on which to base the use of the new tool. Even among very educated people, there is often an excessive dependence on technology to fix project management problems. A big pitfall then is thinking that the purchase and installation of some project software will do all the fixing for them.

A second significant pitfall is the reluctance of some executives to take a leadership role in the deployment of an enterprise project management environment. “Let’s manage by consensus,” goes the theory. Consensus is a wonderful thing if you don’t like conflict. A decision is left before a group of the rank and file. They won’t take a vote and choose based on the majority. They won’t choose a leader and do what the leader decides. They won’t have a leader imposed on them by a higher authority and do what that person directs. They will discuss, debate and eventually arrive at a decision that the whole group can agree on. There will be no conflict because everyone will have agreed. This may work well when picking a color for painting a room, but I can tell you from experience, it’s rarely successful when designing project management software. The most likely result is that the design will have accommodated every little request of each and every user to a point that the design is so complex as to be undeliverable or wildly beyond the budget. Or, that there is no consensus because of the investment members of the group have in avoiding change. Consensus is often a way for executives to avoid commitment. Turn the problem over to the employees and ask them to come up with a plan that everyone agrees on. It avoids conflict to be sure, but it also avoids creating a process that will make the entire organization more effective.

The last pitfall I’ll mention here is to avoid the Fifth Column. The Fifth Column is a term that comes from the Spanish Civil War circa 1936 when General Mola claimed to have a fifth column of military in Madrid while he was attacking with four columns from outside the city. We tend to use the term these days to refer to a clandestine element within our own organization that says it is our ally but, in fact, is working to subvert our objectives. Some executives tell me “our people will comply if I darned well tell them to,” when I ask how we will deal with support within the organization for an enterprise project management environment. But there are a lot of “Fifth Column” techniques for avoiding doing so. The most common, and for me, the most difficult to deal with is the middle manager who nods his or her head in agreement at every single meeting but then will take no action to support the project in any way.

A successful plan

Is it hopeless? It certainly is not. If you have the job of enrolling the reluctant enterprisers, there is a lot you can do. Here are some of the most successful techniques we’ve seen:

First make a plan. I know, I say that in some way in almost every article I write. The reason I say it so often is that it’s still the most common error I encounter. People often end up starting an enterprise project management project without a solid plan. They don’t “ready-aim-fire”. They “fire-fire-fire”. They are in action almost instantly, choosing an enterprise project management product, hiring skilled project managers, responding with action to management’s desire for more decision making tools. Then everything that happens subsequently is a reaction to not having had a plan in the first place. So, make a project plan. And, do all the things you’d normally do on any other project on this one too. That might mean creating a charter, getting a budget, having a schedule, choosing some milestones and so on.

Secondly, get some friends in high places. I’ve been around a number of EPM deployments lately where there is no management support at all. In one meeting, the vice-president who had started the initiative had deliberately avoided any meetings with the people involved because they didn’t want to interrupt the consensus building of the group. In another situation, the senior executive didn’t want to attend key decision-making meetings because they didn’t want to leave some employees who were not invited feeling like their fates were being decided in their absence.

It’s critical to have the support of some or all of senior management. If you don’t then the chances of success of the project drops quickly. Think of it like this. The project management process in most organizations will affect almost every part of the organization. Doesn’t it make sense that the senior management should play a significant role in redefining that process? The project management process for many organizations includes having an executive sponsor to shepherd the project through the senior management ranks. This project deserves the same.

Once you’ve got your plan, communicate it. Then do it again, and again, and again and again. Communicating how the plan is going to work, is working so far and how it worked yesterday will all go a long way towards enrolling those who might be worried about how the new enterprise project management environment will affect their jobs. Since EPM is always an evolving and adapting process, there should always be a little time reserved for communicating about it.

While some senior managers may believe they can come down and knock some heads together to get compliance, it is rarely successful. So, think in terms of more carrot and less stick. Instead of imposing big penalties on non-compliance, why not look to how you can improve the return on investment of each person who interacts with the new EPM environment. What can you give them that will make their life better and more effective?

Finally, try to have your plan deliver bite-sized pieces. Getting started small and gradually expanding the new process is inevitably more successful than trying to create a massive plan and delivering it all at once. There are a lot of reasons for this but one of the most important is that the very design you’re trying to create will be changed by implementing it. The needs and interests of the organization will evolve, and changing such a fundamental process might have it evolve significantly. If you’re deploying your new EPM system bit by bit then you can adapt each parcel of it to the changing needs of the people it must serve.

On Star Trek, the Borg were never defeated head-on with a brute show of force. But they could be overcome with finesse, using guile, creativity and perseverance. Those qualities will hopefully serve you well as you work on enrolling your reluctant enterprisers.

Don’t forget to leave your comments below

How Data Display Can Change Project Decisions

Written by Chris Vandersluis on December 16, 2009. Posted in Articles. 3 Comments on How Data Display Can Change Project Decisions

Anyone who has worked with project management systems knows that the way you display data can dramatically affect the decisions people make from it. This is why we often see Gantt charts with critical activities in red. I’m reminded of one of my very first sales of project scheduling software back in the ’80s. I don’t dare share the name of the organization but it was a large utility. We’d made this sale a few days earlier and now I got a call for “technical assistance.”

“I have a big problem. All my tasks are red,” the hapless client reported.

“Oh, that’s not a problem at all,” I replied. “Red tasks just mean that you are looking at the critical tasks. These tasks have been marked as red because they are on the critical path.”

“That’s another thing,” said my new client. “That word ‘critical’. That’s not going to work for us.”

There was a moment of silence. I was speechless. (For people who’ve met me you will know how unusual this is.)

“Perhaps the word ‘priority’ would be more appropriate,” I hesitantly replied. “Yes, that’s excellent!” said the client. “Now, what can you do about changing these colors? I need to get rid of these red tasks”

For those of you who have grown up with critical path methodology you might laugh. “This person needs training,” you might say. But I learned something very important from the interaction. My first reaction was to think that we needed to get in there right away and train people to distinguish between red tasks and blue tasks but I realized that the problem wasn’t his, it was mine. His perspective was that red tasks were a problem and that he’d have to take action to eliminate all the red from his report before he could give it to management. If you’re familiar with the critical path algorithm, this was going to be a problem because there are always tasks which are critical.

The challenge for the user wasn’t trivial. Even if I had trained him, he knew that his management would not appreciate the distinctions of critical vs. non-critical and would see red tasks the way a bull sees a red cape – they’d want to charge at them with as much force as they could muster.

When data moves beyond highly skilled users and into the hands of people who will interact with it only occasionally, choosing the display mode of the data is extremely important. In this day and age, the desire of management to get “real-time” dashboards and “live displays” of projects can lead to unhealthy project environments. Let’s consider the following very simple dashboard

howdatadisplay1

The situation here seems quite straightforward. Project 1 is running very late, Project 2 is slightly late and Project 3 is on time.

Showing this display instead of a complex bar chart might be very appropriate to management. This display will draw attention to the schedule of Project 1. What should be done? Most managers would now query the project manager of Project 1 to ask why the project is late and what can be done to get it back on time.

That’s great so far. But next week when management sees the same report, is the same action appropriate? Probably not. Just having displayed the dashboard once has changed its context. If we display the identical dashboard with identical results next week, management will be likely to ask a very different question: “Have things improved since last week?” The display doesn’t show this.

So, we have the same data, the same author of the data, the same display, the same reader of the data but the reaction is quite different. This is because the context is very important. The manager of the project system has a couple of choices now. He or she can make a report that shows a year of icons for this display so the time factor can show management when the task becomes red and then goes back to the yellow caution and hopefully then to green. Or, they can try something like this:

howdatadisplay2

Now both Project 1 and Project 2 are significantly behind schedule but we’ve added a new indicator to the graph. Now the trend of the scheduled delay is displayed. The eye naturally goes to the two red Projects: Project 1 and Project 2 and then to the right where we see that the trend for Project 1 seems to be improving and the trend for Project 2 seems to be getting worse. Also a concern is now Project 3 where the schedule is still on time but the trend is very much in the wrong direction. It looks like resources have been pulled from Projects 2 and 3 to work on Project 1 which is improving at the cost of the schedule of Project 3.

This is all still pretty good now but you can see how the paradigm of such data expands exponentially. There is nothing quite so attractive to senior management than coloured dashboard indicators and there’s a whole industry of people making indicators and formulas to drive them. In the simple example above, new indicators might be ordered up in a heartbeat. Was the improvement in Project 1 actually done at the cost of Projects 2 and 3? What was the relative return on investment of working on Project 1 instead of 2 and 3. Perhaps this red indicator caused us to move resources from our most important client to our least important internal project. How was the move of resources to respond to the red “X” in Project 1 aligned to our strategic goals? What did it cost?

Before you know it we’ll have a page full of symbols, curves, flashing lights and glowing buttons. There are a few other things missing from the whole display that are often overlooked. They can be summed up as timeliness and completeness.

Are we looking at all the data? Perhaps the project schedule is showing late but only half the tasks have been updated and when the data is all collected, the indicator will turn green. There’s no indicator in this simple display about how complete the data is or isn’t.

Is the data up to date? Perhaps Projects 2 and 3 were updated yesterday but Project 1 was only updated 90 days ago. Should they even be displayed on the same page? The data might no longer be relevant when comparing one project to another, yet there is no indicator on the display that the data is all homogenous.

When we create display systems such as dashboards and summary reports we have to consider these things. I have a couple of basic rules about dashboards:

Less is more. Just because we can measure a thing doesn’t mean we should. Imagine a page with 500 coloured indicators with 100 different shapes being used. That’s obviously visually stimulating, but will it be useful? Almost certainly not. Yet, a page with one color on it (just red for example) isn’t useful either. That tells you to get into action but not where.

There must be action. Every indicator should be able to have a related action to it. E.g. If the traffic light is red and the arrow beside it is red, then the VP must call the project manager immediately and review an action plan for getting back on track.

The indicator must have quality. We have an expectation that project data that is reviewed by management has already been approved in some way. Yet management often asks for real-time dashboards that show data long before it’s been reviewed or approved. Showing the quality of the data by either showing the level of approval, completeness or timeliness right on the dashboard, or through some other process, is key to being able to count on the decisions that will be made from the data.

The indicator is made for a particular audience. Making graphic dashboards with coloured, animated flashy graphics is fun and, in this day and age of technology, not that hard. Designing such a display that makes an organization more effective is much tougher. So, every display we make is written with a particular audience in mind. Who will read this display and what will be their context for the data.

The way you display data and what you display can make decisions and action possible that was impossible in the past. By the same token, a badly designed display can cause decision makers to make the incorrect decision inadvertently. So, think about what action such displays will cause as you’re designing them.

Don’t forget to leave your comments below

Restarting Projects; Get Ready for New Challenges

Written by Chris Vandersluis on November 18, 2009. Posted in Articles. 5 Comments on Restarting Projects; Get Ready for New Challenges

restarting-projects1 As the economy slowly recovers, project teams are facing an unusual challenge. Management is coming to project offices, and to product managers, and asking them to “restart” projects that were suspended some time ago due to economic concerns.

Restarting a project can be infinitely more complex than starting it originally. The original project plan might have been created with great care over an extended period but the assumptions that play behind the scenes in any project may have changed dramatically. Management may not be aware of the challenges the project might face. Here are just a few:

Those Experts? They’re Not Available

The personnel in place when the original project plan was created may no longer be available. They may now be involved in other projects. They might have moved positions and be in other roles within the organization or they might have left the organization altogether during restructuring. It is not uncommon to find that when restructuring is done on a large scale that one of the most common departures are people who are near retirement age. This is particularly true in large organizations. Not surprisingly, these long standing employees often have unique key skills and experience that the project was counting on when the original plan was created. You’re going to have to go back to your resource plan to see what has changed and even redo a skills inventory, if there have been big changes.

Those Sub-contractors? They’re Doing Something Else

Suppliers of all kinds may have changed in the last two years. That includes sub-contractors that you might have expected would be available at critical moments of your project. Also, the suppliers that you used to deal with often might no longer be in a position to supply the expertise, product or service you were counting on. In some cases, the changes might be positive ones. Some suppliers may have used the intervening time to sharpen their operations and now be in a position to supply what you’d counted on at a reduced cost or with less delay. Either way, you’re going to have to go back to any sub-contractor assumptions in your schedule to see what may have changed.

Where’s the Funding?

Funding options have dramatically changed in the last two years. Money might not be more expensive to get but it is almost certainly harder to get. This can result in significant challenges getting funding from the same sources or under the same conditions that existed two years ago. If your project is multi-national then funding sources may be even more complex in different jurisdictions.

Game Changing Regulations

While the private sector has had tremendous challenges in the last two years, the public sector has also undergone changes of a different sort. Governments are requiring more transparency in anything they fund, and with so much recovery money coming from governments recently, you may find you have more reporting regulations than you had to deal with previously. Make sure that you do a review of regulatory and permit requirements that may have changed on your project.

Governance

Sounds like government but it’s not. Governance is about good management and there’s a newfound interest in it in the last two years. “What will we get for our money?” is something that every responsible manager now asks. That’s true not just for your own management but also possibly from your client, the bank and the government. Your reporting requirements for your project may have to be adjusted to comply with new requirements.

Return on Investment Factors Have Changed

I’ve been talking about the “I” in ROI while discussing how the costs of the project may have changed. At the same time it’s worthwhile to think for a moment about the business key performance indicators that may have changed. For organizations that use a Stage-Gate structure, the metrics that got the project through one or two gates may no longer be accurate. Is the product or output of this project going to produce the same value as it was expected to when the project was suspended? Are the prospective clients still prepared to pay the same amount or purchase the same volume of the project’s product as you had expected in your original business case? This has to be reviewed.

But, it’s not all bad news!

For some organizations, a pause or slowdown is an opportunity for the Project Management Office to shore up the project management expertise and tools. Many PMOs I’ve been in contact with in the last two years have been using the time to expand project training, to deploy project management products, and to develop project management best practices. Some progressive organizations used projected management during the economic downturn as a method of being more efficient. This paid immediate dividends while the company was under pressure to perform more effectively but there are additional dividends to be had as the economy improves.

Being efficient never goes out of style.

As projects need to be restarted in these organizations, the newly developed best practices can be applied along with any new tools. The additional project management training these organizations have acquired can be used to review those old project plans from a new perspective.

As organizations slowly open the taps of production again, it will fall to project management to ensure that we don’t assume we can just start up where we left off. It’s a relief and a happy day when management makes the call to say, “Time to get restarted.”

But…

Re-starting is often going to mean Re-planning.

Don’t forget to leave your comments below

Matrix Management Gone Awry

Written by Chris Vandersluis on October 21, 2009. Posted in Articles. 4 Comments on Matrix Management Gone Awry

In a remarkable number of companies I visit, fledgling internal project organizations revert towards hierarchical structures. The organization becomes managed through the department or organizational structure and project managers become attached to that structure rather than an independent project office. The PMO devolves to a reporting function and in this modern era of cost cutting becomes a prime target for evaporating altogether.

How can this happen? After all, those of us in the project management industry tend to think of project management as most critical in difficult times and there is plenty of evidence to show how projectized organizations generate tremendous levels of efficiency.

To figure this out, it’s important to think of how organizations come to be in the first place.

Organizations usually get started from an entrepreneurial spirit. Company founders use family or trusted advisors to take over key elements of the company because it’s too big to do alone. This historic perspective continues into modern day accounting and business management. Organizations are traditionally organized by function, not by result. Look at any standard accounting chart of accounts and you’ll see department-oriented thinking. Look at standard budgeting and it is department organized.

So department heads have traditionally had ultimate power, thinking of themselves as the heads of their own companies within companies. That’s great right up to the point where the products the company needs to create must cross these departments in order to be completed. And, it is in answer to that challenge, that today’s matrix organization came about.

The matrix organization theory is relatively new but has been almost universally accepted in organizations that do projects. The idea is that projects move across departments. The power in the organization is now shared in some manner. Department heads are still responsible for their people but the project office is responsible for producing the result. Many modern day managers have grown up in world where they’ve only experienced matrix structures in the organizations they’ve worked in. But, is matrix management automatically the most effective path? Opinions vary.

In a perfect world, the two axes of the matrix are intended to balance each other out. We’d expect that an organization that is completely oriented to the organizational axis of the matrix would have very happy employees who were well taken care of, highly trained and well compensated but would not get a lot of project throughput. Conversely, we’d expect that an organizations that is completely oriented to the project axis of the matrix would have lots of projects being completed but would be burning out staff on a regular basis, have lots of turnover and ultimately would lose its key resources. The idea of a matrix organization is that it is conflict by design. In a matrix organization we expect the two axis to push against each other with the intent being that we will find a perfect balance.

There are two big problems with this assumption however. First, not all people are created equal. Every organizations has some managers who are more articulate, more experienced more forceful, more networked, better at negotiating and better at internal politics than others. Those people who are less experienced, less connected and ultimately less powerful will suffer by comparison. The second challenge is much more significant. The traditional position of the PMO is often one with lots of responsibility but little authority. Authority rests almost always with the organizational aspect of the matrix. So, when an organization is put under pressure (as happens in a tough economy) those people in authority are pressed to protect themselves. The result is often the exact opposite of what would be good for the organization.

In the economic pressures of the last couple of years, we’ve seen a number of organizations where the role of the PMO has been degraded. It’s exactly the opposite of what you’d expect in a challenging economy. We’d expect that this would be the time where the most throughput possible would be the incentive and, to be sure, in some companies that’s the case. But, in some organizations, the pressure on the organizational department managers is to grab back as much authority as possible. These groups create their own project management groups that are specific to their departments thus paying lip service to the project management requirement but at the same time removing the most powerful benefit to the organization overall: the ability to manage work across departments.

This is most common in the largest of organizations where the size of the matrix is tough to comprehend at the best of times. The end result is a weaker and weaker PMO until in the end, the PMO is, in some cases, dissolved completely in favor of “department PMOs” which, of course, manage projects only from a hierarchical perspective; that is to say, only for their own departments.

It’s a complete return to silo management by department.

If this is something you’re experiencing and you’re responsible for the project aspect of the matrix, there are a few things you can do.

First, market, market, market. Communications from the PMO are critical. We’ve always said this to our clients but selling the PMO shouldn’t ever stop once the PMO is established. An organization with lots of responsibility and little authority needs to lobby for its position forever. It’s just part of a good PMO. So, create a blog, a collaborative workspace or a website and start pitching your benefits to the organization straight away.

Next, keep your friends close but your enemies closer. It’s an old expression but it holds true today. Make sure your portfolio selection process or your project prioritization process includes those very department heads who feel they might become disenfranchised. Making sure that people in authority don’t feel left out can eliminate a huge risk to the PMO.

Finally, become Switzerland. Being the facilitator of portfolio meetings puts you one level beyond inter-department rivalry and makes you the neutral territory on which departments can negotiate. Having a neutral territory somewhere which prides itself on its neutrality rather than an organization which is looking for authority of its own is something everyone can commit to.

Maintaining a level of balance between the organizational and project axes of your matrix organization is essential if you don’t want to risk being returned to a silo organization.

Don’t forget to leave your comments below