Righting a Capsized Ship: Project Rescue Services

Tuesday, June 4, 2019

Periodically we draw from other Princeton Consultants practice areas for helpful content.

When does a project go bad? Signs of trouble don’t appear in status reports until the project is well underway. After all, it takes some time for the budget to slip significantly, and even if early dates are missed, there is a bias toward explanations like “growing pains”, “the team learning to work together”, and “IT is overallocated”.

In reality, the seeds are often sown before the project starts, camouflaged in business as usual. While the team focuses on acute problems—resource gaps, dropped features, schedule delays--systemic issues lie in wait for the next big project.

In the heat of the action, however, it is possible to identify systemic blockers to on-time, on-budget performance; then, in the aftermath, to weigh the costs and benefits of their remedies.

Challenge

A business line of a global, top 5 financial services company serves thousands of institutional clients who demand flawless accounting and always-on reporting. Leadership recognized the need to replace an aging financial system with a modern platform that had a far horizon and features that its customers wanted promptly.

The move to the new system required both perfect execution and on-time performance to avoid losing clients to competitors. After six months of work, deadlines for the high-priority clients were approaching quickly, implementation was well behind, and simple arithmetic told the team that failure was imminent.

Approach

Company leaders retained Princeton Consultants to rescue the implementation and get it back on track. A Princeton Consultants project manager (PM) with technical expertise and deep experience in the application development lifecycle took over management of the project. After two weeks our PM had an inventory of major problems, each of which impaired a fundamental component of project management:

  • Project plan: Instead of one project plan, there were three, residing in different functional areas/implementation tracks. The task names didn’t match at any level across the project plans and the file formats were different (MS Project vs. Excel vs. Smartsheets, for example). This arrangement left the business executive tasked with overall project supervision a day of work each weekend to figure out the project’s status, find blockers, and report up to the sponsor. Why did this situation exist? A company practice of creating project managers out of colleagues trained in other functional areas (e.g. fund accounting) meant that the implementation team was a mix of cultures and practices.
  • Status reporting: Weekly status meetings detoured regularly into working a single issue. Rather than reporting on tasks completed, incomplete, and upcoming, and registering issues and blockers, the team consumed meeting time with hashing out an issue. Why? The status meetings were the only time that the cross-functional team met as a group. For compliance reasons, the company did not allow an instant messaging platform such as Slack--which might have facilitated cross-functional communication—and there was no other arrangement in place to promote working sessions among team members who were often dispersed across continents.
  • Issue and bug tracking: Developers working on the project habitually kept their bug lists private as well as their schedule for fixing them. Similarly, issues were not visible in a practical way above the level of a few team members at a time. This situation hobbled key PM processes like prioritization and communicating the true status of the project. Why? The company’s IT department had limited the use of bug/issue tracking software (such as JIRA) to small group of users in IT, because rolling out software to the wider firm required very high-level compliance review and approval in a window that only opened twice a year.
  • Testing: Acceptance testing was out of alignment with development cycles, often taking place on the eve of the release date. As a result, the client-relationship folks were blindsided by delays as acceptance testers reported issues back to developers at the last minute. Why? It is standard at many companies to ask end-users to participate in acceptance testing, since they know their business rules better than anyone in the firm, and additionally it’s a reasonable alternative to maintaining a permanent, dedicated testing team. However, it’s not prudent to ask business folks to own the testing process, as their day jobs don’t prepare them for this responsibility, and may in fact interfere with it.

Results

Our client collaborated in our rapid, tactical effort to address gaps in project management, and the Princeton PM was able to realign the implementation with the original timeline, resulting in no overall slippage. Just as important, we gave our client a realistic path forward.

Princeton Consultants recommended long-term changes in project-management processes and enablers. The company leaders connected its existing practices to recurring problems through the neutral, objective frame of efficiency, cost savings, and customer satisfaction, and began to rigorously assess which organizational and policy changes to make.

Contact us to learn more about our project rescue services.