Finishing the final yard

For many years athletes have used trainers fortwo distinct purposes: get fit and better at whatthey wish to excel in; and then to build thefortitude needed to push through the knurly stuffon the way to the top. Really good trainers areparticularly successful at this later skill. Theirtrainees tend to be able to compete with the best,but then pull ahead when the going gets tough, notthrough any better skill or technique in thesport, but in being able to set a square jaw andtough out the bad bits, not let off the pressure,inch forward.

What does this have to do with techies, you mayask? Well, having been through the meat grinder ofmany projects, quite a few of which eventuallyallowed companies to generate billions of dollarsin revenues, I have observed that the successfulprojects, the ones that really earn the money,tend to get built in spite of the opposing forces,not through technical brilliance, but throughforce of personality.

Getting any none trivial project to completionrequires the coming together of many things. Theremust be adequate management support, competentproject management (though not necessarily by theproject managers), steady technical progress,development inertia (yes, inertia keeping the plotmoving in a straight line), and finally that "tillthe fat lady sings" type of devotion to an ending.

This doesn’t take into consideration projectslike the F-22 fighter software, which is agargantuan multi-year effort, with thousands ofdevelopers, managers, and testers. No, the averagebusiness project that takes 4 or 5 developers 6months to a year to complete, is the bread andbutter of computing. I have been on largerprojects (30 – 100 people) but none of them everproduced more than the smaller teams achieved, andgenerally the smaller teams produced more, faster,and with better reliability than the larger teams.In my time at Conoco, we produced new routersevery 9 to 12 months, with a team of 3. At IBM weproduced new routers every 2 to 3 years with ateam of 50. At Conoco those routers cost about$2000 each in parts; at IBM they cost $4000 eachin parts… pretty much the same parts. During mytime at a publishing house, I was involved ingetting one of 3 pieces of strategic software intoservice. One piece never got built. One piece, asales reporting tool, was built by about 30developers working 2 years, and ended up beingused by 2 people. Lastly my software, an orderentry system, took 3 developers 10 months, wasused by 90 people and handled a quarter of thecompanies sales (over $¼ billion.) Why do someprojects fail to deliver the goods, when clearlythey have all the right ingredients?

In American football, a great many games falterright in front of the goal line. The very reallast yard: the most players possible are squeezedinto the smallest space possible, half are pushingforward, half pushing back. The ability to finishand score points is established by the team thatproduces the most muscle, or decides to go roundthe problem rather than through it. So go manysoftware projects. They get written, but theysomehow fail that last yard. They falter as theyare to be rolled out.

If you can’t stand the heat, get out of thekitchen. Old saying. What if software projectsacquire some sort of ephemeral friction. Thecloser they get to the end the more the frictionbuilds up, the hotter things get, the tougher thetimes. The development team must bear through allthis. It has to put up with the last minutechanges, the sudden time line alterations,defections to other projects, failed personnelthat leave at critical times, and all manner of types of issues that are not of a technicalnature. This last yard is so beset with traps andissues, many people just buckle ceasing to putin the effort needed by the project to progress,and increasing that friction. The stress is asmuch as anyone could ever wish for. It paralysesmany with a loathing of the job that quickly sapstheir strength.

It is exactly this final yard where those topathletic trainers have aimed so much of theirtraining and psychological efforts. They know,either by experience (hopefully), or by readingbooks (hope not), that there are problems to besurmounted as the battle draws to a close, whenlimbs are weary, brains befuddled, and hope drained. They know that they have toengender in the athlete a presence that allowsthese tribulations to be accounted for, to bediminished and to be conquered. Only by getting tothe next step does the athlete have a chance toget to the finish, there to show the real athleticskill they have, and hopefully win.

Technology teams have had the use of technicalconsultants for many years, but these consultantsare often brought in at the start for veryspecific technical needs, like telling people howto turn on their computers, or how to make Aribatalk to eBay so they can sell more junk. Ingeneral however, technology teams never seem toget the training needed to finish the job.

At the end of a project, a huge amount of humancapital has been expended by the team. Thatcapital is now the software, or a grand systemthat encompasses lots of software. It has a lot ofthe personal traits of the people that wrote it.For better or worse, these people feel fortheir software. It is a very hard thingto distance yourself from the code you havewritten, the system you designed, or the systemyou tested to completion. At a time when you aremeant to be pushing it into users hands, you needto be emotive to any complains or issues, nevertaking knocks personally. For too many developersit’s not something they can do. The stress ofseeing their creation ripped by various externalpeople or even broken by external stimuli thatwere not envisioned when the project started, canbe more than these people can cope with withoutrecourse to support. In large ponderous teams,maybe that support comes from other people thathave already failed and say things like, "Nevermind, they’re starting a project in a new groupnext month, just hang in there and we can fleathis sinking ship." Maybe it comes from the peopleleading, saying things like "It’s good, it justneeds a little more, ignore those comments, thatidiot wouldn’t know a working program from a holein his head." In small teams though, there isless latitude for swings in either direction, anda lose of confidence in one member can terminallyimpact a project, to the detriment of all.

Unfortunately, trainers are of little use atthe end of a project. There are too many knifeedge issues to have a trainer come in and try andstraighten out your head. A trainers time has tobe in the preamble to the project. They have to bethere at project inception, looking at eachpersons approach and trying to steer and buildinto those people the understanding of where theirweaknesses lie, their strengths, wherethey need to be aware they can lose control orexhibit too much control. The training needsto build the confidence of the team, then add theperseverance that will be needed to get a hardproject through to completion. Giving example,after example, after example.

Of course, not all projects have bad weather,sometimes there will be no need for a teamtrainer. Sometimes the team will be composed oftough-as-nails old cronies, that would not listento such advice, after all they invented the bookon project issues anyway! But for newer people inIT, and for fledgling teams, such trainers mightbe of great benefit.

We always talk of doing post mortems onprojects. Those projects that work, and arecompleted, tend to have the most cursory postmortems. The projects that fail, well, they tendnever to have post mortems, nobody wants to getto the horrible mess at the heart of its failure.Using trainers at the outset, could lead to teammembers having a desire to do these post mortems.Learning from them, add what the trainers havegiven them, add what their experience has shownthem, and go on to give the next project anothersuccessful completion.