From the Sponsor’s Desk – Every Project Is a Business Project

“Information technology and business are becoming inextricably interwoven. I don’t think anybody can talk meaningfully about one without talking about the other.”- Bill Gates

We have all experienced the euphoria over (or perhaps terror of) a new technology upgrade. Remember changing ISPs, or email servers, a PC hardware or operating system upgrade, moving to a new smart phone, changing online banking? Integrating that shiny new technology into our daily, everyday existence can be a challenging, even terrifying journey. But, until that integration is complete, the full promise of the new technology often isn’t realized. We need to move things to a business as usual basis to get our bang for the buck.

That’s what happened in this case. What started out as a project installing some shiny new technology ended up as a business not as usual disaster. It required a complete restart to finally achieve the promise. It showed, once again, that every project is a business project.

Thanks to A.K. for the details on this story.

Situation

A small wealth management organization was acquired by a global insurance company a number of years ago. Over the intervening period, the insurance company had moved to standardize the technology infrastructures between the two operations to reduce costs and complexity and pave the way for better process integration.

The standardization effort was driven by the insurance company’s IT organization. As the wealth management’s technology products approached their end of service life, the insurance IT group would initiate a project to replace the wealth management technology with one used by and supported by the insurance company.

One of the last products to be replaced was for document management. Two different products were being used in the two organizations and the wealth management product was no longer supported by the vendor. That fact added some extra urgency to the project. The insurance company’s CIO assigned a technology lead to the effort and urged him to get the job done as quickly as possible. And so the tech lead launched his project.

The Goal

Replace the wealth management organization’s document management software and services with the technology used by the insurance company. Get the job done as quickly as possible.

The Project

The tech lead met with the wealth management organization’s Director of Administration, let’s call her Katie. From what the tech lead could determine, her organization was the largest user of document management services and would be the customer most impacted by the change.

The tech lead explained to Katie that the project he was running was simply a technology swap, a “like-for-like” change that shouldn’t require too much of her time and attention and wouldn’t impact her operations in any significant way.

Unfortunately for all concerned, Katie had been on the job for less than three months. She wasn’t yet familiar with the organization, its operating processes and practices and its technology. As well, she was up to her proverbial eyeballs learning her new job, getting to know her staff, responding to day-to-day demands and understanding how her organization tied into the whole wealth management entity and operated within the overall corporation. The document management upgrade project wasn’t top of mind.

While Katie was coping with her learning curve, the tech lead put together a plan for his project. He figured it would take him less than a year to get the job done. He needed three programmers to deliver access to the existing systems archives and some system admin time to set up user access for the new software and roll it out across the organization. He reviewed the plan with the CIO and got the go ahead to proceed.

As the work got underway, his team brought a number of issues to his attention for decisions. They found the ‘like for like’ assumption at the outset was faulty. There were significant gaps between business requirements and new system capabilities. Other issues arose. For example, the data mapping between the old and new systems wasn’t completely compatible, the security categories that allowed different classes of users various rights to view, add, change and delete information weren’t the same and there were a number of problems with formatting information exchange to and from other applications.

The tech lead met with Katie as the issues were brought to his attention. Katie, distracted as she was, told the tech lead to find a way to make it work. And so he did. His team did some cursory testing to prove that the new software worked as it should. They reasoned that the application was satisfying the document management needs of the much larger insurance organization so more extensive testing wasn’t required. And the work continued.

The Results

The new document management system went live on a Monday morning, eleven months after launch. The tech lead and the CIO were happy with the project and the new services that were delivered.

By midafternoon, there was a huge outcry from both remote and local users. It took many users much longer to complete their transactions and the processes were more error prone. There was a frustrating learning curve to cope with interfaces that were just different enough from the old system. The cursory training that was offered hadn’t addressed the need. It was discovered that a significant number of PC’s in wealth management were running with only 4 gigabytes of memory. The minimum requirement for the new software was 8 gigabytes. The software timed out after 15 minutes, losing any work in progress, and there didn’t seem to be a workaround. Also, the new software lacked a number of features that were used regularly in the old environment. Productivity suffered across the board.

As the negative feedback flowed to Katie, she got in touch with the tech lead, gave him a piece of her mind and told him to roll back the changes. When the tech lead investigated, he was told by numerous sources in IT that he couldn’t back out the change. The personnel and technical services weren’t available. When Katie got this message, she called the CIO and her boss, the VP of Operations. Suddenly the document management project became her top priority, a critical operational challenge for the entire wealth management organization and a painful lesson for the corporate IT department.

The VP of Operations, with the CIO’s blessing, selected a seasoned project manager from the PMO and charged him to make things right as quickly as possible. Over the next nine months, the PM carefully steered the project to a successful conclusion using established best practices to deliver a high performing document management service. He identified the major operational challenges and resolved them first. Subsequent releases addressed the outstanding performance, usability and functional issues. The final solution earned accolades from all involved.

Katie was replaced as Director of Administration. She left the company.

How a Great Leader Changed the Result

I wrote an article a number of years ago entitled “There Are No IT Projects”. It is still relevant today. The case we’ve covered in this post provides ample justification for managing every project as a business project, regardless of how much or how little technology change is involved.

How did the newly assigned PM redirect and deliver a successful implementation after such a messy and painful start? He went back to the beginning and moved forward with the basics – every project is a business project.

1. Know your project’s sponsor – This project started out with the CIO as sponsor. It ended up with the wealth management VP of Operations as sponsor. If he had been sponsor from the outset, I expect the course the project followed and the project’s initial outcome would have been very different. Having the correct sponsor in place, engaged and leading the charge influences a project’s degree of success more than any other single decision.

2. Build your guiding coalition – There was no guiding coalition in place when this initiative was launched. The sales organization didn’t have a place at the table. They were heavy users of the document management service. Nor did the Finance organization, Human Resources, not even the Service Desk. Under the restructured project, key decision makers in all of the wealth management organizations using the document management services and affected by the planned technology changes were engaged, involved and committed to the venture. They all helped shape the outcome for the better.

3. Manage the change – Understand the burning platform, the motivation for initiating the change in the first place. Articulate the desired end state. Establish specific goals for the change including benefits, costs, key milestones and outcomes. Identify the impact – what’s changing and what’s not – throughout the organization and beyond. Identify who has to learn new skills, capabilities and behaviours for the change to be successful. Engage with those affected to make everyone a part of the solution. Communicate with each based on their need. Celebrate successes and help everyone learn from failures. Manage the change! The new PM led that charge.

4. Follow a proven path – The first instance of this project had a ballpark target, installed some technology, did a bit of testing, offered a bit of training and implemented. The second instance followed a proven path. The PM identified the stakeholders affected and brought them together for their insights and assistance, thus building his guiding coalition. Together they articulated what the venture was trying to achieve. They established their priorities. They developed a plan that leveraged best practices used on other projects within the organization. They tracked time, cost, quality and acceptance to a successful conclusion. Yes, as part of that effort they determined requirements, both functional and non-functional. They identified and managed risks. They tracked issues and their resolution. They identified desired changes and managed the change process pragmatically. They developed and executed test plans to prove the solution was fit for duty on all fronts, both business and technical. They communicated widely. They celebrated successes. Finally, they had the right people in the right place at the right time to produce quality deliverables and move the project forward.

5. When in doubt, restart – Sometimes a project gets off to such a rough start that the best course of action is a complete restart. That’s what happened here. I did a story a while back called If at First You Don’t Succeed. It was a similar project with not one restart but two. It too turned out well. In this case, picking a new project manager and relaunching the project as a business undertaking set the stage for a great comeback.

Katie had a rude awakening when it came to managing change. She was so preoccupied with everything else going on in her life that she didn’t take the time to reset her priorities when the tech lead informed her of the planned change. She should have asked others with more experience in the organization what the change would mean to them. She didn’t. She paid the price.

So, as you work on your current project and when you tackle you next project, consider these proven practices for improving 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.