Finishing the final yard

For many years athletes have used trainers for two distinct purposes: get fit and better at what they wish to excel in; and then to build the fortitude needed to push through the knurly stuff on the way to the top. Really good trainers are particularly successful at this later skill. Their trainees tend to be able to compete with the best, but then pull ahead when the going gets tough, not through any better skill or technique in the sport, but in being able to set a square jaw and tough out the bad bits, not let off the pressure, inch forward.

What does this have to do with techies, you may ask? Well, having been through the meat grinder of many projects, quite a few of which eventually allowed companies to generate billions of dollars in revenues, I have observed that the successful projects, the ones that really earn the money, tend to get built in spite of the opposing forces, not through technical brilliance, but through force of personality.

Getting any none trivial project to completion requires the coming together of many things. There must be adequate management support, competent project management (though not necessarily by the project managers), steady technical progress, development inertia (yes, inertia keeping the plot moving in a straight line), and finally that "till the fat lady sings" type of devotion to an ending.

This doesn’t take into consideration projects like the F-22 fighter software, which is a gargantuan multi-year effort, with thousands of developers, managers, and testers. No, the average business project that takes 4 or 5 developers 6 months to a year to complete, is the bread and butter of computing. I have been on larger projects (30 – 100 people) but none of them ever produced more than the smaller teams achieved, and generally the smaller teams produced more, faster, and with better reliability than the larger teams. In my time at Conoco, we produced new routers every 9 to 12 months, with a team of 3. At IBM we produced new routers every 2 to 3 years with a team of 50. At Conoco those routers cost about $2000 each in parts; at IBM they cost $4000 each in parts… pretty much the same parts. During my time at a publishing house, I was involved in getting one of 3 pieces of strategic software into service. One piece never got built. One piece, a sales reporting tool, was built by about 30 developers working 2 years, and ended up being used by 2 people. Lastly my software, an order entry system, took 3 developers 10 months, was used by 90 people and handled a quarter of the companies sales (over $¼ billion.) Why do some projects fail to deliver the goods, when clearly they have all the right ingredients?

In American football, a great many games falter right in front of the goal line. The very real last yard: the most players possible are squeezed into the smallest space possible, half are pushing forward, half pushing back. The ability to finish and score points is established by the team that produces the most muscle, or decides to go round the problem rather than through it. So go many software projects. They get written, but they somehow fail that last yard. They falter as they are to be rolled out.

If you can’t stand the heat, get out of the kitchen. Old saying. What if software projects acquire some sort of ephemeral friction. The closer they get to the end the more the friction builds up, the hotter things get, the tougher the times. The development team must bear through all this. It has to put up with the last minute changes, the sudden time line alterations, defections to other projects, failed personnel that leave at critical times, and all manner of types of issues that are not of a technical nature. This last yard is so beset with traps and issues, many people just buckle ceasing to put in the effort needed by the project to progress, and increasing that friction. The stress is as much as anyone could ever wish for. It paralyses many with a loathing of the job that quickly saps their strength.

It is exactly this final yard where those top athletic trainers have aimed so much of their training and psychological efforts. They know, either by experience (hopefully), or by reading books (hope not), that there are problems to be surmounted as the battle draws to a close, when limbs are weary, brains befuddled, and hope drained. They know that they have to engender in the athlete a presence that allows these tribulations to be accounted for, to be diminished and to be conquered. Only by getting to the next step does the athlete have a chance to get to the finish, there to show the real athletic skill they have, and hopefully win.

Technology teams have had the use of technical consultants for many years, but these consultants are often brought in at the start for very specific technical needs, like telling people how to turn on their computers, or how to make Ariba talk to eBay so they can sell more junk. In general however, technology teams never seem to get the training needed to finish the job.

At the end of a project, a huge amount of human capital has been expended by the team. That capital is now the software, or a grand system that encompasses lots of software. It has a lot of the personal traits of the people that wrote it. For better or worse, these people feel for their software. It is a very hard thing to distance yourself from the code you have written, the system you designed, or the system you tested to completion. At a time when you are meant to be pushing it into users hands, you need to be emotive to any complains or issues, never taking knocks personally. For too many developers it’s not something they can do. The stress of seeing their creation ripped by various external people or even broken by external stimuli that were not envisioned when the project started, can be more than these people can cope with without recourse to support. In large ponderous teams, maybe that support comes from other people that have already failed and say things like, "Never mind, they’re starting a project in a new group next month, just hang in there and we can flea this sinking ship." Maybe it comes from the people leading, saying things like "It’s good, it just needs a little more, ignore those comments, that idiot wouldn’t know a working program from a hole in his head." In small teams though, there is less latitude for swings in either direction, and a lose of confidence in one member can terminally impact a project, to the detriment of all.

Unfortunately, trainers are of little use at the end of a project. There are too many knife edge issues to have a trainer come in and try and straighten out your head. A trainers time has to be in the preamble to the project. They have to be there at project inception, looking at each persons approach and trying to steer and build into those people the understanding of where their weaknesses lie, their strengths, where they need to be aware they can lose control or exhibit too much control. The training needs to build the confidence of the team, then add the perseverance that will be needed to get a hard project 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 team trainer. Sometimes the team will be composed of tough-as-nails old cronies, that would not listen to such advice, after all they invented the book on project issues anyway! But for newer people in IT, and for fledgling teams, such trainers might be of great benefit.

We always talk of doing post mortems on projects. Those projects that work, and are completed, tend to have the most cursory post mortems. The projects that fail, well, they tend never to have post mortems, nobody wants to get to the horrible mess at the heart of its failure. Using trainers at the outset, could lead to team members having a desire to do these post mortems. Learning from them, add what the trainers have given them, add what their experience has shown them, and go on to give the next project another successful completion.