Sometimes it's better to let the train pass you by
- Sometimes it's better to let the train pass you by ***
There are thousands of "bits of wisdom" out there about how to make a software project successful. All of us have read them or seen presentations. As Architects we review them from time-to-time and gloss over the truth in them. None of them work in all cases. But all of them have value in gaining experience and confidence as an Architect.
What is not found is solid recommendations as to what constitutes a software project doomed to fail. After all, one person's failure might be another person's success, right? What we find much more often are statistics. Some sample numbers might say that 70% of agile projects succeed, 60% of traditional projects succeed, and 50% of offshore projects succeed. That leaves a lot of projects that did not succeed with very little documented to help us learn from them.
The main reason there is a lack of direction concerning how to identify a doomed project is because the traits are rarely the same in more than one case. Any attempt to identify a list that could be expected to exist which definitively doom a project is an attempt in vain. There exists a universal lack of consistency in defining what exactly constitutes a failed project. Sometimes a project must fail in order for its successor to succeed. Sometimes the actual status of a project does not depend on "success" as we know it but on some other arbitrary set of goals as defined by a team of leaders and filtered when communicated. Due to the nature of our responsibilities as Architects we are usually in the best position to determine that a software project is likely to fail.
As an Architect you will do justice to yourself and those you work with to consider how you would handle given situations well in advance. All you can count on in your planning is that a decision to act will likely be a hard decision to make and any actions taken will are likely to be met with resistance.
We all have our own motivation for doing what we do. For some it's the challenge of building things that work. For some it's money. For some it's simply that we can, so we do. For others it's a combination of these things and others. Regardless of the motivation, as an Architect you will one day be placed in the unenviable position of deciding if you care to watch the ship sink and decide if you will swim, row, steer or simply pass out life-jackets.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page