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 – Fix the Business Process First

Written by Drew Davison on July 11, 2012. Posted in Articles. 5 Comments on From the Sponsor’s Desk – Fix the Business Process First

FEATUREJuly11th In my last post, 10 Project Management Practices Make All the Difference, we explored the practices that a project used to implement digital imaging in a highly successful eight hospital pilot.

In this post, we’ll look at how a team successfully turned around a broken and costly Group benefits new business process that was frustrating this insurance company’s customers and costing the company in lost business, productivity and escalating expenses.

Thanks to reader K.L. for contributing the details on this project.

The Situation

The Group benefits division of this medium sized insurance organization was experiencing considerable customer backlash over the quality of the newly issued contracts and support materials and the elapsed time required to complete the issue. This resulted in denied claims, incorrect benefit coverages and inaccurate employee booklets and drug cards. The situation had reached a critical point with a complete lack of confidence expressed by both clients and sales staff. As well, there was poor morale among most of the Group Insurance staff involved in the process as it appeared they “could never get it right”.

It was generally felt that the system used by the sales force for the submission of new cases was the main cause of the quality problems and needed to be improved and updated. However, the new VP who was appointed to oversee the Group Benefits operation did not want to embark on an expensive system replacement project without first determining the root of the problem. She was able to convince the VP, Sales to jointly sponsor a project to review the current issue process using the Tatham process methodology (similar to Six Sigma) to map and diagnose the root causes of the quality problems.

The Goal

The stated goal was to improve the performance of the new business process for medium and large cases to reduce customer complaints, improve cycle time and reduce costs, especially those due to rework.

The Project

This was the first time the organization had set out to review a process end to end rather than focusing on processes within the walls of the operational area. A stakeholder group was formed which included representation from the Sales offices, Sales support, New Business and Financial Underwriting.

The first step was to obtain feedback from current customers to find out what was most important to them. Accurate plan set up reflecting all their specifications was ranked as the most important with timely delivery of set up documentation as next important. It was an eye opener to learn that clients were not that concerned with how fast the plan was issued – they just wanted it right the first time!

As a result, the specific quality goal was defined as follows: “Quality of a new business issue occurs when the benefit plan meets the customer specifications”. This was a novel approach in terms of defining and measuring quality as historically the company had only measured quality in relation to specific internal new business processes that occurred after the submission of the case to head office.

With the focus on improving the end to end process, the project team proceeded to the next stage – mapping the processes, collecting data and performing root cause analysis. This took about three months and at the end, the team reached the following conclusion: there was little or no structure around the sales submissions from the field. In fact, most sales reps appeared to “do their own thing”. There was no single process being followed!

There was a lack of consistency in submitting the plan specifications and a total lack of enforcement and rigour in the New Business areas upon receiving incomplete sales submissions. This resulted in much “re-work” and back and forth between the sales rep and head office to clarify data.

The bottom line: it was estimated the 25%-50% of head office resources were devoted to re-work and represented a significant productivity issue. This analysis also confirmed that, indeed, process changes needed to be implemented before any future system and/or automation project should be looked at.

The Results

A fourteen step process called the “New Way” was developed and launched in the field and in head office by the VP Sales and VP Group Benefits. The new process affected about 300 staff in the sales offices and head office. A key step in the process required sales staff to meet with the client to receive sign-off for the plan specifications. It was also made very clear that the case would not be issued and all documentation would be sent back to the sales rep for completion of the missing information if they did not follow all the steps in the process.

In-process quality measures were implemented for completeness and accuracy of new business submission. A customer quality measure was also instituted to determine satisfaction level with each new business issue. Within 6 months, customer satisfaction increased from a baseline of 0 to 50%. Within 12 months, over 75% of customers were completely satisfied with the quality of the new business issue. Within 12 months, the issue “unit costs” were 30% less per case and the cycle time for a new issue had been reduced by 9 days overall, about a 20% reduction.

How a Great Sponsor Helped

Sometimes serendipity plays a key role in delivering a successful project result. In this case, the new VP of Group Benefits wasn’t immersed in the old culture, resisted the temptation to launch a system upgrade and insisted that the organization go back to first principles – what problem were they really trying to solve. She also took a number of other actions that contributed to implementation success:

She ensured that the other stakeholders were identified and engaged. Without the Sales VP as a co-sponsor, enforcing sales rep compliance with the new process would have been difficult if not impossible. As well, engaging the clients in the process was an essential opening step.
She ensured that everyone understood this was the top priority initiative in the Group Benefits organization to ensure the proper focus was in place and the right resources were available and committed.
She contracted with an external organization that had proven capabilities to assess end-to-end process performance to manage the project. That included a “boot camp” for involved executives and staff to reorient their frame of reference from organizational silos to a process view.
She demanded tight, three month time boxes for the process analysis and subsequent phased implementations to ensure a timely response to the customer satisfaction challenges they were facing.
She established a few key metrics and measured and reported progress monthly throughout the organization to reinforce the importance of the change and the positive progress they were making towards their goals.

By focusing on these five key areas, the VP Group Benefits ensured that the organization was targeting the core issues, with the right players, in an appropriate time frame, with clear goals in mind. In fact, the practices that served this project so well will help any change initiative deliver more effectively. That’s why they’re also covered by Project Pre-Check’s stakeholder model, processes and Decision Framework. It is a great place to start your project and supplies a terrific oversight framework through to project completion.

If you can’t afford to rely on serendipity to get your project started right and guided to a successful conclusion, 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 Sponsor.

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

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Ten Winning Project Management Practices

Written by Drew Davison on June 12, 2012. Posted in Articles. 5 Comments on From the Sponsor’s Desk – Ten Winning Project Management Practices

In my last post, Sometimes Agile Isn’t, we saw what happened when pre-conceptions about the business problem and how to fix it aren’t examined and challenged.

In this post, we’ll look at how one team successfully implemented digital imaging technology in eight separate hospitals. Their secret weapon? Ten project management practices that covered all the bases and worked superbly to engage stakeholders, administrators, doctors, nurses, technicians, support staff and vendors from project inception through post implementation.

Thanks to reader H.D. for contributing this case and providing her insights on the project.
The Situation
In 2002, a number of hospitals began exploring the feasibility of implementing a shared services approach to digital diagnostic imaging (DI). Many hospitals in the region were seeking opportunities to form strategic alliances. Most required access to the expertise and resources outside of their own settings to address the needs of their patients. Shared digital imaging fit perfectly with these objectives as it provided a way to access expert diagnosis without having to move the patient.

The Goal

The hospital leaders wanted to develop a cooperative initiative among hospitals to deliver digital imaging, rather than each hospital independently developing its own system. They agreed to initiate a pilot project to implement DI in eight of the hospitals in the region, some with multiple sites, commencing in early 2004 and finishing in the first quarter of 2006. Expected benefits included:

Enhanced patient care:

Improving access to a range of services for patients in their own communities;
Providing better access to radiologists, nuclear medicine physicians and other DI specialists;
Enhancing the speed of treatment decisions;
Reducing unnecessary repeat diagnostic procedures and patient transfers.

Improved medical management:

Enabling multiple exams to be viewed simultaneously at multiple locations;
Displaying prior studies and reports;
Providing immediate, 24/7 access to images and reports;
Producing clearer images that can be easily manipulated.

Reduced costs:

Making the system more affordable to smaller communities by sharing infrastructure, support and maintenance;
Eliminating film, processing and packaging materials, and paper reports;
Reducing the time spent locating and transporting films.

The Project

The pilot was officially launched in early 2004. A governance/partnership agreement was developed to guide and govern the development of the shared imaging service. It included active participation from the stakeholders – the hospital leaders, five vendor partners, a federal government agency and the provincial health ministry.

In addition, a core team was created to guide the project. It included the Project Director, Core Clinical Coordinator, Technical Team Project Manager, Change/Knowledge Management Lead, Benefits Evaluation Lead, Regional Communications Lead, Financial Analyst, Communications Specialist and Clerical Support. This team also consulted with the DI Leads from each participating site.

The project focused on the following steps to achieve success:

Build a data center with the highest level of availability and performance possible to support the electronic patient record (EPR) and on-line digital imaging. A secondary data center would provide for site disaster tolerance and ensure data availability 24/7 with a failsafe, seamless backup continuously available.
Assess clinical needs, the digital imaging and report viewing requirements throughout the hospitals to determine who requires access, and what type of access they require.
Assess modality (machine) upgrade requirements to determine whether the existing equipment could be upgraded or needed to be replaced. Also determine how workflows and processes needed to change and what was needed to support that change.
Establish milestones that would satisfy the funding partners’ practice of reimbursing the project based on the completion of deliverables to their satisfaction.
Work with the vendor partners to ensure the system that was built could be replicated and expanded based on common standards that allowed different suppliers and vendors to be involved.
Capture knowledge as the project progressed. The funding partners required the development of case studies and lessons learned to assist future initiatives in other regions—both nationally and internationally.
Manage change by ensuring education and communication supports were in place for those involved in the transition to digital imaging to help them embrace, support and sustain the change.
Develop and offer training to best fit the needs of the learners.
Evaluate benefits delivery based on selected indicators throughout the project.
Ensure the privacy and security of patient information and was fully compliant with federal and provincial privacy legislation.
Develop and implement the ongoing CDI (Cooperative for Diagnostic Imaging) business utility including the cost recovery model to sustain the shared services.
Conduct research on compression technology to manage an estimated 20 terabytes of digital images annually and the related operational and legal issues.

The Results

This multi-million dollar undertaking successfully implemented the DI solution in the eight pilot sites. It was one of only five operating sites in the world using the full suite of GE Healthcare’s PACS (picture archiving and communication system) software. This gave multiple hospitals the ability to update and access digital images simultaneously in a highly reliable and available system. Further, the solution tightly integrated the PACS system, the Cerner Radiology Information System and the Lanier dictation system. This integration supported the high level of reliability, performance and availability required for the on-going operation of the system.

The project did not have quantitative measurements in place to track of the value realized by the eight pilot sites. However, surveys were used extensively to measure the perceptions of those involved with and affected by the change. Some key findings:

The majority of radiologists and referring physicians indicated that their efficiency improved as a result of PACS implementation
Several examples identified significant improvements in patient care:

Access: Almost 40% of radiologists reported remotely to new sites
Quality: 2/3rds of referring physicians reported that PACS had improved their ability to make decisions regarding patient care

Some evidence that organizational efficiency has improved:

70% of referring physicians identifying reduction in duplicate exams
Some support for reduction in patient length of stay

Higher levels of satisfaction among radiologists and all users of the Hospital workstation in operating PACS

In all, the project was deemed a highly successful undertaking by all stakeholders and provided the learnings and foundation for DI rollout to the other hospitals in the region.

How a Great Project Management Team Helped

Normally, I talk about the things the project manager did, or could have done, to achieve a successful result. In this case, however, I’ll give credit to the entire core team for the pilot’s successes. Not only did they realize their goals, they left a legacy of lesson learned for the benefit of the hospitals that would follow their lead. Here are some of their findings:

Leadership and sponsorship were acknowledged as key drivers in the success of the project. The leadership clearly articulated and continually reconfirmed the objectives and scope, successfully removed the barriers and ensured that all the objectives were met.
The Core Clinical team moved from site to site. The team only got better as they went along; able to leverage their experiences and adapt processes to incorporate lessons learned.
The strength of the project was communications, including
1. The regional bulletin, a key communiqué to those in the field
2. The community sites had direct ownership of the communication plan at their site.
3. The stakeholder and target audience analysis laid the foundation for getting the details on identifying all the training targets.
4. Different strategies worked at each site, according to their needs.
5. DI Leadership forum (regular monthly meetings of the Diagnostic Imaging Managers) worked well to promote agreement and standardization across the regions.
6. The eRoom provided a central online repository for the current and archived documents, readily accessible to all project team members.
From a financial point of view, good controls and good planning were in place. In addition, the project was well funded.
The project teams were a combination of internal and external resources. The teams were ‘A’ players with the right skills. A recurring theme was that ‘Availability is not a skill.’
The technical architecture workshops provided a forum for identifying and working through issues prior to contract signings.
The Vendor Statement of Work was a process and a document that involved all vendors, promoted a single team approach and a commitment to results.
The nursing units/departments had a positive experience with the ‘Last Call Walk Through’ process. This provided an opportunity to provide quick fixes and quick wins.
Also key was the ‘Sweep Back Process’ prior to the project end.
The Biweekly status meetings with stakeholders and the monthly Milestone summary sheets were very helpful.

These ten areas of focus provided the foundation for a successful project and a legacy for the follow-on work. In fact, the practices that served this project so well can help any change initiative deliver successfully. That’s why they’re also covered by Project Pre-Check’s stakeholder model, processes and Decision Framework. In fact, some of the findings the team classified as “What We Wish We Had Known at the Beginning”, like the need for orientation for new members and an understanding of current operational processes and policies are included in the Project Pre-Check practice as well. It is a great place to start your project and supplies a terrific oversight framework through to project completion.

So, if you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great Project Manager, 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. And, new this month, if your project is selected and published, I’ll send you a free copy of my latest book, Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Sometimes Agile Isn’t

Written by Drew Davison on March 13, 2012. Posted in Articles. 9 Comments on From the Sponsor’s Desk – Sometimes Agile Isn’t

FEATUREMAR14th In my last post, Tenacity Can Achieve Miracles, we saw the results that were achieved through the tenacity and commitment by one Quality Assurance manager to turn around a company’s sagging fortunes and renew client confidence in their products and services.

In this post, we’ll look at the damage that can result when pre-conceptions about the business problem and how to fix it aren’t examined and challenged. Thanks to reader E.B. for the details on this case.

The Situation

This financial services organization had attempted to replace the system used for the production of statements for its clients and their employees on three occasions over the last ten years. The statement runs produced over one million statements each quarter consuming annual processing costs of about $200,000. The applications were a mish mash of legacy technology and code that was very difficult to change and problematic when it came to ensuring the necessary quality levels. Previous statement projects usually took up to twelve months to implement and cost hundreds of thousands of dollars.

The Goal

The business wanted to replace these applications with a new system that would be easier to use, more responsive, and maintain service level agreements. At the same time the business wanted to provide support for a variety of ad hoc queries for administrative and sales staffs and their clients. The new solution had to provide the ability to replicate exactly previously produced client and employee statements at any point in the future. In addition, annual production costs shouldn’t exceed $250,000.

The Project

The reporting project was commissioned to tackle both the production of statements and support ad hoc queries through the creation of a data warehouse.

The VP of the business unit was the project’s sponsor. Two project managers were appointed, one from the business and one from IT. Selection of new technology to support the data warehouse and the ad hoc queries was seen as a priority so a technology assessment stream was launched to expedite that process. In addition, because of the difficulties that had been experienced in the last three attempts to solve this problem, senior IT staff proposed the use of agile techniques to allow phased delivery that could be incrementally built upon to achieve the final state. The IT PM, a recent hire, was selected in part because he had previous agile experience. An early project development delivery charter was created and it did highlight the Statement versus Ad hoc reporting differences.

The new technology was selected, installed and vendor staff was brought in to help train the in house staff and help build the application. Concurrently agile training was selected and conducted under the tutelage of an agile leader. In short order the project team was up to 18 IT and contract staff and burning through $200,000 per month. A data warehouse proof of concept was launched in the fourth month to bring all the disparate elements together – production statement, ad hoc queries, new technology and agile.

The Results

The ad hoc aspect suffered because the business hadn’t really thought through what it was they wanted to do. The early identification of Statement versus Ad hoc delivery differences was never resolved. The agile implementation suffered because the team wasn’t able to identify and tackle implementable pieces. Much of the work reverted to traditional development practices the majority of the staff were used to. Finally, a production statement pilot revealed that annual processing costs would be in excess of $ 2 million using the new technology versus $200,000 for the existing system. After another two months of analysis and head scratching, the project was cancelled with over $ 1 million in staff and contractor costs down the drain.

How a Great PM Would Have Helped

This project is a sad example of how not to implement change effectively. A great PM would have done a number of things differently. For example:

Look at the reasons for the failure of the previous three attempts to deliver an improved environment to support production statements and ad hoc queries. In all three cases, the project wasn’t really a top business priority. Business support eroded as the demand for more decisions escalated. Getting clear direction on the Project Pre-Check Change Domain Decision Areas, like burning platform, opportunities, goals, worth, requirements, benefits, assumptions, etc. would have revealed the clarity of the business vision as well as the commitment of the stakeholders.

One of the challenges this project experienced was getting the required business resource. Apparently the business had reorganized about the time the project launched and the reorganization consumed the business management time that was required for the project to progress. Déjà vu all over again!

This project was actually four different changes grouped together: product statements, a data warehouse with ad hoc query capability, new technology and agile. One of the Decision Areas in the Change Domain mentioned above is assumptions. If the PM had explored the assumptions around each one and the four together, I expect a very different structure and approach to the problem would have been used.

One of the sources of ongoing friction between the business and IT was the use of the data warehouse for the generation of production statements. IT believed the profiles of the two functions were sufficiently different to warrant unique solutions. The business disagreed. Had the PM considered the Volumes, Mix & Peaks Decision Area in the Project Pre-Check Change Domain, he would have discovered vastly different profiles, well known for the production statements, yet to be determined for the ad hoc queries. If he had committed business stakeholders, the accumulated evidence would have helped them see the light.

There was no risk analysis or plan, an interesting oversight for a project that had failed three times previously. A risk plan would have considered the challenges posed by running the four changes together, would have looked at the impact of the business reorganization on project resourcing and would have addressed the challenges associated with implementing and operating a new technology component. The resulting mitigation strategies may have helped avoid project failure and could have guided the PM to a different approach.

Every time I run into a project like this, I get angry. It’s so easy to use a framework like Project Pre-Check to make sure the PM and other stakeholders address factors that have proven essential to project success. It’s an almost painless exercise, it takes little time and it cements the stakeholders’ commitment to the endeavor. If you don’t want to use Project Pre-Check, build your own checklist of vital best practices, use it on every project and shape it to reflect your own learnings. Please! Your stakeholders will thank you.

There was a silver lining to this project. The PM facilitated a project post mortem and developed a lessons learned log covering many of the points above. The internal team was moved largely intact to a project in another business unit where they have been able to apply their learnings and leverage the benefits of agile techniques.

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.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Tenacity Can Achieve Miracles

Written by Drew Davison on February 22, 2012. Posted in Articles. 7 Comments on From the Sponsor’s Desk – Tenacity Can Achieve Miracles

Tenacity_Fotolia_12319244_XS In 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:

Metrics	Before Changes	After One Year	After Two Years
Customer Satisfaction (1-Very Dissatisfied 10-Very Satisfied)	4.1	6.3	8.4
Critical System Defects	41	3	0
IT Productivity (Revenue/FTE)	$48K	$55K	$81K

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:

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

Don’t forget to add your comments below.

From the Sponsor’s Desk – Knowing Your Project Profile

Written by Drew Davison on January 18, 2012. Posted in Articles. 4 Comments on From the Sponsor’s Desk – Knowing Your Project Profile

In my last post, Avoiding New Technology Risks, we looked at the steps one project manager took to leverage a promising new technology while avoiding the pitfalls often encountered with new technology introductions.

In this post, we’ll look at the approach one CIO took to confirm his gut feeling that a project was going to be well over budget and behind schedule. Thanks to reader B.L. for the details on this case.

The Situation

This Canadian insurance company was experiencing significant growth and having difficulty maintaining service levels at an affordable cost. The underwriting organization, in particular, was having a challenging time. Experienced underwriters were hard to find and training new staff was a long, slow process. The sales agents were unhappy with the response and level of quality on new applications for insurance. It cast the organization in a bad light with their clients. And, of course, agent compensation was negatively affected.

The VP responsible for the underwriting function, in consultation with the CIO, decided to explore the use of technology to alleviate the pressure, improve service and reduce costs.

The Goal

The VP of the underwriting function, the sponsor of the initiative, decided to launch a development project to automate much of the underwriting process. The plan was to have the applications for insurance processed by staff in the sales offices across the country using the new automated service with the potential for immediate approval and contract production if everything checked out. The target was to get the project implemented and operational in a year or less.

The sponsor and his staff calculated that they could save over $1 million annually in reduced administrative costs in his organization while cutting processing time from 10 days to 1 day on 60% of the applications. As well, sales agent compensation would be accelerated, service to clients would be improved dramatically and dependence on scarce underwriting resources would be reduced.

In consultation with the Sales VP, it was determined that the additional time required from administrative staff in the sale offices to process the insurance applications could be factored into the existing workloads and would require no incremental staffing. The project was a no brainer!

The Project

The sponsor appointed a manager from his organization to act as overall project manager. His job was to implement new underwriting and administrative processes and practices that would affect the sales agents, administrative staff in the sales offices and underwriting and administrative staff at head office.

The CIO appointed a project manager from his organization to guide the development of the technology solution.

The two managers collaborated on the estimate based on their previous experiences and arrived at a cost of $2.5 million and a year or so duration. They agreed to adopt the in-house system development methodology, a typical waterfall practice. They formed a steering committee with the key stakeholders – the sponsor, the VP Sales and the CIO – and proceeded to form their teams to tackle requirements definition.

The sponsor was adamant that the new automated system reflect their current underwriting practices to maintain or improve on their claims experience. So, the project managers adopted a prototyping philosophy that they could us to demonstrate practice compliance to the sponsor and his senior underwriters as well as to the staff in the sales offices. As the requirements definition progressed, the project managers encountered a multitude of “what if” questions in response to their prototypes, mostly from the senior underwriters. That required another round of prototypes and reviews and lead to more “what if’s”, and so on.

The planned three month requirements phase extended to four months, then five but the project managers insisted the overall project was still on target. Their rationale was that the requirements would be so well defined and fully approved that the 10% change contingency they had included in the budget would not be required. They also argued that the level of detail in the prototypes would enable multiple parallel development streams and reduce the cost and time required for the development and testing phases.

Project Profile Chart

The sponsor and the VP Sales bought the argument. The CIO did not. He had his Project Office pull together a profile for projects completed by the system development group in the previous two years. The profile showed that, on average, the development and delivery phases consumed over 60% of elapsed time and over 70% of resource costs. He concluded that the project would take another year to deliver and exceed the estimate by $1.5 million.

The Results

The CIO was right. The project took a year and a half to complete and cost almost $4 million. The IT project manager tried to reduce the elapsed time by developing the application components in parallel as he had argued previously. However, resource constraints limited the contribution the approach could make to accelerating the schedule.

The upside? The project was delivered successfully. The quality of the solution was excellent. The staff affected by the change in the sales offices and head office were enthusiastic about the system. The clients appreciated the service improvements. The project actually delivered over $2 million in annual benefits, largely because of the scope expansion resulting from the “what if” cycles. Even with the increased cost, the actual payback was greater than originally anticipated.

How a Great PM Could Have Helped

The project managers did a number of things well:

Forming the steering committee help all areas affected by the change get involved and onside.
Use of prototyping to facilitate requirements definition really did engage the experts and resulted in full backing from all involved. It also did contribute to a much lower level of change requests and helped deliver significantly greater value than originally planned.
The quality practices leveraged from the in-house development methodology were applied effectively throughout the development process, ensuring a high quality solution in all respects, including the required ease of use for each target audience, appropriate performance and security, provision of an audit trail, integration with back end administrative systems, continuity of processing and adaptability to future changes.

Unfortunately the PM’s missed a couple of opportunities to help the project excel and damaged their bosses’ perceptions of their performance in the process:

They didn’t recognize that the “what if” cycles were signs of scope creep. There’s nothing inherently wrong with expanding project scope but it has to be managed to expectations. In this case, it wasn’t.
There was a good deal of urgency in getting relief from the growing costs and service problems. But, the plan didn’t recognize the need for a fast response. Instead, the PM’s planned to define all requirements up front. Had they adopted a phasing strategy from the get go, they would have had an opportunity to deliver a first release sooner than planned and would have had a framework to manage the “what if” cycles more effectively.
The IT PM started looking for resources to support his parallel development plan as the requirements stage wound down. Instead, had he really understood the urgency of the situation, he would have had a resource plan in place from the start with the required staff ready to step in when needed.
Finally, the PM’s didn’t have a Project Profile for the organization in question. If they had access to that information, it would have forced more rigor on the cost and time forecasting and reduced the wishful thinking that they ultimately engaged in to justify their circumstances.

This could have been a great project! In fact, after the initial disgruntlement over cost overruns and schedule slippage, the stakeholders were extremely pleased with the results. The PM’s could have been heroes. Instead, they were goats. It would have helped if the other stakeholders had challenged their approach and assumptions earlier. Unfortunately they didn’t. The PM’s missed the opportunity to take advantage of a few simple practices that could have made all the difference and they paid the price.

Drew Davison

Don’t forget to leave your comments below.