Tag: Stakeholder

An Overly Engaged Sponsor Can be as Lethal as a Disengaged One!

Written by Kiron Bondale on February 6, 2013. Posted in Articles. 13 Comments on An Overly Engaged Sponsor Can be as Lethal as a Disengaged One!

Bondale FeatureArticle Feb6 PMI’s 2012 Pulse of the Profession survey listed “engaged project sponsors” as one of the project management practices identified in organizations which had 80% or more of their projects meeting expectations. Most project managers would echo this finding as they are likely bearing scars incurred on past projects where they suffered from the impacts of disengaged sponsors.

Under such conditions, for those project managers who have never had hyper-engaged sponsors, this might seem to be an ideal situation! So what’s the harm that an overly engaged sponsor can do?

Personal impacts include the marginalization of your role on your project and a longer term reduction in the perceived benefits of having professional project managers assigned to lead projects. In extreme cases, I have witnessed project managers requesting re-assignment or even leaving their company if they feel that such behavior is tolerated or encouraged.

Beyond the personal impacts, as over engaged sponsors usually possess significant political clout, if this influence is being used to divert resources from higher valued projects or they are actively conspiring to undermine other projects, this could cause the organization to not achieve its strategic objectives.

Finally, significant operational or people management impacts might be occurring if the excessive focus on the project is diverting your sponsor from their functional responsibilities.

While the overly engaged sponsor is rarer to find in the project “wild” than their more commonly observed disengaged cousins, this sub-species is more troubling because the tell-tale signs of over engagement are more subtle than those of disengagement. In fact, as many project managers might feel grateful about the excessive attention their projects are receiving, here are some tests (with inspiration drawn from Jeff Foxworthy’s stand-up redneck comedy routine) to help identify the presence of an overly engaged sponsor.

If your sponsor appears to be exhibiting Theory X behaviors by checking on your project’s status or open actions on a daily or even more frequent basis, he might be overly engaged.
If your sponsor is circumventing you by frequently providing direction or work allocation to team members, she might be too engaged.
If your sponsor insists on attending each and every project meeting, regardless of the meeting’s objective or audience, he may be overly engaged.
If your sponsor is using Machiavellian tactics to ensure sustained funding and resource availability for the project, even when the project has been clearly identified as NOT being the top organization priority, he might be just a bit too engaged.
If you find your sponsor is first in line to back fill for you when you are off, even when one of your work package leads or PM peers is available to do so, she may be just a little too engaged.
If your sponsor re-writes your regular project status reports to senior management and other stakeholders, he is definitely too engaged!

If one or more of these tests are positive, it’s still a good idea to get some independent validation before you try to address the situation. This is one of those cases where having a peer support group of other project managers within your organization can be invaluable. Review the evidence you’ve gathered with one of your trusted colleagues and see if they agree with your hypothesis.

Once the diagnosis has been confirmed, curing the disease can begin by “walking a mile in their shoes” to understand why your sponsor might be behaving this way.

If it’s the first time he has been a sponsor, he may simply be unclear on the expectations for his role as well as the full accountabilities for yours. This is why it’s crucial to review rules of engagement with sponsors and team members at the outset of a project, but even if you did so at that time, it is a good idea to review and reinforce these expectations periodically.

If your sponsor’s actions are the result of her feeling tremendous personal accountability for the success of the project (which should be encouraged) but she is worried that you’ll let her down, you should help her understand how her behaviors are undermining your role and work with her to define a progressive plan which will help her to develop trust in your ability to manage the project.

If your sponsor’s actions are not due to either of these acceptable reasons, he may simply be playing the political game to ensure he or his project succeeds at the expense of others. In such cases, if repeated objective, focused discussions with your sponsor result in no change in behavior, escalation through your own manager may be the only option.

An attentive sponsor might seem like water in the desert to most project managers, but be careful that you don’t drown in the pool of over engagement!

Don’t forget to leave your comments below.

From the Sponsors Desk – For Best Results Use Your Sponsor Wisely

Written by Drew Davison on January 9, 2013. Posted in Articles. 10 Comments on From the Sponsors Desk – For Best Results Use Your Sponsor Wisely

In my last post, we looked at Project Interlopers – project players who are often contributors to project difficulties and project management migraines – and how they can negatively influence project outcomes. We also looked at steps you can take to counter their negative impact and improve the performance of your own projects.

In this post, we’ll look at how a director’s refusal to engage the project sponsor on a multi-million dollar reorganization effort resulted in project failure and his own loss of position.

Thanks to reader G.M. for contributing the details on this project.

The Situation

This public sector organization had a multi-year plan to improve the responsiveness and cost-effectiveness of its IT organizations to deliver $100 million in annual savings. Part of that plan was the consolidation of four local service desks into one virtual service organization.

The Goal

Reduced cost of Service Desk and associated services
Provide a consistent level of customer service for service desk and associated services
Provide a single point of contact for technology users to report incidents and make service requests
Provide a single organization responsible for providing standard services to the organization’s technology users.

The Project

The project was launched to great fanfare, with an announcement from the CIO outlining the goals and addressing plans to close the local service desks and consolidate the functions and staff in a remote, virtual site, accessible by phone, email and web services.

A new director was appointed by the VP Technology Services to form and operate the new organization, transfer staff from the local centers, acquire additional staff as needed and put the services and technology in place. The new director proceeded to hire a project manager to guide the process design and implementation and manage the technology initiatives necessary to support the new service desk operations.

The new director found that very few of the existing service desk staff were willing to transfer from their existing communities to the city where the new organization was based. That meant that the hiring and training challenges were significantly greater than originally anticipated. In addition, the new director faced considerable resistance from the architecture and IT operations organizations over the technology that he wanted to use to support many of the service desk functions. The estimated project and operating costs ballooned and the target dates slipped and slipped again.

The director and his PM tried to phase in the new service one local service desk at a time. However because of the cost and schedule slippage, the local service desk managers were reluctant to release their staff and the technology users continued to make use of their local service desks, leaving the new consolidated unit with significant excess capacity.

The Results

The new service desk director continued to build his organization but much of the technology supporting its operation was legacy offerings from the local service desks. Because of this, the service experience was not a terribly pleasant one for technology user. They continued to frequent their local help desks for assistance where they knew the staff on a first name basis, could drop in unannounced with their questions and problems and receive the same personalized, friendly service they had become accustomed to over the years.

The new director had no authority over the local service desk managers (they reported to a peer director) so he couldn’t unilaterally close them down and the director who oversaw the local help desks was in no hurry to close them down because of the negative feedback he was receiving from technology users about the service of the new organization. It was a costly mess.

With a growing number of complaints from technology users and an increasing number of questions from the executive ranks, the CIO was forced to pull the plug on the new consolidated service desk. The director and PM were reassigned. The staff were either reassigned or let go. The price paid: $3 million in operating costs and $1.5 million in project costs. The cost of the reputations sullied: priceless!

How a Great Project Manager Would Have Helped

Sometimes on projects, perception is not reality. The new consolidated service desk director thought he was the sponsor of the initiative he was heading. The project documents actually stated that. When asked how often he interacted with his VP, he replied “only when I need his signature”. In reality, the director was a target, a manager of an organization that is affected by a change much larger than his span of influence. The real sponsor should have been the VP Technology Services, who had authority over both the local help desks and the new organization. He was also on a peer level with the heads of the architecture group and IT Operations, the two organizations that were resisting the new technology that was essential for a superior user experience.

So, what could the project manager have done to remedy the situation? Here are a few questions he could have posed to get the discussion about stakeholder roles and responsibilities underway and hopefully change the game:

What organizations need to be involved and change the way they operate for the project to be successful?
Which managers have the authority to allocate time, costs, resources and establish priorities in those organizations?
What explicit role will each of those managers play on the project – sponsor, change agent, target or champion?

In my Project Pre-Check practice, a stakeholder is a decision maker who:

• Directs an organization that initiates, is affected by or is charged with managing all or part of a change,
• Has the authority and responsibility to set direction, establish priorities, make decisions, commit money and resources and
• Is accountable for delivering the planned benefits on budget and on plan.

Stakeholder involvement and commitment is one of the most important ingredients for successful business and technology change. Let’s look at what probably would have happened if the right decision makers were involved in the appropriate roles:

We would have had the following players sitting around the stakeholder table:
- The sponsor – VP Technology Services
- Targets – the new director of the consolidated service organization, the four managers of the local help desks, the heads of the architecture group and IT operations (because of the impact of the new technologies) and someone representing the interests of the technology users (because of the changes in the service desk location, processes and technologies)
- Change Agent – the project manager, who would take his primary marching orders from the sponsor as well as addressing the needs of the targets.
Those stakeholders would have been committed and engaged from project inception through completion.
The issue of relocating staff would have been addressed and perhaps the location of the new consolidated center would have been changed to facilitate staff moves.
The technology choices would have been addressed with the buy-in of all stakeholders, including those representing the interests of the technology users.
The phased close out of the local centers would have been managed in concert with the phase in of the new service desk.
The technology users would have been much more amenable to the new service, processes and technologies because of their upfront engagement and ongoing involvement in the decisions affecting their world.
The incremental operating costs would have been eliminated or minimized.
The reputations of the CIO, Director and project manager would have been preserved and probably enhanced.

I know this analysis is hypothetical. However, without the right players in place and the right guiding coalition going forward, the project was essentially doomed from the start.

The stakeholder group is a most powerful force for enlightened project guidance and an essential resource for project managers. But it needs to be nurtured and cultivated from project launch. That’s why it’s central to Project Pre-Check’s model, processes and Decision Framework. It is a great place to start your project and supplies a terrific framework for building an effective guiding coalition that will be there when conflicts and crises arise.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great Project Manager.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks

Don’t forget to leave your comments below.

Tips on Stakeholder Management

Written by Gareth Byatt on December 19, 2012. Posted in Articles. 12 Comments on Tips on Stakeholder Management

hamilton Featurearticle Dec19 In many cases, managing stakeholder expectations while managing projects or programs within their constraints is as much an art as a science. It takes a balance of knowledge, tools, and “soft skills” on the part of the Program/Project manager, and an environment that is conducive to success. With so many factors to take into account, what does it take to successfully work with the stakeholders on your program or project? All of us who work on programs and projects face this question.

A great deal of excellent guidance material, tips and techniques for working with stakeholders exists. In this brief article, we aim to provide you with a synopsis of things to consider, some “food for thought,” if you will, including some ideas and techniques that we have seen work well in our own experiences running programs and projects.

1. What or who is a stakeholder?

Let’s start by defining what a stakeholder is. The Project Management Institute’s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) describes a stakeholder as a person or organization that:

Is actively involved in the project
Has interests that may be positively or negatively affected by the performance or completion of the project
May exert influence over the project, its deliverables or its team members

Within the context of a project, The UK’s Association of Project Management defines stakeholder management as follows:

“Stakeholder management is the systematic identification, analysis and planning of actions to communicate with, negotiate with and influence stakeholders. Stakeholders are all those who have an interest or role in the project or are impacted by the project.”

We shall use these definitions as our starting point.

2. Should you think of your stakeholders in groups or segments?

When considering whether to group stakeholders together, you are asking yourself: what “stake” does this stakeholder, or do these stakeholders, have in my program/project? Several dimensions can be used – choose what works for you (if it makes sense to do so). An example of one dimension is to break them into responsibility, such as the client, the project team, suppliers/contractors, the end consumer(s), activist groups, and so on. Another method is to categorize stakeholders by their level of influence and their level of support. Some people use “stakeholder maps” to graphically show who their stakeholders are, and who is most important or “closest” to the program / project.

3. What do your stakeholders think constitutes success on your program/project?

In a previous article on Project Success Planning, we posed the question “What does success mean?” to everyone on your program or project. In another article, The Nine Critical Steps for Project Success, we discussed documenting all stakeholder expectations early (step 2, for those of you who recall this article). As we mentioned at that time, small projects may collect stakeholder expectations through personal interviews or by email. Larger programs and projects, with stakeholders potentially numbering in the thousands, may need to employ more sophisticated/broader techniques such as sampling and extensive consultation. Different stakeholders (or groups of stakeholders) will view your program or project through different lenses, and this is something over which you will only have limited control. Some stakeholders will be against your program or project, and you will need to determine how to work with them.

The takeaway message is that it is important to understand your key stakeholders’ meaning of success (or why they oppose your initiative), work with them to understand why they think of the program/project in this particular way, and get on the same wavelength as them. Understanding their viewpoints is the first step to knowing how to respond and inform them appropriately.

4. How do you resolve conflicts between stakeholders?

One issue that is all too common is the lack of a defined process for resolving conflict amongst stakeholders. A stakeholder influence diagram is often used to prioritize stakeholders; however, less influential stakeholders can have ideas that are discounted. Balancing the influence on decision-making to add benefit to the program/project is vital to success.

5. Should you create a Stakeholder Management Plan?

In our experience, it can be useful to create this type of plan, as long as it is then used by your team. Creating a Stakeholder Management Plan just to satisfy a company procedure, and then putting it “on the shelf” or forgetting to carry out the actions it contains is a waste of valuable project resources.

6. Is it worth keeping a “CRM log” to track your stakeholder relationships?

CRM or Customer Relationship Management is a term widely used in marketing circles, and basically means to keep track of customers. This principle can be applied to your stakeholders. Do you have a list somewhere of all the stakeholders you deal with? If you don’t, think about creating one – you will probably be surprised by the number of people you liaise/work with. Whether you think keeping a register is or is not of value is up to you. You may find it a helpful process to review your stakeholders, say, once a month, to ensure you are keeping on top of things. Spending 30 minutes each month summarizing any key comments such as when you last contacted people, how helpful they are being to your initiative, and who you need to put more effort into speaking with next month could jog your memory and ensure that you have things covered.

7. How can you influence your stakeholders?

Exerting influence in a subtle way without using formal authority (for the most part) is key to successfully working with your stakeholders. Whilst you will have formal authority bestowed on you with some stakeholders on your program or project, with many, you will not. Program and Project Managers should be conversant with the basics of what is known as Organization Change Management” to help them with this. Various approaches to managing change in an organization exist; the basics are about ensuring there is a level of understanding early, and then continuing this effort to communicate to ensure that this understanding turns into support and willingness to adopt change. Using a few simple techniques and approaches to get your stakeholders on board will go a long way toward helping your initiative to succeed. In particular:

Start the process early on; do not leave it until well into the Execution phase.
Be very clear with your communications.
Be open and honest with people.
Show a genuine interest in “what is happening in their world.”
Gain feedback and take it into account – do not make it “one way traffic.”
Keep up the “hard yards” of talking with people.

8. This is all great in theory, but I don’t have time!

We all know the old adage, that project management is 90% communication. A large proportion of communication is working with stakeholders. If you cannot devote quality time to working with your stakeholders using well-conceived strategies, you will probably be placing your program or project at risk in some way or another.

Don’t forget to leave your comments below.

Project Schedules Should Benefit More Than Just the Project Manager!

Written by Kiron Bondale on November 28, 2012. Posted in Articles. 10 Comments on Project Schedules Should Benefit More Than Just the Project Manager!

Bondale FeatureArticle Nov28 I’d written an article previously which listed the benefits a good project schedule can provide, but most of those would be perceived as being of value to a project manager. “All you care about is the schedule!” is likely a complaint that has been heard by most project managers.

The danger in such cases is that project managers will struggle to get sufficient engagement or input into the creation or ongoing maintenance of project schedules. This can become a vicious cycle as the project managers are more likely to develop schedules themselves with minimal input which will only further the negative perception that these schedules are of limited value or don’t reflect reality.

While I don’t expect project managers to be primarily responsible for educating team members and stakeholders on project management practices, part of our role is to support and reinforce the importance of these – after all, we usually don’t know what PM 101 knowledge a new team member has when they are assigned to our projects!

So what are some of the ways in which project managers can convey the necessity or benefits of a schedule to their team members or to the functional managers that should support and demand their creation?

It helps to establish and maintain expectations between team members, stakeholders and customers. This should help to reduce the volume of the “Are we there yet?” requests from those outside of the project team.
It helps functional managers achieve some measure of predictability around resource allocation. In organizations where staff work concurrently on projects and operations, it can be very challenging for functional managers to plan for the peaks and troughs of day-to-day activities. Improved visibility into the demand from projects can at least remove one variable from this complex equation. It can also help functional managers keep project managers honest by confirming when team members are expected to be released from projects.
It should help the customer and project sponsor sleep better at night! If the customer or sponsor are relying on the project manager telling them everything is on track without a method of objectively assessing that, they are likely in for an unpleasant surprise.
It can provide protection to the project team if the sponsor or customer requests a change that cannot be accommodated without unnatural behaviors.
It helps to pull everyone’s (that includes the project manager!) head up from getting too focused on the most immediate critical milestone, and helps to remind them that the current battle is just one campaign of a much bigger war.

Project schedules are detailed directions for travelling to a faraway land. In their absence, if the extent of one’s geographic knowledge is limited to what you can see or the places one has visited (and remembers!), it can become challenging to visit new destinations in a predictable fashion.

Running a project of even moderate complexity without a schedule is similar to navigating with those maps of old that indicated “Here be dragons”!

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Managing Project Interlopers

Written by Drew Davison on October 31, 2012. Posted in Articles. 15 Comments on From the Sponsor’s Desk – Managing Project Interlopers

In my last post, Projects Done Well, a Recap – Part 2, we concluded the review of lessons learned from the 22 case studies covered in this blog over the last two years. We discovered nine top contributors to project outcomes, all effecting more than half the cases studied. We also found that other studies and commentators agreed with our conclusions. If you haven’t reviewed those findings, please do so and apply the lessons learned to all your projects from now on. You’ll be glad you did. Your stakeholders will thank you.

Before getting back to our case study reviews, I’d like to address a situation that has often been a contributing factor to project difficulties and project management migraines – Project Interlopers. I’ll describe how they can negatively influence project outcomes and suggest how you can counter their impact to improve the performance of your own projects.

Effective stakeholder management is a key project success factor. Keeping the stakeholder group pure and focused is an absolutely essential part of that task. To use a culinary analogy, at least in Project Pre-Check, the process is the recipe, the decision areas are the ingredients and the stakeholders are the chefs! And we all know that too many chefs spoil the soup.

Project Interlopers (I’ll call them PI’s from now on) are influential and usually opinionated executives, managers and senior staff members who have no formal project decision making role yet insist on imposing their opinions and beliefs on project stakeholders and staff. Their unnecessary and unwanted involvement can create dissent among the real project stakeholders, launch wild goose chases, blow schedules, increase costs, negatively affect quality, diminish the value delivered and, in some unfortunate cases, directly contribute to project failure.

Let’s look at an example. In a previous post, You Can’t Always Get What You Want, we looked at how a tyrannical director’s excessive and unreasonable demands on a project team resulted in project failure and his own demise. What I didn’t mention in the post was the fact that the project director was a PI. His day job was the director of IT. He unilaterally took on the sponsor and the project director mantle. The actual sponsor, the plant manager, backed off and allowed the IT director to play his game. The actual PM ran the project until the boss’s interference drove her to depart. You know the rest of the story. The project failed.

Another example: a colleague of mine recently joined a project as a contract project manager. It involved the launch of a new financial product with a boat load of web development. She jumped into the project with both feet in response to some critical target dates. And then she ran into a number of conflicts. The VP of System Development, her boss and, unfortunately, a PI, explained that he was the project sponsor and proceeded to dictate direction, which was at odds with business expectations. The resource manager with whom she dealt to obtain project staff, another PI, issued orders regarding the functionality, look and feel of the application, again at odds with the business direction.

The project manager took a deep breath and stepped back. She asked the individuals involved who they thought the stakeholders were and what roles they were playing. She found considerable disagreement and pursued the issues until there was unanimity. As a result of her questioning, a number of changes were made to the makeup of the stakeholder group. The business VP responsible for the product launch became the sponsor. The System Development VP had no formal stakeholder role, nor did the resource manager. Two organizations affected by the project were not initially represented in the stakeholder group. Senior managers were appointed to fulfill their target roles. According to the project manager, once the stakeholder group was reformed, the PI’s were removed and the real stakeholders engaged, the difference in clarity on goals and directions, in the speed of decision making and the level of stakeholder commitment was palpable. The project was a terrific success.

In the post The Offshoring Challenge, Part 2, the designated sponsor wasn’t really the sponsor after all. He didn’t initiate the change. He didn’t have the economic, logistical or political power to make the change happen. In fact, he had no organizational role other than the project role. He could have acted as the project executive but instead tried to be the sponsor. He was a PI of the imposter kind, playing a role he shouldn’t have been playing and not doing the job he could have done. Chaos reigned. As well, the designated PM turned out to be a consultant to the business and spent most of her time developing business specifications. Another PI imposter!

Ultimately, the sponsor imposter was removed from the project and sponsorship accountability was placed in the hands of the CEO, where it should have been all along. A senior executive with in depth knowledge of the business and recent experience in a similar project was brought in to provide overall guidance as project director. The project was finally delivered successfully, a year later and over 50% more than originally budgeted. Much of that overrun can be traced back to the PI’s and the absence of the right stakeholders.

Another colleague of mine joined a project as a contract project manager and ran into an aggressive and dictatorial PMO manager. She was a PI of the first order. She had no formal stakeholder role. She wasn’t the sponsor. She wasn’t a target. She certainly wasn’t the PM. She wasn’t a champion. Yet she ran all the stakeholder meetings and she dominated all the project team meetings. She harassed and bullied the contract PM from his first day on the job, in private and in public.

The PM tried to get the situation rectified by approaching the PMO manager directly. After that failed, he asked the sponsor, a business VP, for help. The business VP was a nice guy but not terribly decisive and he urged the PM not to worry about the PMO manager and just carry on. The PM approached the CIO and received the same advice. It seemed no one wanted to take on the PMO manager. The other stakeholders and his team members all sympathized with him, patted him on the back and told him he was doing a great job. And urged him to just carry on.

So he just carried on. The project turned out to be very successful and all the stakeholders were thrilled with the results. But the PM’s life was miserable. He claimed those nine months were the worst of his entire professional career.

So what can you do to deal with PI’s on your projects? First, you need to know who the real project decision makers are and what roles they’re playing – sponsor, target, change agent and champion. That it! The easiest way to find out is to ask the other participants. You want to see consistency in the responses. Who was responsible for launching the project? Who does the organization look to to deliver the change successfully? Which departments and which staff will be affected by the change? Which managers will have the final say on how a change will be implemented in each affected organization? Are those groups and individuals represented in the stakeholder group?

What about all those other folks who are usually involved in overseeing, supporting, contributing and commenting on a project’s makeup and performance? If they are not filling one of the four stakeholder roles and making explicit decisions on the conduct of the project, they’re not stakeholders, nor are they members of the stakeholder group. If they can’t logically fill one of the four stakeholder roles, they have no place at the stakeholder table.

The stakeholder group will be self-sufficient as long as all players have the authority and capability to make decisions on behalf of the organizations they represent, all the necessary organizations are represented and the consensus process works. Where conflicts arise that cannot be resolved within the group, the issues should be quickly escalated up the organization until a decision can be reached. Escalation should never be construed as a sign of failure. Rather, it should always be positioned as an available and appropriate measure for resolving a deadlock.

How does the stakeholder group relate to traditional project steering committees? If the rationale for and participation in the two groups is similar, perhaps only one group is required. However, in many cases, a steering committee is formed to provide an oversight function rather than a decision-making role. In those cases, a steering committee may still be appropriate. It can also be an effective forum for real or want-to-be PI’s to get information and air their thoughts and suggestions.

Stakeholders in any role can be tough to identify and even more difficult to replace. The time and effort that’s usually required to manage the replacement of a PI can distract everyone from the job that matters, delivering a project successfully. It’s best to assess stakeholder roles and capabilities right up front and address any apparent gaps. And to keep the stakeholders engaged, monitor stakeholders’ level of agreement on the decision areas critical to project success on an ongoing basis.

Don’t forget to leave your comments below.