To get their initiatives to succeed, project practitioners must understand how they might fail.
Stories abound of high-profile projects and programs in jeopardy.
“To recover any project, we need a strong and confident team—people who can trust each other.”
—Alexandre Sörensen Ghisolfi, MBA, PhD, PMP, Curitiba City, Brazil
A US$3.1 billion initiative to build a highway tunnel in Seattle, Washington, USA suffered a nine-month delay when its giant US$80 million tunnel-boring machine broke down. An AU$45.6 billion project to provide broadband access to every resident of Australia has seen its scope drastically diminish, as the original plan to serve 93 percent of the population has been revised to 22 percent.
It's not just the headline-grabbing projects that face tough times. More than 40 percent of strategic initiatives do not meet their goals and business intent, according to PMI's 2014 Pulse of the Profession®: The High Cost of Low Performance. That has a palpable consequence for an organization's bottom line: As a result of project failure, almost 11 percent of every project dollar is at risk.
Project success means perpetually identifying and avoiding the risks—and at times the seeming inevitability—of failure. In addition to constantly monitoring the triple constraint and the project's contribution to the organization's strategy, project managers overseeing troubled projects should consider the human element—especially team morale.
“To recover any project, we need a strong and confident team—people who can trust each other,” says Alexandre Sörensen Ghisolfi, MBA, PhD, PMP, an independent project director working on technology and construction programs in Curitiba City, Brazil. “When facing difficulties, it is important for people to believe we can change for better. That's where the sponsor or the manager can have a tremendous impact, for good or for bad.”
Darryl Isip, PMP, Barclays Bank, London, England
PHOTO BY JON ENOCH
Here, three project managers share their experiences with projects or programs in trouble—and how they guided them to success.
Even the seemingly most intractable projects and programs can be salvaged—but only if their project managers can identify the malfunctions and fix them. Darryl Isip, PMP, program director at Barclays Bank, a PMI Global Executive Council member, in London, England, learned that firsthand with the e-Channels Renewal Programme.
The Barclays program aimed to deliver a new, secure online bank user interface for 5 million customers, a new financial planning platform for online banking customers and a new content management system. To launch all three projects, the program team had just 18 months.
Several months into the program, however, it was red-flagged for spending a significant amount of the £20 million budget with minimal progress. Senior executives decided the program needed a complete assessment—and new program management. That's when Mr. Isip stepped in.
“I was actually the fourth lead who came in to manage the program,” he says.
Facing intense pressure to improve program delivery, Mr. Isip quickly assessed the problems he inherited. He identified three main culprits: unclear communications, ambiguous structure and scope creep.
The program had more than 20 project managers, test managers and business analysts, while the technical supply chain had more than 100 team members. A team of that size and variety needed clear, reliable direction. “Decisions needed to happen,” Mr. Isip says, but “the outcomes of the decisions were not communicated quickly or consistently down the line.”
TIPS OF THE TRADE
For other leaders of troubled projects, Mr. Isip offers a couple of pieces of advice. One is tactical: To help foster a strong team culture, try to build trust, empower colleagues, provide a platform to listen and respond to feedback, and create a reward and recognition program, celebrating significant milestones along the way. “You don't always have to wait until the end of the program to celebrate,” he says.
The other is more strategic: “Inheriting program rescue missions will get more difficult before it gets easier, so hang in there and don't forget about your PMA—positive mental attitude—as the team sees you as a role model to weather the storm and cross the finish line.”
PHOTO BY JON ENOCH
“There were too many cooks in the kitchen when it came to deciding priorities and scope, with many executives shouting to have activities delivered.”
—Darryl Isip, PMP, Barclays Bank, London, England
Mr. Isip made project reporting more streamlined, consistent and transparent with a new status report process and format. With streamlined reporting, “there is a single known source of truth, to ensure all stakeholders receive a consistent message,” he says. More consistent reporting “allowed everyone from enabling functions to the CEO to understand the status of the program.” In addition, it “called out the key risks so the team could support and unblock issues.” His team also established a program newsletter and intranet site.
The program had a very fragmented project structure, Mr. Isip says. Some project managers oversaw only the initiation and planning phases, while others managed the execution and closing phases. “There was a fuzzy line where work was handed off from plan to execute, and no one knew who owned which activity.” The program also suffered from a lack of clear accountability: “There were too many cooks in the kitchen when it came to deciding priorities and scope, with many executives shouting to have activities delivered.”
Mr. Isip established a clear organizational structure, roles and responsibilities and communicated them to the entire team and stakeholders. He also enabled his project managers to oversee end-to-end projects, instead of managing only phases of the projects and then handing them off. “This empowered them but also gave them accountability,” Mr. Isip says. It also gave team members a sense of pride and accomplishment, he adds.
While strategic work took precedence among the program's resource and budget priorities, tensions emerged when digital operations wanted to implement tactical changes, like resolving content and stability issues. “This led to scope creep when someone of influence had an idea and said, ‘Wouldn't it be good if…,’” Mr. Isip says. The program lacked rigor around such change requests.
“We put in controls to manage scope,” Mr. Isip says. He ensured that any possible changes to the scope would be determined in a controlled manner, with a committee vetting all change requests. Mr. Isip set up a “new demand forum” that reviewed any new ideas outside of the project scope and ensured they were strategically aligned, sponsored by an executive, had assigned funding and made sense technically. When it comes to such requests, Mr. Isip has a golden rule: “Don't be afraid to say no,” he says.
Even with these improved processes in place, the program took about twice as long as the original 18-month timeline. Still, because Mr. Isip's team rescued an imperiled program and delivered it within scope, the sponsor considered it a success. In the end, the change initiative improved online customer interfaces, increased security features, enhanced content management and reduced the time to edit content.
While the project required technological prowess, the problems weren't necessarily about technology, Mr. Isip says. Instead, they were people-related. “Many times, programs run at full force attacking the technical problems, completely forgetting the colleague element,” he says.
When a communication breakdown threatens to send projects off course, the problem might be not whether there's enough communication—but instead whether it's effective.
That proved to be the issue for a software implementation project overseen by Matt Mudge, PMP, a senior project manager at Backstop Solutions Group, Chicago, Illinois, USA, an organization that provides customer relationship management software for institutional investment firms. With a kickoff date of June 2012 and a planned end date of March 2013, the project intended to install and configure software for a client and re-engineer its business processes around the software.
At first, the project ran smoothly. It showed measurable progress, and the few risks that emerged were easily mitigated. Midway through the project, that changed. As Mr. Mudge describes it, the communication between his team and the client's team became “very coarse.” When tasks weren't completed, a blame game ensued.
“The status calls would escalate into tense arguments and even yelling,” Mr. Mudge says. As a result, one of his team members stopped attending meetings and client calls. The slowing progress posed a threat to on-time completion.
Mr. Mudge knew the situation was untenable. So, one evening, he called the client's project manager, and they talked for two hours. “I learned more in that one call than over the previous two months,” he says.
The conversation revealed a power struggle that had been playing out on the client's project team. The leader of that team—the person Mr. Mudge spoke with that evening—was the client's director of IT. However, the client's team included process managers and business managers, who all reported to different supervisors. While the client's project lead relied on those managers to complete project dependencies, she didn't have the authority to make that happen.
TIPS OF THE TRADE
Troubled projects highlight the importance of interpersonal skills, Mr. Mudge says. While the framework for project management remains consistent among his projects, he says, the major variable is the client team. Mr. Mudge advises project managers to learn the client team members' personalities and motivations. “Understand what they are being measured on, and you will understand what the client's senior leadership ultimately expects from you,” he says. “Since I don't own my clients' resources, I rely on a great relationship with the client's core team.”
“Since I don't own my clients' resources, I rely on a great relationship with the client's core team.”
—Matt Mudge, PMP, Backstop Solutions Group, Chicago, Illinois, USA
During the weekly status calls, when Mr. Mudge asked if a task was moving along, the client task owner would say, “Yes, going great.” But as Mr. Mudge learned during the two-hour call, the client lead knew that wasn't always the case. Because she felt she couldn't call out her own organization's members, she instead directed the responsibility back at Mr. Mudge's team—which is why the status calls escalated into shouting matches.
“The client project manager would feel pressured by her management to have X, Y and Z done, but she couldn't direct the pressure to her peers,” Mr. Mudge says. “So she would blame individuals on our team, who would take the criticism very personally and fire right back.”
By communicating with the client's project lead, Mr. Mudge learned how to communicate with her team. During the next status call, Mr. Mudge framed his questions so that they targeted the tasks themselves, not the task owners. “The way I presented it, simply as standard progress updates on each task, it appeared that it was just standard desired knowledge on my part—when in reality, it was everything their project manager was struggling to get them to do and accomplish.”
By asking “much more specific, situational questions,” Mr. Mudge says, he “didn't expose the client project lead and make her seem like she was throwing her team under the bus,” he says. “The specific questions triggered different responses than previously and put more transparency on high-level conversations.”
After that, Mr. Mudge says, the communication became easy—and productive, with the project finishing within budget, scope and schedule. “We made more progress than any time previously.” There was plenty of communication before, he observes—just not the effective kind.
High-level support isn't always enough to motivate team members. As Aaron Ward learned, external motivation, even when it comes from the top, can be less effective than self-motivation.
Before becoming the portfolio and governance manager at AIG in Tokyo, Japan early this year, Mr. Ward worked in global capital markets at another major financial institution in Tokyo. There he oversaw a project to reduce the infrastructure footprint and associated costs for the firm's markets business, including stock and bond markets. His team identified opportunities to reduce costs by using virtual servers instead of physical ones. “The opportunities were presented to the business and received high-level management support,” Mr. Ward says. At project initiation in 2012, an estimated timeline of one year was set.
While the infrastructure-overhaul project enjoyed executive backing at the firm's headquarters, where there was heightened pressure to reduce costs, that pressure was not translating to the application teams that develop, implement and manage the business' software. They were located in parts of the global organization that had only weak matrix reporting lines to Japan.
“Getting application teams' acceptance of the solutions was very challenging, despite the pressure from management in Japan,” Mr. Ward says. There was also resistance from the business teams, which represented the organization's business units and its end users.
Mr. Ward identified the main cause of resistance to the change initiative: a fear of risk. “Changing systems is not without risk,” he says. “And if the change led to a downgrade in performance, it would be hard to meet the requirements of end users.” Also, he notes, “the teams are busy and don't like to take on more work.” As a result, requirements gathering and delivery were delayed.
When those delays threatened a budget overrun and an eroded ROI in the process, Mr. Ward came up with a proposal: Rather than forcing a single project onto the application and business teams, he broke it up into smaller subprojects and gave the teams responsibility for executing them. This would transfer project costs, benefits and accountability directly to those teams. Mr. Ward's approach: “Let them decide if they will realize the benefits or not without running up project overhead.”
He presented his proposal to the project sponsor. “It was clear that if we continued with the original plan, the budget—and then some—would be spent without the result. This gave me leverage to convince management to change our plan,” he says.
With the resulting buy-in from both management and the application and business teams, Mr. Ward took advantage of “an opportunity to realize cost reductions for the business without prohibitive project cost.” Ultimately, the project took about two years, but it stayed within its original US$1 million budget. “It was a case of project salvage,” Mr. Ward says, “but it was a real project management success which I am proud of.” PM
TIPS OF THE TRADE
For Mr. Ward, the biggest lesson learned from troubled projects is to understand what drives team members—and what threatens to impede them. “You need to understand the commitments and pressures your sponsors and managers have made,” he says. “Be their eyes and ears on the project, and don't be distracted by the noise of the issues—guide it to the best solution for the organization.”
“Changing systems is not without risk. And if the change led to a downgrade in performance, it would be hard to meet the requirements of end users.”
—Aaron Ward, AIG, Tokyo, Japan
PM NETWORK JULY 2014 WWW.PMI.ORG
JULY 2014 PM NETWORK