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 Sponsor’s Desk – Delivering Portfolio Management Light

In my last post, Eight Steps to PPM Implementation Success, we looked at an organization’s attempt to deliver portfolio management capability. The IT department took it upon themselves to implement a portfolio management solution to curb what they saw as excessive and conflicting business demands without engaging those same business units in the effort. They failed miserably! We also looked at the eight steps a great PM would have taken to avoid the issues encountered and deliver a successful solution.

In this post, we’ll look at an organization that found itself in need of a decision making framework and managed to deliver a workable project portfolio management solution in a little over four months through pragmatic use of available best practices and technology.

The Situation

This 2000 person technology infrastructure operations group, part of an international financial services organization, had just completed a major reorganization along functional lines. Because they did not have a centralized, consistent, scalable and repeatable approach for managing their IT project portfolio, the restructuring resulted in ad hoc procedures for submitting, assessing, authorizing and monitoring change initiatives and a sizeable backlog of changes looking for approval, funding and resourcing.

The Goal

The organization set out to design and roll-out an end-to-end project portfolio process that would support the leadership team in their decision-making activities related to infrastructure investments. The developed process was to leverage industry best practices and available technology to achieve the following objectives:

  1. Ensure proposed initiatives were proactively socialized with all impacted stakeholder groups to solicit buy-in and support.
  2. Provide a consistent and repeatable approach for capturing required information for effective management decision making.
  3. Build and manage a project portfolio to maximize the returns from the investments in infrastructure expansion and improvement initiatives.
  4. Deliver and implement an operating solution within four months to address a considerable demand backlog.

The Project

The initiator and sponsor of the project portfolio venture, one of four VP’s in the group, sold the project to his peers and to the senior VP who had overall responsibility for the infrastructure operations organization. He brought in a Director with whom he had previously worked to act as the first portfolio manager and be the first target. He also contracted with a consulting firm familiar with Project Pre-Check to act as the change agent for the design and implementation activities. In addition, approximately thirty directors were identified as targets of the change. In the future, they would have to understand and use the new practice to initiate projects that exceeded a certain threshold and required or impacted resources in other parts of the organization.

The sponsor selected Project Pre-Check as the source framework and specified the use of MS Office and related products for the initial launch. He chose Project Pre-Check because its Decision Framework is built upon guidance from numerous well-established and recognized industry frameworks and methodologies (e.g. ITIL, CobiT, PMBoK, SEI, ValIT, Gartner, etc.).

The sponsor worked with the targets and change agents to agree on relevant decision areas from among the 125 included in Project Pre-Check. Twenty decision areas were ultimately selected for the initiation stage and a further twenty five were selected for the planning stage submission. An Excel template was developed to capture the input. A prioritization model was built, again in Excel, to assess the multiple submissions, weight, rate and rank and generate the summary charts for the decision makers. In addition, MS Project was used to manage the resource demands using its Excel import capability and SharePoint was used to source the templates and capture the submissions. 

Support materials were developed including the process models, a process guide, terms of reference and cheat sheets. The targets were engaged in a number of sessions throughout the development of the materials and provided with a half day review of the finalized process.

The Results

The first senior management portfolio review including twenty-four project submissions was conducted three and a half months after the project launch. With a few minor teaks along the way, the portfolio management light solution continues to meet the organization’s needs. Not bad for a quick and dirty solution!

How a Great PM Helped

The PM on this project did four things very well:

  1. He involved the sponsor and gave him free reign throughout. The sponsor was an enthusiastic, respected and committed leader who knew what he wanted. The targets knew very well not to resist for very long or they would get flattened by the steamroller. The PM gave the sponsor the information he needed and stepped out of the way.
  2. He engaged with the targets frequently, addressed their concerns as best he could and leveraged their suggestions so that it was obvious to everyone that the solution was a collaborative effort.
  3. He settled for “good enough”. He could have spent months evaluating and debating the selection and definition of the decision criteria. He could have spent many more months on the weighting, rating and ranking exercise. Instead, he made sure the 90% solution was in front of the stakeholders quickly and wrapped up debate expeditiously. Leveraging Project Pre-Check provided a significant advantage because it helped establish the boundaries and provided a ready, comprehensive source for decision criteria.
  4. He used the available technologies within their capabilities. He ensured the tools were used for what they were good at and suitable for. He didn’t invest a great deal of time and money getting the technology up and running. It’s easy to run and relatively easy to change and it won’t cost much to get out if a decision is made to go to something more robust in the future.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a project that assessed an organization’s project management maturity and helped lead to a significant improvement in their capability and performance.

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.

 Don’t forget to leave your comments below.

From the Sponsor’s Desk – Eight Steps to PPM Implementation Success

In my last post, The Offshoring Challenge, Part 2, we looked at the challenges a company faced when it chose to use an offshore developer to rebuild its core administrative systems. They ran into oodles of issues and exceeded targets on budget and schedule but, amazingly, all parties were pleased with the end result. We also looked at how a great PM would have helped avoid or minimize the issues encountered and deliver an even better outcome.

In this post, we’ll look at an organization’s attempt to deliver project portfolio management (PPM) capability. In this endeavor, the IT department took it upon themselves to implement a PPM solution to curb what they saw as excessive and conflicting business demands without engaging those same business units in the effort. The project was NOT a resounding success.

The Situation

This organization provided insurance products for individuals and businesses across the country. The business units prided themselves on their innovative product offerings and were constantly refining and developing products and services to serve their markets. Lacking any formal assessment or priority setting mechanism, the IT organization struggled to respond to the growing demands for faster delivery and improved and expanded services. That left the business units frustrated with their inability to compete effectively in the marketplace and very dissatisfied with IT performance.

The Goal

The IT organization saw PPM as the means of dealing with the business concerns. It would provide the platform for assessing multiple, competing business demands and establishing organizational priorities that would enable IT to respond in a rational and managed manner.

The Project

The CIO assigned the VP responsible for the PMO to address the growing business dissatisfaction with IT responsiveness. The VP launched an initiative to implement a project portfolio management solution in the belief that it would address the problem. The target date was the start of the annual corporate planning cycle, seven months away. Because of the limited time available before the start of the corporate planning process, he chose not to involve the business units in the development of the solution.

The project manager assigned was to draw his staff from the PMO pool, using project managers between and during project management assignments. He was also charged with implementing the design on the parent company’s chosen project and portfolio management technology platform.

The Results

The PM proceeded to secure what staff he could from the PMO pool and set them to work exploring the PPM processes. They identified the information they thought they would need to evaluate project requests and establish project priorities. They reviewed their designs with the PMO VP and other IT VP’s and incorporated the feedback as they proceeded. However, progress on the project was impeded by the lack of staff and the reassignment of staff to other projects. The design work that was expected to take three months took six months. They had one month to get the solution implemented on the provided PPM technology before the start of the corporate planning cycle. With no knowledge of the technology, they were woefully unprepared for the task. With no time left they decided to introduce the PPM process to the business and hope they could get the technology up and running in time to support the planning effort.

With the PPM capture form in hand, the IT Account Managers engaged with the business units just prior to the start of the corporate planning exercise. They informed the business unit heads that, henceforth, a new portfolio management process would be used to determine project priorities and allocations. No more could they demand IT resources and facilities for their own latest pet project with going through PPM. No more could they inject their new project at any time during the year without going through PPM. No more could they suddenly expand scope on an in-flight project and expect IT to respond immediately to the change, without going through PPM.

You can guess how those encounters turned out! The business unit heads were outraged. They harangued the CEO and urged him to quash this perceived intrusion on their ability to operate as they saw fit. The CIO was so besieged, he capitulated. The project was cancelled. The PMO VP and project manager were dismissed. Life returned to its unsatisfactory past with half a million dollars down the tube.

How a Great PM Would Have Helped

This was a very difficult situation for the project manager. The sponsor, the PMO VP, needed to be challenged! The sponsor imposed constraints on the project that dramatically increased the risks; no business unit involvement, staffing with PM’s who were either on the bench or running other projects and the target technology. It was decision time for the PM and he folded. The lesson – don’t take an assignment if you don’t have control over the critical success factors. Here’s what a great PM would have done:

  1. Identify and engage the stakeholders – A great PM would have insisted that the business units be brought into the project. Yes, that could have yielded all kinds of resistance. And that’s exactly what a great PM wants to bring to the surface and resolve early in the game. It may also have results in shifting the initiative from the IT realm to business ownership with the CEO as sponsor.
  2. Know what problem you’re trying to solve – In the aftermath of the PPM project cancellation, the CIO launched another initiative to improve IT responsiveness and what it discovered was revealing. 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.
  3. Staff appropriately – what chance did this project have when it had to beg, borrow and steal from an uncertain pool, where the incumbents had limited or no experience with PPM, process design and the PPM technology. A great PM would have insisted on getting the staff and skills needed to do the job right.
  4. Establish prioritization criteria early – There was an assumption from the start that IT would set and apply the prioritization criteria. Wrong! The prioritization criteria IT presented to the business unit heads became the factor that generated the most resistance. IT was looking for things that most concerned them, like resource demand, technology platform impact, required timing. The business would have been much more amenable to the project if it had focused on things of interest to them, like support for business strategies, impact on revenues, costs and the bottom line. A great PM would have seen this as a critical success factor and addressed it early in the game.
  5. Get agreement on roles and responsibilities – The assumption that IT would be the final decision-maker on the priorities set the project on the wrong course from the very beginning. This was an enterprise wide initiative! A great PM would have recognized that fact and dealt with the question of roles and responsibilities early on, at least at a high level.
  6. Understand demand, capacity and cultural impacts – The PPM project being run by IT focused primarily on quantifying demand, understandably. However, had they been successful in implementing and running their solution, they would have soon encountered difficulties with the capacity question and the need to understand and manage the allocation of resources and skill sets and the cultural influences (statutory holidays, vacation and education policies and other demands including advisory groups, standards teams, governance committees) that can consume 20% or more of available capacity.
  7. Take little steps – The PPM project consumed the majority of their available time in the design of their PPM process. They had little experience with and knowledge of PPM and no confirmation that they were on the right track outside of IT. A great PM would have recognized and mitigated these risks with a plan to test early and often. It would have also served to get the business engaged much earlier.
  8. Measure and communicate, early and often – This factor, or lack thereof, was actually at the heart of the IT/business conflict. IT lacked formal communication approaches and so the business and IT executives never were presented or saw the whole picture. They lacked metrics to assess ongoing performance of services that were important to the business so there was no context for business complaints. At a project level, communication was left up to the individual PM. There were no established reporting templates or distribution standards. A great PM would have understood that transparency and visibility are critical to project and organizational success. A great PM would have ensured that project targets were established, progress was measured, risks identified and mitigated, issues identified and managed and stakeholders informed in a form, medium and time frame suitable to their needs.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a situation that I call Delivering Portfolio Management Light. The organization in question found itself in need of a decision- making framework as a result of a re-organization and managed to deliver a workable portfolio management solution in a little over three months.

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.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – The Offshoring Challenge, Part 2

In my last post, The Offshoring Challenge, Part 1, we looked at a situation where a project manager with no prior experience in offshoring ran into serious trouble with the offshore developer. The project was delivered, but at double the original cost and significantly late and only after terminating the offshoring contract. We also looked at how a Great PM would have leveraged the Project Pre-Check fundamentals of stakeholders, defined processes and a best practice based decision framework to achieve great results.

In this post, we’ll look at the challenges a company faced when it chose to use an offshore developer to rebuild its core administrative systems. That’s why I call this post The Offshoring Challenge, Part 2.

The Situation

This organization provided a number of key administrative services to the domestic and international financial services communities including banks, trust companies, investment dealers and others. Their core administrative processes and systems were not able to address the clients’ growing demands for faster response times and improved and expanded services through online and internet based offerings.

The Goal

The company’s plan was to redevelop their core administrative processes and systems and leverage modern technologies to provide the most advanced services of their kind in the world. The company had a total of 400 employees and clearly lacked the capacity to handle the challenge ahead of it although it did have a wealth of expertise in the business and application architecture fronts. Consequently they sought an offshore development partner.

The Project

The organization created a steering committee to guide project progress. The steering committee was chaired by the CEO and included all VP’s from all the organizations affected by the planned change. A senior business executive was designated as sponsor and a consultant brought in by the business was appointed PM. A $20 million contract was negotiated with a software development vendor in India. The overall budget was established at $40 million.

The Results

The project was organized into five phases to be delivered over four years with the bulk of the work, and risk, in the last three phases. The first two phases were delivered largely on budget and plan. And then the fun began!

The Negatives:

  • The members of the steering committee had no formal roles on the project other than oversight and they took to that assignment with zeal, harpooning anyone whose performance may have been less than stellar. There was frequent finger pointing across the table — at the business, IT and vendor teams and their own members. Of course, those conflicts carried on outside the steering committee meetings and infected the business, IT and vendor team relationships as well. It was a caustic environment.
  • 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. Chaos reigned.
  • The designated PM turned out to be a consultant to the business and spent most of her time developing business specifications. The IT organization assigned senior staff to manage various development components but had no one in place to provide overall project management.

The Positives:

  • The offshore developer provided a senior project manager at the company’s site and another at their offshore location and the two controlled and coordinated all software development activity. That resulted in a very positive outcome and contributed significantly to the success that was achieved.
  • The designated business sponsor, IT development managers and the vendor PM had twice weekly conference calls with their counterparts offshore to review progress and resolve issues. In spite of the communication challenges and conflicts, the exercise worked well and was able to initiate remedial action and deliver results.
  • The in house software development methodology and existing processes for managing issues and changes were used effectively by all parties.
  • A risk plan was developed and updated periodically but was not integrated into an overall project plan. Consequently some key mitigation actions did not happen, causing schedule delays and resulting in incremental costs.

Significant quality issues started to emerge during the latter stages of phase 3 as well as  the concurrent early work on phase 4. The problems were traced to language issues, communication problems, lack of business understanding by the offshore development staff and lack of overall direction. Three major changes in the conduct of the project were instituted by the steering committee after consultation with senior vendor staff:

  • The offshore developer moved part of the development team to the client site. At one point over 100 developers were on site working hand in hand with the business staff and IT development staff.
  • There was a dramatic increase in the number of face to face meetings between the vendor’s senior staff and the company’s senior staff, in India and locally, to improve communications and foster better, faster decision making.
  • The designated sponsor was removed from the project and sponsorship accountability was placed in the hands of the CEO. A senior executive with in depth knowledge of the business and recent experience in a similar project was brought in to provide overall guidance.

The project was finally delivered successfully, a year later and over 50% more than originally budgeted. Ironically, at the end of the project, all parties involved in the undertaking were pleased with the results.

How a Great PM Would Have Helped

Even though no one had overall responsibility for managing the project until Phase 4, there were talented, knowledgeable and committed staff from the business, IT and the vendor who took a number of actions to help ensure some degree of success.

  • Senior management did a good job articulating their vision and ensuring that there were no other competing priorities to impede the progress on this mission critical venture. In hind sight, senior management also did a good job of selecting the offshore developer.
  • The business units affected contributed some of their key personnel to ensure the specs were done right and to confirm that the delivered components met their needs.
  • The IT managers involved ensured that a development methodology was in place and used consistently both locally and by the offshore developer. They also established the internal procedures for issue, change, risk and quality management as well as project control and communication.
  • The offshore developer provided talented leaders and took the appropriate actions when required to resolve the quality issues in phases 3 and 4.

A lot of good things were done on this project but with much gnashing of teeth and clenching of fists. A great PM could have made it a much more pleasant experience with improved performance in addition to facilitating the formation of a committed, collaborative and accountable stakeholder group to shape the delivered solution. A great PM would have ensured that each member of the stakeholder group understood the role they were playing (sponsor, change agent, target and champion) and the accountabilities that went with each role. In fact, that’s what actually happened when the senior executive was brought in as the project executive during phase 4.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a situation that I call Portfolio Management, the Bad. In this endeavor, the IT department took it upon themselves to implement a portfolio management solution to curb what they saw as excessive and conflicting business demands without engaging those same business units in the effort. The project was NOT a resounding success.

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.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – The Offshoring Challenge, Part 1

In my last post, Anybody Can Manage a Project, Part 2, we looked at a situation where a manager with no prior PM experience and no formal PM education managed to deliver an enterprise wide project successfully and with wide acclaim. We also looked at how this Great PM leveraged the Project Pre-Check fundamentals of stakeholders, defined processes and a best practice based decision framework to achieve great results.

In this post, we’ll look at the challenges a company faced when it chose to work with a third party organization with staff from a different culture, in a distant location, in a different time zone. That’s why I call this post The Offshoring Challenge, Part 1.

The Situation

A leading financial services organization planned to offer Creditor Insurance to their branch customers through a newly created insurance subsidiary. Creditor insurance provides insurance to cover mortgage payments, credit card payment protection, coverage for home and small business loan payments, and personal line of credit payments. The company aggressively advertised the availability of Creditor insurance at all company branches as of a certain date.

The Goal

The company needed a new system and new administrative processes to administer Creditor insurance. The change required interfaces with approximately 75 existing systems and procedures within the company and with external partners. The company expected high revenues from this product offering and established a project budget of $7milion

The Project

The organization assigned a senior project manager who had a proven track record in managing projects for the company although he had no experience managing an offshored initiative. The company also decided to offshore much of the development work to a vendor in India. These resources were very well-priced and the vendor had a good relationship with the company from work in another division. The developer assigned a senior project manager to guide the offshore effort and liaise with company’s PM.

The Results

The project immediately went into a tail spin:

  • A plan was developed jointly with the developer and the company’s staff but progress lagged even in the first few months.
  • The quality of the products delivered by the offshore developer was abysmal.
  • Over 70% of the deliverables had at least one defect.
  • The number of submitted change requests from the company’s staff was very high due to their lack of experience with Creditor insurance products, processes and practices.

Senior management on both sides of the ocean was not actively involved, even as the project spiraled dangerously out of control.

The two project managers and their senior staff initially used weekly conference calls to review progress and agree on remedial actions and required changes. However, the sessions were so frustrating and ineffective for all participants that they were abandoned in favor of email. Meaningful communications went downhill from there.

Nine months into the project, the company’s project manager recommended to senior management that the relationship with the offshore developer be terminated and local resources be used to complete the project. After much gnashing of teeth, management acquiesced. The newly acquired local resources had to go through a learning curve to get up to speed and additional resources had to be hired to try and bring the project back on schedule, at significant cost to the company. The final result: actual costs were double the original budget and the project was delivered nine months late.

How a Great PM Would Have Helped

This project is an unfortunate example of what can happen when a project situation varies from the usual organizational experiences and steps aren’t taken to address that gap. The company’s senior management and the assigned project manager had minimal exposure to Creditor insurance and little experience with an offshoring effort, yet they took no action to understand the issues and risks and adapt their approaches accordingly.

Certainly there is a vast store of information and expertise on offshoring challenges and the practices that can be used to mitigate the risks. Unfortunately, considerable time, effort and energy are usually required to leverage that knowledge effectively. That’s where something like Project Pre-Check can add huge value for a company and its project managers, by providing a mechanism to ensure stakeholders are identified and engaged and a decision framework is available to foster effective deliberations and decision making.

Below are some actions a great PM would have taken, leveraging the Project Pre-Check Decision Areas or a similar framework, to ensure a successful outcome.

  • First and foremost, a great PM would have ensured stakeholders from both the company and offshore developer were identified and actively engaged in the project.
  • 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.
  • Creating an effective team takes more than throwing some staff at a problem and hoping they all get along.
  • A great PM would have developed a team formation plan that ensured shared goals, objectives, processes and ground rules, addressed the cultural and language differences, dealt with the distance and time zone challenges and leveraged technology as appropriate to enhance team performance.
  • A great PM would have looked at the skill and capacity needs in both the offshore and in house teams and put a development plan in place to address the gaps.
  • A great PM would have confirmed, with all parties involved, the processes to be used to plan, organize and control the project and communicate performance against plan. If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at another offshored project that I call The Offshoring Challenge, Part 2. This massive undertaking was largely successful even though it wasn’t clear at times who the project manager was or who the sponsor was.

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.

Don’t forget to leave your comments below

From the Sponsor’s Desk – Anybody Can Manage a Project, Part 2

In my last post, Anybody Can Manage a Project, Part 1, I reviewed a failed project that had a PM with no prior PM experience, no formal PM education and no in-place mentor. I also looked at how a Great PM could have leveraged the Project Pre-Check fundamentals of stakeholders, defined processes and a best practice based decision framework to achieve great results.

In this post, we’ll look at a similar situation with a much more successful outcome. The PM was asked to manage an enterprise wide project with no prior PM experience, no formal PM education and no in-place mentor and she pulled it off. That’s why I call this post Anybody Can Manage a Project, Part 2!

The Situation

A global mining company had a number of Enterprise Resource Planning (ERP) solutions in place in various regions and departments as a result of their growth by acquisition. Work was in progress to standardize their ERP platforms. As part of that standardization effort, the organization also planned to implement a global standard for segregation of duties (SOD) to meet required compliance standards (i.e. Sarbanes-Oxley).

The Goal

The company planned to develop and implement a global SOD standard that would be used to support the management of controls for regional ERP applications and to support the management of SOD risks into the future. The project would also benefit other functions including compliance.

The Project

The Finance organization launched the SOD standards initiative and developed a comprehensive SOD matrix over a period of eight months. A Working Group was established to move the project forward and included Finance department managers and staff with some consultation with the head office IT organization.

As Finance was wrapping up their SOD design, the head of Global Internal Audit heard rumblings from the regions concerning the work being done, its complexity and the regions’ lack of involvement to that point. He proposed to the Finance VP that an audit be done to assess the performance of the project to date, identify gaps and target opportunities to provide the foundation for a successful implementation. His recommendation was approved.

Internal Audit launched the project audit using Project Pre-Check’s Diagnostic process. The assessment involved a review of the processes used to guide the SOD work and the project deliverables to date. It also involved interviews with selected members of the Working Group and additional staff in the regions regarding their views on progress to date and thoughts and suggestions on future plans. The interviews addressed the interviewees’ level of agreement on a selected subset of Project Pre-Check’s Decision Areas (60 of the 125) covering the nature of the planned change, the environment within which the change would be implemented, organizational processes and practices that could be leveraged and the management of the project itself.

The interview results showed that the SOD project’s overall level of stakeholder agreement on the project was 2.4 on a scale from 1 to 5, where 5 was completely in agreement with the decisions reached. The results indicated that the stakeholders interviewed were not in synch on the 60 Decision Areas addressed. Not a great recipe for success!

The results identified 43 of the 60 Decision Areas in the assessment (70%) as areas of divergence (at least one of the stakeholders was not in agreement with how a decision area was addressed) and 8 areas (17%) where a gap existed (where the majority of stakeholders expressed a lack of agreement). The responses reflected differing views on the scope of the project, costs, benefits, the target dates, the sponsor, project manager, decision making responsibilities and governance.

The audit took about four weeks to complete. The audit leader presented the findings and recommendations to the audit committee. The recommendations included:

  • Confirm the sponsor
  • Form a stakeholder group including comptrollers from all regions
  • Appoint a project manager
  • Work towards full agreement on all 60 Decision Areas included in the audit.

The Results

The sponsor was confirmed. A stakeholder group was formed and operated through to the completion of the project. A project manager was appointed to carry the project forward. She was a recent hire in the Finance organization with accounting qualifications and a financial background but no formal project management training or experience.

The project was delivered successfully in all regions according to the budgets and dates negotiated with the head office groups and with each regional comptroller. At implementation, all 60 of the Decision Areas addressed in the audit averaged 4 or greater, indicating very strong agreement among the stakeholders on the decisions made. All gaps and areas of divergence had been eliminated. The members of the stakeholder group were unanimous in their praise for the job done by the PM. Not bad for a PM with no prior project management experience!

How This Great PM Helped

The senior management attention initiated by the project audit and the subsequent actions taken on the audit recommendations provided the PM with a huge starting advantage. She had a designated sponsor and she had a committed stakeholder group representing the organizations affected by the change. As well, because everyone knew she had been selected by senior management to guide the project, she was perceived to have the authority to act, to acquire the necessary staff and other resources and quickly push through the needed decisions.

To her credit, the PM used those assets effectively and took the following additional actions that were necessary to get the job done:

  • She determined the sponsor’s expectations regarding ongoing oversight on costs, benefits and timing and on existing corporate practices that he expected to be used. She helped him articulate his thoughts on how scope, change, issue, quality and risk management should be handled and confirmed his criteria for calling the project complete.
  • She engaged the sponsor to review these expectations with the other stakeholders and gain their agreement, facilitating collaboration and compromise where needed.
  • She established roles, responsibilities and operating protocols for the stakeholder group, including the sponsor, targets, the champion and her own role as change agent.
  • She used the 60 Decision Areas addressed in the project audit as the basis for a report card tracking stakeholder agreement levels over time.
  • She modified the standard project reporting template used by the IT organization to address the sponsor’s information needs and further adapted the practices to address some unique concerns of the other stakeholders.
  • She worked with the other stakeholders to develop an overall plan and approach that met the overall needs of the organization and addressed the requirements of each region.
  • She went the extra mile to ensure the regional comptrollers from far off places (Asia Pacific, Australia and South America) were involved and up to speed on developments even though it meant some extra long days for her. It paid dividends in open and honest dialogue over the course of the project.

The bottom line: she was successful because she worked effectively with a committed, knowledgeable stakeholder group and she used and adapted existing frameworks and practices to guide the project to completion.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a great PM, and your sponsor’s best friend.

Next, we’ll look at a situation that I call The Offshoring Challenge. In this assignment, the project manager paid the price for failing to assess the risks of working with staff from a different culture, in a remote location, in a different time zone. 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, send me the details and we’ll have a go.

Don’t forget to leave your comments below