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 Sponsor’s Desk – Leaving a Legacy of Lessons Learned

Written by Drew Davison on . Posted in Articles. 4 Comments on From the Sponsor’s Desk – Leaving a Legacy of Lessons Learned

“Those who cannot remember the past are condemned to repeat it”. 

                                                                       – George Santayana

In my previous posts in the From the Sponsor’s Desk series, I’ve focused on real projects and the lessons we can learn from those experiences, good and not so much. My reference point in each case has been Project Pre-Check. It provides a framework of best practices, mined from a variety of sources including project management, software development, management of change, strategic planning, quality practices and others, that project stakeholders need to consider at project launch, throughout the course of the change and into the post completion review. But what can an organization or an individual do with those learnings to gain ongoing value? This post suggests an approach.

Project completion reviews or post-mortems are often seen as an essential best practice that enables organizations to learn from their experiences. However, all too frequently, the insights gained from post implementation reviews are lost to posterity.

There are a ton of books, periodicals and articles that address project management, software engineering and management of change disciplines and practices. But the rate of success for major business and technology changes is still well below 50%? Why? The bottom line – we lack a common mechanism where findings can be stored, examples cited and recommendations for future undertakings recorded and accessed. And, we lack the structure and discipline to ensure that our knowledge is managed and referenced consistently and rigorously.

According to Nancy Dixon in her conversation matters blog, “NASA learned its lesson about losing knowledge early in 1990. They experienced “the sad recognition that much of the knowledge about how to build the Saturn V rocket that took the astronauts to the moon, had retired along with the engineers who had been encouraged to take early retirement”. In response, NASA created the NASA Engineering Network, a knowledge network to promote learning and sharing among NASA’s engineers. The Network includes the NASA Lessons Learned data base, “the official, reviewed learned lessons from NASA program and projects”.

Most stakeholders involved in a change aren’t aware of all the best practice information out there and aren’t inclined to spend the time and money to find out. They’re business people, financial types, actuaries, engineers, marketing folks, business analysts, IT practitioners. They’re not project management or management of change experts. They don’t really understand the role they need to play and the knowledge they need to have to ensure success! They just want to get the job done.

So, what do you do as a sponsor, stakeholder, PM, BA or other interested party to leave a legacy of lessons learned? There are five critical steps:

  1.  

    Identify and confirm accountability for managing lessons learned

Somebody needs to own this practice, to establish the goals and objectives, to measure performance, communicate to stakeholders and establish and drive initiatives to increase organizational value. Even open source software groups, which count on thousands of interested volunteers to deliver and enhance functionality, have managing entities to oversee progress. Find an owner and hold him or her accountable. More on this later.

  1. Build or acquire a framework

Even with lots of great experiences, insights and findings, without some kind of organizing structure, a collection of project post-mortems will pose an unwieldy and perhaps insurmountable barrier to leveraging collective lessons learned. Fortunately, PMI, ISO, ISACA, SEI and many other organizations have developed frameworks and a wealth of best practice information. I personally developed the Project Pre-Check Decision Framework to bring together the best of project management, management of change, software development and other practices and provide a Lessons Learned framework in my consulting practice. Select a structure you and your organization are familiar with and build it up with real world experiences and examples to facilitate effective use and enable real performance improvements. Or build your own framework.

  1. Enforce usage

Having a comprehensive, easy to access, easy to use facility for mining best practices adds absolutely no value if no one uses it. So part of the Lessons Learned challenge, and a critical responsibility for the owner, is to ensure that everyone uses it, on every assignment, for every project. That use needs to involve a thorough review to identify and leverage applicable best practices and contributed learnings in a form and structure others can use. I can hear the groans already! More bullshit! More red tape! Get over it! If your organization wants to improve its ability to deliver major business and technology change successfully, a certain level of rigor and compliance is essential. What would you rather be, a sponsor, PM, BA or architect with an incredible track record of successful project deliveries, enabled by an organizational ability to leverage lessons learned, or an incredible individual contributor with a mixed record of project successes? Your choice!

  1. Manage the transformation of project experiences to organizational Lessons Learned

A key challenge is gathering the experiences and insights of each project participant and the collective wisdom of project teams and abstracting that information into the selected framework. Don’t leave it up to the BA or PM to post the project learnings to the Lessons Learned framework! The owner needs to assume that responsibility and establish the analytical mechanisms and quality and usability standards that will ensure that others, in different circumstances and on other assignments, can quickly and effectively gain value from the information.

  1. Manage Lessons Learned value contribution

There is no point in doing anything beyond individual project post-mortems if you’re not willing to manage the organizational value contribution. Getting a return from Lessons Learned means measuring usage, compliance, value derived and contribution frequency and identifying gaps and discrepancies in content and application. The measurement results provide the fodder to develop and implement continuing improvements to the practices, increasing the value delivered to the organization.

Where should Lessons Learned be managed? The PMO is an obvious suspect. The PMO mandate is usually very compatible with a Lessons Learned program. It typically has a broad view, encompassing enterprise or organizational initiatives, programs and projects. It should be tracking and reporting on aggregate project performance and taking steps to improve that performance, actions that are very compatible with a Lessons Learned program.

But, implementing a Lessons Learned practice across an organization is another change that has to be sold, prioritized, funded, initiated, staffed, managed and monitored. It is still very worthwhile but there is another option – the individual Lessons Learned practice. As a professional, you have undoubtedly committed yourself to a program of continuous improvement. An individual Lessons Learned practice starts and ends with you. You need to follow the same five steps reviewed above but you don’t have to sell anybody else on the idea. You are the decision maker. As you gain value, and confidence, you’ll build a track record and reputation others will notice. Also, share your experiences with your peers. Chances are you’ll find an enthusiastic audience and perhaps an attentive sponsor in waiting. Good luck.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Avoiding New Technology Risks

Written by Drew Davison on . Posted in Articles. 4 Comments on From the Sponsor’s Desk – Avoiding New Technology Risks

In my last post, Collaboration in a Command and Control World, we looked at one project manager’s experience trying to guide a technology upgrade where the sponsor focused exclusively on time and costs.

In this post, we’ll look at the steps one project manager took to leverage a promising new technology while avoiding the pitfalls often encountered with new technology introductions. Thanks to reader A.R. for the details on this case.

The Situation

This U.S based financial services organization managed 401(k) plans for employees of small to medium size businesses. A 401(k) retirement savings plan allows a worker to save for retirement and have the savings invested while deferring current income taxes on the saved money and earnings until withdrawal.

The company’s product offerings allowed participating client employees to invest in a wide variety of popular mutual fund products. The client employees would call the company’s service staff to get quotes on funds and to place orders for new investments or changes to existing ones. The company had a web site that offered similar services but found that the volume of phone calls continued to increase with the growth in their business. It was posing an ever increasing cost burden on the organization.

While interactive voice response (IVR) technology is common today, in the early 21st century it was an emerging technology. However, because it held such promise to address their challenge, the company decided to take the plunge.

The Goal

The VP, Customer Service, the sponsor of the initiative, after discussions with the CIO and senior technical staff, decided to wade into the then largely uncharted IVR waters. She launched a project to leverage the new technology to reduce the current and growing costs of their phone services.

Her goal was to deliver an IVR system that would support the quote and trading functions for client employees across the country and have it fully operational in one year. She was looking for a 50% rate of conversion to IVR.

The Project

The IT organization appointed a seasoned project manager. Because the company had no experience in the IVR arena, he knew trying to estimate the costs of the project would have been a fool’s errand. They talked to a number of vendors and early users to know that an effective solution was possible. But the costs quoted varied widely. So he worked with the VP to figure out what she could afford by looking at the expected reduction in current costs and slowing the cost growth rate while offering the same or improved service levels. Her target – $1.2 million with a 70% IVR usage rate. That would give her a 2 year payback.

The project manager, working with an assigned business manager, the $1.2 million cost target and two of the most likely technology vendors, developed a plan of attack that included the following key elements:

  • Identify and engage key stakeholders
  • Get stakeholder agreement on the dimensions of the change. That included clarifying the opportunity for the company beyond this particular application, the specific goals, requirements, benefits, locations affected, desired or required target dates, anticipated volumes and phasing and staging opportunities from a business perspective.
  • Get stakeholder agreement on the quality expectations, including factors like security, authorization, ease of use, continuity, scalability, localization and audit trail.
  • Also, with the stakeholders, firm up the economic justification including the overall economic impact (business, IT, clients, others), competitive advantage, strategic fit, competitive risk and project risk.

With a fully developed picture of the project, its impact on the organization, and buy-in from the stakeholders, the PM assembled a small team including an experienced and respected staff member from the Customer Service organization, a business analyst, a programmer analyst and a senior technical analyst from the IT Operations group. Together they developed an RFP that went out to the two IVR vendors who had helped in the planning plus two additional vendors that showed promise based on feedback on the systems they had delivered.

When the RFP responses came back, the content was vetted, rated, ranked and their proposals assessed against the $1.2 million cost target. One company stood out (one of the two involved in the planning effort) and was approached to deliver the required solution. During the contract negotiations that followed, it was also decided to rely on the vendor to do the application development and maintenance rather than train up internal resources to develop the applications and maintain them after implementation. This would avoid the risks involved in having a critical technology service being supported by a too small internal talent pool.

Once the vendor was selected and on side, the project proceeded with a five stage plan:

  1. Develop an initial prototype focusing on the quotation function to test the integration of the technology into the company’s infrastructure and the required application interfaces and get stakeholder reaction to the speech recognition structure and sound.
  2. Implement the full quote capability in one region of the country to ensure the system’s ability to support the local accents, assess the willingness of their clients to use the new service and refine as needed to address any issues. In this first implementation, clients would be given a choice of using IVR or speaking to a Customer Service consultant as before.
  3. Roll out the quote capability across the country, region by region, assessing support for local accents and degree of use in each region and refine as necessary. The choice to use IVR or speak to a person would continue to be offered.
  4. Develop and implement the full IVR trading capability and implement in one selected region as before to gauge effectiveness and appeal and revise as necessary.
  5. Roll out the full trading solution across the country, one region at a time, refining as necessary.

The Results

The project was a terrific success. It was fully deployed across the country in 11 months at a cost of $1.1 million with IVR utilization at 75% and rising. Customer feedback was very positive, especially because of the extended 24 hour phone service window using IVR versus the old 12 hour service period.

The staged rollout allowed the vendor to tweak the application to be more sensitive to local accents and adapt the structure and content of the menus and messages to improve responsiveness, based on feedback. It also allowed the organization to target clients and employees in the region being implemented to introduce the new IVR service, encourage client employees to use it and explain how to address problems and provide feedback.

The staged rollout gave the business the ability to redeploy the Customer Service staff gradually over the 6 month rollout period, reducing the anxiety that is a normal part of business and technology change. Also, it gave the IT organization the time needed to integrate the new IVR technology into their infrastructure and operations and refine the application interfaces to improve IVR responsiveness. And, all of the stakeholders were thrilled with the outcome. It was a project well done!

How a Great PM Succeeded

This project manager did a number of things right:

  • He leveraged Project Pre-Check’s three building blocks (even though he had never heard of Project Pre-Check).
    • He identified and engaged the key stakeholders, including the vendor and the clients.
    • He took them through a structured process that enabled them to stay interested and involved, allowed them to provide their expertise to the project from inception through completion and confirmed their agreement with decisions made at each stage of the project.
    • Finally, he leveraged best practices (the equivalent of Project Pre-Check’s Decision Framework) to ensure the factors that should be addressed to ensure success were, in fact, addressed.
  • The staged, iterative approach he took to implementation effectively avoided the risks of a big bang approach and allowed the vendor and project team to adjust the applications, the environment and the internal practices based on real world experience.
  • His work with the sponsor to help her figure out how much she could afford to spend on the project to achieve her financial and service goals (it’s call ‘Worth’ in Project Pre-Check’s Decision Framework) was a key success factor. It was a meaningful figure that drove all the project decision making from scoping, RFP and vendor selection, through implementation. It enabled the other stakeholders and project team members to make calls against a meaningful number they all understood.
  • He managed to avoid the usual potholes and pitfalls usually associated with trying to leverage new technologies to deliver business value.

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 PM, and your sponsor’s best friend.

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 – Collaboration in a Command and Control World

Written by Drew Davison on . Posted in Articles. 4 Comments on From the Sponsor’s Desk – Collaboration in a Command and Control World

In my last post, Managing IT Services Contractors, we looked at the experiences of a project manager trying to corral two IT Services contractors as part of a major infrastructure upgrade and the steps he could have taken to improve the overall project experience.

In this post, we’ll look at one project manager’s experience trying to guide a technology upgrade offering a multitude of opportunities to enhance maintainability, performance and usability in an environment where the sponsor focused exclusively on time and costs. Thanks to reader S.R. for the details on this case.


The Situation

In 2000, this medium sized, mid-west based manufacturing concern launched an in-house development effort to automate and enhance a core administrative function that had been a mish-mash of older technologies and manual processes that were costly, error prone and time consuming. The new application, developed in Visual Basic version 6 (VB6) back then, leveraged the in house development group’s experiences with earlier versions of the language and delivered the expected improvements in quality and performance.

Unfortunately, in 2008, Microsoft ended support for VB6 and replaced it with its .NET offering. The VP Administration at the firm was aware of the impending loss of support but declined to take any action until just before vendor support for the product ended. He then challenged the CIO to find a way out of the dilemma as quickly as possible and at the lowest cost possible.

The Goal

The VP Administration, the sponsor of the undertaking, established the following objectives for the project:

  • Deliver a supported solution in six months or less
  • The costs should not exceed $250,000
  • There should be no changes to the business user experience. They should be able to operate exactly as before.

The Project

The CIO, with the sponsor’s agreement, appointed an experienced internal project manager to lead the effort. She identified and met with the other stakeholders who needed to be involved. Collectively they met with the sponsor to review his expectations and discuss some of the needs and opportunities the other stakeholders had in mind.

The sponsor restated his three objects. He rejected all other suggestions from the other stakeholders. He made it perfectly clear to everyone in the meeting that there would be no further discussion on the scope of the project. A follow-up meeting between the sponsor and project manager produced the same outcome but the sponsor added an additional requirement. He wanted an external company to bid on the project. When the project manager pointed out that that would add additional time, cost and risk, the sponsor exploded and challenged the project manager to get the job done within his expectations.

This is probably where the project manager should have removed herself from the project. However, she motored on. She worked with the other stakeholders and their staff to develop a Request for Proposal, worked with the CIO and other IT managers to identify two external candidates with solid track records and worked with those contractors to help them understand the challenges ahead. She also facilitated the development of a proposal from the internal development group. The proposals:

  • External Company A – $900,000 and 10 months duration
  • Internal Development Group – $600,000 and 7 months duration
  • External Company B – $500,000 and 6 months duration.

The project manager, with the support of the CIO and other stakeholders, recommended the Internal Development group’s proposal over the two external proposals based on a thorough, objective, fact based review. The sponsor picked External Company B’s proposal. In spite of considerable debate and discussion at the executive level, the VP Administration got his way. The contract was awarded to External Company B which immediately assigned its own project manager. The internal project manager was assigned to another internal project. She was lucky!

The Results

The project was a mess! It ended up costing over $1 million and took over a year to complete. Much of the overrun was due to rework. The sponsor demanded that the contractor’s project manager find ways to cut costs from their original $500K estimate. He personally cut out the costs associated with the participation of the internal development group in plan and code review and unit and integration testing. He also personally cut the involvement of the business unit staff in the same activities. He rejected any attempts to take advantage of the .NET platform and declined to consider changes to the application the business proposed to improve overall performance.

This sponsor from Hell should have looked in the mirror to place blame. Instead, he threatened the contractor with bad press and legal action. The contractor ultimately agreed to swallow most of the overrun. He also publicly criticized the other business and IT stakeholders for failing to identify competent external contractors and doing their part to ensure a successful outcome.

In this situation, there was no collaborative stakeholder group. In spite of the efforts of the internal PM to engage the other stakeholders, the sponsor’s frame of reference was command and control – I say, you do! No sponsor, regardless of how experienced, informed and qualified has all the information needed to make all the right decisions necessary for managing a change. This sponsor’s unwillingness to leverage the knowledge and insight of the other stakeholders was the number one cause of failure.

In this situation, the internal development group and the two contractors relied on their experiences with similar technology upgrades to provide a proposed roadmap for the work ahead. The roadmaps presented a rational series of steps and decision points, the participants in each step and the roles and responsibilities for each participant. When the sponsor started dictating what steps would not be done and what parties would not be involved, any opportunity to leverage a proven, end-to-end process went out the window. Failure cause number two!

In this situation, the sponsor’s attempt to dictate all three variables – time, cost and function – caused the contractor’s PM to abandon best practices that had served the organization well in the past. Their estimating practice, their approach to planning and delivering quality solutions, planning and managing risk, always considering business and technology alternatives, phasing development and staging delivery to provide early insight and added value, and others, were all sacrificed in an attempt to please an out-of-control sponsor. Cause of Failure number three!

How a Great PM Could Have Changed the Outcome

As the saying goes “Hindsight explains the injury that foresight would have prevented”. We know what’s needed to deliver a successful project: a committed, collaborative stakeholder group, proven processes that can be applied or adapted to the situation at hand, and use of proven best practices to cover the change landscape.

In fact, the internal PM did most things right. She engaged the other stakeholders. She escalated by bringing her CIO into the fray. She offered a number of intelligent options to the sponsor. Unfortunately, the contractor’s PM didn’t challenge the sponsor’s edicts and didn’t attempt to escalate within his own organization or within the client’s organization until the damage had already been done.

Dealing with sponsor incompetence is a challenge. The sponsor is in that role because of his or her place in the organization. A replacement sponsor typically has to come from the same organization, either in a position above or below the incumbent. Obviously, a PM needs lots of assistance to make that happen. Changing a sponsor’s perspective and style towards an engaged, collaborative stakeholder model can happen if the PM and other stakeholders are able to demonstrate that it’s a more effective model for achieving the sponsor’s goals. However, for that to work, the PM needs the other stakeholders to be actively on the sponsor’s case, the message has to be delivered consistently and repeated often until the metamorphosis happens. Finally, a great PM knows when to pull the plug. You’ve heard the saying “Life is too short to drink bad wine.” In this case the saying should be “A PM career is too short to take on bad projects.”

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 PM, and your sponsor’s best friend.

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.

From the Sponsor’s Desk – Managing IT Services Contractors

Written by Drew Davison on . Posted in Articles. 3 Comments on From the Sponsor’s Desk – Managing IT Services Contractors

In my last post, Pulling the Project Plug, we looked at the value a mid project audit can provide by helping stakeholders confirm or rethink the motivations and rationale for an initiative. In that case, the audit helped avoid potentially costly enterprise wide conflicts through a change in corporate priorities.

In this post, we’ll look at the experiences of a colleague of mine managing two IT Services contractors as part of a major infrastructure upgrade. We’ll also look at the steps you can take to ensure IT Services contractors involved in your project deliver everything you need, when you need it to implement a successful result.

The Situation

This U.S based financial services firm acquired content management software a number of years ago to manage the content in their web sites and Web based applications. With the competitive pressures to enhance and expand their Web offerings, the company ignored the vendor’s periodic upgrades to the content management software until they found their version was no longer supported. Not an ideal situation for mission-critical services!

The Goal

The company immediately launched a project to upgrade the content management software to the current version and migrate all content to the new platform. To keep the focus on the task at hand, accelerate delivery and reduce risk, no application or content changes would be made until after the new version was implemented and operated successfully in production for a six week proving period. The change was expected to cost $600,000 and take six months to complete.

The Project

This organization outsourced the maintenance of their desktop devices and servers to two different contractors – one looked after the client side, the other managed the server infrastructure. Because the content management software upgrade involved both client and server components, both contractors were engaged to manage the changes to their respective platforms. An internal team was formed to plan and manage the overall project and migrate the content to the new environment. The project was headed by my colleague, a great PM with a terrific track record of project successes under his belt.

The Results

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. Some examples:

On the server side:

  1. The contractor took 4 months to get the statement of work to the point where their PM’s could be assigned to the project.
  2. The contractor’s Tier 1 support staff was not involved in the initiation phase and were not privy to key discussions and decisions, causing rework, increased costs and schedule delays.
  3. There were numerous challenges with server configuration and content where the contractor made unilateral decisions that were not discussed with the project team. The remedial effort wasted scarce time and money.

On the client side:

  1. Much of the effort focused on developing scripts to update the local and remote PC’s. The scripting work was done by an offshore team who were not very proficient. The quality was spotty, the work wasn’t completed on schedule and communication regarding progress was poor. In addition, the PM assigned by the contractor to oversee the work didn’t seem to have much influence over the offshore team.
  2. As a precaution, the PM asked the contractor to scan the desktops to ensure they found all machines with the software / code requiring upgrading. The results revealed there were far more desktops to upgrade than the business had advised, a significant expansion of the scope.
  3. There were a number of problems with the rollout that the contractor was slow to respond to, delaying completion and frustrating the business.

How a Great PM Could Have Changed the Outcome

If you’ve read my previous articles and posts, you know I’m fanatical about the importance of the Project Pre-Check building blocks – stakeholders, defined processes and proven best practices in the form of the Decision Framework. If this great PM had applied those building blocks to this project, there is no question in my mind that the results would have been much better and the journey would have been less painful. Here’s how:

  • Stakeholders: the project did not have adequate stakeholder representation from the contractors. It needed people who could make binding decisions on behalf of the contractors to achieve the project’s goals and direct activities within the contractors’ teams to deliver accordingly.
  • Defined Processes: there was no established Technology Change process within the company or offered by the contractors that the participants could use as a road map for managing the change. That lead to numerous disconnects between the project team and the contractors on key fundaments including roles and responsibilities, progress reporting, content and timing, requirements documentation, managing scope and ongoing issues, the quality expectations and a plan to deliver to those expectations. Spending some time up front with the contractors mapping out the process to be used would have avoided many of the issues that caused delays and increased costs.
  • Best Practices: the Project Pre-Check Decision Framework includes 125 Decisions Areas that stakeholders can review in two hours or less to identify the ones most relevant to the project at hand. Had this project’s PM sat down with the other stakeholders and reviewed those Decision Areas, chances are they would have identified the following as highly relevant.

– Stakeholders and their roles and responsibilities
– Burning Platform
– Requirements
– Change Control
– Issue Management
– Risk Management
– Assumptions
– Communication Plan
– Quality Plan
– Change Management

Addressing these and other relevant Decision Areas up front would have ensured an engaged stakeholder group and reduced or eliminated the ongoing debates on a variety of fronts as well as the costly rework that ensued. It would have helped constrain scope and focus the contractors’ efforts on the priority requirements to deliver on budget and plan. And, it would have been a much more pleasant experience for all involved.

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 PM, and your sponsor’s best friend.

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 – Pulling the Project Plug

Written by Drew Davison on . Posted in Articles. 6 Comments on From the Sponsor’s Desk – Pulling the Project Plug

In my last post, Building Project Management Maturity, we looked at a company that found itself at a competitive disadvantage because of their project management performance and the steps they took to improve their performance and capability and level the competitive playing field.

In this post, we’ll look at the value that a mid-project audit can provide by helping stakeholders confirm or rethink the motivations and rationale for an initiative. In this case, the audit helped avoid potentially costly enterprise wide conflicts through a change in corporate priorities.

The Situation

This Canadian based mining company had contracted with one of the “Big Four” accountancy firms to assess the organization’s readiness to implement the International Financial Reporting Standards (IFRS), determine the impact on their world-wide operations and recommend an appropriate plan of action.

While European public companies have been applying these standards since January 2005, in Canada, the Accounting Standards Board had proposed that Canadian GAAP for publicly accountable enterprises migrate to IFRS over a transition period. The move to IFRS would impact many areas of business including fundamental decision-making processes and would change the way companies presented their business results to analysts, investors and other stakeholders.

The Goal

The company planned to develop and implement IFRS compliant practices and procedures throughout its global operations in accordance with the targeted transition period.

The Project

The Finance organization launched the IFRS initiative and contracted with the accounting firm which assigned senior consultants who had extensive experience planning and implementing IFRS solutions in Europe. A working group was established to liaise with the consultants and included Finance department managers and staff with some consultation with the head office IT organization.

As the consultants were wrapping up their IFRS assessment, the head of the Internal Audit organization 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 the Project Pre-Check’s Diagnostic process. The assessment started with the identification of key stakeholders from all global operations and involved interviews to solicit their views on progress to date and thoughts and suggestions on future plans.

The assessment process used a selected subset of Project Pre-Check’s Decision Areas (47 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 47 Decision Areas were used to gauge three perspectives:

  1. Stakeholder views from face to face and phone interviews, including stakeholders from the corporate office, from the regions and the consultants.
  2. Review of deliverables from the project to date
  3. Review of any project management methodologies, practices and templates used.

The interview results found that the IFRS project’s overall level of stakeholder agreement at this stage of the project was 2.4 on a scale from 1 to 5, based on the following definitions:

1 – Not addressed, don’t know or disagree with current decision

3 – Somewhat addressed

5 – Completely addressed

The interview results identified 7 of the 47 Decision Areas addressed in the assessment

(15%) as areas of divergence (at least one of the stakeholders was less than comfortable with how a best practice was applied). 40 Decision Areas (85%) where identified as gaps (where the majority of stakeholders expressed a lack of comfort). The results showed that these challenges needed to be addressed posthaste to avoid a less than successful outcome.  

Key areas of concern were those areas relating to the scope of the project, organizational priorities, the target dates, stakeholders (confusion over the sponsor and project manager), decision making responsibilities and ongoing governance.

The audit took about six weeks to complete. The Audit leader presented the findings and recommendations to the Finance VP. The recommendations included:

  • Confirm the sponsor and project manager
  • Form a stakeholder group including stakeholders from all affected organizations
  • Establish the priority of the IFRS initiative relative to other competing projects
  • Work towards full agreement on all 47 Decision Areas included in the audit.

The Results

The project was deferred! After reviewing the audit results and conferring with stakeholders in head office and the regions, the Finance VP acknowledged that the IFRS project would face significant risks trying to go head to head against other initiatives that were judged to have higher corporate priority.

The audit helped bring the disparate views of the stakeholders to the surface and escalate the concerns about corporate priorities to the executives who had the information and authority to make the right call. Prompt action by the Audit head and a comprehensive six week review focusing on the key project stakeholders helped this company make a timely decision and avoid the financial and operational risks of too many projects chasing too few critical resources.

How a Great PM Could Have Helped

The IFRS project was at a disadvantage from the moment it was launched – it had no internal project manager. Sure, the consultants managed their piece of the work. But no one from the company was formally responsible for managing the changes to the company’s practices and operations from inception to successful delivery.

Had a Great PM been assigned, undoubtedly he or she would have addressed the following fundamentals:  

1. Establish the project’s sponsor clearly and publicly. On the internal project documents and the report prepared by the consultants, three different sponsors were identified. That’s a recipe for chaos. Even co-sponsors can lead to muddled and circuitous decision-making. Pick one!

2. Identify and engage the other project stakeholders across the enterprise and around the globe and ensure that they understand their roles and responsibilities. All stakeholders – the sponsor, targets, change agents and champions – need to contribute according to their responsibilities on a multitude of fronts for the project to be successful.

3. Manage the level of stakeholder agreement on the relevant decision areas. Work to resolve the gaps and areas of divergence up front and on an ongoing basis as new issues and conflicts crop up. Early estimates of the cost of the IFRS project ran in the $8 million to $10 million range to be implemented over an 18 month period. That means navigating a mountain of mole hills. A Great PM would thrive on that challenge.

4. Managing stakeholder agreement on the relevant Decision Areas will help a Great PM ensure that critical questions about the planned change and the environment within which the change is being implemented are addressed. A Great PM will ensure that the impact on and/or use of appropriate company assets (methodologies, practices, resources, etc.) is fully articulated and endorsed by all. Finally, a Great PM will ensure the approach to planning organizing and controlling the project is fully supported by the other stakeholders and that project communications address their collective and individual 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 the challenges a Great PM faced as he tried to guide the upgrade of extremely out of date but mission critical content management software through the demands of the business and the ineptitudes of two external contractors. In this case, the Great PM’s tough love approach won the day, and a successful project.

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.