Lexpert magazine features articles and columns on developments in legal practice management, deals and lawsuits of interest in Canada, the law and business issues of interest to legal professionals and businesses that purchase legal services.
Issue link: https://digital.carswellmedia.com/i/654294
72 LEXPERT MAGAZINE | JANUARY 2013 TECHNOLOGY | COLUMNS | compares estimates to actuals for the cost of hosting the Olympics (those statistics do exist, by the way — as well they do for IT projects and other large-scale develop- ments). e stats on the Olympics will show that over the past 50 years, the cost of the games exceeded original estimates on average by 179 per cent. So, if you are embarking on an IT (or other) project of a certain size, and you have a certain budget in mind, why not test your estimates against cases in the database be- fore retaining your supplier? e sobering feedback will be very valuable. > BITE-SIZE SUB-PROJECTS Once you've done your realistic planning, and you're ready to begin, another criti- cal factor for risk mitigation comes into play — breaking down the big project into smaller, bite-size chunks. It's important to have defined, measurable gates at the end of each sub-project, where you must asses your level of comfort with the degree of progress achieved, before the work can pro- ceed to the next stage. You don't want to micromanage the work, but you absolutely must know that value is being created on time, and on bud- get. erefore, you have to be very much on top of what is going on, and whether suf- ficient value is being created. Ensure that, collectively, the team has common successes that they can celebrate together. I think the true recipe for steady progress on big projects is the cumulative collection of small successes. > PEOPLE MATTER Not surprisingly, another critical factor in the success (or failure) of a major IT proj- ect is whether that project has been staffed with bright folks who also have deep, rel- evant experience in exactly what you are planning to do. is is not a time for learn- ing on the job. You need a proven, experi- enced veteran — someone who has done it before (and multiple times). Once you have these people in place, you need to make sure they don't leave you until the project is done. A clause to this effect in your agreement with your supplier can be immeasurably helpful here. You really want to avoid the scenario where the su- perstar initially assigned to your project is shuffled a few months later to another proj- ect by the supplier. Continuity is key. > HIGH-PERFORMANCE TEAMS Getting great people working on your proj- ect isn't enough, though. You have to also get these incredibly smart folks to work as a high- performance team. ese initiatives are so complex nowadays, with so many working parts, that no one individual can do it all — or even oversee it all. Stel- lar group behaviour is nec- essary. And, in particular, you have to bring together the IT people and the busi- ness people into one func- tional family. To this end, best-practice techniques for group communication, such as newsletters and desktop group calendaring, can help immensely. ese sorts of tools remind us that "none of us is as smart and effective as all of us," which is a central tenet of the suc- cessful IT project. > YOU NEED A PLAN It is astounding how many IT projects begin without a detailed plan. You would never allow a contractor to start building a house before the architect delivered the blueprints. Yet, this happens all the time in the IT world — and typically with dev- astating consequences. Is there going to be a washroom on the second floor of your house? e equivalent questions needs to be asked and answered before you start building soware code. Skip this step at your own peril. Be wary of suppliers who say that the particular base soware doesn't need a plan in order to be modified — all you have to do is start working with it and it just modifies itself. is approach has resulted in many disappointments. So, I repeat, you need to understand what the specifications for the new system are before you start building it. > QUALITY CONTROL As the deliverables begin to be created, you have to test them. And then test some more. And then test some more (you see where this is going). Moreover, on a project of any size, it's wise to have another supplier do the test- ing. Having the same supplier who built the deliverable also test it is like sending the lettuce to market with the rabbit. You need someone independent, who will assert a vigorous quality control on the work effort of the developer. Rigour is required here. > MANY SMALLER DELIVERABLES e final lesson is to break down the deliv- erables into multiple, smaller components. Of course, at some point you will want to test them all together in one great big in- tegration test. But initially you want work- able and easily testable constituent parts so you can get a handle on the quality of what is being produced, and whether it truly meets the original specifications. To use an analogy, if the building blocks aren't placed correctly, there's no reason to expect that the house will turn out all right. Get the components right, and the odds of success increase dramatically and you stand a much better chance of avoiding mention as another failed project in the Oxford study's 2013 report. YOU NEED to reassess the original goals. Is the business case still there? Sometimes the answer is no. But this conclusion is often ignored, so the project proceeds on its blissfully and ignorantly fatal course George Takach is a senior partner at McCarthy Tétrault LLP, the author of Computer Law, and an Adjunct Professor in Computer Law at Osgoode Hall Law School.