TTC = Toronto Transit Corporation. CDP = Convergent Design Principles. It’s really about understanding requirements and projects.
In my time at IBM Canada, and to a lesser extent at CIBC, I took many courses. Artificial Intelligence. Dealing with Difficult People. And pretty much everything in between. I have all the notes from the good and better courses here in my writing room. I just looked up the notes from the CDP course and confirmed: it was extremely insightful and has general relevance to getting things done: requirements and projects.
One exercise I remember: we were sitting in tables of six. We were told we were going to work on a communications device. We were told to estimate the weight of the device, write it down on a piece of paper, circle the number and initial the circle. Independently.
Then each table was asked to compare numbers (weights) and give the ratio of the highest to the lowest. One estimate at my table was roughly a metric ton; another was a few grams. A communication satellite versus a telephone bug.
When the ratio is extremely large, you don’t know what you’re talking about. As the ratio got better (we were given extra information, a bit at a time) we were going from a marketing dream to a crude design to a decent device definition. Meaningful requirements.
The TTC makes a practice of ignoring numbers. Ridership. We have the Union Pearson Express (UPX) which is losing taxpayer money even faster after the fair cut. We have the Sheppard Stubway which cost a billion dollars and runs specially shortened trains, which are empty. We are going to build a subway to Scarborough with one stop and ridership numbers that don’t justify anything. The light rail alternative with seven or more stops would have had higher ridership and been well within carrying capacity.
City council recently, apparently, refused to consider ridership projections in selecting projects and project details.
The CDP course listed a number of requirements to make a Requirements document real. Convergence of estimates: cost, time, ridership. And, interestingly enough, test cases. How will we know we are on time, on schedule, and have ridership correct? How will we check the stations for accessibility? How will we rate our choices of station location? How will we rate our approach to getting the tunneling done (expropriation of a dozen homes versus an easy relocation of the starting points?)
One thing city projects never do is this: assign a person to follow the project who will, on completion, document how the benefits (of the project) were reaped. This person will noisily complain to everyone if those benefits are being jeopardized by project decisions. (If this had been in place, the Scarborough subway would instead be light rail, paid for, and in operation now. Instead we still have a dumb debate likely to waste over four billion dollars.) Project decisions are often political, and they should not be. If they are, the benefits are meant to get election results, not civic results.
Toronto is not unique in not creating a ‘reap the benefits’ czar for each project. I explained the value of such a czar to an IBM Marketing Rep and he could not make himself grasp the concept. He said I was confusing Sell with Install.
That’s the problem with political decisions. We are sold up to the election, and what then gets installed may be quite different. Donald Trump is going to clean up the swamp in the USA by appointing the owners and operators of that swamp to positions of political power. John Tory is going to build SmartTrack (whatever that is) but has no way to fund it. (The road toll will not raise much of the billions we need, and even that may be cut. Other staff-recommended revenue tools were allowed to be shot down in city council.)
So we continue to build (actually delay building) transit in Toronto in a process that is not informed by real numbers but rather by hoped-for votes.
Dumb question? Is that cynical enough? Will you do anything about it?