Lessons from the Bluenose II

Regular readers of this space will know that from time to time I discuss IT development projects that go way over budget and extend well beyond the original scheduled completion date. You would think that by 2015 this wouldn’t happen frequently — that by now the tech industry would have figured out how to do these projects better. You would think that, but you would be wrong. ...
Lessons from the Bluenose II
George Takach, McCarthy Tétrault LLP

Regular readers of this space will know that from time to time I discuss IT development projects that go way over budget and extend well beyond the original scheduled completion date. You would think that by 2015 this wouldn’t happen frequently that by now the tech industry would have figured out how to do these projects better. You would think that, but you would be wrong.

Recently, this sort of disaster befell the project to restore the Bluenose II, the iconic racing ship whose image graces our country’s 10-cent coin. While not an
IT transaction, so much of what went wrong in this project has parallels in the IT world that it’s worth highlighting and learning from. The unfortunate details of what went wrong are set out at some length in a recently published report of the Nova Scotia Auditor General (NSAG).

Essentially, if you’re involved in large
IT deals, or are about to be, you should read this NSAG report cover to cover and share it with your colleagues. Herewith, the highlights of the findings, and a brief commentary on their application to IT projects.

> Selecting the Team
The first in a long series of mistakes was the decision to put the ship’s restoration in the hands of the Nova Scotia Department of Communities, Culture and Heritage (DCCH), which operated the Bluenose II as a sailing ambassador and as part of an important historic site. Bottom line, the DCCH didn’t have the required in-house expertise in project management, or construction projects in general.

Surprisingly, this happens a lot in
IT deals as well. A specific operating business unit within your organization needs a major new technology platform. But when they go to market, they don’t involve the IT department, the procurement group, or in-house or external legal counsel until some very basic mistakes have already been made. So, important lesson get the right expertise in the room as you begin your endeavour.

Another big early mistake was that the government agency in question retained a project manager and a construction company (which actually performed the restoration on the ship) before a solid set of specifications for the project were developed. In layperson’s terms, and using a different analogy, the construction company was chosen before it was known whether the building to be erected was going to be a two-storey residential house, or a five-storey commercial condominium.

Again, there is a direct analog in the information technology sector. Any number of
IT system integration firms are out there ready to take on new work, but only a few truly have expertise in particular software platforms. An important part of your due diligence is to make sure the firm you select really does do a lot of the specific work that you need done.

> Mitigating Risks
One best practice in the IT world today – and in many other industries – is to make sure that, at the beginning of the project, you consciously put your mind to the coming risks associated with your ambitious endeavour, and then actively plan some mitigation strategies for addressing these risks should they arise. And of course, by doing this, you often revise your own project plans accordingly, in order to avoid the risk surfacing altogether.

Nova Scotia’s auditor general found that such risk management was lacking in the Bluenose II restoration project
with the result that, when the restoration exercise hit bumps in the road, the whole effort was thrown significantly off course.

> Managing Financial Expectations
In a similar vein, the financial planning and estimation around the project was given very little thought. Indeed, a preliminary cost estimate was ultimately used as the budget. Partly this was done to quickly commence the project in order to take advantage of a federal infrastructure program offering matching funds.

This, including the hurried nature of the planning work to be able to access the federal funds, was a recipe for disaster. When we see this sort of behaviour in the IT space, the resulting misalignment of financial expectations sometimes leads several senior members of the customer’s team – often including the chief information officer – to lose their jobs. The all too typical scenario is that the business unit – and the CIO – originally tell the CEO that the project will cost X, but many months later, when it finally comes in at Y (often a three- or four-times multiple of X), the CEO and the board are aghast. Soon thereafter the CIO is out on the street looking for another job.

In the case of the Bluenose II, this problem was exacerbated because the contract contained no financial disciplines on the service provider. Moreover, rather than present the service provider with a general breach-of-contract claim when it became clear the service provider could not perform their end of the deal in a timely manner, the delivery dates in the contract were routinely allowed to be extended. Hey, if you’re not going to apply strict rules to the performance of the contract, then don’t expect the service provider to complain
or to perform on time and on budget.

In order to obtain matching federal government funds for the project,
DCCH had to comply with Ottawa’s deadline that the restoration be complete by March 31, 2011 (the project was announced some two years earlier). Ironically, a further “cost” of this federal money was that an unrealistic completion date was announced, again all with a view to meeting the federal funding rules and not because the date was appropriate for the project.

Then, adding insult to injury, the delays due to the poor planning (caused in turn by the rush to meet the government deadline) ultimately resulted in the
DCCH only receiving $4.9 million from Ottawa, rather than the $7.2 million they hoped to receive. What a disaster.

> Managing Many Moving Parts
It is the rare major IT project today that has you dealing with only one supplier. The reality is what we call the “multi-vendor environment.” Lots of different players are involved in the project, because of the need for multiple skill sets. But at the end of the day someone needs to get everyone in the sandbox to play well together or, to use a different metaphor, you need a conductor that can get all the players in the orchestra to perform well together.

Sadly, this was lacking in the Bluenose
II case, notwithstanding that it was a very complex multi-supplier/multi-stakeholder environment: there was the DCCH, the builder, the designer, the project manager, different regulatory bodies and some project committees. And you guessed it the DCCH was unable to get all these disparate entities to work together effectively.

As well,
DCCH neglected to define the various roles of all the different participants; for example, none of the committees had specific terms of reference. This often happens in IT deals as well, where there are multiple suppliers. “Hey, I’m the hardware fellow. I wasn’t supposed to buy the database software.” “Hey, I’m the application fellow, but the customer has to get the database software.” “Hey, I’m the customer, but I didn’t even know the database software was required.” And so it goes.

In
IT deal shorthand, we call this the “finger pointing” exercise. In the Bluenose II case, for example, the designer of the restoration and the builder (who would actually carry out the restoration work) had a major falling out over the quality of the blueprints. The designer, who prepared the drawings, said they complied with the requirements of the design contract; but the builder argued they were inadequate for the needs of the builder. This is a classic case of finger pointing. Again, what a mess.

Moreover, the lack of effective project-management practices stood out like a sore thumb. First, there was no comprehensive, overall, integrated project plan, against which all the players could schedule and coordinate their activity. Second, the project manager failed to attend certain meetings
it’s actually pretty hard for a conductor to impose discipline on the orchestra if the conductor doesn’t attend the rehearsals! And third, status reports were intermittent how do you know how the project’s going if the progress (or lack thereof) is not suitably tracked.

While these all sound like rookie mistakes, it never ceases to amaze me how many large
IT projects suffer from an absence of these disciplines. Perhaps not all of these deficiencies crop up on the same project, as was the case with the Bluenose II debacle, but enough of them do to significantly impact the budget and schedule for implementation.

> The Usefulness of Lessons
At the end of the summary to its report, the NSAG concludes: “Government needs to exercise leadership and take away some important lessons from this project to ensure mistakes are not repeated on significant construction projects in the future. If the government fails to act upon these lessons learned, it may be doomed to repeat the same poor performance in the future.”

This is good advice, whether you’re restoring a sailing ship, or implementing a new technology platform. Our parents used to say, “You should learn from your own mistakes,” which is a very painful form of pedagogy. It’s far better, and hurts a lot less, to learn from the mistakes of others. Which is why the
NSAG report makes for such important reading and study.

George Takach is a senior partner at McCarthy Tétrault LLP and the author of Computer Law.