Introduction
All IT projects face similar challenges that can benefit from good, solid project management strategies. This paper discusses successful strategies used on two IT projects – one large and one small -- that ensured the ultimate success of both. Both projects had many differences in terms of objectives, scope, priorities, teams, time, and cost. But at a certain point, both strayed from course and threatened to flounder due to similar issues: unclear accountability between project team members, unsustained buy-in from business teams, inadequate communications, and an unclear change management strategy. These issues led to poor morale, project delays, conflict, miscommunications, and resistance to change. After some digging, we were able to determine the sources of these problems, and come up with strategies to get both projects back on track.
Project 1: Getting Off on the Wrong Foot
The first project involved completely rewriting a home-grown legacy system written in Natural Adabase, used by 25% of the company's resources to manage short-term insurance and financial transactions. Eventually, this system became more and more difficult to maintain or adapt to changing business demands. The technology and supporting processes could not keep pace with changing business realities.
In 1999, the company decided to retire the old system and replace it with a new one, also developed in-house. The design was completely overhauled: new, user-friendly, web-based interface; improved navigation; better integration with in-house systems, and new features to reflect current business practices.
The project scope was large and ambitious with a multi-million-dollar budget over three years. The project plan and schedule were aggressive: first release in 18 months. And there were a lot of “firsts” for the corporation: first IT project with such a large, diverse team; first time building an in-house web application; and first time completely replacing a legacy system. However, we were confident that we had the right players, processes, and resources in place to succeed.
Problem Summary
In any large project, some delays, roadblocks, and shifts in focus are inevitable. It's what good Project Managers plan for. And from a project planning perspective, we felt we had made all the right moves. We identified and assigned key resources, and hired supplemental resources in areas where we either didn't have the expertise or resources to deliver. We identified key milestones for delivery. We got buy-in from senior management. We assembled our project team and project plans and began to work very hard toward our first major milestone.
So, where did we go wrong? In hindsight, we missed opportunities in several key areas.
Accountability
With such a diverse project team: internal and contract resources representing four corporate groups, assigned to all project phases (from analysis and business requirements to UI and database specifications), some important roles and responsibilities were undefined or ambiguous. This left room for interpretation and process gaps. There was no consensus on who owned certain tasks and milestones, or indeed the project as a whole. The two main groups running the project – business analysts and systems analysts – reported to different team leaders, with no one lead ultimately responsible. As well, even when we knew about gaps and overlaps, we had no tools or process for assigning an “owner.” So, we had team leaders in place, but no chief; we had overlaps and gaps in accountability, but no way to address them.
Business Stakeholder Buy-In
We got buy-in from business stakeholders at the beginning, at the highest level. However, we failed to engage them as continuing owners in the project's progress and success.
The approach at the time was for the business to review and approve the concept, then hand it over to the analysis and technical teams to “make it so.” After initial requirements gathering, they generally left the table until the system was almost finished and acceptance testing had begun – too far down the path to make significant changes without a high, negative impact on timeline and budget. So we had buy-in, but it was not sustained. The business was not at the table except when they had new requirements or we experienced delays. They felt no accountability for the project's success or failure. They had no clear role or stake in the project team building their system.
Communications
Communications problems appeared at several levels: between groups working on the project, between the project team and users, between the project team and other groups impacted in some way (e.g., owners/users of integrated systems), between working and management levels, and between top-level managers. While we had a basic communications strategy, we really only shared status via emails and meetings. At times the messages were conflicting or inconsistent because different groups used different channels. At others, communications were not frequent or timely enough to have the desired impact. And with no clear ownership or accountability, our strategy did not have the necessary breadth or depth, nor was it guided by one clear vision.
Change Management
We were unprepared for the changes the project would precipitate: to how the project team worked to deliver a system, to our daily working environment, to the dynamics between different project groups, and to the jobs of hundreds of users. Therefore, we had no strategy for dealing with varying responses to and the consequences of these changes. We also greatly underestimated the amount of time, effort, and resources required to both understand and manage the impact of change.
The Warning Signs
While we may have missed out on anticipating some key challenges, the warning signs were clear. The project suffered from setbacks and delays, which impacted the morale of the working team and angered the business who felt we had “let them down.” To mitigate delays and restore confidence, the team started working punitive hours and some began to burn out. We've all been there before: if we just focus more and put our heads down, add resources where needed, we'll get back on track. The project's long duration also meant that business requirements and priorities inevitably changed, becoming a “moving target.” Our business clients were frustrated at our inability to quickly adapt without changing the project timeline. The end goal started to become unclear as time or functionality was sacrificed to adapt to the changes. At our lowest point we were faced with delays of eight months at a sacrifice of 30% functionality and the grim prospect of unrelenting overtime for as many months to support the new schedule.
Project 2: Strong Start, Uncertain Finish
The second project was a pipeline system for improving processes and gathering strategic information on medium-and long-term transactions. The goal was to make the business “better and smarter” by realigning core competencies and streamlining inefficient/duplicate efforts. A less ambitious scope and timeframe, smaller user community, and more focused requirements allowed us to break the project down into manageable phases with clear goals with an annual budget of less than $1 million. We outsourced most of the development effort, as we did not have the people or skills in-house to deliver and maintain the system.
Problem Summary
At first, the project was on track, with clear direction, targeted deliverables and dedicated and skilled resources. However, we started experiencing the same problems. Business stakeholders were disengaged from the process, project roles and responsibilities were unclear, communications suffered, and we were ill-equipped to deal with the impacts of change on our clients and ourselves.
Accountability
The relationship between the infrastructure, functional, and technical teams became a difficult triangle to manage. One team was responsible for business analysis, requirements, acceptance testing and overall project management. Two others were responsible for the technology implementation: a small internal team tasked with integration, operations, and infrastructure issues, and a consultant tasked with building the system to our specifications. Many tasks overlapped or were not clearly defined. When new tasks or issues arose, it was not always clear who “owned” them. Additionally, it was not clear who was responsible for sorting out and addressing gaps in ownership, roles, and responsibilities to ensure nothing fell through the cracks.
Business Stakeholder Buy-In
The smaller project also had senior management backing: they were the ones championing the “new way of doing things.” But we learned this was more an approval at the senior management level than solid support at the working level. This was most apparent in the lack of buy-in from their teams, the people whose jobs we were changing. Because the system was a pipeline, rather than transactional, they saw more work, but no associated benefits. For example, during a post-delivery benefits realization study, users said they believed this “disruption” would go away in a matter of months, once they failed to use the new system. So the users resisted using the new system and we had no formal backup from our business stakeholders. Our clients felt no ownership around the project's success: that was our job.
Communications
We met regularly as a project team, but not with senior management to discuss how we were implementing their requirements. We consulted the Project Sponsor about changes to functionality or schedule, but failed to educate other key managers on the process behind our decisions, so they did not value the time it took to manage them. Communications with users was generally one-way, so when we met with resistance we were surprised.
Change Management
From many perspectives, the project was a success. We had nailed the requirements. We had assembled a strong team. We were on target to deliver. But we greatly underestimated the impact of change. For one thing, having internal and external technical teams caused a lot of friction. The business systems project manager oversaw the consultant's work rather than the IT group, which traditionally had this role. They resented not having that control. Users were frustrated because they felt their workload was increasing, yet they had no control over or stake in the new system, and didn't see the value.
Warning Signs
There were two key warning signs. The project team triangle caused a great deal of tension, friction, miscommunication, and misunderstanding. People were unsure of their roles and felt their jobs were threatened: an unhealthy situation. Users were refusing to try the new system; we had to devise tactics to convince them to use it. While these issues had caused only minor delays so far, the environment of resistance and mistrust threatened the project's overall success.
Getting Our Ducks Lined Up
Recognizing these problems was the first step. For the larger project, we faced a critical dilemma: we had gone too far to stop, take a step back and start over. Even if we understood the issues, we didn't have time to address them all. They might threaten clear project success, but we could still deliver something useful within an acceptable timeframe. With no time to “learn new things,” everyone was eager to go forward. For the smaller project, we had already successfully delivered Phase I, we could work on user buy-in and morale issues as we went. For both projects, our plan was to review the lessons learned at the end of the next stage and then apply them to the following phase to catch up on any lost momentum. This is the strategy many, many projects follow. Unfortunately, with tight deadlines, new expectations, and changing resources, we are often forced to suffer from the same challenges again and again.
This time we were determined to break the cycle and take the time to address these problems this time around. We asked our Learning & Development team to assist us, starting with sessions for the team on the larger project, aimed at “getting our ducks in a row.” We involved various teams to scope out the problems behind the warning signs outlined above. Then we worked out strategies to address each of the four main problems identified. This process worked so well, we used it again on our smaller project, which greatly benefited from the same strategies. The following is an outline of what we came up with.
Defining Accountability
Accountability was a critical issue that had to be addressed immediately. We needed a clear consensus on definitions of project tasks, roles and responsibilities – who was responsible for what and when. These details had to be much more granular than a project plan; there was no room for gaps or overlaps that could impact our timeline. We also needed a tool to mitigate the frustrations experienced by various project team members over unclear role and responsibility definitions. This required clearly defining roles and responsibilities for different project pieces, as well as for the overall project.
Our tool was an Accountability Matrix (see Appendix). Seems simple, but it took a while for all groups to even agree on the major project tasks. The design and use of the matrix was first presented to our internal Technology Initiatives Group (TIG), a committee that represents and manages all resources assigned to the corporation's technology projects. Getting TIG involved helped us secure senior-level support for the matrix, ensuring all groups were on side with this approach to building consensus around project responsibilities. The next step was to agree on the tasks to be covered, and assign roles and responsibilities to each: Accountable, Responsible, Informed, or Consulted. This involved senior management, project managers, business analysts, systems analysts, and consultants, and, most importantly, representatives from our business team clients. Including the business team in our matrix was an important step toward formalizing their stake. It not only made them aware of their role, but also of the things they had to deliver to ensure project success. The matrix also gave the business a more “hands-on” exposure to the project, helping them understand and value the contributions of each group toward overall project success.
It took five sessions and six management resources to build and approve the matrix, but it was an important step in getting the project back on track. While it moderately impacted our timeline, we realized big gains through better communications between teams and increased buy-in, particularly from the business. We were also able to apply what we learned to the larger project to help resolve role clarity issues. Today we use the matrix on all projects, large or small. It is a key tool for projects with two or more groups (internal or external) participating in the project team.
Getting Sustained Buy-In
For both projects, we sought and obtained approval in principle at the highest level. But, after the initial win, the business turned back to their critical tasks at hand – bringing in and serving customers. They left us to deliver the system; after all, that was our job. This relationship might work well on a short-term project, or perhaps even a long-term one. If we got our requirements perfectly the first time round and if the project went smoothly from start to finish: an unknown experience when building business systems.
This model stopped working as soon as we experienced problems and required business input. They were often irritated by the “distraction” from their day jobs. Some felt we had let them down, failing to meet their expectation of doing the job and getting it right without their involvement/commitment. We contributed to this problem by accepting this expectation and striving to meet it rather than pushing back and asking for a bigger commitment to the project's success.
The accountability matrix was an important first step, but we needed a sustained commitment from our business clients to be involved in the project and have a stake in its success. We encouraged the business to add their “skin to the game” through several initiatives. For the larger project, we established a weekly steering committee made up of 10 senior managers representing the groups building or using the system, financial and audit groups, and other key stakeholders in the company. The project was also assigned four full-time resources from the business team. These resources were our business experts, dedicated 100% and reporting to the project team. We were no longer a distraction, supporting the project was now their job.
For the smaller project, we created a monthly Management Steering Committee responsible for the timely disclosure of issues and their resolution. In addition to a dedicated Executive Sponsor, we also identified a business partner for each project phase, pulling from the broad group of business teams who would use the system. Assigning a different manager to each new phase spread out the responsibility so that the project did not have an ongoing impact on one team's daily work. Along with regular participation in management and related project issues, the sponsor assigned subject matter experts from the business team, available as needed by the project team, particularly for acceptance and usability testing and to act as “super users.”
These strategies worked immensely well on both projects, ending the “blame cycle” and bringing the business to the table to make key decisions and, most importantly, feel ownership and responsibility for the projects’ success.
Communications “With” Rather Than “At” our Clients
Improved communications were an integral part of our initiatives for accountability, ownership, and our understanding of change. For example, sustaining business buy-in involved establishing new communications channels for identifying and resolving critical issues. As well, the accountability matrix provided a touch point for the details behind our project plan.
We supplemented these initiatives with others to address issues of morale and overall project understanding. For both the large and small projects, we began to recognize people for outstanding achievements, dedication, and innovation. We didn't wait for the projects to finish; we did this throughout to keep up both momentum and spirits. We also identified super users in affected business teams to “champion” the new system. As well, specific individuals became accountable for acting as the key source of all relevant project information for all project team groups, ensuring a clear, consistent message. And for the larger project, we created a Gazette that presented current issues, initiatives, and progress in a more fun and palatable format. For the smaller project, we held quarterly briefing sessions with each team impacted by the new functionality to give them a chance to see what was coming, and to get their input and buy in ahead of delivery.
Understanding Change
Change was the most elusive item to tackle, mostly because we didn't understand the value of understanding it until we were well into the process. Our reluctance to buy in at first also meant we had a hard time selling it to others. Fortunately, we had experts on hand to advise us on how to proceed.
We engaged our internal learning and development team to hold sessions to teach us about the Change Cycle™ -(Exhibit 1)- how “people react and adjust to change in a sequence of six predictable states.” (Interchange International, Inc) This understanding was what we were missing. Up until that point, we were unable to assess where groups and individuals were, in response to specific changes instigated by the project. By learning how people react to change and move through the Change Cycle, we were able to tailor our communications to successfully address both morale and buy-in issues.
After our initial reluctance, everyone was impressed with how we could immediately apply what we had learned to improve our work environment. Understanding change didn't directly help employees accept the changes more, rather it helped them understand their own reactions to change and what they needed to do to move forward. It also helped us tailor our communications and gauge subsequent reactions to improve the process of acceptance.
Exhibit 1 (Interchange International, Inc)
Aside from holding sessions with all project team members, including the business, we also created a “roadmap for readiness.” This helped us assess how ready the overall group was to accept the changes identified. We also set up change teams with representatives from various affected groups to act as a bellwether for how people from their areas would react to upcoming changes. We chose people who were “credible” -- great communicators, seen as leaders or “go to” people on their teams. However, we weren't looking for cheerleaders; we also included people who had not bought into the change, but were open minded enough to participate in a positive way. These latter representatives were an invaluable source of feedback on our greatest change “resistors.”
Understanding change is an ongoing process for us as people react differently to each new change. However, we now greatly value the benefit of understanding this critical people component, and apply this strategy to ongoing projects, particularly those with a large impact on employees.
Summary
Our experience with these two IT projects taught us that all projects, large or small, can benefit from strategies aimed at improved communication, clear accountability, sustained buy-in, and the ability to understand and manage change. While the two projects were very different at first glance, both suffered from similar symptoms which, when we dug a bit deeper, had the same root causes. With the help of our internal Learning and Development team, we were able to get our ducks lined up by first identifying the source of these issues and then coming up with successful strategies for addressing them. These strategies were so successful for us they are now part of our basic project management strategy for any new IT projects managed by our group.
