Skip to main content

Author: Drew Davison

Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check - The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at [email protected].

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

Written by Drew Davison on . Posted in Articles. 3 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.

From the Sponsor’s Desk – Managing Project Interlopers

Written by Drew Davison on . Posted in Articles. 7 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.

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.

From the Sponsor’s Desk – Projects Done Well, a Recap – Part 2

Written by Drew Davison on . Posted in Articles. 4 Comments on From the Sponsor’s Desk – Projects Done Well, a Recap – Part 2

In my last post, Projects Done Well, a Recap – Part 1, we started to look at the lessons learned from the 22 case studies we’ve covered in this blog over the last two years. We covered three of the top nine contributors to project outcomes, all effecting more than half the cases studied.

In this post, we’ll look at the final six factors that most contributed to project success or failure and suggest how you can leverage these findings to improve the performance of your own projects.  

The Methodology

DrewSept26th3

Check the Part 1 post if you’d like a refresh on the methodology we used. Essentially, we analyzed the 22 cases presented in the From the Stakeholder’s Desk blog on Project Times against the 18 Factors in Project Pre-Check’s Decision Framework. The Decision Framework helps stakeholders form and deliver a common vision for a planned change from inception through completion. In Part 1, we looked at two factors in the Change domain – Stakeholders and Dimensions, and one factor in the Environment domain – Business Plan. In this post, we’ll look at three factors in the Assets domain – Resources, Delivery and Project Management and three factors in the Project domain – Planning, Control and Communication. This should shed still more light on what we can do to make projects routinely successful.

The Findings

In summary, nine of the eighteen factors in the Decision Framework were identified as critical to the project outcomes in ten or more of the cases as shown in the chart. The bottom line: get your stakeholders agreeing on these factors first and your project has a much better chance of achieving its goals.

The nine factors identified here as the leading contributors have a broad impact on pretty well all business and technology projects. Pay special attention to them.

The Assets Domain

The Assets domain addresses stakeholder decisions regarding the people, processes, products, tools and facilities that are required to support a planned project or which may need changes for the project to succeed. In essence, the Assets Domain is the supply cabinet to the project world.

DrewSept26th2

Resources

The Assets domain includes the following factors: resources, delivery, project management, business operations, security administration, technology operations and infrastructure. Three of those factors contributed to project success in our review: resources, delivery and project management.

The Resources factor includes seven decision areas including skills and capacity, skill development, resource procurement, contract management, team formation, performance management and succession planning.

The Resource factor was a contributor to project outcomes on 19 cases.

In The Offshoring Challenge, Part 1, the challenges of forming effective teams and ensuring the availability of required skills and capacities with an off shore software development organization were never tackled. The domestic and off shore teams never really had shared goals, objectives, processes and ground rules, there were no actions taken to address the cultural and language differences and the distance and time zone challenges were never dealt with. The final result: actual costs were double the original budget and the project was delivered nine months late.

Why is the performance management decision area a concern to stakeholders? Check out You Get What You Pay For. In that case, the two project managers were incented to meet a date. So they met the date! Unfortunately the implementation was a disaster. Nothing worked. The changes were pulled out. There was no contingency plan so the reversion to the original systems was messy and time consuming. The cost to complete the project ballooned to $70 million, 40% greater than originally forecast.

In the post Tenacity Can Achieve Miracles, the QA manager had the knowledge and skills necessary to turn around a serious quality gap that was causing a loss of customers and revenues. She was also able to tap into an available supply of QA talent to lead her teams successfully. In addition she was able to form three multi-disciplinary teams quickly and effectively using her knowledge of team building practices. She brought together small groups of staff with clear mandates, appropriate availability, the right perspectives, knowledge and skills and short term time frames to deliver a meaningful result.

Finally, Fix the Business Process First demonstrated the kind of success that can be realized when the right skills and capacity are put in place. In this case, the organization had never done an end-to-end process assessment. The sponsor contracted with an external group that had proven capabilities to assess end-to-end process performance to manage the project. That included a “boot camp” for involved executives and staff to reorient their frame of reference from organizational silos to a process view. The project was a resounding success.

Takeaway: the stakeholder group needs to have a complete understanding of the Resource factor decision areas relative to the project needs and be fully on side with that view and any plans to address the gaps.

Delivery

The Delivery factor addresses the processes that are in place and can be used or adapted to develop and implement the target solutions. The Delivery factor includes the following decision areas: management of change, software delivery, technology change, quality assurance, prototyping, partitioning, time boxing, reuse and project close.

The Delivery factor had a material impact in 11 of the 22 cases.

An example of a project that paid the price for not addressing the Delivery factor was presented in the post Managing IT Services Contractors. The project was delivered successfully, but five months late and sixty percent over the original estimate. The vast majority of the overrun came from the contractors’ failure to deliver. Key contributors to that failure were the lack of technology change and QA processes that the participants could use as a road map for managing the change. That contributed to numerous disconnects between the project team and the contractors on key fundamentals including roles and responsibilities and the quality practices and a plan to deliver to those expectations.

In Knowing Your Project Profile, the project ultimately delivered a significantly better return than originally anticipated but the two project managers ended up as goats. They adapted the in house quality practices ensuring a high quality solution in all respects. They used prototyping effectively to understand the business requirements. Unfortunately, they didn’t address the incremental functionality that was added to the scope resulting in higher costs and more time. That surprised the other stakeholders. They also missed an opportunity to partition the project into phases to accelerate benefit delivery and reduce risks. If the PM’s had considered the Delivery factor decision areas up front, they might have been heroes.

Takeaway: it’s imperative that the stakeholders have a discussion on the processes and practices that will be used to deliver the solution and are in agreement on the decisions reached. This factor is often seen as the exclusive responsibility of the PM but keeping it to oneself is a mistake. The more the other stakeholders understand the choices and agree on the direction chosen, the greater the overall commitment.

Project Management

The Project Management factor covers those practices and guidelines that PM’s can use off the shelf or amend as appropriate to guide their projects. The Project Management factor includes the following decision areas: the project management process, organization profiles, estimating guidance, project tracking and reporting templates, requirements management frameworks and standard practices on risk management, issue management, change control, defect tracking and gating.

The Project Management factor was a material contributor to the success of 11 of the 21 cases.

In the post Anybody Can Manage a Project, Part 2, we saw how a new hire with a financial background and no prior project management experience was able to deliver a global project successfully with accolades from all the stakeholders involved. Part of her success was due to the use of in place processes and templates to guide her actions, including the standard reporting templates which she tweaked to address her sponsor’s needs. She also obtained stakeholder agreement on the risk management, issue and change control practices to be used on the project.

In the post Anybody Can Manage a Project, Part 1, the individual assigned to manage the project had no prior project management experience either. However, in her case, she didn’t have the benefit of stakeholder discussions regarding the project management process to use, how to estimate the work, manage requirements, track and report progress, manage risks, issues, changes, etc., nor did she take advantage of materials or expertise within the organization that could have helped. A new project manager was finally assigned and the project was delivered for almost twice the original budget, nine months late.

Takeaway: all stakeholders need to be engaged in a project on a regular basis, certainly weekly, often daily. They need to know how the work will be planned and managed, who the players are and what their responsibilities are, how they’ll be involved and the basis of that involvement. This factor is also often seen as the exclusive concern of the PM but that’s unwise. Stakeholders who understand the choices and agree on the direction chosen will be more committed and more effective.

The Project Domain

The Project domain addresses the specific project decisions that need to be made to shape and deliver changes that achieve the organizations goals. These decisions deal with how to deliver to the stakeholder expectations articulated through the decisions made in the other domains. The Project domain includes four factors: planning, organization, control and communication. Three of the factors – planning, control and communication – were among the top nine factors contributing to project success.

Planning

The Planning factor takes the relevant decision areas addressed in the Assets domain and applies them to the unique needs of the project. Huh??? OK, an example: if the stakeholders agree that they don’t have the right skills, or enough of the skills required when considering the Resources factor in the Assets domain, then the plans to address that gap are included under the Planning factor. It covers the following decision areas: business alternatives, technology alternatives, release plans, cost estimates, benefit plan, quality plan, resources and facilities plan, contracts plan, communication plan and risk plan.

The Planning factor was a contributor to project success in 13 of the 22 cases.

The Power of Teams post shows the positive results that can be achieved by building a resource plan that addresses the critical skill and capacity needs. As well, the project developed and managed a comprehensive risk plan that was used to guide the project around and over the many obstacles that arose. The project implemented successfully just prior to the yearend freeze, twelve and a half months after launch. The actual cost was slightly under budget and the quality of the delivered software, processes and services was outstanding.

On the downside, The Offshoring Challenge, Part 1 shows what happens when the Planning factor decision areas are ignored. Identification of possible risks and development of a mitigation plan is a prerequisite for just about every successful major change undertaking. Had that been done in this case, chances are the risks relating to quality, communication, team performance and expertise and other factors would have been addressed. In addition, there were no plans to manage the vendor contract, the quality of the delivered products, skills and capacity issues and guide the communication with the stakeholders. The final result: actual costs were double the original $7 million budget and the project was delivered months late.

Takeaway: exposing the Planning factor decision areas to the other stakeholders and asking them for their thoughts on each item can be intimidating. Early on, the majority of response will be, more often than not, “I don’t know”. However, as the project progresses and positions and proposals are developed, the dialogue will increase and stakeholder collaboration will evolve to mutual understanding and, finally, agreement. How powerful is that! Take advantage of it – a process to gain stakeholder agreement and cement their engagement at the same time.  

Control

The Control factor includes those control mechanisms that help stakeholders shape and guide the project to achieve the objectives of the planned change. It includes the following decision areas: release plan performance, contracts plan performance, risk plan performance, team plan performance, change tracking and reporting, issue tracking and reporting, and project completion.

The Control factor was a material influence in the success of 13 of the 22 cases.

The post A Perfect Project highlights the value of mastering the Control factor. In this case the PM clarified and quantified the project’s goals and measured project performance against those goals on an ongoing basis. She developed and managed a risk plan that resulted in some pragmatic changes in approach to improve quality and value and she controlled the development of the application through a number of phases and rolled out in stages to reduce risk and accelerate business value. The project was hugely successful. It delivered on plan and within budget and the high quality of the implementation was confirmed by the standing ovations the PM received as she travelled across the country introducing the new environment. It also won the Conference Board of Canada’s ITX award for technology innovation and excellence. The ROI calculated by the judging committee was about 800%.

In the post You Get What You Pay For, the entire organization was surprised when the $20 million first release was a disaster that had to be pulled from production. Aside from the fact there was no formal stakeholder group to guide the way and monitor progress, the two PM’s didn’t use effective   controls on risks, quality, issues, changes or team performance. In fact, the product from the selected vendor had two major deficiencies – their systems needed major modifications to handle individual pension records across organizations and they had never co-sourced a solution before. The latter fact did not come to light until the first phase implementation failed.

On a positive note, the project highlighted in Ten Winning Project Management Practices implemented and applied control practices effectively throughout the initiative. From a financial point of view, good planning and good controls were in place. The nursing units had a positive experience with the ‘Last Call Walk Through’ process, which provided an opportunity to provide quick fixes and quick wins. The biweekly status meetings with stakeholders and the monthly milestone summary sheets were very helpful. The project was deemed a highly successful undertaking by all stakeholders and provided the learnings and foundation for Digital Imaging rollouts to the other hospitals in the region.

Takeaway: over the course of a project, stakeholders will encounter many variances between the plan and actual results and will have numerous decisions to make. The Control factor is the catalyst for those decisions. It is the compass that tells the team where it’s headed. As Yogi Berra once said “If you don’t know where you are going, you will wind up somewhere else.”

Communication

The Communication factor deals with the ongoing practices and decisions that will ensure all participants in the change are fully involved and informed in a timely manner concerning the progress of the project. Sponsors, change agents, targets and champions all have a stake in the success of the project and therefore have a significant interest in the Communication factor and the two decision areas, monitor updates and monitor feedback.

Communication isn’t just about sending out periodic status reports. It’s about fostering a multi-way dialogue, ensuring stakeholders get what they need, in the format and medium they need, in a suitable time frame.

The Communication factor was instrumental in the success or failure of 20 of the 22 cases.

A good example of a project that covered the Communication factor with aplomb is the previously mentioned Ten Winning Project Management Practices post. The strength of the project, and a major contributor to its success, was communications, including:

  • The regional bulletin, a key communiqué to those in the field.
  • The community sites had direct ownership of the communication plan at their site.
  • The stakeholder and target audience analysis laid the foundation for getting the details on identifying all the training targets. 
  • Different strategies worked at each site, according to their needs.
  • The Leadership forum (regular monthly meetings of the Diagnostic Imaging Managers) worked well to promote agreement and standardization across the regions. 
  • The eRoom provided a central online repository for the current and archived documents, readily accessible to all project team members.

Another example of the power of a well-managed Communication factor is the project reviewed in the post Speaking Truth to Power. The new contract PM assumed responsibility for a project due to be delivered in nine months. The project reported a Green status – everything going according to plan – from its inception. He found that there was no believable plan in place, no risk plan, incomplete testing and acceptance plans and inadequate resourcing. In short, there was absolutely no justification for a Green status.

At the end of his first week on the job, the contract PM filed his first status report, with a status of RED. That colour would grace all the status reports for the following ten weeks. That got the stakeholders’ attention and earned him a good deal of stakeholder wrath. Gradually, he was able to get them to agree on project scope, develop a comprehensive plan to deliver on target, get the right resources and, after almost three months on the job, report his first Green status. He also adopted a project reporting scheme that objectively determined the status colour and ensured the stakeholders were on side with the criteria used. That took some executive heat off him in the second and third months and encouraged the decision makers to focus on the issues rather than his judgment.

As the ultimate testimony to his achievement, his project was the only one of the nine initiatives in the program to deliver on plan!

Takeaway: you can do a wonderful job getting the stakeholders engaged, project dimensions agreed to, the right assets lined up, the relationship of the project to the broader business plan clarified, a comprehensive plan and resources in place but if you don’t manage the Communication factor, your project will probably fail. The Communication factor is the glue that holds everything else together. It’s a force multiplier!

The Way Forward

A number of organizations and individuals have researched project performance over the years to identify the magic formula for project success. The table below shows a sample of the findings on the top eight factors contributing to success or failure. The Standish Chaos studies have been running since 1994. Professor Ryan Nelson of the University of Virginia has been studying project performance results over a number of years and identified the top reasons for failure garnered from 99 project reviews. He’s not alone in his findings. The results are very close to the successes and failures we’ve uncovered above and in the previous post when we looked at our 22 case studies as summarized in the Project Times column below.

DrewSept26th1

You will notice that the top nine Project Pre-Check factors we’ve looked at in this two post recap address each of the success factors from a number of different perspectives. There are also nine more factors in Project Pre-Check that we haven’t covered that add additional diligence to the project experience. Effective stakeholder management ensures that all factors with the potential to impact project success are addressed and monitored collaboratively and consensually.

So, you have a choice, as a sponsor, change agent, target or champion. Proceed according to these findings and your projects will be much more successful and the experience will be a rewarding one. Ignore these findings and join the ranks of stakeholders who were too busy to learn from the experience of others. More often than not, their projects failed. That’s why Project Pre-Check is a great place to start your project. It supplies a terrific best practice based framework for building an effective guiding coalition that will be there when conflicts and crises arise to ensure your projects are done well.

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 have a go. This month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management.

Don’t forget to leave your comments below.

Projects Done Well, a Recap – Part 1

Written by Drew Davison on . Posted in Articles. 6 Comments on Projects Done Well, a Recap – Part 1

FEATURESept12thOver the last two years, we’ve looked at 22 case studies in this blog. They were real projects. Some were wildly successful. Some were miserable failures. What were the key factors that contributed to those successes and failures? In this post, Part 1, we’ll start the review with a look at three of the nine most influential factors that contributed to those project outcomes. We’ll also suggest how you can leverage these findings to improve the performance of your own projects. In the next post, Part 2, we’ll complete the review of the remaining six factors.

The MethodologyDrewSept12th1

We analyzed the 22 articles presented in the From the Stakeholder’s Desk blog on Project Times against the 18 Factors in Project Pre-Check’s Decision Framework. The Decision Framework helps stakeholders form and articulate a common vision for a planned change from inception through completion. The stakeholders need to consider each of the four domains – all aspects of the change itself, the environment within which the change is being implemented, the assets that can be leveraged or that will be affected, and the way the project will be conducted.

The Findings

The good news – nine of the eighteen factors were identified as critical to the project outcomes in ten or more of the cases as shown in the graph below. The message: get your stakeholders agreeing on these factors first and your project has a much better chance of achieving its goals.
That isn’t to suggest that the other factors are unimportant. The Quality factor, the Investment Evaluation and Current/Future State factors and the Organization factor were material contributors to the outcomes on three or more of the projects we looked DrewSept12th2at. However, we believe the significance of the other factors will be situational, depending on the nature and characteristics of each unique project. The nine factors identified here as the leading contributors will have a much broader impact. Pay special attention to them.

Let’s take a closer look at three of the factors and some of the projects they influenced, either positively or negatively.

The Change Domain

The Change domain focuses on stakeholder decisions regarding the specifics of the change itself. It includes the dimensions of the change initiative, the quality needs and expectations that must be satisfied, the investment decisions behind the change and the stakeholders and their capabilities.

The two Change domain factors that stood out in our review were Stakeholders and Dimensions:

Stakeholders

The Stakeholder factor was a key contributor to project success or failure on all 22 cases. In fact, not one project with an effective stakeholder group failed. So, what is a stakeholder? Stakeholders are the decision makers on the project. They are the keys to project success. Without the right stakeholders on board, your project won’t be successful. Period! In fact, the fundamental premise underlying Project Pre-Check is this: if the stakeholders for a given change are actively involved in and agree with each decision, and all the vital decisions are addressed, the project will be successful.

Project Pre-Check uses a stakeholder model with the four roles shown at the left; sponsor, change agent (project manager), targets and champions. The sponsor, change agent and target roles always need to be filled. The champion role is desirable butDrewSept12th3 optional. Let’s take a look at how the stakeholder group helped or imperiled project success on a few of the case studies.

My last post, You Can’t Always Get What You Want, is a perfect example of what can happen when the balancing influence of the other stakeholders isn’t available to override the ego of a tyrant. The PM formed the stakeholder group at the start of the project but didn’t keep the members engaged over time. The project failed. The post Collaboration in a Command and Control World is another example of the destructive power of a tyrant. In this case, the stakeholder group was never formed and the sponsor attempted to intimidate by edict. That project failed as well.

Sometimes, a steering group is formed to guide a project but the roles and responsibilities aren’t clear and the results tend to reflect that uncertainty. In the post The Offshoring Challenge, Part 2, a multi-million dollar, mission critical undertaking, lack of clear roles and responsibilities in the steering group resulted in lots of back stabbing and finger pointing when things went wrong, and they often did. On top of that, the real sponsor wasn’t engaged and driving the change forward and the designated sponsor really wasn’t. You can’t delegate sponsorship! Eventually the roles and responsibilities were addressed, the right players were engaged and the project got delivered, but months late and millions over budget.

On the positive side, the posts Delivering Portfolio Management Light and A Perfect Project show the kind of successes that can be achieved with a fully formed and engaged stakeholder group – a lead-the-way sponsor, committed and aggressive targets who look after their own organizations’ interests and a change agent who facilitates stakeholder decision making from project inception through completion.

The takeaway: make sure you have your stakeholder group in place and engaged up front and throughout!

Dimensions

What the heck are Dimensions? Dimensions define the breadth and depth of the opportunity or problem being addressed and includes the burning platform, the business problem, need or opportunity, business goals and objectives, worth (what the organization is willing or can afford to spend), requirements, benefits, locations targeted, target dates and rationale, phasing and staging opportunities and expectations, assumptions, success criteria and volumes, transaction mix and peak periods.

The Dimensions factor was central to the project outcome in 21 of the 22. The only case where dimensions didn’t overtly influence the outcome was The Offshoring Challenge, Part 1. The dimensions were known but there were so many other gaps on the stakeholder front, resourcing, risk management, etc., the project went down in flames.

One project that suffered from a “dimensional” gap was covered in the post, The Never Ending Project. It had huge stakeholder issues which may explain why they also had difficulty defining requirements, no sense of the project’s worth to help guide decision making and no understanding of the phasing alternatives to help reduce risk. The project was years late and over four times the original $7 million estimate, with less functionality.

There are other examples of “Dimensional” gaps. The project covered in Eight Steps to PPM Implementation Success didn’t uncover the root causes of business unit discontent until after the Project Portfolio Management effort was terminated. Poor project management practices accounted for over half of the business unit complaints. Limited availability of certain IT skill sets was responsible for almost 40% of project delays. Lack of a comprehensive standard technology infrastructure resulted in significant custom work, increasing costs and risks and adding further delays. PPM would have contributed some value but it wasn’t even in the top ten action items identified.

Sometimes Agile Isn’t covered a similar problem – no clear understanding of the problems that needed to be solved. This project was actually four different changes grouped together. If the stakeholders had actually understood the problems being addressed by the four changes and explored the assumptions around each one and the four together, I expect a very different structure and approach to the problems would have been used. The project was cancelled with over $ 1 million in staff and contractor costs down the drain.

One of many projects that nailed the Dimensions and delivered successfully was covered in the post Avoiding New Technology Risks. The stakeholders knew explicitly what problems they were trying to solve. They figured out what the project was worth to the organization which led to the selection of an appropriate and affordable solution. As well, identifying a business based phasing and staging approach right up front helped iron out the new technology wrinkles and manage the risks effectively. It was a project well done!

The takeaway: ensure your stakeholders have fully addressed the Dimensions decision areas and that they are fully in agreement and stay that way throughout the project.

The Environment Domain

The Environment Domain addresses key dimensions of the current state enterprise infrastructure, the future state target architecture and the business plan that will move the enterprise from the current state to the desired future state.

One Environment domain factor, business plan, was identified with project success in our review.

Business Plan

The Business Plan factor includes eight decision areas: mission, vision, core values, strategies, enterprise priorities, dependencies, programs and timing. Stakeholders need to understand a project’s relationship to each of these facets to ensure consistency of direction and ongoing success. Any dichotomies between the stated directions and beliefs and the impact of a planned change need to be addressed as part of the project.

The Business plan factor was integral to project outcomes in 12 of the 22 cases. Here are some examples:

In the post Pulling the Project Plug, the project was deferred because it had a lower priority than other in-progress projects. Of course, the fact that the initiative had no sponsor and no stakeholder group to assess its relevance and priority was a key contributor to its demise. The end result was wasted millions of dollars and the time of critical resource required by other higher priority projects.

Conversely, in Speaking Truth to Power, the PM knew the project was a high priority, government mandated initiative with significant financial penalties for failure to deliver on time. He leveraged the CFO’s wrath over the lack of progress to secure the right staff, with the right skills at the right time to get the project delivered on time.

The takeaway: your stakeholders need to be fully aware of your project’s relationship with the culture, plans and activities of the larger organization and ensure your project is positioned appropriately.

The Way Forward

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 inception through completion. That’s why it’s central to Project Pre-Check’s model, processes and Decision Framework. We’ve seen how the three factors covered in this article are central to project success. In the next post – Projects Well Done, a Recap – Part 2, well look at the other six factors and how they contribute to project outcomes.

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 have a go. This month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – You Can’t Always Get What You Want

Written by Drew Davison on . Posted in Articles. 4 Comments on From the Sponsor’s Desk – You Can’t Always Get What You Want

FEATUREAug15thIn my last post, Fix the Business Process First, we looked at how a newly appointed VP went back to basics to understand the source of the problems being encountered and tackle the core issues. She solved critical client concerns and operating issues by fixing a broken business process.

In this post, we’ll look at how a tyrannical director’s excessive and unreasonable demands on a project team resulted in project failure and his own demise.

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

The Situation

This regulatory agency mandated a program to create central systems to share engineering data at each of the power generation plants under its oversight. The plant that is the subject of this case was an old plant. Their computer systems and processes were proprietary to each department making it difficult for engineers in other departments to see data that might give them clues about potential and real problems. As well, the plant had had a few low-level incidents and so was being closely monitored by the agency.

The Goal

A project was launched in response to the mandate from the agency to enable full sharing of operational and historical information across the organization, providing engineers with an overall view of plant operations and performance.

The Project

To help understand the desired end result that needed to be delivered, the project team developed and implemented a pilot in nine months. While it was not perfect, it did in fact work and was used on an interim basis to collect and disseminate the operational information. The regulatory agency was okay with the pilot as an interim solution but wanted the final version greatly improved (as did the engineers).
The pilot was barely finished when meetings for the next generation system started taking place. The project team wanted to move the pilot to a more advanced platform for managing the current and historical data and the associated charts, graphs, images and documents that were the core of the system. They considered a number of alternative solutions and presented their recommendations to IT management and the plant managers. The proposed solution was based on recently released technology and had a two year implementation target. The IT and plant managers liked the proposal but were somewhat concerned with target platform’s stability and reliability and the projected time frame. The team developed a plan to mitigate the risks. The IT and plant managers were satisfied. The project director was not.

The project director was a tyrant – an impossible man who had temper tantrums regularly and chewed people out throughout the day. He gave the team 6 months to put a new system in place with the new architecture. The project manager consulted with her team. They all agreed that 6 months would be utterly undoable. They proposed a number of options that would get them a phased in target solution over a two year period. The director insisted on the 6 month target. The project manager resigned. The regulatory agency was watching with great interest.

The Results

As predicted by the project manager, the deadline arrived and the system was not even close to complete. The replacement project manager was fired. The other plant managers looked the other way and had their engineers continue to use the original pilot. The project went on, but it was now too little, too late. The pilot stayed in use as the real system for another three years. Once again, a team was put under extraordinary pressure for little reason and nothing to show for it. The project director left the plant to pursue other interests. You can’t always get what you want!

How a Great Project Manager Tried and Failed

These are always tough situations to deal with. When the individual in charge tries to impose his or her will on others without considering and responding appropriately to the opposing views and feedback of knowledgeable professionals, chaos almost always ensues. The result: messed up lives (and sometimes careers), questionable quality, wasted opportunity, time and money.

In many ways, the original project manager did the right things:

  • She focused on the objectives of the project to address the needs of the plant managers and the regulatory agency.
  • She consulted fully with her team and accepted their counsel.
  • She and her team developed alternative approaches that would phase the solution in over two years to accelerate the delivery of benefits and manage the risks associated with the new architecture.
  • She said NO to an unreasonable demand.
  • She escalated her concerns to her boss but, for a number of reasons including his own potential loss of job, he sided with the director.

What else could she have done? It’s not easy defying a tyrant but that’s exactly what was called for in this situation. Obviously the project director’s pursuit of an impossible 6 month solution was not only bad for the team, it was bad for the whole plant and the regulatory agency too. The director’s demands were exposing the plant to significant risk. The project manager needed to go around and/or over. And, that’s exactly what she did.

  • She tapped into the other stakeholders to shift the director’s demands. The departments were protective of their data, but were told they had to comply (even though they hated this guy and did not want to see him succeed). Here was an opportunity for the other stakeholders to wield their influence. Unbelievably, they sided with the director.
  • She escalated directly to the plant manager, admittedly very tough to do without the support of your own boss. He sided with the project director as well.
  • Finally, she went directly to the regulatory agency for guidance. The agency’s representative on the project also supported the project director’s stance.

The project manager discovered that the director had sold a bill of goods to the stakeholders (behind her back) and by the time he presented his demands to her, it was too late to alter the opinions of the other stakeholders. They were all on board with the director, assuring the project manager that it would be all right. She watched the director’s enemies slap him on the back and congratulate him for being so smart. The project manager departed with her head held high.

The project manager had formed a stakeholder group at the outset of the pilot and they had been actively involved through the early stages. But, as so often happens over the course of a project, during the pilot development and implementation and the envisaging of the replacement solution, the project manager had focused much more of her attention on guiding her team to get the work done, much less on stakeholder engagement. That left her stakeholders ripe for the picking by the project director. Had she fully engaged the stakeholders throughout the pilot and into the development of the new architecture, they would have been much more aware of the issues and risks, more committed to the approach recommended by the project manager and much less likely to be swayed by a bullying director.

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 inception through completion. 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 have a go. This month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management.

Drew Davison

Don’t forget to leave your comments below.