I’ve had the pleasure and privilege of having worked on a number of very different projects, for a diverse array of clients, using different processes and methodologies every time. I’ve seen projects that delight the client and exceed every expectation, and projects that failed to live up to every promise. And I think I’ve discovered a common thread – a thread runs throughout all the successful projects, and is largely lacking in the projects that fail to deliver on every expectation.
Software projects are among most complex things mankind has ever built, and most of us rely on software to perform critical functions in our lives. Businesses and governments rely on software to such an extent that they would be crippled if it suddenly stopped working. Software is also very, very expensive to build. And yet, as an industry we often act as if we have no idea of how to structure a software project that stands a good chance of succeeding.
In my opinion, the single best predictor of success or failure in a software project is the presence or absence of humanity. Humanity, then is: the extent to which the project team engages, connects with, and supports one another for the shared purpose of creating the best possible solution to the project at hand.
All too often we structure our software projects in such a way to make it nearly impossible for the people on the project to communicate effectively with one another. We do this through a number of insidious techniques:
- Separating members of the team, often placing them on separate continents. When people are physically separated, communication and understanding suffer. Throw in time-zone differences and language and cultural barriers, and you compound the problem.
- An over-reliance on documentation. This, I believe, hearkens back to the old days of computer science when people thought of programming in the same way they thought of engineering – in primarily technical terms. “Analysts” would produce reams and reams of documentation in a “specification”, which the programmers would then convert into code. This approach probably worked well back then, and is still the way to go if you’re designing a space shuttle or a microwave oven, but modern software has a human element that documentation just can’t handle. The old way doesn’t work anymore.
- Resistance to change. Many software projects are religiously schedule-driven, and change represents threat, so it must be beaten back. On projects like this, innovation and new ideas are subordinate to the Almighty Schedule, even if they lead to more value to the customer. So the innovation is disregarded, or renegotiated into a “change request”(meaning more paperwork), lest the status KPIs turn yellow.
But it doesn’t have to be like this. Most software teams have the capability to produce innovative, high-quality products. But what’s often lacking is a culture conducive to such innovation. What’s needed is a culture that values interaction and cooperation as its highest virtue. What we need is humanity.
And by the way, I say “culture” rather than “process”, because a process is merely a set of guidelines to follow, whereas a culture lives in the hearts and minds of its members. In other words, it is an internal, rather than an external, focus.
In Part 2 of this post, I’ll discuss two examples of how a lack of humanity can produce disastrous results on a software project, the first from a user’s point of view and the second from a developer’s point of view.