TTC Panel: Restart our project!
Friday, March 05 2010
With the announcement of the TTC's customer service advisory panel, I thought I would offer my own suggestion for low-cost improvements to customer service:
Restart the e-commerce project.
The e-commerce project is a simple, low-cost, high-benefit project whose main purpose is to modernize pass purchasing: customers can buy passes with a web browser or a mobile device, anytime they want. No more waiting in line at booths.
This is not even a new project: the TTC issued a competitive RFP in August of 2008 which a number of companies, including Bell, responded to. In October 2009, my company - Tiny Planet- was awarded the contract.
We lasted 21 days between getting the purchase order (the legal start point of our work) and the Commission meeting of October 29, 2009 where the e-commerce project was moved below the funding "line" along with a laundry list of other improvements, from station modernization to replacing the vehicle position-reporting system.
The list of deferred work looks like this:
(source; page 19)
That's us at the bottom of the first list, pushing the total value over $600M.
(Lest you think we're charging the Commission $800k for an e-commerce site, please note our fees are a very modest fraction of that figure. $0.8M is our fees + the TTC's costs to build their end of things, and operate it for three years. There's a mobile application in there too. All for less than half the cost of the project to install debit/credit card machines at every station.)
Customer-visible improvements aside, this project will also provide the TTC's staff with a better understanding of the realities of running an electronic payments system that can be accessed by the public. Typically, online transactions see fraud rates between 4% and 10%. Part of our job is to build up the TTC's countermeasures and institutional understanding of electronic fare payments.
So in summary, this is a project that:
- is relatively cheap.
- has already been through a competitive tender.
- provides clear customer service improvements.
- can be restarted by a Commission decision.
Why not restart it now?
The project is on hold and can be restarted until June 30, 2010, after which time it can be (will be?) cancelled.
Customer service panel: recommend this project be restarted.
TTC Commissioners: don't wait for them to recommend it.
Written by Stephen van Egmond | permalink
iPhone Tech Talks
Friday, December 04 2009
We attended the Apple-run "iPhone Tech Talks" event in Toronto. The guys there asked us not to blog about it, so I won't, but I do have some reflections from the day.
Mobile application development is a long list of trade-offs. For instance, if you want accurate positioning, you will drain the user's battery. You can sync with servers out on the Internet, but the sheer number of ways your network connection can fall apart is amazing, which means your testing burden is enormous. There really is no free lunch.
Programming for the iPhone reminds me a lot of programming for the Commodore 64, back in my very geeky youth. The environment is very restricted in terms of the amount of CPU and disk, and you can't just ignore problems like using too much memory. The operating system will warn your application, and then kill it, if you're not careful.
Essentially, if you program the iPhone like you program a desktop or web application, you'll make an application that nobody likes, that earns you either an app store rejection or a lot of negative reviews. Much of the advice from the Tech Talks boils down to: don't write your software like you own the place.
Written by Stephen van Egmond | permalink
A refreshing visit to a data centre
Wednesday, October 28 2009
There's nothing like a visit to a Internet datacenter to remind you of the realities of being a product developer.
I had to go to 151 Front to replace a blown hard drive in one of our computers, and I was thrilled to be so close to the actual, whirring, blinking, heart of the Canadian Internet.
These places are pure pragmatism: there's people and equipment out front who are very good at keeping you out; there's multiple feeds from the various utilities and Internet feeds that come in; there's power generators and giant diesel tanks and air conditioners whose cooling power is measured in tons. They laugh at your puny household BTUs.
All of this is designed to get bits from A to B, efficiently, and taking into account the fact that every single piece of electronics in that building will break or get replaced within 5 years. Except the monitors they wheel around to plug into servers to look at the console: that's a 1992-era CRT.
So much of the software industry is based on cowboyism and posturing. If you drrink the kool-aid passed around the Rails and Drupal communities, everyone is one caffeinated coding binge away from a brilliant product. Install the right gem, find the right module, get mentioned on Techcrunch. Step 3: profit! Shouldn't we take at least as much care and forethought as the hardware crew?
I'm encouraged by the work of people like Greg Wilson who want to reconnect academic Computer Science with what industry is up to, and who have something to say about the stories we're telling ourselves. Like he says: data is ones and zeroes. Software is ones and zeroes and hard work.
Written by Stephen van Egmond | permalink
Working with the TTC
Monday, October 05 2009
The Toronto Transit Commission has just announced it, so we can too: we are the winning proponents of bid #P25CE08263, "Provision of e-commerce software and services."
Our job, in brief, is to help the TTC launch an ecommerce site for the sale of passes... and perhaps anything else that might be sold electronically.
Most of our clients are startups, or small businesses, and it's going to be an interesting change to work with an organization of this size and complexity. I've met some of the people we'll be working with during the bidding process. They're energetic, smart, and committed; I couldn't ask for anything more.
Yay!
Written by Stephen van Egmond | permalink
Delicious deadline sausage
Monday, August 17 2009
I decided to write a blog post about project management in software design projects because, for the most part, it pisses me off. That isn't to say that the people who do it make me angry, or that projects shouldn't be managed or something. But far too often businesses and software developers fall into the same old myths and traps that Frederick P Brooks tried to dispel around 1970 in The Mythical Man-Month.
Designing something new is a creative process. Figuring out how something works is like that, and figuring out how something works for you is just as complex and creative. That's a good thing. Everybody likes creative solutions to problems, and that's what smart software developers are all about (like us, wink-wink).
Managing that creative process, understanding it, taming it, and making sure that essential creativity is applied to problems that matter is what project management is all about. Where Gantt charts fit into that, I have no idea, but I guarantee you they don't make software projects get delivered on time.
I'm a cranky guy, but I'm not going to just whine about problems, I'm going to tell you ways they can be solved. Here's a toolbox of a few patterns of human-human communication that we sometimes employ at Tiny Planet to make sure projects run on time, and everybody is happy. We didn't invent any of this stuff, but we use what works in a particular context.
Take the two-week tempo. Whenever possible, we like to move projects forward bit by bit, in two-week bits. At the beginning of each cycle, you decide what the goals are for that two-week interval, and at the end of it you demo what you've got. As a client undertaking an important and potentially expensive software project, this gives you control over product development by allowing you to make those critical minor adjustments in direction as they happen. As a developer, this keeps you motivated and confident that you are on the right track. Two weeks is enough to really get something done, but not long enough that you can seriously lose track along the way. Having relevant not-too-distant deadlines is a good thing because it keeps you focussed. Deadlines that are 6 months away are much harder to concentrate on, and in reality most people do a heck of a lot more work in the second half of a deadline time interval than the first half. I'm guilty of that, even though I try to stay consistent and organized all the time. When do you think I write blog posts that are due Fridays? Not Monday, that's for sure.
Some great ideas about how to manage projects have come not coincidentally from an attention to realism and what seems to be essentially an acceptance of unfortunate character traits. I think the two week tempo is like that in some ways because we have to drop the ideal notion that we can plan our time for the next six months accurately and precisely throughout a creative process. It also relates to the perspective that written specifications are always ambiguous. We need those meetings every two weeks so you can tell us if we read your specs right! It's a funny thing about language and the written word. The same words always seem to mean different things to different people. There are a few ways that people try to eliminate ambiguity from the written word. In contract law there are all kinds of seemingly circuitous phrases, paragraphs and idioms that occur over and over again, just because they are used to eliminate ambiguity in some sort of agreement between two people. If we - society - were completely successful in developing unambiguous contracts, then a judge's job would be very easy, and there would be basically no need for law suits. Sure. The other set of unambiguous languages are programming languages. These really are unambiguous in a way, but the process of specifying what you want a computer to do using this sort of unambiguous language is called "programming." Typically you have to be pretty specialized to do it. So why do software people so often write books of program designs and specifications that detail everything that a program should do? Don't ask me, I don't think it works. There's too much ambiguity in screenshots, flow charts, and descriptive text. If you want that much detail, write the code. If you're not a programmer, work closely with one so that when each individual exceptional case comes up, you're the one that provides the answer about what to do.
Get rid of those book-length specification documents and get a two-week tempo going. That doesn't mean you don't write anything down, it means you write down the very specific stuff only two weeks ahead. You write all your ideas about how things will work and interact as user-stories. If you want a web site that someone can use to play games, write that down. Write down the steps they take to do what they're trying to do. If you need to revise your business process for onboarding clients, write that down. How are they supposed to come on-board, and how do you see the computer system relating to the handoff from sales to support? What steps do the sales and support teams take? Worry about what the screens look like later, when it fits in with other parts of the system and starts to make sense, otherwise you're going to write a spec in the context of the isolated case of a specifc customer's handoff details, and it's going to be interpreted differently in the context of web-app design that considers lots of other stories too.
I'm leaving you with procrastination, short attention spans, poor communication skills. What does this have to do with answering the question "how long will that take?" True, that's kind of a big deal that needs an answer, and project managers very often have that answer. It comes off the gantt chart. I'm saying "it depends" which is always the worst answer to anything. The project manager's job is way more complex and important than just cranking a meat grinder where estimates go in one end, and the delicious sausage of a deadline comes out the other. The project manager is responsible to manage expectations, communication, and progress. He chooses the communication tools and how they'll be used, and sets up the context that makes everybody confident they know what's going on, and when to expect what.
Sometimes people ask me "when is it going to be done?" and I sure as hell want to tell them "here's what we have now, which is pretty good considering. So we need to do x,y and z and we're confident we can do that by the deadline." Kind of like "it depends" but way more confidence-inspiring than "in about two months, give or take two months."
Written by Bill Snow | permalink
» Archives
