In the early 1800s one-quarter of all bridges fell down. Today, however, most of them stay up.
In 1998, 28 per cent of all software projects failed – coming in 100 per cent over time, over budget or cancelled outright. This means, said Brian G. Rice, that in a few hundred years companies should be able to ship software on time.
But for those who need to ship software a little sooner than that, Rice, a C# developer, .NET architect and president of the Vancouver-based Entier Solutions Inc., had a few tips for getting good software out the door. The project management strategies that Rice outlined at a Comdex 2002 seminar in Toronto were anchored in the Microsoft Solution Framework (MSF) and focussed on team roles, communication, risk management and trying not to lie to the customer.
Speaking throughout with the zeal and humour of a revival-tent orator, Rice said that the first step to building an effective team is flattening communications. Since everyone can have useful, important ideas, let the interns, architects and managers all talk to each other as equals. But no titles doesn’t mean chaos, he added. Instead the MSF identifies six project roles that need to be filled: product management, program management, development, user education, logistics and testing.
“There could be as few as three people doubling up to cover the six roles, or hundreds doing some of them. But every team role should be covered from day one of the project,” Rice said.
In the past, product management and program management were often one job, but both require full-time people, Rice said. The product manager is the team advocate to the customer and customer advocate to the team. This job is about communicating with the customer – most often a president or senior executive – in business terms, then turning around and “speaking geek” back to the team. Meanwhile, the program manager’s role is to instill discipline and keep the code on track, he said.
Other than suggesting the testers and developers work side by side, Rice’s main coding tip was to leave the developers alone as much as possible. “The great developers – when you can get ’em to shower – are amazing at just that. Don’t make them do anything else. Keep the customer away from them, keep layoff talk away from them, and don’t burden them with hourly status reports,” he said.
Seminar attendee Bogdan Jedrzejewski, a senior software engineer with i2b Global Inc. in Hamilton, Ont., agreed that non-techies often don’t realize how much creativity is involved in coding. In fact, he said, when you consider the way true developers work, always turning over a problem in their mind at any hour of the day, their wages probably work out to about $10 per hour. But the moments of near-euphoria when things are going well make it worthwhile, Jedrzejewski added.
Once a team is established they need to adopt a shared vision of the project, Rice said. In his experience any attributes displayed by the team – negative or positive – will show up in the product. “So if you’re having problems with your software, fix the team.”
The next step is developing a “product mindset,” or treating any project as if it were a shrink-wrapped box that needs to be put on a truck and shipped, Rice said. “I consulted with a guy at a transportation company in B.C. who’d been on the same project for 20 years. There was no end. He just rolled out incremental fixes. He’s the most miserable person I know – he’s never even had a shipping party.”
This is why he recommends defining incremental ship dates of three or four months, built around a message more than a specific set of features. “Then you get it out the door, have a party, then start version two the next day,” he said.
Although customers may be misinformed or even a little slow on the uptake, they may have put their jobs and reputations on the line for this project and they need to be respected, Rice said. Customers need to be managed, and almost certainly educated, but respected and never lied to – even if they want you to lie to them, he added.
“Never give a ship date you don’t understand, if you don’t know when it’s going to be done don’t say you do and don’t ever pre-announce a product,’ he said.
Of course standing up to the customer is easier said than done, said Mark Sniatkiewicz, a Toronto-based application developer. In a perfect world this plan would be ideal, but it is difficult to say no to a customer and his money, especially given IT’s culture of constantly increasing expectations, he said.
Like Jedrzejewski, Rice and – according to a show of hands – every other developer present, Sniatkiewicz has seen his share of troubled projects. He fully agreed with Rice that these almost always seem to come down to communication problems between customers, developers and management.
Rice said it’s also essential to initiate risk management. “You don’t have (bricks and mortar) architects say ‘Fire? That’ll never happen,'” he said. Of course, knowing what might go wrong is the first step to preventing it, but not the only step, he added.
“I worked on one project where we had a list of hundreds of things that could go wrong – and about two-thirds of them did – but we had no contingency plan in place. So we just ticked each problem off our list as it happened, and said ‘Well, we saw that one coming too,’ and watched the project slide further behind,” he said.
The bottom line, Rice said, is that architecture is just the consistent application of process to a problem, and when it come right down to it, any problem can be solved with good process. Changing an organization is hard, he said, and it can take years, but if companies develop a shared vision of change, and take baby steps, eventually everyone will forget to fight you on the new processes.
