From the Sponsor’s Desk – Project Partnerships Pay Dividends

“If we are together nothing is impossible. If we are divided all will fail.”- Winston Churchill

A project is a unique beast. It’s a method of delivering change, hopefully in an organized and predictable fashion. Yet it can be a challenging exercise, requiring people who often don’t know each other and haven’t worked with each other to come together, coalesce around a common vision and sweat the details to deliver something better.

Partnership structures, both formal and informal, are vital for the effective collaboration and decision-making so essential to a project’s success. Formal partnerships define the structures, accountabilities, roles and responsibilities of the key players and can manifest as an organizational structure, RACI chart and similar artifacts in a project setting. Informal partnerships tend to form between and among project participants based on shared mission, vision, culture, core values and shared interests.

The following case demonstrates that, regardless of the nature of the planned change, project partnerships pay dividends, for the better, in myriad ways.

Thanks to Y.N. for the details on this story.

Situation

This international bank acquired the life insurance operations from a large multinational insurance organization that was struggling in the aftermath of the great recession of 2008. However, investment in the insurance branch had stagnated and it found itself behind its competition in terms of business process productivity and technology offerings.

The VP of Marketing and VP of Underwriting were aware of the challenges they faced and, working together, developed a plan to make their operations and offerings more competitive. They proposed the development and implementation of an electronic application for the independent agents that sold their products to clients. It would be an attractive package, easy to learn and use, improve front end productivity for the agents and the bank’s staff, reducing errors and producing a completed policy for the majority of clients in considerably less time than the current systems allowed.

The two VP’s, with their CEO’s assistance, were able to secure funding from their parent company for the project. And so the journey began.

The Goal

Implement an electronic application for life insurance for the company’s independent agents to increase business by 50% over three years and reduce unit costs by 30%. The project budget was set at $3 million with a 12 month duration.

The Project

With the funding in hand, the two VP’s, the project’s co-sponsors, proceeded to staff the project. They agreed on an experienced senior SME from the underwriting group as the business PM and approached the leader of the PMO to secure the technology PM.

The sponsors had identified the selection of the technology PM as a high risk. The technology organization the insurance company relied on was part of the bank’s organization and took direction from the bank’s executives, not from the insurance operation. The sponsors needed a tech PM who would be willing and able to collaborate openly with them and the business PM, who would focus on the target business solution, not just on the technology components. They succeeded in securing the services of a PM with more than twenty years of experience at the bank. More importantly, he was a great communicator and thoroughly familiar with the insurance company’s technology infrastructure.

The sponsors charged the two PM’s with three priorities:

1. Define the requirements for the project,
2. Develop and issue an RFP for the solution based on those requirements and
3. Review the RFP submissions and recommend a course of action for the sponsors’ consideration.

The business PM brought in two business analysts to work with independent agents and administrative staff to understand their needs going forward. They focused on the business processes and rules that needed to be supported. They also addressed the non-functional needs such as performance, ease of use, flexibility, continuity of service and security.

Concurrently, the tech PM worked with the Lead Technology Officer and his staff to establish the needs of the technology organization including architectural compliance, authorization requirements, service level administration and service desk, change management, system administration, output management and system administration needs. As the business needs evolved, he also worked with the application support group to identify interface requirements and any interface standards that needed to be met.

As the business and technology needs were being discovered, the PMs worked together to draft the RFP, identify potential candidates for providing the solution and contact those vendors to determine their level of interest. The tech PM also explored the possibility of an internally developed solution with the application development organization. He discussed his findings with the business PM and the sponsors. They decided not to pursue the option further because of a lack of any strategic advantage and greater risks associated with a from scratch, home grown solution.

The requirements gathering was a collaborative effort across the board. Independent agents and their staff were consulted. Managers and senior staff in the organizations that would be affected by the project were engaged. The collective “wants” were subjected to a priority setting MuSCoW process (Must, Should, Could and Would) that was widely vetted and endorsed, from operating staff through to the sponsors.

The finalized RFP was reviewed and approved widely before being passed to the interested vendors. The RFP submissions and vendor presentations were made available and open to all affected parties as well as the final RFP assessments and recommendations.

When a vendor was finally selected, the project scaled up quickly. The vendor, who planned to do most of the development work offshore, designated a project manager and business analyst as the local contacts. They were embraced by the business and tech PMs and worked seamlessly with the in-house staff and the project’s sponsors.

The vendor selection process had placed a priority on matching the company’s requirements to the functionality offered by the various software packages. As a result, the software from the selected vendor required very few functional changes. The majority of the effort was focused on building and implementing the interfaces to the company’s infrastructure and back end applications. That helped reduce costs, accelerate delivery and ensure a quality solution.

When issues did arise, the PMs adopted a sidebar strategy that involved initial one on one discussions with the affected stakeholders followed by collaborative group meetings if necessary. That approach made everybody feel a part of the solution. The PMs were never blindsided by an issue at a steering committee meeting and that increased the sponsors’ confidence in their management abilities and their project oversight.

As development progressed and the solution took shape, demonstrations and “Tell us what you think” sessions were offered to the independent agents and their staff and to the company’s underwriting and administrative staff. The feedback was extremely positive. Suggestions for improvement were captured, most were implemented in short order and the requestors rewarded for their contributions.

The testing plan addressed the required business functionality, of course. But it also covered the non-functional requirements (including usability, performance, flexibility and security) that would be key to the application’s ultimate success. Finally, the application was phased in by region and product line with ample on-site support for the early adopters. Although there were very few defects encountered, the approach made those involved feel enthusiastic about the new application. The word quickly spread that this was a very positive change for the better.

The Results

The implementation of the electronic application went seamlessly. It was phased in by region and product line to minimize the impact and risk. It was a well-liked solution. The user feedback was great and user adoption exceeded targets. The project was also essentially on plan and budget, a little under budget actually and a bit late because of the phase implementation. Business volume in the first two years increase by 37% and was expected to exceed the 50% target in three years. Unit costs in the first two years were down by 36%. The sponsors were thrilled. Project partnerships pay dividends indeed!

How a Great Leader Succeeds

It’s no surprise that successful projects reveal a common and consistent set of qualities and practices. Check out this blog and others that focus on project success and failure and you’ll see those success factors at play again and again, including the following best practices:

Set your goals – In the words of the New York Yankees catcher Yogi Berra, “If you don’t know where you’re going, you’ll end up someplace else”. The two sponsor of this initiative knew what they wanted, why they wanted it, set concrete goals to guide them and shaped the project to achieve them. The PMs and other key stakeholders marched to the same drummer.

Partnerships all around – The co-sponsors partnered on their vision, on their pitch to the bank to secure funding and with their PMs to deliver the solution. The PMs partnered on their plan and with their constituents (business, technology, project and vendor) to gain insights and consensus and deliver successfully. They used their sidebar strategy to engage stakeholders and form a partnering and collaborative culture.

Know your requirements – The PMs and BAs drove the requirements process though individual engagement, collaboration, iteration and repetition. They focused not only on the business aspects but on the non-functional and quality needs. The process they used, from inception, through the RFP exercise, to testing and post-implementation offered an openness and willingness to change and evolve to make it right for everyone involved.

Manage the change – The focus of the project from the get-go was on the business solution, not the technology, and on the people who would have to acquire new skills, attitudes and behaviours to achieve the project’s goals. The people who were affected were invited, on numerous occasions and in different contexts, to contribute their knowledge, issues, concerns, thoughts and suggestions. As the project progressed through its various stages, they were able to see their contributions reflected in the evolving solution. That increased their comfort with the change, their satisfaction with the project’s direction and their confidence in their abilities to handle the change going forward.

Phase it – There is nothing worse than flipping the switch on a major change and watching it seize up and implode. It’s almost impossible to recover from that kind of setback, politically, professionally and organizationally. If you want proof, check out The Great Canadian Payroll Debacle and Start Your Project with PACE, two previous posts in this blog. The three PMs agreed on a slow, phased rollout by region and product line to minimize the risks and gain experience and user support. The sponsors endorsed the strategy. The early adopters loved the notoriety that went with being the first to use the offering. When the first implementations succeeded without a hitch, there were high-fives all around and the word got out.

So, as you work on your current project and when you tackle your next project, consider these points as proven ways to improve overall project performance. Also remember, use Project Pre-Check’s three best practice based building blocks covering the key stakeholder group, the decision management process and the Decision Framework right up front so you don’t overlook these key success factors for managing change.