Contribution 25

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(New page: == 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 ...)
Current revision (10:25, 15 July 2008) (edit) (undo)
(Sometimes it's better to let the train pass you by)
 
(One intermediate revision not shown.)
Line 1: Line 1:
== Sometimes it's better to let the train pass you by ==
== 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.
-
There are thousands of "bits of wisdom" out there about how to make a software project successful. All of us have read them or often heard them discussed. As Architects we review them from time-to-time and gloss over the truth in them.
+
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.
-
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?
+
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. There exists a universal lack of consistency in defining those things that constitute 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. 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.
-
One reason for the lack of direction concerning identifying a doomed project is that the traits differ widely due to many different factors. Any attempt to identify a list of these that could be expected to exist in all cases is an attempt in vain. Due to the nature of our responsibilities as Architects we usually sit in the best position to determine that a software project is doomed.
+
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 meet 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 un-enviable position of deciding if you care to watch the ship sink.
+
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.
-
More to come....
+
By [[Norman Carnovale]]
 +
 
 +
This work is licensed under a
 +
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
 +
 
 +
Back to [[97 Things Every Software Architect Should Know]] home page

Current revision

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. There exists a universal lack of consistency in defining those things that constitute 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. 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 meet 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.

By Norman Carnovale

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools