Skip to main content

From the Sponsor’s Desk – Tenacity Can Achieve Miracles

Tenacity_Fotolia_12319244_XSIn my last post, Knowing Your Project Profiles, we looked at the approach one CIO took to confirm his gut feeling that a project was going to be well over budget and behind schedule.

In this post, we’ll see the results that were achieved through the tenacity and commitment of one Quality Assurance manager to turn around a company’s sagging fortunes and renew client confidence in their products and services. Thanks to reader M.D. for the details on this case.

The Situation

This provider of billing and customer information services to the utilities industry was experiencing significant customer dissatisfaction with the quality of its applications and services, contributing to loss of customers and a serious revenue decline.

Software updates and releases were handled by the internal development group. Responsibility for quality was shared between the programmers on each project and a central quality control unit. There were no standard development or quality practices. The development teams relied upon previous approaches used on a specific software package or service. The sales organization, which drove much of the enhancement activity, placed much greater emphasis on time to market, which was a significant contributor to the quality problems.

The CEO challenged the CIO to turn the situation around quickly through an order of magnitude improvement in the quality of delivered software and services. 

The Goal

 The CIO recognized that a number of changes would need to be made to their practices to achieve the CEO’s mandate.

He proceeded to hire a manager to head the quality assurance function and guide the other changes. She had a wide range of experiences and accountabilities and an impressive track record. Her mandate was to deliver the changes within an 18 month time frame and achieve the targeted order of magnitude quality improvements to increase customer satisfaction and reverse the revenue decline.

The new QA manager took over a team of 32 staff, half of them located centrally in head office, the rest in four other offices spread across the country plus a small offshore testing facility in India. She was also responsible for supporting 60 applications and services for over 50 clients, most being large, very demanding utilities.

Her first week on the job was spent talking to the senior managers and staff to get their thoughts on what problems existed and how best to tackle them. She discovered the following views:

  • There was inadequate documentation on the core systems and services, inadequate documentation about business requirements and application functionality for new offerings and a mishmash of project management practices to guide the projects.
  • There were frequent and ad hoc changes to the planned new releases.  
  • There was an absence of standard project management, development and quality practices which hampered the movement of staff to priority projects and created conflict and ill will when dealing with other organizations and clients.
  • There were no controlled test environments for the core applications and services and no management and reuse of test conditions, cases and scripts.
  • There were ongoing communication gaps among the development groups, Quality Control, Computer Operations, Sales and the clients.
  • There was no or limited technology available to support requirements traceability, test planning and execution, release builds and promotion to production

She did a stakeholder map to identify who her key partners in this endeavor would be. They included:

  • The CIO, who identified himself as sponsor of the change.
  • The VP Sales, a key target because of the relationship with the sales staff and their clients.
  • The VP System Development, also a key target because of the planned changes to development and quality practices
  • The VP Computer Operations, an important target because of the planned changes to improve the build and promotion processes and the need for more responsive client support.
  • The clients, for obvious reasons.
  • Herself, manager of QA, as the change agent and also an important target because of the changes she would have to implement in her own organization

With the exception of the client representation, this became her initial stakeholder group. The Sales VP would wear two hats, as a proxy for the clients and representing the Sales organization. All material decision would be reviewed and approved by these players. All decisions needed unanimous consent.

Her next step was to develop and vet the vision for the changes that were needed, including the sequence of implementation and the planned time frame. When she had obtained senior management buy in, she launched her project. Her budget was just over $800,000 including software.

The Project

The first order of business was to communicate the vision to all those who would be affected by the upcoming changes. The Sales VP and Operations VP cooperated fully and encouraged their managers and staff to listen, provide feedback and get on board. Her vision called for a first wave of process improvements including the project management, development and QA processes, a testing technology project and a metrics and reporting initiative. These were to be followed by a second wave including release coordination, configuration management and document management

The Development VP refused to return her calls and didn’t attend her meetings. She went below him to a Development manager who had taken considerable heat for quality issues on his applications and had expressed a desire to be an early adopter of the new practices.

She formed a team with representatives from the Development manager’s group, Operations, Sales and QA to evolve the project management, QA and development processes. The mandate to that team was to use the best in house methods available and beef them up with industry best practices, from PMI, SEI and QAI among others, in a six week time box. That work was completed in the targeted six weeks and included high level documentation, references to external best practices, examples where possible and general training materials.

She appointed an experienced QA lead to manage the implementation, starting with the supportive Development manager’s team and two projects just getting underway. As those two projects progressed in applying the new methodologies, gaps were identified and plugged, errors and omissions were fixed, new examples were collected and training materials and methods were updated.

On the testing technology side, the QA manager had been through a formal technology assessment, selection and implementation process in her last job. She was very familiar with the available offerings. In the interests of time, based on that experience, she pulled together a formal recommendation including assessment of the available alternatives and specific recommendations and reviewed it with the stakeholder group. All except the Development VP approved the proposal. In spite of the requirement to have unanimous agreement on all stakeholder group decisions, the CIO (the sponsor of the initiatives) gave approval for the QA manager to proceed with the technology acquisition and implementation and indicated he would work with the Development VP to resolve his concerns.

The QA manager proceeded to form another team, led by another of her QA leads, to implement the technology and develop standards and practices and then apply those to supporting the two development projects. The team included staff from Operations, QA and Development (from the supportive Development manager’s group). She was also able to get a staff member from the client involved with the two development projects.

On the metrics front, she consulted with the CIO and VP Sales about their views on the metrics required and, based on those discussions, recommended three initial measures: customer satisfaction and the change from period to period; quality, as measured by the number of critical system defects (failures in production) and IT productivity, as measured by revenue per staff. The last metric, site productivity, was an attempt to measure revenue growth in conjunction with improvements in IT productivity. With the exception of the Development VP, the stakeholder group approved the recommendations. The QA manager was given the green light to proceed.

After two months on the job, the QA manager had built and sold a vision and developed, pitched, received approval for and launched three key initiatives. She communicated formally on a weekly basis up, out, down and sideways. She also engaged anyone who wanted to talk about the program in the form and timeframe appropriate to the need. And, she took it upon herself to monitor the grape vine, to see what people were thinking, feeling and saying.

While all this was going on she also executed her duties as manager of the QA unit and helped her staff not formally involved in the three projects get up to date and on side.

The Results

The three initiatives were extremely successful. On the process initiative, the first two projects were delivered with zero critical defects and slightly beyond the initial target dates. However, the client was thrilled, to some extent due to the involvement of their staff in the testing technology undertaking. The testing technology project worked with the two project teams and the process group to build and reuse test scripts to cover the changes being made, resulting in much better test coverage, less time to execute, improved productivity and better quality. On the metrics front, the tie-in of the three metrics to IT staff bonus calculations and publishing the monthly results throughout the company had a palpable effect on the company culture. The CEO noted the effect in one of his quarterly updates.

The first wave of changes was rolled out across the organization in fourteen months. The second wave was completed in an additional ten months. Here’s how the actual results looked: 



Before Changes

After One Year

After Two Years

Customer Satisfaction

(1-Very Dissatisfied 10-Very Satisfied)




Critical System Defects




IT Productivity (Revenue/FTE)




One final note: the Development VP, who opposed the QA manager’s plans and refused to participate, was replaced.

How a Great Change Agent Helped

This is an interesting study. Obviously, all the initiatives clearly qualify as projects. Yet the QA manager didn’t really run them according to the usual model, with clear requirements, sign-offs, prescribed phases, etc. There was no risk plan, no issue log, no formal change control, no test plan, no detail project plans.

What allowed the QA manager to achieve these stellar results? I think five factors contributed to her success:

  1. The QA manager had the knowledge, skills and capabilities to lead the initiative. She understood enough about project management and software development to understand the relationship to quality and productivity. She had a deep understanding of quality assurance, quality control and supporting technologies. She had the knowledge on tap to create the vision and the plan and get it approved.
  2. She knew, either instinctively or formally, how to manage change. She pulled the stakeholder group together. Instead of waiting for the Development VP to get on side or get lost, she went below him to a supportive and needy Development manager. She knew she could get away with the move because she had the support of the other stakeholders. She leveraged the burning platform – declining revenue and customer satisfaction – to get the decisions and resources she needed.
  3. She was a confident and gifted communicator. She communicated frequently, to all affected targets. She listened and acted on the messages she received. She involved the client, including bringing one client into the stakeholder group in the second year.
  4. She knew how to form effective teams – small groups of staff with clear mandates, appropriate availability, the right perspectives, knowledge and skills and short term time frames to deliver an actual result.
  5. She acted! She didn’t wait around for someone else to tell her what to do. She didn’t wallow in analysis paralysis. She went out and got stakeholder approval. She took clear, decisive steps. She did what she said she was going to do. When things went wrong, and they did, she was the first to acknowledge a problem and collaborate with those affected to seek an acceptable resolution.

Perhaps this is an example of how to use some Agile principles to deliver better, faster business solutions.

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 Change Agent, 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 add your comments below.

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].

Comments (8)