<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_07_15_1255258</id>
	<title>Why New Systems Fail</title>
	<author>samzenpus</author>
	<datestamp>1247683620000</datestamp>
	<htmltext><a href="http://bfwa.com/" rel="nofollow">bfwebster</a> writes <i>"Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, <em>Why New Systems Fail</em>, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level, customizable, off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon's book is not only useful, it is important."</i> Read on for the rest of Bruce's thoughts on this book.</htmltext>
<tokenext>bfwebster writes " Over the last forty years , a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print .
The authors are well known , or should be : Gerry Weinberg , Fred Brooks , Ed Yourdon , Capers Jones , Stephen Flowers , Robert Glass , Tom DeMarco , Tim Lister , Steve McConnell , Steve Maguire , and so on .
These books all focus largely on projects where actual software development is going on .
A new book by Phil Simon , Why New Systems Fail , is likewise a risks-and-pitfalls book , but Simon covers largely uncharted territory for the genre : selection and implementation of enterprise-level , customizable , off-the-shelf ( COTS ) software packages , such as accounting systems , human resource systems , and enterprise resource planning ( ERP ) software .
As such , Simon 's book is not only useful , it is important .
" Read on for the rest of Bruce 's thoughts on this book .</tokentext>
<sentencetext>bfwebster writes "Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print.
The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on.
These books all focus largely on projects where actual software development is going on.
A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level, customizable, off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software.
As such, Simon's book is not only useful, it is important.
" Read on for the rest of Bruce's thoughts on this book.</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615</id>
	<title>Didn't need a book to know this</title>
	<author>Em Emalb</author>
	<datestamp>1247687580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>Not trying to be a jerk (hah, stupid buttface!) but the reason most new "systems" fail is for one of 4 reasons:</p><p>1) the decision maker(s) not understanding the actual requirements thereby causing a situation where they end up with a system that doesn't fit their needs</p><p>2) the third party or in-house developers not understanding the actual requirements thereby causing a situation where the system they've created either doesn't work or doesn't work as it should</p><p>3) the new system is too complicated/buggy/worthless and the end users of the system refuse to use it and/or complain constantly (I HATE CHANGE!)</p><p>4) all of the above.</p><p>There are more, but those are the big 3.</p></htmltext>
<tokenext>Not trying to be a jerk ( hah , stupid buttface !
) but the reason most new " systems " fail is for one of 4 reasons : 1 ) the decision maker ( s ) not understanding the actual requirements thereby causing a situation where they end up with a system that does n't fit their needs2 ) the third party or in-house developers not understanding the actual requirements thereby causing a situation where the system they 've created either does n't work or does n't work as it should3 ) the new system is too complicated/buggy/worthless and the end users of the system refuse to use it and/or complain constantly ( I HATE CHANGE !
) 4 ) all of the above.There are more , but those are the big 3 .</tokentext>
<sentencetext>Not trying to be a jerk (hah, stupid buttface!
) but the reason most new "systems" fail is for one of 4 reasons:1) the decision maker(s) not understanding the actual requirements thereby causing a situation where they end up with a system that doesn't fit their needs2) the third party or in-house developers not understanding the actual requirements thereby causing a situation where the system they've created either doesn't work or doesn't work as it should3) the new system is too complicated/buggy/worthless and the end users of the system refuse to use it and/or complain constantly (I HATE CHANGE!
)4) all of the above.There are more, but those are the big 3.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28714795</id>
	<title>Re:A better book would be "How New Systems Succeed</title>
	<author>some-old-geek</author>
	<datestamp>1247748480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>A project specified mostly by people who don't know what the system is supposed to do, implemented by people who don't understand the business, replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present.  What could possibly go wrong?</p></div><p>
You do realize you've just described most reengineering efforts, right?</p></div>
	</htmltext>
<tokenext>A project specified mostly by people who do n't know what the system is supposed to do , implemented by people who do n't understand the business , replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present .
What could possibly go wrong ?
You do realize you 've just described most reengineering efforts , right ?</tokentext>
<sentencetext>A project specified mostly by people who don't know what the system is supposed to do, implemented by people who don't understand the business, replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present.
What could possibly go wrong?
You do realize you've just described most reengineering efforts, right?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708681</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709155</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Anonymous</author>
	<datestamp>1247656080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Lately, I've begun to feel that a lot of the reason for project failure is the "All You Have To Do Is.." effect.</p><p>Users get a wild idea, someone shows them some artwork, they say "It's simple! All You have to do is...".</p><p>Unfortunately, the developers get the specs, look at it, forget how much time and effort gets wasted on obscure diversions because while the hard parts of the project often end up being simpler than imagined, some of the "simple" parts of the project turn out to be <b>much</b> harder than imagined. And because even before we were constantly being threatened with replacement by cheap offshore labor, few of us had the nerve to stand up and say "No, it's actually probably going to take three times that long".</p><p>Plus, of course, there's the classic ailments like Second System Effect, Feature Creep, <i>etc.</i></p><p>Computers are stupid. They don't understand "All You Have To Do". In fact, that's one of the first lessons in programming is that a computer has to be told in excruciating detail <b>exactly</b> what to to.</p><p>A recent complication has been the extensive employment of developers who were raised in cultures where the good worker has traditionally been expected to be little more than a computer him/herself. Thus, the design team has to "program" the programmers so that they can provide those Great Big Savings by programming more cheaply than Western programmers, who require relatively little programming.</p><p>Of course, the final insult is that computers have lost their reputation for precision and reliability, because the customers frankly don't care that much about quality, as long as the work gets done fast and cheap. So even if the project doesn't fail outright, it's often pretty worthless.</p></htmltext>
<tokenext>Lately , I 've begun to feel that a lot of the reason for project failure is the " All You Have To Do Is.. " effect.Users get a wild idea , someone shows them some artwork , they say " It 's simple !
All You have to do is... " .Unfortunately , the developers get the specs , look at it , forget how much time and effort gets wasted on obscure diversions because while the hard parts of the project often end up being simpler than imagined , some of the " simple " parts of the project turn out to be much harder than imagined .
And because even before we were constantly being threatened with replacement by cheap offshore labor , few of us had the nerve to stand up and say " No , it 's actually probably going to take three times that long " .Plus , of course , there 's the classic ailments like Second System Effect , Feature Creep , etc.Computers are stupid .
They do n't understand " All You Have To Do " .
In fact , that 's one of the first lessons in programming is that a computer has to be told in excruciating detail exactly what to to.A recent complication has been the extensive employment of developers who were raised in cultures where the good worker has traditionally been expected to be little more than a computer him/herself .
Thus , the design team has to " program " the programmers so that they can provide those Great Big Savings by programming more cheaply than Western programmers , who require relatively little programming.Of course , the final insult is that computers have lost their reputation for precision and reliability , because the customers frankly do n't care that much about quality , as long as the work gets done fast and cheap .
So even if the project does n't fail outright , it 's often pretty worthless .</tokentext>
<sentencetext>Lately, I've begun to feel that a lot of the reason for project failure is the "All You Have To Do Is.." effect.Users get a wild idea, someone shows them some artwork, they say "It's simple!
All You have to do is...".Unfortunately, the developers get the specs, look at it, forget how much time and effort gets wasted on obscure diversions because while the hard parts of the project often end up being simpler than imagined, some of the "simple" parts of the project turn out to be much harder than imagined.
And because even before we were constantly being threatened with replacement by cheap offshore labor, few of us had the nerve to stand up and say "No, it's actually probably going to take three times that long".Plus, of course, there's the classic ailments like Second System Effect, Feature Creep, etc.Computers are stupid.
They don't understand "All You Have To Do".
In fact, that's one of the first lessons in programming is that a computer has to be told in excruciating detail exactly what to to.A recent complication has been the extensive employment of developers who were raised in cultures where the good worker has traditionally been expected to be little more than a computer him/herself.
Thus, the design team has to "program" the programmers so that they can provide those Great Big Savings by programming more cheaply than Western programmers, who require relatively little programming.Of course, the final insult is that computers have lost their reputation for precision and reliability, because the customers frankly don't care that much about quality, as long as the work gets done fast and cheap.
So even if the project doesn't fail outright, it's often pretty worthless.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706585</id>
	<title>Too Many Words in Sentence</title>
	<author>Anonymous</author>
	<datestamp>1247687460000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext>"Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All"

should read as "Similarly, he identified the four types of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All"</htmltext>
<tokenext>" Similarly , he identified four dangerous type of project managers : the Yes Man , the Micromanager , the Procrastinator , and the Know-It-All " should read as " Similarly , he identified the four types of project managers : the Yes Man , the Micromanager , the Procrastinator , and the Know-It-All "</tokentext>
<sentencetext>"Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All"

should read as "Similarly, he identified the four types of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707149</id>
	<title>65\% of all IT projects fail</title>
	<author>Anonymous</author>
	<datestamp>1247689980000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>65\% of all IT projects fail (whatever "fail" means). Most projects are entered into without upper management support and are under funded and under prioritized. The vast majority of projects started by a middle manager should never have begun at all. Those cause churn in their team until they reach a point that new networking or servers are needed. Then they are stuck with all the wasted time already spent.  Another failed project.</p><p>Control the budget and resources to prevent false starts. That is the main way to increase the success ratio.</p><p>After that, you need user buy in for any new software system deployed.  Users need to find all the good things it will allow, not all the things they will need to do differently or can't do.  More than a token number of real users need to be brought in during planning to ensure the new system will actually be "better" however that is defined.  Better could mean - not on a mainframe or not on UNIX or not a desktop thick application.</p><p>After working for 15+ years performing designs and installations of COTS systems across many, many servers, I'm positive most users won't change unless they have no other choice.</p><p>Do you really need a book the say that?</p><p>As for turning more projects into successes, you'll need to pay someone from outside your company to tell the PHB Exec-types the same thing you've been saying for years.  Somehow, if someone charging $300/hr says it while wearing a suite, then it must be true.</p></htmltext>
<tokenext>65 \ % of all IT projects fail ( whatever " fail " means ) .
Most projects are entered into without upper management support and are under funded and under prioritized .
The vast majority of projects started by a middle manager should never have begun at all .
Those cause churn in their team until they reach a point that new networking or servers are needed .
Then they are stuck with all the wasted time already spent .
Another failed project.Control the budget and resources to prevent false starts .
That is the main way to increase the success ratio.After that , you need user buy in for any new software system deployed .
Users need to find all the good things it will allow , not all the things they will need to do differently or ca n't do .
More than a token number of real users need to be brought in during planning to ensure the new system will actually be " better " however that is defined .
Better could mean - not on a mainframe or not on UNIX or not a desktop thick application.After working for 15 + years performing designs and installations of COTS systems across many , many servers , I 'm positive most users wo n't change unless they have no other choice.Do you really need a book the say that ? As for turning more projects into successes , you 'll need to pay someone from outside your company to tell the PHB Exec-types the same thing you 've been saying for years .
Somehow , if someone charging $ 300/hr says it while wearing a suite , then it must be true .</tokentext>
<sentencetext>65\% of all IT projects fail (whatever "fail" means).
Most projects are entered into without upper management support and are under funded and under prioritized.
The vast majority of projects started by a middle manager should never have begun at all.
Those cause churn in their team until they reach a point that new networking or servers are needed.
Then they are stuck with all the wasted time already spent.
Another failed project.Control the budget and resources to prevent false starts.
That is the main way to increase the success ratio.After that, you need user buy in for any new software system deployed.
Users need to find all the good things it will allow, not all the things they will need to do differently or can't do.
More than a token number of real users need to be brought in during planning to ensure the new system will actually be "better" however that is defined.
Better could mean - not on a mainframe or not on UNIX or not a desktop thick application.After working for 15+ years performing designs and installations of COTS systems across many, many servers, I'm positive most users won't change unless they have no other choice.Do you really need a book the say that?As for turning more projects into successes, you'll need to pay someone from outside your company to tell the PHB Exec-types the same thing you've been saying for years.
Somehow, if someone charging $300/hr says it while wearing a suite, then it must be true.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707243</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Chirs</author>
	<datestamp>1247690460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>While it's true that things can go wrong building a bridge, it's also true that the fundamental physics of bridge-building are fairly well understood.  There are standard tables that are used to spec girder strength, fastener type, etc.  I suspect that most bridges don't involve custom-making the metal alloys specifically for that bridge, or nonstandard concrete mixes.</p><p>With software, for many fields it just isn't standardized.  I suspect that there are many more original problems being solved in software than in bridge building.</p><p>Add to that the fact that there really isn't any professional responsibility attached to software designers.  (I won't dignify them with the term "engineers".)  If a bridge fails, the engineer who signed off on it gets in a lot of trouble.</p></htmltext>
<tokenext>While it 's true that things can go wrong building a bridge , it 's also true that the fundamental physics of bridge-building are fairly well understood .
There are standard tables that are used to spec girder strength , fastener type , etc .
I suspect that most bridges do n't involve custom-making the metal alloys specifically for that bridge , or nonstandard concrete mixes.With software , for many fields it just is n't standardized .
I suspect that there are many more original problems being solved in software than in bridge building.Add to that the fact that there really is n't any professional responsibility attached to software designers .
( I wo n't dignify them with the term " engineers " .
) If a bridge fails , the engineer who signed off on it gets in a lot of trouble .</tokentext>
<sentencetext>While it's true that things can go wrong building a bridge, it's also true that the fundamental physics of bridge-building are fairly well understood.
There are standard tables that are used to spec girder strength, fastener type, etc.
I suspect that most bridges don't involve custom-making the metal alloys specifically for that bridge, or nonstandard concrete mixes.With software, for many fields it just isn't standardized.
I suspect that there are many more original problems being solved in software than in bridge building.Add to that the fact that there really isn't any professional responsibility attached to software designers.
(I won't dignify them with the term "engineers".
)  If a bridge fails, the engineer who signed off on it gets in a lot of trouble.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708225</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>dgreenbean</author>
	<datestamp>1247652120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The difference between a "Programmer" and a "Software Engineer" is analogous to that between a "Mathematician" and an "Accountant."  The former uses a creative process that cannot be broken into discrete parts.  The entire process is design.  The latter merely manipulates the work of the former in a formal, discrete process toward an end goal.  This is not a value judgement on either; it is merely a definition.

The problem is that, in business, there is either a lack of understanding or of acceptance of this definition.  The roles then get blurred.  People more inclined to the creative side are stifled with detail, while those with great attention to the details are thrown into design.  Other terms can also confuse the issue: "Architect," "Developer," "Analyst," etc. all have implications that are often not natural to the industry.  Next comes the systems/software divide.  It seems that when people are promoted in the corporate world, their focus tends to shift from software to systems.  This nearly guarantees that "Programmers" will turn into "Software Engineers," and often "System Administrators," as that is where the promotions are (note that most middle management essentially performs the role of a "System Administrator").  Unfortunately, this makes for a bad programming environment.

The hybrid model that "Programmers" and "Software Engineers" are forced to live in creates this hybrid culture of creatively designing a system that takes on a new life during implementation, finally culminating in failure.  Agile project models are better, but this still does not address the issue that creativity cannot be time- or resource-constrained.  Management hates this because that is exactly what they are supposed to figure out how to resolve.  I certainly don't have the answer, but I can at least recognize the problem for what it is.

Until we change the industry to support separate "Programming" and "Software Engineering" positions, projects will continue to fail tremendously.</htmltext>
<tokenext>The difference between a " Programmer " and a " Software Engineer " is analogous to that between a " Mathematician " and an " Accountant .
" The former uses a creative process that can not be broken into discrete parts .
The entire process is design .
The latter merely manipulates the work of the former in a formal , discrete process toward an end goal .
This is not a value judgement on either ; it is merely a definition .
The problem is that , in business , there is either a lack of understanding or of acceptance of this definition .
The roles then get blurred .
People more inclined to the creative side are stifled with detail , while those with great attention to the details are thrown into design .
Other terms can also confuse the issue : " Architect , " " Developer , " " Analyst , " etc .
all have implications that are often not natural to the industry .
Next comes the systems/software divide .
It seems that when people are promoted in the corporate world , their focus tends to shift from software to systems .
This nearly guarantees that " Programmers " will turn into " Software Engineers , " and often " System Administrators , " as that is where the promotions are ( note that most middle management essentially performs the role of a " System Administrator " ) .
Unfortunately , this makes for a bad programming environment .
The hybrid model that " Programmers " and " Software Engineers " are forced to live in creates this hybrid culture of creatively designing a system that takes on a new life during implementation , finally culminating in failure .
Agile project models are better , but this still does not address the issue that creativity can not be time- or resource-constrained .
Management hates this because that is exactly what they are supposed to figure out how to resolve .
I certainly do n't have the answer , but I can at least recognize the problem for what it is .
Until we change the industry to support separate " Programming " and " Software Engineering " positions , projects will continue to fail tremendously .</tokentext>
<sentencetext>The difference between a "Programmer" and a "Software Engineer" is analogous to that between a "Mathematician" and an "Accountant.
"  The former uses a creative process that cannot be broken into discrete parts.
The entire process is design.
The latter merely manipulates the work of the former in a formal, discrete process toward an end goal.
This is not a value judgement on either; it is merely a definition.
The problem is that, in business, there is either a lack of understanding or of acceptance of this definition.
The roles then get blurred.
People more inclined to the creative side are stifled with detail, while those with great attention to the details are thrown into design.
Other terms can also confuse the issue: "Architect," "Developer," "Analyst," etc.
all have implications that are often not natural to the industry.
Next comes the systems/software divide.
It seems that when people are promoted in the corporate world, their focus tends to shift from software to systems.
This nearly guarantees that "Programmers" will turn into "Software Engineers," and often "System Administrators," as that is where the promotions are (note that most middle management essentially performs the role of a "System Administrator").
Unfortunately, this makes for a bad programming environment.
The hybrid model that "Programmers" and "Software Engineers" are forced to live in creates this hybrid culture of creatively designing a system that takes on a new life during implementation, finally culminating in failure.
Agile project models are better, but this still does not address the issue that creativity cannot be time- or resource-constrained.
Management hates this because that is exactly what they are supposed to figure out how to resolve.
I certainly don't have the answer, but I can at least recognize the problem for what it is.
Until we change the industry to support separate "Programming" and "Software Engineering" positions, projects will continue to fail tremendously.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706957</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707747</id>
	<title>Requirements, requirements, requirements...</title>
	<author>rlseaman</author>
	<datestamp>1247649660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>All projects can be described by:

</p><ol>
<li>define the problem</li>
<li>entertain solutions</li>
<li>iterate</li>
</ol><p> <b>Requirements are the interface</b> between #1 and #2.  Thus, one way or another all system failures are about requirements.  Either the true project requirements were never discovered - or the customer was allowed to impose unnecessary and counterproductive pseudo-requirements - or the domain requirements weren't correctly elaborated into appropriate functional requirements - or the process for managing the requirements was top down and static when it should have been bottom up and iterative (or vice versa) - or a contractor was permitted to be non-responsive to the requirements (for any of a 1000 reasons) - or...</p><p>Which is to say that each project represents a single complex-but-inherently-self-consistent problem.  There are an infinity of possible solutions.  Each solution attempts to manage the complexity of the problem space, but <a href="http://en.wikipedia.org/wiki/Entropy\_(information\_theory)" title="wikipedia.org">cannot ever eliminate this complexity</a> [wikipedia.org].  Further, <b>all real world solutions are guaranteed to be inconsistent.</b>  We often refer to these inconsistencies as <b>bugs</b>, but more often they are failures of the conceptual model, that is they are <b>requirement failures</b>.</p><p>On the other hand, development teams often complain that requirements have changed - for instance that the customer is demanding new features.  Rather, <b>requirements never change</b>, only our understanding of the scope of the problem changes.  Discover the requirements and the Platonic ideal of a project will be <a href="http://onter.net/cinema/jones\_c.jpg" title="onter.net">laid out in front of you</a> [onter.net].</p><p>The <a href="http://www.youtube.com/watch?v=rNDuGuerpf8" title="youtube.com">search for project requirements</a> [youtube.com] can be an adventure as rich as any our species embarks upon.  Projects fail for the same reason that expeditions fail - <b>a lack of imagination</b>.  A customer's <a href="http://en.wikipedia.org/wiki/Elevator\_pitch" title="wikipedia.org">description</a> [wikipedia.org] always fails to capture the essence of a project; customers always fail to include a broad enough vision for how the new or modified system will fit into the organization.  The first stage of any project is to clarify that vision.  As with Indiana Jones, <a href="http://en.wikipedia.org/wiki/I\_Had\_Trouble\_in\_Getting\_to\_Solla\_Sollew" title="wikipedia.org">the trail is fraught with dangers</a> [wikipedia.org], but <a href="http://en.wikipedia.org/wiki/George\_Mallory" title="wikipedia.org">the trek is the essence of the exercise</a> [wikipedia.org].</p></htmltext>
<tokenext>All projects can be described by : define the problem entertain solutions iterate Requirements are the interface between # 1 and # 2 .
Thus , one way or another all system failures are about requirements .
Either the true project requirements were never discovered - or the customer was allowed to impose unnecessary and counterproductive pseudo-requirements - or the domain requirements were n't correctly elaborated into appropriate functional requirements - or the process for managing the requirements was top down and static when it should have been bottom up and iterative ( or vice versa ) - or a contractor was permitted to be non-responsive to the requirements ( for any of a 1000 reasons ) - or...Which is to say that each project represents a single complex-but-inherently-self-consistent problem .
There are an infinity of possible solutions .
Each solution attempts to manage the complexity of the problem space , but can not ever eliminate this complexity [ wikipedia.org ] .
Further , all real world solutions are guaranteed to be inconsistent .
We often refer to these inconsistencies as bugs , but more often they are failures of the conceptual model , that is they are requirement failures.On the other hand , development teams often complain that requirements have changed - for instance that the customer is demanding new features .
Rather , requirements never change , only our understanding of the scope of the problem changes .
Discover the requirements and the Platonic ideal of a project will be laid out in front of you [ onter.net ] .The search for project requirements [ youtube.com ] can be an adventure as rich as any our species embarks upon .
Projects fail for the same reason that expeditions fail - a lack of imagination .
A customer 's description [ wikipedia.org ] always fails to capture the essence of a project ; customers always fail to include a broad enough vision for how the new or modified system will fit into the organization .
The first stage of any project is to clarify that vision .
As with Indiana Jones , the trail is fraught with dangers [ wikipedia.org ] , but the trek is the essence of the exercise [ wikipedia.org ] .</tokentext>
<sentencetext>All projects can be described by:


define the problem
entertain solutions
iterate
 Requirements are the interface between #1 and #2.
Thus, one way or another all system failures are about requirements.
Either the true project requirements were never discovered - or the customer was allowed to impose unnecessary and counterproductive pseudo-requirements - or the domain requirements weren't correctly elaborated into appropriate functional requirements - or the process for managing the requirements was top down and static when it should have been bottom up and iterative (or vice versa) - or a contractor was permitted to be non-responsive to the requirements (for any of a 1000 reasons) - or...Which is to say that each project represents a single complex-but-inherently-self-consistent problem.
There are an infinity of possible solutions.
Each solution attempts to manage the complexity of the problem space, but cannot ever eliminate this complexity [wikipedia.org].
Further, all real world solutions are guaranteed to be inconsistent.
We often refer to these inconsistencies as bugs, but more often they are failures of the conceptual model, that is they are requirement failures.On the other hand, development teams often complain that requirements have changed - for instance that the customer is demanding new features.
Rather, requirements never change, only our understanding of the scope of the problem changes.
Discover the requirements and the Platonic ideal of a project will be laid out in front of you [onter.net].The search for project requirements [youtube.com] can be an adventure as rich as any our species embarks upon.
Projects fail for the same reason that expeditions fail - a lack of imagination.
A customer's description [wikipedia.org] always fails to capture the essence of a project; customers always fail to include a broad enough vision for how the new or modified system will fit into the organization.
The first stage of any project is to clarify that vision.
As with Indiana Jones, the trail is fraught with dangers [wikipedia.org], but the trek is the essence of the exercise [wikipedia.org].</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706575</id>
	<title>New Systems Fail Because...</title>
	<author>SolarStorm</author>
	<datestamp>1247687460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>the users dont understand what I write!</htmltext>
<tokenext>the users dont understand what I write !</tokentext>
<sentencetext>the users dont understand what I write!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708779</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Anonymous</author>
	<datestamp>1247654700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Even the ones in management?</p></htmltext>
<tokenext>Even the ones in management ?</tokentext>
<sentencetext>Even the ones in management?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706953</id>
	<title>Re:Didn't need a book to know this</title>
	<author>Coz</author>
	<datestamp>1247689020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>YOU may not need a book to know this. but there are intelligent-in-their-area bean-counters who get sold on these things at major companies every year.  THEY need this book, and as responsible techies, it's our job to make sure they have it.  Remember, if it's in a book, it's not just OUR opinion - it's Official<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>YOU may not need a book to know this .
but there are intelligent-in-their-area bean-counters who get sold on these things at major companies every year .
THEY need this book , and as responsible techies , it 's our job to make sure they have it .
Remember , if it 's in a book , it 's not just OUR opinion - it 's Official : )</tokentext>
<sentencetext>YOU may not need a book to know this.
but there are intelligent-in-their-area bean-counters who get sold on these things at major companies every year.
THEY need this book, and as responsible techies, it's our job to make sure they have it.
Remember, if it's in a book, it's not just OUR opinion - it's Official :)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709335</id>
	<title>Re:A better book would be "How New Systems Succeed</title>
	<author>PeanutButterBreath</author>
	<datestamp>1247657040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Because why they fail is not all that interesting</p></div><p>Be sure to tune in for tonight's episode of "When animals don't attack".</p><p>Please?</p></div>
	</htmltext>
<tokenext>Because why they fail is not all that interestingBe sure to tune in for tonight 's episode of " When animals do n't attack " .Please ?</tokentext>
<sentencetext>Because why they fail is not all that interestingBe sure to tune in for tonight's episode of "When animals don't attack".Please?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708681</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707255</id>
	<title>The bigger the rollout, the harder the crash</title>
	<author>petes\_PoV</author>
	<datestamp>1247690580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>"But we don't have time for a pilot"
<p>
Also heard as "Why, don't you have confidence in your project"
</p><p>
Putting aside the sheer commonsense approach of not giving a porsche to a newly passed driver, most projects are run in a state of panic. Panic that the timetable is slipping (although this is almost always due to poor time-estimating, it seems to get presented as being due to slothful or untalented techies), Panic that it's costing too much - again due to poor cost estimation, rather than ovespending. Panic about bugs, Panic about training (ha!). Panic about compatibility with other systems. Panic about all the little patches, workarounds, working practices and hacks that have developed in the old system - that everyone knows about, but have never been documented.
</p><p>
All these, could have been identified and most of them fixed just by running a small scale prototype in parallel to the existing system. However by the time the project is halfway through, most of the directors are firmly engaged in either "buyers remorse" or utter denial. They become deaf to bad news and generally take full aim at the messenger, while leaving the culprits of all the problems unscathed. This is usually because all the biggest mistakes are made right at the start - in the design stages. However, these have been completed and signed off, so by definition cannot be at fault. The blame gets transferred down the line, to the people who have their hands-on right at the time the deadline is due. It's the original smoking gun: "The project ran over time / budget today - you were working on it when that happened, therefore you must be to blame". It's simplistic, always wrong and always starts off the finger pointing part of the process. You can't get away from it.
</p><p>
Although the biggest problem I see is "seagull" consultants. They fly in, make a lot of noise, crap over everything and fly off. The trouble usually only surfaces once they've disappeared.</p></htmltext>
<tokenext>" But we do n't have time for a pilot " Also heard as " Why , do n't you have confidence in your project " Putting aside the sheer commonsense approach of not giving a porsche to a newly passed driver , most projects are run in a state of panic .
Panic that the timetable is slipping ( although this is almost always due to poor time-estimating , it seems to get presented as being due to slothful or untalented techies ) , Panic that it 's costing too much - again due to poor cost estimation , rather than ovespending .
Panic about bugs , Panic about training ( ha ! ) .
Panic about compatibility with other systems .
Panic about all the little patches , workarounds , working practices and hacks that have developed in the old system - that everyone knows about , but have never been documented .
All these , could have been identified and most of them fixed just by running a small scale prototype in parallel to the existing system .
However by the time the project is halfway through , most of the directors are firmly engaged in either " buyers remorse " or utter denial .
They become deaf to bad news and generally take full aim at the messenger , while leaving the culprits of all the problems unscathed .
This is usually because all the biggest mistakes are made right at the start - in the design stages .
However , these have been completed and signed off , so by definition can not be at fault .
The blame gets transferred down the line , to the people who have their hands-on right at the time the deadline is due .
It 's the original smoking gun : " The project ran over time / budget today - you were working on it when that happened , therefore you must be to blame " .
It 's simplistic , always wrong and always starts off the finger pointing part of the process .
You ca n't get away from it .
Although the biggest problem I see is " seagull " consultants .
They fly in , make a lot of noise , crap over everything and fly off .
The trouble usually only surfaces once they 've disappeared .</tokentext>
<sentencetext>"But we don't have time for a pilot"

Also heard as "Why, don't you have confidence in your project"

Putting aside the sheer commonsense approach of not giving a porsche to a newly passed driver, most projects are run in a state of panic.
Panic that the timetable is slipping (although this is almost always due to poor time-estimating, it seems to get presented as being due to slothful or untalented techies), Panic that it's costing too much - again due to poor cost estimation, rather than ovespending.
Panic about bugs, Panic about training (ha!).
Panic about compatibility with other systems.
Panic about all the little patches, workarounds, working practices and hacks that have developed in the old system - that everyone knows about, but have never been documented.
All these, could have been identified and most of them fixed just by running a small scale prototype in parallel to the existing system.
However by the time the project is halfway through, most of the directors are firmly engaged in either "buyers remorse" or utter denial.
They become deaf to bad news and generally take full aim at the messenger, while leaving the culprits of all the problems unscathed.
This is usually because all the biggest mistakes are made right at the start - in the design stages.
However, these have been completed and signed off, so by definition cannot be at fault.
The blame gets transferred down the line, to the people who have their hands-on right at the time the deadline is due.
It's the original smoking gun: "The project ran over time / budget today - you were working on it when that happened, therefore you must be to blame".
It's simplistic, always wrong and always starts off the finger pointing part of the process.
You can't get away from it.
Although the biggest problem I see is "seagull" consultants.
They fly in, make a lot of noise, crap over everything and fly off.
The trouble usually only surfaces once they've disappeared.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708753</id>
	<title>Re:Tolstoy's version</title>
	<author>dcollins</author>
	<datestamp>1247654580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>All happy families are alike; every unhappy family is unhappy in its own way.</i></p><p>That's interesting. I think just yesterday I said exactly the opposite.</p><p>Everyone I know who's furiously pusued the American married-with-2-kids nuclear family ideal is miserable. Everyone I know who has some alternative-y lifestyle (without marriage, kids, lucrative job, white picket fence, or some combination) seems a lot happier.</p></htmltext>
<tokenext>All happy families are alike ; every unhappy family is unhappy in its own way.That 's interesting .
I think just yesterday I said exactly the opposite.Everyone I know who 's furiously pusued the American married-with-2-kids nuclear family ideal is miserable .
Everyone I know who has some alternative-y lifestyle ( without marriage , kids , lucrative job , white picket fence , or some combination ) seems a lot happier .</tokentext>
<sentencetext>All happy families are alike; every unhappy family is unhappy in its own way.That's interesting.
I think just yesterday I said exactly the opposite.Everyone I know who's furiously pusued the American married-with-2-kids nuclear family ideal is miserable.
Everyone I know who has some alternative-y lifestyle (without marriage, kids, lucrative job, white picket fence, or some combination) seems a lot happier.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706997</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709087</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Anonymous</author>
	<datestamp>1247655900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Why do we always compare building/implementing software to building bridges and cars?  Why not compare building/implementing software to starting and running a restaurant?</p></htmltext>
<tokenext>Why do we always compare building/implementing software to building bridges and cars ?
Why not compare building/implementing software to starting and running a restaurant ?</tokentext>
<sentencetext>Why do we always compare building/implementing software to building bridges and cars?
Why not compare building/implementing software to starting and running a restaurant?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707083</id>
	<title>Tim Lister? Who's he?</title>
	<author>davidwr</author>
	<datestamp>1247689620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Tim <a href="http://en.wikipedia.org/wiki/Tim\_Lister" title="wikipedia.org" rel="nofollow">who</a> [wikipedia.org]?  Sure, he's probably <a href="http://en.wikipedia.org/w/index.php?title=Special\%3ASearch&amp;search=\%22Tim+Lister\%22&amp;go=Go" title="wikipedia.org" rel="nofollow">done stuff</a> [wikipedia.org] but as long as he doesn't have a <a href="http://en.wikipedia.org/wiki/Wikipedia:BLP" title="wikipedia.org" rel="nofollow">Wikipedia entry</a> [wikipedia.org] he's just a nobody.</p><p>Counting down the seconds before I get a "<a href="http://en.wikipedia.org/wiki/Wikipedia:DYN" title="wikipedia.org" rel="nofollow">there, fixed that for you</a> [wikipedia.org]."</p></htmltext>
<tokenext>Tim who [ wikipedia.org ] ?
Sure , he 's probably done stuff [ wikipedia.org ] but as long as he does n't have a Wikipedia entry [ wikipedia.org ] he 's just a nobody.Counting down the seconds before I get a " there , fixed that for you [ wikipedia.org ] .
"</tokentext>
<sentencetext>Tim who [wikipedia.org]?
Sure, he's probably done stuff [wikipedia.org] but as long as he doesn't have a Wikipedia entry [wikipedia.org] he's just a nobody.Counting down the seconds before I get a "there, fixed that for you [wikipedia.org].
"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707769</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Anonymous</author>
	<datestamp>1247649720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>That's obviously true, but how many bridges never get finished compared to the number of software projects that never get finished?</p></div></blockquote><p>You tend to have to make an expensive investment in resources (securing real estate, preparing the site, etc.) to even begin building a bridge, which is less true of software projects, therefore a bridge project that gets cancelled between when the <i>project</i> starts and when it is complete is a lot more likely to be cancelled before any construction is done than a software project that is cancelled is likely to be cancelled before any programming is done. So IT projects are more likely to be visibly abandoned after "construction" has begun than bridges, because there tend to be less front-loaded costs in IT.</p></div>
	</htmltext>
<tokenext>That 's obviously true , but how many bridges never get finished compared to the number of software projects that never get finished ? You tend to have to make an expensive investment in resources ( securing real estate , preparing the site , etc .
) to even begin building a bridge , which is less true of software projects , therefore a bridge project that gets cancelled between when the project starts and when it is complete is a lot more likely to be cancelled before any construction is done than a software project that is cancelled is likely to be cancelled before any programming is done .
So IT projects are more likely to be visibly abandoned after " construction " has begun than bridges , because there tend to be less front-loaded costs in IT .</tokentext>
<sentencetext>That's obviously true, but how many bridges never get finished compared to the number of software projects that never get finished?You tend to have to make an expensive investment in resources (securing real estate, preparing the site, etc.
) to even begin building a bridge, which is less true of software projects, therefore a bridge project that gets cancelled between when the project starts and when it is complete is a lot more likely to be cancelled before any construction is done than a software project that is cancelled is likely to be cancelled before any programming is done.
So IT projects are more likely to be visibly abandoned after "construction" has begun than bridges, because there tend to be less front-loaded costs in IT.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707205</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>dkleinsc</author>
	<datestamp>1247690280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>In contrast, when a company's software project fails, the only people who learn from it are <b>some of</b> the ones involved with the project.</p></div><p>You make an incorrect assumption, namely that all those involved in the project will learn anything. Least of all the guy who decided to start the (possibly completely doomed) project with insufficient time available for things to go wrong, who has managed to successfully blame the failures completely on his most junior subordinate.</p></div>
	</htmltext>
<tokenext>In contrast , when a company 's software project fails , the only people who learn from it are some of the ones involved with the project.You make an incorrect assumption , namely that all those involved in the project will learn anything .
Least of all the guy who decided to start the ( possibly completely doomed ) project with insufficient time available for things to go wrong , who has managed to successfully blame the failures completely on his most junior subordinate .</tokentext>
<sentencetext>In contrast, when a company's software project fails, the only people who learn from it are some of the ones involved with the project.You make an incorrect assumption, namely that all those involved in the project will learn anything.
Least of all the guy who decided to start the (possibly completely doomed) project with insufficient time available for things to go wrong, who has managed to successfully blame the failures completely on his most junior subordinate.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708145</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Nursie</author>
	<datestamp>1247651640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>""Software Engineers" are one of the few types of engineers that are not liable for the failure of the systems they create."</p><p>Annnnnd... FAIL.</p><p>You think electronic engineers are personally liable for incorrect or buggy circuit design?</p><p>You think companies that sell software under contract are *not* liable when it doesn't perform?</p><p>What a load of shit.</p></htmltext>
<tokenext>" " Software Engineers " are one of the few types of engineers that are not liable for the failure of the systems they create. " Annnnnd.. .
FAIL.You think electronic engineers are personally liable for incorrect or buggy circuit design ? You think companies that sell software under contract are * not * liable when it does n't perform ? What a load of shit .</tokentext>
<sentencetext>""Software Engineers" are one of the few types of engineers that are not liable for the failure of the systems they create."Annnnnd...
FAIL.You think electronic engineers are personally liable for incorrect or buggy circuit design?You think companies that sell software under contract are *not* liable when it doesn't perform?What a load of shit.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706957</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706645</id>
	<title>PHBs is the simple answer</title>
	<author>Finallyjoined!!!</author>
	<datestamp>1247687700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Buying software designed to take the user 4 times longer to use, takes 4 times more key presses &amp; takes a 4 times faster processor to do the same task as the "old" software, but it enables some sodding PHB to get a report in one click.</htmltext>
<tokenext>Buying software designed to take the user 4 times longer to use , takes 4 times more key presses &amp; takes a 4 times faster processor to do the same task as the " old " software , but it enables some sodding PHB to get a report in one click .</tokentext>
<sentencetext>Buying software designed to take the user 4 times longer to use, takes 4 times more key presses &amp; takes a 4 times faster processor to do the same task as the "old" software, but it enables some sodding PHB to get a report in one click.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707703</id>
	<title>Sturgeon's Law</title>
	<author>n6kuy</author>
	<datestamp>1247649420000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p>90\% of Everything is Crap.</p></htmltext>
<tokenext>90 \ % of Everything is Crap .</tokentext>
<sentencetext>90\% of Everything is Crap.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707563</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>radtea</author>
	<datestamp>1247648700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>I was discussing with a friend how software projects are probably the most difficult to run and predict, especially with very large projects.  He disagreed and said that all large projects are difficult...</i></p><p>Actually, all large projects are equally easy with regard to prediction.  A larger project is even more amenable to a statistical estimation approach, because the workforce and circumstances are averaged over the larger size, creating a more homogeneous, stable mass.</p><p>For any organization that has built more than one of something, you have lots of hard data from previous schedules and estimates to base your new schedules and estimates on, if your project managers are even minimally competent.  After all, it isn't exactly rocket science to keep a table of numbers ("how long we expected the project to take" and "how long it actually took.")  This also requires adequate requirements documents, and that's a more difficult problem, but it's hardly surprising that "projects teams that don't know what they're building have a hard time estimating how long it will take to build it."</p><p>The first project an organization undertakes is a bit trickier, but again, even a modestly competent project manager will track schedule progress against real time, and after about three weeks will have a correction factor to the original schedule that will bring things pretty close to reality.  This should be done anyway, on all projects, of course, because circumstances do vary from project to project, but on subsequent projects the correction factor should be closer to unity than not.</p><p>The thing that makes project scheduling and estimation "hard" is that most project managers are either incompetent, or so beaten up the first they tell the suits the truth that they spend the rest of their days lying to avoid further abuse.  I've known people in both categories, and the first group are the ones who crow most loudly that project estimation is hard because it is so far beyond their modest competencies.  The second group will pull it out as a backup excuse when things go badly wrong next time, and because suits are idiots they are willing to believe it, thus perpetuating the cycle whereby everyone gets off the hook for failing to do an incredibly simple job:  keeping a table of numbers, and applying a simple numerical multiplier to their schedule after the first three weeks.</p><p>Someone below quoted Tolstoy about all unhappy families being unhappy in their own way.  This is funny, but it's false in the case of project management.  There are very few ways projects go bad, and one of the the most common is an excessive focus on the particularities, rather than a global view that sees the individual circumstances as a valid statistical ensemble that can be averaged over meaningfully.</p><p>There is nothing particularly difficult, intellectually, about project estimation.  Virtually all the difficulty comes in the politics of the organization, and a deep grounding in solid empirical estimation practises will help you navigate those waters.  McConnell's Rapid Development has some nice starter material on estimation that is well worth having a look at.</p></htmltext>
<tokenext>I was discussing with a friend how software projects are probably the most difficult to run and predict , especially with very large projects .
He disagreed and said that all large projects are difficult...Actually , all large projects are equally easy with regard to prediction .
A larger project is even more amenable to a statistical estimation approach , because the workforce and circumstances are averaged over the larger size , creating a more homogeneous , stable mass.For any organization that has built more than one of something , you have lots of hard data from previous schedules and estimates to base your new schedules and estimates on , if your project managers are even minimally competent .
After all , it is n't exactly rocket science to keep a table of numbers ( " how long we expected the project to take " and " how long it actually took .
" ) This also requires adequate requirements documents , and that 's a more difficult problem , but it 's hardly surprising that " projects teams that do n't know what they 're building have a hard time estimating how long it will take to build it .
" The first project an organization undertakes is a bit trickier , but again , even a modestly competent project manager will track schedule progress against real time , and after about three weeks will have a correction factor to the original schedule that will bring things pretty close to reality .
This should be done anyway , on all projects , of course , because circumstances do vary from project to project , but on subsequent projects the correction factor should be closer to unity than not.The thing that makes project scheduling and estimation " hard " is that most project managers are either incompetent , or so beaten up the first they tell the suits the truth that they spend the rest of their days lying to avoid further abuse .
I 've known people in both categories , and the first group are the ones who crow most loudly that project estimation is hard because it is so far beyond their modest competencies .
The second group will pull it out as a backup excuse when things go badly wrong next time , and because suits are idiots they are willing to believe it , thus perpetuating the cycle whereby everyone gets off the hook for failing to do an incredibly simple job : keeping a table of numbers , and applying a simple numerical multiplier to their schedule after the first three weeks.Someone below quoted Tolstoy about all unhappy families being unhappy in their own way .
This is funny , but it 's false in the case of project management .
There are very few ways projects go bad , and one of the the most common is an excessive focus on the particularities , rather than a global view that sees the individual circumstances as a valid statistical ensemble that can be averaged over meaningfully.There is nothing particularly difficult , intellectually , about project estimation .
Virtually all the difficulty comes in the politics of the organization , and a deep grounding in solid empirical estimation practises will help you navigate those waters .
McConnell 's Rapid Development has some nice starter material on estimation that is well worth having a look at .</tokentext>
<sentencetext>I was discussing with a friend how software projects are probably the most difficult to run and predict, especially with very large projects.
He disagreed and said that all large projects are difficult...Actually, all large projects are equally easy with regard to prediction.
A larger project is even more amenable to a statistical estimation approach, because the workforce and circumstances are averaged over the larger size, creating a more homogeneous, stable mass.For any organization that has built more than one of something, you have lots of hard data from previous schedules and estimates to base your new schedules and estimates on, if your project managers are even minimally competent.
After all, it isn't exactly rocket science to keep a table of numbers ("how long we expected the project to take" and "how long it actually took.
")  This also requires adequate requirements documents, and that's a more difficult problem, but it's hardly surprising that "projects teams that don't know what they're building have a hard time estimating how long it will take to build it.
"The first project an organization undertakes is a bit trickier, but again, even a modestly competent project manager will track schedule progress against real time, and after about three weeks will have a correction factor to the original schedule that will bring things pretty close to reality.
This should be done anyway, on all projects, of course, because circumstances do vary from project to project, but on subsequent projects the correction factor should be closer to unity than not.The thing that makes project scheduling and estimation "hard" is that most project managers are either incompetent, or so beaten up the first they tell the suits the truth that they spend the rest of their days lying to avoid further abuse.
I've known people in both categories, and the first group are the ones who crow most loudly that project estimation is hard because it is so far beyond their modest competencies.
The second group will pull it out as a backup excuse when things go badly wrong next time, and because suits are idiots they are willing to believe it, thus perpetuating the cycle whereby everyone gets off the hook for failing to do an incredibly simple job:  keeping a table of numbers, and applying a simple numerical multiplier to their schedule after the first three weeks.Someone below quoted Tolstoy about all unhappy families being unhappy in their own way.
This is funny, but it's false in the case of project management.
There are very few ways projects go bad, and one of the the most common is an excessive focus on the particularities, rather than a global view that sees the individual circumstances as a valid statistical ensemble that can be averaged over meaningfully.There is nothing particularly difficult, intellectually, about project estimation.
Virtually all the difficulty comes in the politics of the organization, and a deep grounding in solid empirical estimation practises will help you navigate those waters.
McConnell's Rapid Development has some nice starter material on estimation that is well worth having a look at.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711343</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Swampash</author>
	<datestamp>1247669100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Bridges are designed by engineers. Software is designed by people who CALL themselves engineers. There's a big difference.</p></htmltext>
<tokenext>Bridges are designed by engineers .
Software is designed by people who CALL themselves engineers .
There 's a big difference .</tokentext>
<sentencetext>Bridges are designed by engineers.
Software is designed by people who CALL themselves engineers.
There's a big difference.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706793</id>
	<title>Incredible review</title>
	<author>Anonymous</author>
	<datestamp>1247688360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project."</p><p>Who is Bruce Webster?  He must a trainer of CIO's or something to presume to know what CIO's should or shouldn't read.  No doubt he's an expert in risk management.  I suppose he's developed seriously mission-critical systems in his time.  But if that was the case, why didn't he write a book about it then?</p></htmltext>
<tokenext>" Simon 's book is far more informative and instructive than a Google search and should be required reading for all CIOs , IT project managers , and involved business managers prior to starting any such enterprise COTS project .
" Who is Bruce Webster ?
He must a trainer of CIO 's or something to presume to know what CIO 's should or should n't read .
No doubt he 's an expert in risk management .
I suppose he 's developed seriously mission-critical systems in his time .
But if that was the case , why did n't he write a book about it then ?</tokentext>
<sentencetext>"Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project.
"Who is Bruce Webster?
He must a trainer of CIO's or something to presume to know what CIO's should or shouldn't read.
No doubt he's an expert in risk management.
I suppose he's developed seriously mission-critical systems in his time.
But if that was the case, why didn't he write a book about it then?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707131</id>
	<title>Underpromise and over-deliver! That's my motto...</title>
	<author>filesiteguy</author>
	<datestamp>1247689860000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>...or at least one of them. I haven't read the book yet - but it is now listed as a to-do in my list of to-do items taking up space on my blackberry.<br><br>In any case, I'd be curious what the answer is. In my short software development experience - only since '93 have I been doing enterprise-level development - I see one factor being the overwhelming key to failure.<br><br>Communication.<br><br>When you have analysts and developers (who are notorious for not being communicative in the first place) trying to interface with executives and managers (who are trying to CYA) then you have a perfect storm brewing.<br><br>Add to it, the fact that COTS solutions rarely actually fit the needs of everyone, and you subscribe to failure. A classic example that I just saw this week is with the California State Child Welfare lien processing system, written by Accenture. I asked for a minor change in the file layout some months ago. Only this week did I hear that I'd need a change request and that they'd get back to me in a few months.<nobr> <wbr></nobr>:P<br><br>By contrast, I've written my own in-house custom software systems for the enterprise. (One system in production has well over 500 concurrent users on any of fifteen different modules.) When teh customer(s) request a change, then it can - depending on complexity - be implemented and tested in a matter of days. Of course, harping on the communication theme, I'm in constant communication with teh customer, the end-user (if different), my developers, and my analysts. (I'm a PHB in the middle.)  I make sure that we under-promise and over-delivery whenever possible.</htmltext>
<tokenext>...or at least one of them .
I have n't read the book yet - but it is now listed as a to-do in my list of to-do items taking up space on my blackberry.In any case , I 'd be curious what the answer is .
In my short software development experience - only since '93 have I been doing enterprise-level development - I see one factor being the overwhelming key to failure.Communication.When you have analysts and developers ( who are notorious for not being communicative in the first place ) trying to interface with executives and managers ( who are trying to CYA ) then you have a perfect storm brewing.Add to it , the fact that COTS solutions rarely actually fit the needs of everyone , and you subscribe to failure .
A classic example that I just saw this week is with the California State Child Welfare lien processing system , written by Accenture .
I asked for a minor change in the file layout some months ago .
Only this week did I hear that I 'd need a change request and that they 'd get back to me in a few months .
: PBy contrast , I 've written my own in-house custom software systems for the enterprise .
( One system in production has well over 500 concurrent users on any of fifteen different modules .
) When teh customer ( s ) request a change , then it can - depending on complexity - be implemented and tested in a matter of days .
Of course , harping on the communication theme , I 'm in constant communication with teh customer , the end-user ( if different ) , my developers , and my analysts .
( I 'm a PHB in the middle .
) I make sure that we under-promise and over-delivery whenever possible .</tokentext>
<sentencetext>...or at least one of them.
I haven't read the book yet - but it is now listed as a to-do in my list of to-do items taking up space on my blackberry.In any case, I'd be curious what the answer is.
In my short software development experience - only since '93 have I been doing enterprise-level development - I see one factor being the overwhelming key to failure.Communication.When you have analysts and developers (who are notorious for not being communicative in the first place) trying to interface with executives and managers (who are trying to CYA) then you have a perfect storm brewing.Add to it, the fact that COTS solutions rarely actually fit the needs of everyone, and you subscribe to failure.
A classic example that I just saw this week is with the California State Child Welfare lien processing system, written by Accenture.
I asked for a minor change in the file layout some months ago.
Only this week did I hear that I'd need a change request and that they'd get back to me in a few months.
:PBy contrast, I've written my own in-house custom software systems for the enterprise.
(One system in production has well over 500 concurrent users on any of fifteen different modules.
) When teh customer(s) request a change, then it can - depending on complexity - be implemented and tested in a matter of days.
Of course, harping on the communication theme, I'm in constant communication with teh customer, the end-user (if different), my developers, and my analysts.
(I'm a PHB in the middle.
)  I make sure that we under-promise and over-delivery whenever possible.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>MightyYar</author>
	<datestamp>1247688420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>how many bridges never get finished compared to the number of software projects that never get finished?</p></div><p>All bridges are essentially "open source". Plenty of bridges have failed, but the failures are right out there in the open, ready to be studied by anyone who wants to build another bridge.</p><p>In contrast, when a company's software project fails, the only people who learn from it are the ones involved with the project.</p></div>
	</htmltext>
<tokenext>how many bridges never get finished compared to the number of software projects that never get finished ? All bridges are essentially " open source " .
Plenty of bridges have failed , but the failures are right out there in the open , ready to be studied by anyone who wants to build another bridge.In contrast , when a company 's software project fails , the only people who learn from it are the ones involved with the project .</tokentext>
<sentencetext>how many bridges never get finished compared to the number of software projects that never get finished?All bridges are essentially "open source".
Plenty of bridges have failed, but the failures are right out there in the open, ready to be studied by anyone who wants to build another bridge.In contrast, when a company's software project fails, the only people who learn from it are the ones involved with the project.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706873</id>
	<title>New Systems fail because:</title>
	<author>vertinox</author>
	<datestamp>1247688600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Clients are over expecting.<br>Salespersons are over promising.<br>Developers are over outsourcing.</p></htmltext>
<tokenext>Clients are over expecting.Salespersons are over promising.Developers are over outsourcing .</tokentext>
<sentencetext>Clients are over expecting.Salespersons are over promising.Developers are over outsourcing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28712113</id>
	<title>Another good book</title>
	<author>eyrieowl</author>
	<datestamp>1247674980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>which isn't software focused, but contains principles *absolutely* useful for software as well as other types of engineering is <a href="http://www.invitingdisaster.com/" title="invitingdisaster.com">Inviting Disaster</a> [invitingdisaster.com].  It's an easy, highly entertaining read, with the bonus that you (ought to) learn something as well.  I highly recommend it.</p></htmltext>
<tokenext>which is n't software focused , but contains principles * absolutely * useful for software as well as other types of engineering is Inviting Disaster [ invitingdisaster.com ] .
It 's an easy , highly entertaining read , with the bonus that you ( ought to ) learn something as well .
I highly recommend it .</tokentext>
<sentencetext>which isn't software focused, but contains principles *absolutely* useful for software as well as other types of engineering is Inviting Disaster [invitingdisaster.com].
It's an easy, highly entertaining read, with the bonus that you (ought to) learn something as well.
I highly recommend it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707571</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>getNewNickName</author>
	<datestamp>1247648700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>Software projects fail more easily than their physical counterparts due to the brittleness of software programs.  It is unlikely a bridge falls apart if it's missing a single screw, but for software a single line of bad code could cause the application to crash.  Currently software has a very small tolerance for errors, which makes it very difficult to successfully complete large projects.</htmltext>
<tokenext>Software projects fail more easily than their physical counterparts due to the brittleness of software programs .
It is unlikely a bridge falls apart if it 's missing a single screw , but for software a single line of bad code could cause the application to crash .
Currently software has a very small tolerance for errors , which makes it very difficult to successfully complete large projects .</tokentext>
<sentencetext>Software projects fail more easily than their physical counterparts due to the brittleness of software programs.
It is unlikely a bridge falls apart if it's missing a single screw, but for software a single line of bad code could cause the application to crash.
Currently software has a very small tolerance for errors, which makes it very difficult to successfully complete large projects.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711929</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>crispytwo</author>
	<datestamp>1247673540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Custom software is extremely hard to predict and way more difficult than most bridges.</p><p>The most obvious problem  with software is that no-one knows what it should do when you start. A bridge, on the other hand, you know that it connects one side with another side and it carries stuff across. Hell, a rope can do that! Now make it bigger!</p><p>With software, it  is a mess of user interactions with imagined unknown outcomes. Words like "maybe" and "probably" are used all the time with the major functionality. Never mind the end user is either technical or non-technical, which encompasses human psychology as much as logical inconsistencies. Even when you get something nailed down, we all know that is fleeting and next week, that's not what we meant anyway.</p><p>Software is a moving target of unknown proportions. When you have a final product that works, ten people will have ten different descriptions of what it is. Three of them will break it in ways it wasn't intended to be used. Two of them will not be able to make it work. One will be so enamoured that changing it will be considered a sin.</p><p>Software is an artistic expression and nothing less. Large projects are truly a group expression, which is pretty cool when you think about it.</p><p>I believe large projects fail, not because they are big, but because either the vision is not focussed enough early, or the vision is too rigid.</p></htmltext>
<tokenext>Custom software is extremely hard to predict and way more difficult than most bridges.The most obvious problem with software is that no-one knows what it should do when you start .
A bridge , on the other hand , you know that it connects one side with another side and it carries stuff across .
Hell , a rope can do that !
Now make it bigger ! With software , it is a mess of user interactions with imagined unknown outcomes .
Words like " maybe " and " probably " are used all the time with the major functionality .
Never mind the end user is either technical or non-technical , which encompasses human psychology as much as logical inconsistencies .
Even when you get something nailed down , we all know that is fleeting and next week , that 's not what we meant anyway.Software is a moving target of unknown proportions .
When you have a final product that works , ten people will have ten different descriptions of what it is .
Three of them will break it in ways it was n't intended to be used .
Two of them will not be able to make it work .
One will be so enamoured that changing it will be considered a sin.Software is an artistic expression and nothing less .
Large projects are truly a group expression , which is pretty cool when you think about it.I believe large projects fail , not because they are big , but because either the vision is not focussed enough early , or the vision is too rigid .</tokentext>
<sentencetext>Custom software is extremely hard to predict and way more difficult than most bridges.The most obvious problem  with software is that no-one knows what it should do when you start.
A bridge, on the other hand, you know that it connects one side with another side and it carries stuff across.
Hell, a rope can do that!
Now make it bigger!With software, it  is a mess of user interactions with imagined unknown outcomes.
Words like "maybe" and "probably" are used all the time with the major functionality.
Never mind the end user is either technical or non-technical, which encompasses human psychology as much as logical inconsistencies.
Even when you get something nailed down, we all know that is fleeting and next week, that's not what we meant anyway.Software is a moving target of unknown proportions.
When you have a final product that works, ten people will have ten different descriptions of what it is.
Three of them will break it in ways it wasn't intended to be used.
Two of them will not be able to make it work.
One will be so enamoured that changing it will be considered a sin.Software is an artistic expression and nothing less.
Large projects are truly a group expression, which is pretty cool when you think about it.I believe large projects fail, not because they are big, but because either the vision is not focussed enough early, or the vision is too rigid.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707275</id>
	<title>Re:Didn't need a book to know this</title>
	<author>Yetihehe</author>
	<datestamp>1247690640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>2.1) Bad communication of requirements with third party coders. Happening right now with one project I'm working on ( aka "Why didn't you implement X? It's logical that it must be that way!" )</htmltext>
<tokenext>2.1 ) Bad communication of requirements with third party coders .
Happening right now with one project I 'm working on ( aka " Why did n't you implement X ?
It 's logical that it must be that way !
" )</tokentext>
<sentencetext>2.1) Bad communication of requirements with third party coders.
Happening right now with one project I'm working on ( aka "Why didn't you implement X?
It's logical that it must be that way!
" )</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707901</id>
	<title>The problem with these kinds of books...</title>
	<author>devleopard</author>
	<datestamp>1247650260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>They're stuck in an old paradigm: plan it, build it, test it, deliver it, you're done. This may still be true for certain types of applications (think an accounting system), However, today's giant web applications written in ColdFusion, PHP, or the like are as much a system as the traditional ones. Moreover, many companies' web applications *are* their business. Therefore they have to make adjustments on the fly, or lose business. No different than other businesses - if you run a restaurant, and your competition is smokin with a new dish, you better get it on your menu. Fast. If your chefs say they can't do it, then you either get new ones or embrace the idea that you don't have the competency, at least in that area, to compete. Unfortunately this reality of online businesses tends to screw up Gantt charts and whatnot. In addition, these books assume giant teams - how many applications that drive entire companies are architected, built, and maintained by teams of less than 5? Heck, my bread and butter is building big apps, primarily in ColdFusion, where I generally am the sole developer, either building from the ground up or coming on after the application was built by a team and supposedly "finished".</p></htmltext>
<tokenext>They 're stuck in an old paradigm : plan it , build it , test it , deliver it , you 're done .
This may still be true for certain types of applications ( think an accounting system ) , However , today 's giant web applications written in ColdFusion , PHP , or the like are as much a system as the traditional ones .
Moreover , many companies ' web applications * are * their business .
Therefore they have to make adjustments on the fly , or lose business .
No different than other businesses - if you run a restaurant , and your competition is smokin with a new dish , you better get it on your menu .
Fast. If your chefs say they ca n't do it , then you either get new ones or embrace the idea that you do n't have the competency , at least in that area , to compete .
Unfortunately this reality of online businesses tends to screw up Gantt charts and whatnot .
In addition , these books assume giant teams - how many applications that drive entire companies are architected , built , and maintained by teams of less than 5 ?
Heck , my bread and butter is building big apps , primarily in ColdFusion , where I generally am the sole developer , either building from the ground up or coming on after the application was built by a team and supposedly " finished " .</tokentext>
<sentencetext>They're stuck in an old paradigm: plan it, build it, test it, deliver it, you're done.
This may still be true for certain types of applications (think an accounting system), However, today's giant web applications written in ColdFusion, PHP, or the like are as much a system as the traditional ones.
Moreover, many companies' web applications *are* their business.
Therefore they have to make adjustments on the fly, or lose business.
No different than other businesses - if you run a restaurant, and your competition is smokin with a new dish, you better get it on your menu.
Fast. If your chefs say they can't do it, then you either get new ones or embrace the idea that you don't have the competency, at least in that area, to compete.
Unfortunately this reality of online businesses tends to screw up Gantt charts and whatnot.
In addition, these books assume giant teams - how many applications that drive entire companies are architected, built, and maintained by teams of less than 5?
Heck, my bread and butter is building big apps, primarily in ColdFusion, where I generally am the sole developer, either building from the ground up or coming on after the application was built by a team and supposedly "finished".</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28715159</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>mrosgood</author>
	<datestamp>1247751480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A/E/C (architecture, engineering, construction) is nothing like software development.</p><p>Software is far more complex than construction. Complex, as in information content, as in how many decisions must be made. Bridges are described with a few 100 construction drawings and some supporting text.</p><p>Construction is a far more constrained problem space, compared to software. Physics (engineering), construction materials, site location, application, and building codes pretty much predetermine what any given bridge is going to look like. A civil engineer spends most of their time "finding" the bridge design that satisfies all the constraints (a search problem). They get all excited over green field projects, because there's more room to play (e.g. highways rebuilt after St Helens blew up).</p><p>Construction design has regular checkpoints (e.g. 30, 60, 90, 100\% submittals) for full client review. Iterative development in software is the exception, not the rule. When things get tough, it always degenerates into the waterfall "model".</p><p>The points previously made about transparency (open source) and quality of requirements also apply.</p></htmltext>
<tokenext>A/E/C ( architecture , engineering , construction ) is nothing like software development.Software is far more complex than construction .
Complex , as in information content , as in how many decisions must be made .
Bridges are described with a few 100 construction drawings and some supporting text.Construction is a far more constrained problem space , compared to software .
Physics ( engineering ) , construction materials , site location , application , and building codes pretty much predetermine what any given bridge is going to look like .
A civil engineer spends most of their time " finding " the bridge design that satisfies all the constraints ( a search problem ) .
They get all excited over green field projects , because there 's more room to play ( e.g .
highways rebuilt after St Helens blew up ) .Construction design has regular checkpoints ( e.g .
30 , 60 , 90 , 100 \ % submittals ) for full client review .
Iterative development in software is the exception , not the rule .
When things get tough , it always degenerates into the waterfall " model " .The points previously made about transparency ( open source ) and quality of requirements also apply .</tokentext>
<sentencetext>A/E/C (architecture, engineering, construction) is nothing like software development.Software is far more complex than construction.
Complex, as in information content, as in how many decisions must be made.
Bridges are described with a few 100 construction drawings and some supporting text.Construction is a far more constrained problem space, compared to software.
Physics (engineering), construction materials, site location, application, and building codes pretty much predetermine what any given bridge is going to look like.
A civil engineer spends most of their time "finding" the bridge design that satisfies all the constraints (a search problem).
They get all excited over green field projects, because there's more room to play (e.g.
highways rebuilt after St Helens blew up).Construction design has regular checkpoints (e.g.
30, 60, 90, 100\% submittals) for full client review.
Iterative development in software is the exception, not the rule.
When things get tough, it always degenerates into the waterfall "model".The points previously made about transparency (open source) and quality of requirements also apply.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28715121</id>
	<title>Software Project Failures ..</title>
	<author>viralMeme</author>
	<datestamp>1247751240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Another interesting read<nobr> <wbr></nobr>.. <a href="http://www.scism.lsbu.ac.uk/inmandw//past/9697/projects/prj127.html" title="lsbu.ac.uk">Software Project Failures</a> [lsbu.ac.uk] Sabina Seifert<nobr> <wbr></nobr>...</htmltext>
<tokenext>Another interesting read .. Software Project Failures [ lsbu.ac.uk ] Sabina Seifert .. .</tokentext>
<sentencetext>Another interesting read .. Software Project Failures [lsbu.ac.uk] Sabina Seifert ...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707805</id>
	<title>Re:Didn't need a book to know this</title>
	<author>lazyforker</author>
	<datestamp>1247649840000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>When I read your post I was reminded of this old old old picture.  <a href="http://www.cubiccompass.com/blogs/main/content/binary/TireSwingCartoon.png" title="cubiccompass.com" rel="nofollow">http://www.cubiccompass.com/blogs/main/content/binary/TireSwingCartoon.png</a> [cubiccompass.com]
I first saw it on paper so I had to Google around for an example.</htmltext>
<tokenext>When I read your post I was reminded of this old old old picture .
http : //www.cubiccompass.com/blogs/main/content/binary/TireSwingCartoon.png [ cubiccompass.com ] I first saw it on paper so I had to Google around for an example .</tokentext>
<sentencetext>When I read your post I was reminded of this old old old picture.
http://www.cubiccompass.com/blogs/main/content/binary/TireSwingCartoon.png [cubiccompass.com]
I first saw it on paper so I had to Google around for an example.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707143</id>
	<title>requirements gathering failure</title>
	<author>Dan667</author>
	<datestamp>1247689920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In my experience, the main reason software projects fail is a failure to collect adequate requirements.  The tendency to jump in a code something is extremely great, but that is the absolute worst thing to do.  For projects I manage, it is about a 2/3 requirements gathering to 1/3 or less code writing.  A lot of people hate gathering requirements, figuring out how people do their job / what people actually need, and following up with minor changes that are extremely important in the different in a system that a user will hate to use vs one a user wants to use.  Also, managing expectations is very important.</htmltext>
<tokenext>In my experience , the main reason software projects fail is a failure to collect adequate requirements .
The tendency to jump in a code something is extremely great , but that is the absolute worst thing to do .
For projects I manage , it is about a 2/3 requirements gathering to 1/3 or less code writing .
A lot of people hate gathering requirements , figuring out how people do their job / what people actually need , and following up with minor changes that are extremely important in the different in a system that a user will hate to use vs one a user wants to use .
Also , managing expectations is very important .</tokentext>
<sentencetext>In my experience, the main reason software projects fail is a failure to collect adequate requirements.
The tendency to jump in a code something is extremely great, but that is the absolute worst thing to do.
For projects I manage, it is about a 2/3 requirements gathering to 1/3 or less code writing.
A lot of people hate gathering requirements, figuring out how people do their job / what people actually need, and following up with minor changes that are extremely important in the different in a system that a user will hate to use vs one a user wants to use.
Also, managing expectations is very important.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706959</id>
	<title>firs7 po5t</title>
	<author>Anonymous</author>
	<datestamp>1247689020000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><A HREF="http://goat.cx/" title="goat.cx" rel="nofollow">Everyday...W3 Whole has lost</a> [goat.cx]</htmltext>
<tokenext>Everyday...W3 Whole has lost [ goat.cx ]</tokentext>
<sentencetext>Everyday...W3 Whole has lost [goat.cx]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707093</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>JobyOne</author>
	<datestamp>1247689620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think it has something to do with the fact that it's easier for bigshot investors/CEOs/bigwigs to wrap their head around physical problems brought up by engineers.<br> <br>

If a structural engineer says "this cabling isn't strong enough, we need this other type and it will cost X more," that's a pretty concrete statement. And nobody wants to argue with a structural engineer.<br> <br>

If a software engineer says "we should just buy X software package so I won't have to spend the next 2 weeks reinventing the wheel," a bad manager could pretty easily decide that they would rather pay their own people $2,000 to get a crappy knockoff of a tool they could have bought for $1,000. Then when that crappy reinvented wheel breaks they can just blame the coder who didn't even want to write it in the first place.<br> <br>

Also people at the top rarely understand software, and can't be bothered to even learn the basics. Saying "do it" and expecting it to magically get done does not make a good manager.</htmltext>
<tokenext>I think it has something to do with the fact that it 's easier for bigshot investors/CEOs/bigwigs to wrap their head around physical problems brought up by engineers .
If a structural engineer says " this cabling is n't strong enough , we need this other type and it will cost X more , " that 's a pretty concrete statement .
And nobody wants to argue with a structural engineer .
If a software engineer says " we should just buy X software package so I wo n't have to spend the next 2 weeks reinventing the wheel , " a bad manager could pretty easily decide that they would rather pay their own people $ 2,000 to get a crappy knockoff of a tool they could have bought for $ 1,000 .
Then when that crappy reinvented wheel breaks they can just blame the coder who did n't even want to write it in the first place .
Also people at the top rarely understand software , and ca n't be bothered to even learn the basics .
Saying " do it " and expecting it to magically get done does not make a good manager .</tokentext>
<sentencetext>I think it has something to do with the fact that it's easier for bigshot investors/CEOs/bigwigs to wrap their head around physical problems brought up by engineers.
If a structural engineer says "this cabling isn't strong enough, we need this other type and it will cost X more," that's a pretty concrete statement.
And nobody wants to argue with a structural engineer.
If a software engineer says "we should just buy X software package so I won't have to spend the next 2 weeks reinventing the wheel," a bad manager could pretty easily decide that they would rather pay their own people $2,000 to get a crappy knockoff of a tool they could have bought for $1,000.
Then when that crappy reinvented wheel breaks they can just blame the coder who didn't even want to write it in the first place.
Also people at the top rarely understand software, and can't be bothered to even learn the basics.
Saying "do it" and expecting it to magically get done does not make a good manager.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28714509</id>
	<title>Software projects only fail for one reason</title>
	<author>192939495969798999</author>
	<datestamp>1247744340000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Software projects only fail because people agree and/or commit to features or schedules that are not thought out ahead of time.  Anytime such a committal is made, either that part of the project will fail, or some part that connects to that part will be forced to fail as a result of the developers being forced not to design the software properly.  Software projects are supposed to be really expensive (just look at the early days for examples), but to cut costs, sales and non-technical people agree to nonsensical schedules and features.  The clients won't sign onto a project unless it is cheap, so the managers/sales folks that agree to the MOST nonsensical stuff are initially seen as winners.  Developers are then given the responsibility for delivering on a deal that they didn't design or agree with.  Since every development outfit does this, none of the clients out there have any idea how complicated and expensive it would be to actually do things the right way.</p></htmltext>
<tokenext>Software projects only fail because people agree and/or commit to features or schedules that are not thought out ahead of time .
Anytime such a committal is made , either that part of the project will fail , or some part that connects to that part will be forced to fail as a result of the developers being forced not to design the software properly .
Software projects are supposed to be really expensive ( just look at the early days for examples ) , but to cut costs , sales and non-technical people agree to nonsensical schedules and features .
The clients wo n't sign onto a project unless it is cheap , so the managers/sales folks that agree to the MOST nonsensical stuff are initially seen as winners .
Developers are then given the responsibility for delivering on a deal that they did n't design or agree with .
Since every development outfit does this , none of the clients out there have any idea how complicated and expensive it would be to actually do things the right way .</tokentext>
<sentencetext>Software projects only fail because people agree and/or commit to features or schedules that are not thought out ahead of time.
Anytime such a committal is made, either that part of the project will fail, or some part that connects to that part will be forced to fail as a result of the developers being forced not to design the software properly.
Software projects are supposed to be really expensive (just look at the early days for examples), but to cut costs, sales and non-technical people agree to nonsensical schedules and features.
The clients won't sign onto a project unless it is cheap, so the managers/sales folks that agree to the MOST nonsensical stuff are initially seen as winners.
Developers are then given the responsibility for delivering on a deal that they didn't design or agree with.
Since every development outfit does this, none of the clients out there have any idea how complicated and expensive it would be to actually do things the right way.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707407</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>davek</author>
	<datestamp>1247691180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>All bridges are essentially "open source". Plenty of bridges have failed, but the failures are right out there in the open, ready to be studied by anyone who wants to build another bridge.</p></div><p>I'm afraid I can't understand your analogy.  Perhaps if it were in terms of a car design failure...</p></div>
	</htmltext>
<tokenext>All bridges are essentially " open source " .
Plenty of bridges have failed , but the failures are right out there in the open , ready to be studied by anyone who wants to build another bridge.I 'm afraid I ca n't understand your analogy .
Perhaps if it were in terms of a car design failure.. .</tokentext>
<sentencetext>All bridges are essentially "open source".
Plenty of bridges have failed, but the failures are right out there in the open, ready to be studied by anyone who wants to build another bridge.I'm afraid I can't understand your analogy.
Perhaps if it were in terms of a car design failure...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711133</id>
	<title>ERP Systems Failure</title>
	<author>Guil Rarey</author>
	<datestamp>1247667420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>ERP Systems fail (and this is by no means an exhaustive list, just what I have seen myself)<nobr> <wbr></nobr>...because the sales pitch is to the board of directors and the implementation is at the user level.<nobr> <wbr></nobr>...because I (financial analyst that I am) have a job to do.  Your system helps or it doesn't, but I've got to get my job done.</p><p>The common theme here is that ERP implementations lack humility and respect for the existing business and the people who actually run it.  In pursuit of relatively nebulous "strategic" advantages, an inflexible, underdocumented, undersupported system is shoved down everyone's throat.</p><p>A few years down the road what happens?  The planning guy (me) and the accounting guy had EACH separately reimplemented Access databases to provide the information we need to do our jobs, despite the fact that a module exists in the ERP system to do exactly what we need to do.</p><p>Except that, of course, it's been configured in such a way that it doesn't do any such thing, and we can't change it.   Hell it took me 3 months (not full time) grovelling through help screens to even understand it.  No, there's no budget for training.  Or user support.  And changing things?  Get in line.</p></htmltext>
<tokenext>ERP Systems fail ( and this is by no means an exhaustive list , just what I have seen myself ) ...because the sales pitch is to the board of directors and the implementation is at the user level .
...because I ( financial analyst that I am ) have a job to do .
Your system helps or it does n't , but I 've got to get my job done.The common theme here is that ERP implementations lack humility and respect for the existing business and the people who actually run it .
In pursuit of relatively nebulous " strategic " advantages , an inflexible , underdocumented , undersupported system is shoved down everyone 's throat.A few years down the road what happens ?
The planning guy ( me ) and the accounting guy had EACH separately reimplemented Access databases to provide the information we need to do our jobs , despite the fact that a module exists in the ERP system to do exactly what we need to do.Except that , of course , it 's been configured in such a way that it does n't do any such thing , and we ca n't change it .
Hell it took me 3 months ( not full time ) grovelling through help screens to even understand it .
No , there 's no budget for training .
Or user support .
And changing things ?
Get in line .</tokentext>
<sentencetext>ERP Systems fail (and this is by no means an exhaustive list, just what I have seen myself) ...because the sales pitch is to the board of directors and the implementation is at the user level.
...because I (financial analyst that I am) have a job to do.
Your system helps or it doesn't, but I've got to get my job done.The common theme here is that ERP implementations lack humility and respect for the existing business and the people who actually run it.
In pursuit of relatively nebulous "strategic" advantages, an inflexible, underdocumented, undersupported system is shoved down everyone's throat.A few years down the road what happens?
The planning guy (me) and the accounting guy had EACH separately reimplemented Access databases to provide the information we need to do our jobs, despite the fact that a module exists in the ERP system to do exactly what we need to do.Except that, of course, it's been configured in such a way that it doesn't do any such thing, and we can't change it.
Hell it took me 3 months (not full time) grovelling through help screens to even understand it.
No, there's no budget for training.
Or user support.
And changing things?
Get in line.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28758313</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Anonymous</author>
	<datestamp>1248113880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'd say that the reason for the difference is that the IT industry is more ideology-laden than the construction business. Many nerds have a near religious belief in technology's ability to "fix things".</p></htmltext>
<tokenext>I 'd say that the reason for the difference is that the IT industry is more ideology-laden than the construction business .
Many nerds have a near religious belief in technology 's ability to " fix things " .</tokentext>
<sentencetext>I'd say that the reason for the difference is that the IT industry is more ideology-laden than the construction business.
Many nerds have a near religious belief in technology's ability to "fix things".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28718347</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>dublindan</author>
	<datestamp>1247765040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I disagree. Software is NOT different or unique. It is, however, cheaper to work on and fail at a software project than a bridge construction project. The barrier to entry is lower, so more people get a chance to try (and fail).</htmltext>
<tokenext>I disagree .
Software is NOT different or unique .
It is , however , cheaper to work on and fail at a software project than a bridge construction project .
The barrier to entry is lower , so more people get a chance to try ( and fail ) .</tokentext>
<sentencetext>I disagree.
Software is NOT different or unique.
It is, however, cheaper to work on and fail at a software project than a bridge construction project.
The barrier to entry is lower, so more people get a chance to try (and fail).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706997</id>
	<title>Tolstoy's version</title>
	<author>T.E.D.</author>
	<datestamp>1247689200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>People have written oodles of books on this subject, because there are oodles of different ways to screw up a project.

</p><p>The best insight on this subject comes from Tolstoy, not Brooks. He was talking about families being functional, not software, but the principle is the same.</p><p><div class="quote"><p>All happy families are alike; every unhappy family is unhappy in its own way.</p></div><p>A far better method of approaching this issue is to study projects that <em>don't</em> fail, not ones that do.</p></div>
	</htmltext>
<tokenext>People have written oodles of books on this subject , because there are oodles of different ways to screw up a project .
The best insight on this subject comes from Tolstoy , not Brooks .
He was talking about families being functional , not software , but the principle is the same.All happy families are alike ; every unhappy family is unhappy in its own way.A far better method of approaching this issue is to study projects that do n't fail , not ones that do .</tokentext>
<sentencetext>People have written oodles of books on this subject, because there are oodles of different ways to screw up a project.
The best insight on this subject comes from Tolstoy, not Brooks.
He was talking about families being functional, not software, but the principle is the same.All happy families are alike; every unhappy family is unhappy in its own way.A far better method of approaching this issue is to study projects that don't fail, not ones that do.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709889</id>
	<title>Software is hard</title>
	<author>plopez</author>
	<datestamp>1247659680000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>You can't see it, touch it, smell it, taste it etc. Most of it is an intellectual abstraction many programmers, not to mention the general population, isn't very good at.</p><p>Doing software well requires being an expert in complex problem domains. The domains may require knowledge of complex financial, legal, engineering and manufacturing systems. It may require modeling human relationships. Or combinations of all of the above.</p><p>Where people get things wrong is they do not take the time to understand their problem domain. They look for magic bullets. They need to spend time with their end users and understand the work processes. A little business process modeling goes a long way.</p></htmltext>
<tokenext>You ca n't see it , touch it , smell it , taste it etc .
Most of it is an intellectual abstraction many programmers , not to mention the general population , is n't very good at.Doing software well requires being an expert in complex problem domains .
The domains may require knowledge of complex financial , legal , engineering and manufacturing systems .
It may require modeling human relationships .
Or combinations of all of the above.Where people get things wrong is they do not take the time to understand their problem domain .
They look for magic bullets .
They need to spend time with their end users and understand the work processes .
A little business process modeling goes a long way .</tokentext>
<sentencetext>You can't see it, touch it, smell it, taste it etc.
Most of it is an intellectual abstraction many programmers, not to mention the general population, isn't very good at.Doing software well requires being an expert in complex problem domains.
The domains may require knowledge of complex financial, legal, engineering and manufacturing systems.
It may require modeling human relationships.
Or combinations of all of the above.Where people get things wrong is they do not take the time to understand their problem domain.
They look for magic bullets.
They need to spend time with their end users and understand the work processes.
A little business process modeling goes a long way.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707003</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>fuzzyfuzzyfungus</author>
	<datestamp>1247689200000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>Software certainly does have the disadvantage of being extremely complex(Both internally and, perhaps ultimately more serious, in its interfaces to other software and systems.) What gives it an extra edge of danger, I suspect, versus some other complex projects is the difficulty(particularly for those of limited technical understanding who happen to be involved) of intuitively grasping how the project is going.<br> <br>

You wouldn't want a non-engineer trying to micromanage bridge construction; but anybody can stick his head out the window and see how far across the water the bridge is today. The incipient cracks in the foundation might well be missed(as they often are), and the project can still easily go over time, or over budget; but it is hard(er) for fundamental delusions about progress to crop up. <br> <br>
A layman looking at a complex piece of software doesn't have nearly the same chances. A "nearly there" system with a few serious but non-systemic bugs looks like a broken unusable mess. A brittle demo being coaxed through by a guy who knows the system better than the back of his hand looks a lot like an intuitive interface. If your institutional structure or culture has any of the factors that encourage delusions, lying, yes-manning, or similar, the people who are supposed to have a grand vision of the project won't have the foggiest idea what is going on.</htmltext>
<tokenext>Software certainly does have the disadvantage of being extremely complex ( Both internally and , perhaps ultimately more serious , in its interfaces to other software and systems .
) What gives it an extra edge of danger , I suspect , versus some other complex projects is the difficulty ( particularly for those of limited technical understanding who happen to be involved ) of intuitively grasping how the project is going .
You would n't want a non-engineer trying to micromanage bridge construction ; but anybody can stick his head out the window and see how far across the water the bridge is today .
The incipient cracks in the foundation might well be missed ( as they often are ) , and the project can still easily go over time , or over budget ; but it is hard ( er ) for fundamental delusions about progress to crop up .
A layman looking at a complex piece of software does n't have nearly the same chances .
A " nearly there " system with a few serious but non-systemic bugs looks like a broken unusable mess .
A brittle demo being coaxed through by a guy who knows the system better than the back of his hand looks a lot like an intuitive interface .
If your institutional structure or culture has any of the factors that encourage delusions , lying , yes-manning , or similar , the people who are supposed to have a grand vision of the project wo n't have the foggiest idea what is going on .</tokentext>
<sentencetext>Software certainly does have the disadvantage of being extremely complex(Both internally and, perhaps ultimately more serious, in its interfaces to other software and systems.
) What gives it an extra edge of danger, I suspect, versus some other complex projects is the difficulty(particularly for those of limited technical understanding who happen to be involved) of intuitively grasping how the project is going.
You wouldn't want a non-engineer trying to micromanage bridge construction; but anybody can stick his head out the window and see how far across the water the bridge is today.
The incipient cracks in the foundation might well be missed(as they often are), and the project can still easily go over time, or over budget; but it is hard(er) for fundamental delusions about progress to crop up.
A layman looking at a complex piece of software doesn't have nearly the same chances.
A "nearly there" system with a few serious but non-systemic bugs looks like a broken unusable mess.
A brittle demo being coaxed through by a guy who knows the system better than the back of his hand looks a lot like an intuitive interface.
If your institutional structure or culture has any of the factors that encourage delusions, lying, yes-manning, or similar, the people who are supposed to have a grand vision of the project won't have the foggiest idea what is going on.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708851</id>
	<title>Re:Tolstoy's version</title>
	<author>Anonymous</author>
	<datestamp>1247655060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Study both, or else you'll get the halo effect.  That means everything that a bad project does is bad, inversely every project that works is doing everything okay.</p></htmltext>
<tokenext>Study both , or else you 'll get the halo effect .
That means everything that a bad project does is bad , inversely every project that works is doing everything okay .</tokentext>
<sentencetext>Study both, or else you'll get the halo effect.
That means everything that a bad project does is bad, inversely every project that works is doing everything okay.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706997</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711415</id>
	<title>The Right ISBN</title>
	<author>TimSSG</author>
	<datestamp>1247669640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>978-1438944241

Tim S.</htmltext>
<tokenext>978-1438944241 Tim S .</tokentext>
<sentencetext>978-1438944241

Tim S.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706565</id>
	<title>This story...</title>
	<author>jornak</author>
	<datestamp>1247687400000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>... is literally full of fail.</p></htmltext>
<tokenext>... is literally full of fail .</tokentext>
<sentencetext>... is literally full of fail.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706957</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Anonymous</author>
	<datestamp>1247689020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"Software Engineers" are one of the few types of engineers that are not liable for the failure of the systems they create. They're also one of the few engineers that usually see construction start before the designs are complete.</p><p>Additionally, software prototypes don't live in the same realm as other prototypes. You can show a proof of concept in software, and then something happens when you scale it up that you weren't expecting, or someone just screws up writing their piece of the code and it takes two years to track down a mis-placed keystroke. If it's a third-party product (as with this book's subject matter), it's even worse, because you call support and everyone's trying to determine how they can shift the blame to someone else and clear their support tickets rather than actually help someone out.</p></htmltext>
<tokenext>" Software Engineers " are one of the few types of engineers that are not liable for the failure of the systems they create .
They 're also one of the few engineers that usually see construction start before the designs are complete.Additionally , software prototypes do n't live in the same realm as other prototypes .
You can show a proof of concept in software , and then something happens when you scale it up that you were n't expecting , or someone just screws up writing their piece of the code and it takes two years to track down a mis-placed keystroke .
If it 's a third-party product ( as with this book 's subject matter ) , it 's even worse , because you call support and everyone 's trying to determine how they can shift the blame to someone else and clear their support tickets rather than actually help someone out .</tokentext>
<sentencetext>"Software Engineers" are one of the few types of engineers that are not liable for the failure of the systems they create.
They're also one of the few engineers that usually see construction start before the designs are complete.Additionally, software prototypes don't live in the same realm as other prototypes.
You can show a proof of concept in software, and then something happens when you scale it up that you weren't expecting, or someone just screws up writing their piece of the code and it takes two years to track down a mis-placed keystroke.
If it's a third-party product (as with this book's subject matter), it's even worse, because you call support and everyone's trying to determine how they can shift the blame to someone else and clear their support tickets rather than actually help someone out.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28714017</id>
	<title>Re:Didn't need a book to know this</title>
	<author>Matje</author>
	<datestamp>1247738100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>So what you're saying is that developers should become better at:<br>
<br>
- eliciting requirements<br>
- designing simple, usable software<br>
<br>
The prevailing mood on<nobr> <wbr></nobr>/. seems to be that users should become better at expressing their requirements. I find that baffling; it's like walking into a restaurant and having the chef come up to you to ask how many teaspoons of cumin should go into your dish. User's don't have requirements - the whole concept was made up by developers in response to complaints that they were developing sh*t software. The focus on requirements is a symptom, not a cure. Instead we should focus on empathizing with users: what is it they are trying to achieve and in what context are those goals embedded?<br>
<br>

[blatant self-promotion] <a href="http://www.renvl.nl/" title="renvl.nl">my company</a> [renvl.nl] actually works that way, with considerable success (measured by happy clients)[/]</htmltext>
<tokenext>So what you 're saying is that developers should become better at : - eliciting requirements - designing simple , usable software The prevailing mood on / .
seems to be that users should become better at expressing their requirements .
I find that baffling ; it 's like walking into a restaurant and having the chef come up to you to ask how many teaspoons of cumin should go into your dish .
User 's do n't have requirements - the whole concept was made up by developers in response to complaints that they were developing sh * t software .
The focus on requirements is a symptom , not a cure .
Instead we should focus on empathizing with users : what is it they are trying to achieve and in what context are those goals embedded ?
[ blatant self-promotion ] my company [ renvl.nl ] actually works that way , with considerable success ( measured by happy clients ) [ / ]</tokentext>
<sentencetext>So what you're saying is that developers should become better at:

- eliciting requirements
- designing simple, usable software

The prevailing mood on /.
seems to be that users should become better at expressing their requirements.
I find that baffling; it's like walking into a restaurant and having the chef come up to you to ask how many teaspoons of cumin should go into your dish.
User's don't have requirements - the whole concept was made up by developers in response to complaints that they were developing sh*t software.
The focus on requirements is a symptom, not a cure.
Instead we should focus on empathizing with users: what is it they are trying to achieve and in what context are those goals embedded?
[blatant self-promotion] my company [renvl.nl] actually works that way, with considerable success (measured by happy clients)[/]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707141</id>
	<title>"New Systems" are never created.</title>
	<author>goffster</author>
	<datestamp>1247689920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A good system is one that evolves constantly from humble beginnings with smart<br>people making and guiding decisions at every step in its evolution.</p><p>You start with a good idea, implement it.   Add more good ideas, discard the bad ones.</p><p>If your system is useful, and supersedes the older slow/bloated one, then it "becomes" the "new system".</p></htmltext>
<tokenext>A good system is one that evolves constantly from humble beginnings with smartpeople making and guiding decisions at every step in its evolution.You start with a good idea , implement it .
Add more good ideas , discard the bad ones.If your system is useful , and supersedes the older slow/bloated one , then it " becomes " the " new system " .</tokentext>
<sentencetext>A good system is one that evolves constantly from humble beginnings with smartpeople making and guiding decisions at every step in its evolution.You start with a good idea, implement it.
Add more good ideas, discard the bad ones.If your system is useful, and supersedes the older slow/bloated one, then it "becomes" the "new system".</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707859</id>
	<title>It's one big poker game</title>
	<author>petes\_PoV</author>
	<datestamp>1247650080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Everyone knows when a project is doomed. However, no-one is willing to report it. The reason is that so many people have bonuses, contracts and reputations at stake that they will always hold out, right up to the last, in the hope that someone else will fold first. Once the first guy admits "there might be a slight problem", everyone else piles in on top of that. Typically blaming the fall-guy for all of their problems, shortcomings, missed deliveries and failures.
<p>
The higher up an organisation you go, the more the people in charge have to lose. Therefore the less likely they are to admit it's a disaster. This goes as far (and often a lot further) as continually pouring in money even when all the signs are screamingly obvious that nothing good will ever come out of it.
</p><p>
<i>The Emperor's New Clothes</i> was obviously written by a long-time predecessor of this book's author.</p></htmltext>
<tokenext>Everyone knows when a project is doomed .
However , no-one is willing to report it .
The reason is that so many people have bonuses , contracts and reputations at stake that they will always hold out , right up to the last , in the hope that someone else will fold first .
Once the first guy admits " there might be a slight problem " , everyone else piles in on top of that .
Typically blaming the fall-guy for all of their problems , shortcomings , missed deliveries and failures .
The higher up an organisation you go , the more the people in charge have to lose .
Therefore the less likely they are to admit it 's a disaster .
This goes as far ( and often a lot further ) as continually pouring in money even when all the signs are screamingly obvious that nothing good will ever come out of it .
The Emperor 's New Clothes was obviously written by a long-time predecessor of this book 's author .</tokentext>
<sentencetext>Everyone knows when a project is doomed.
However, no-one is willing to report it.
The reason is that so many people have bonuses, contracts and reputations at stake that they will always hold out, right up to the last, in the hope that someone else will fold first.
Once the first guy admits "there might be a slight problem", everyone else piles in on top of that.
Typically blaming the fall-guy for all of their problems, shortcomings, missed deliveries and failures.
The higher up an organisation you go, the more the people in charge have to lose.
Therefore the less likely they are to admit it's a disaster.
This goes as far (and often a lot further) as continually pouring in money even when all the signs are screamingly obvious that nothing good will ever come out of it.
The Emperor's New Clothes was obviously written by a long-time predecessor of this book's author.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707259</id>
	<title>classes of problems</title>
	<author>Anonymous</author>
	<datestamp>1247690580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><b>Communication</b> - Ill defined or changing specifications and poor documentation make development and testing very difficult.<br>
<b>Technical</b> - Large systems tend to be very complicated and it's difficult and expensive to make them fault tolerant and build in the sort of redundancy, validation, and security that make critical systems reliable.<br>
<b>Leadership</b> - Decision makers on the client and supplier side often don't know enough details about various parts of the project to really know what they want much less what they need.<br>
<b>Organizational</b> - Setting deadlines before defining the scope of the project, belligerent coworkers and other HR issues,  uncooperative clients, cutting testing time to meet deadlines, and other general issues within the organizations can lead to death march development and other undesirable situations.</htmltext>
<tokenext>Communication - Ill defined or changing specifications and poor documentation make development and testing very difficult .
Technical - Large systems tend to be very complicated and it 's difficult and expensive to make them fault tolerant and build in the sort of redundancy , validation , and security that make critical systems reliable .
Leadership - Decision makers on the client and supplier side often do n't know enough details about various parts of the project to really know what they want much less what they need .
Organizational - Setting deadlines before defining the scope of the project , belligerent coworkers and other HR issues , uncooperative clients , cutting testing time to meet deadlines , and other general issues within the organizations can lead to death march development and other undesirable situations .</tokentext>
<sentencetext>Communication - Ill defined or changing specifications and poor documentation make development and testing very difficult.
Technical - Large systems tend to be very complicated and it's difficult and expensive to make them fault tolerant and build in the sort of redundancy, validation, and security that make critical systems reliable.
Leadership - Decision makers on the client and supplier side often don't know enough details about various parts of the project to really know what they want much less what they need.
Organizational - Setting deadlines before defining the scope of the project, belligerent coworkers and other HR issues,  uncooperative clients, cutting testing time to meet deadlines, and other general issues within the organizations can lead to death march development and other undesirable situations.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706663</id>
	<title>Alot of Software is Shit</title>
	<author>Anonymous</author>
	<datestamp>1247687760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Let's be real here for a moment...</p><p>People who make alot more than I do look at a list of features. They don't tend to ask peons like me if these features are implemented in a reasonable way.</p><p>I'm not given the opportunity to warn of an impending clusterfuck until it's to late. By then it's not just my problem, it's everybody's.</p><p>Of course by the time it gets that far it is to late to turn around.</p><p>By the way, I heard second hand of very senior people at a company being fired because of an SAP implementation gone awry.</p><p>Me - I cram good websites in to shitty content managements systems. Generally i could personally develop most of the features that are in these CMSes if instead of dicking around with them I was just writing code.</p><p>I have personally spend over 3 days implementing a drop down list...</p></htmltext>
<tokenext>Let 's be real here for a moment...People who make alot more than I do look at a list of features .
They do n't tend to ask peons like me if these features are implemented in a reasonable way.I 'm not given the opportunity to warn of an impending clusterfuck until it 's to late .
By then it 's not just my problem , it 's everybody 's.Of course by the time it gets that far it is to late to turn around.By the way , I heard second hand of very senior people at a company being fired because of an SAP implementation gone awry.Me - I cram good websites in to shitty content managements systems .
Generally i could personally develop most of the features that are in these CMSes if instead of dicking around with them I was just writing code.I have personally spend over 3 days implementing a drop down list.. .</tokentext>
<sentencetext>Let's be real here for a moment...People who make alot more than I do look at a list of features.
They don't tend to ask peons like me if these features are implemented in a reasonable way.I'm not given the opportunity to warn of an impending clusterfuck until it's to late.
By then it's not just my problem, it's everybody's.Of course by the time it gets that far it is to late to turn around.By the way, I heard second hand of very senior people at a company being fired because of an SAP implementation gone awry.Me - I cram good websites in to shitty content managements systems.
Generally i could personally develop most of the features that are in these CMSes if instead of dicking around with them I was just writing code.I have personally spend over 3 days implementing a drop down list...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711525</id>
	<title>Re:Didn't need a book to know this</title>
	<author>Anonymous</author>
	<datestamp>1247670420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>5) The problem cannot be solved with software despite the salesman, executive (or frequently politician) proposing the project claiming it will be.</p></htmltext>
<tokenext>5 ) The problem can not be solved with software despite the salesman , executive ( or frequently politician ) proposing the project claiming it will be .</tokentext>
<sentencetext>5) The problem cannot be solved with software despite the salesman, executive (or frequently politician) proposing the project claiming it will be.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707039</id>
	<title>To buy or to build</title>
	<author>snspdaarf</author>
	<datestamp>1247689380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have seen several COTS projects break up in flight, once as a participant, three times as an observer, and a big part seems to be management not wanting to change their business process to match that of the COTS package. It seems simple to me. Either do things the way the purchased software wants them done, or write your own software to automate your existing processes. Unfortunately, the people that make those kind of decisions will not be the ones that read this book.</htmltext>
<tokenext>I have seen several COTS projects break up in flight , once as a participant , three times as an observer , and a big part seems to be management not wanting to change their business process to match that of the COTS package .
It seems simple to me .
Either do things the way the purchased software wants them done , or write your own software to automate your existing processes .
Unfortunately , the people that make those kind of decisions will not be the ones that read this book .</tokentext>
<sentencetext>I have seen several COTS projects break up in flight, once as a participant, three times as an observer, and a big part seems to be management not wanting to change their business process to match that of the COTS package.
It seems simple to me.
Either do things the way the purchased software wants them done, or write your own software to automate your existing processes.
Unfortunately, the people that make those kind of decisions will not be the ones that read this book.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708327</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>guruevi</author>
	<datestamp>1247652600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There are plenty of projects out there that get killed everyday. Even bridge projects get killed everyday. It's just that you don't notice because it hasn't gone to the compile stage (the building of the bridge) - most bridges get stuck in the political, feasibleness or 'is this really necessary' stage. By then a bridge building project has already consumed thousands if not millions in contractors, engineers, lobbyists and hookers and then in the backlash vendors will sue because somebody already promised they would buy stuff or have stuff made for the bridge but then they cancelled the project.</p><p>Sometimes bridges get 'compiled' or built while having a PHB (*ahem*Palin*ahem*Ted Stevens*ahem*) in charge and that's when you'll notice (the famous bridges to nowhere or unnecessary duplicate bridges) - see also: <a href="http://en.wikipedia.org/wiki/Gravina\_Island\_Bridge" title="wikipedia.org">http://en.wikipedia.org/wiki/Gravina\_Island\_Bridge</a> [wikipedia.org] and <a href="http://en.wikipedia.org/wiki/Bridge\_to\_Nowhere" title="wikipedia.org">http://en.wikipedia.org/wiki/Bridge\_to\_Nowhere</a> [wikipedia.org]</p><p>It's tax payers money, it's just a line item on the state or federal budget and compared to other items on the list (defense costs, political advertisements and toilet bowls) it's really nothing to mention.</p></htmltext>
<tokenext>There are plenty of projects out there that get killed everyday .
Even bridge projects get killed everyday .
It 's just that you do n't notice because it has n't gone to the compile stage ( the building of the bridge ) - most bridges get stuck in the political , feasibleness or 'is this really necessary ' stage .
By then a bridge building project has already consumed thousands if not millions in contractors , engineers , lobbyists and hookers and then in the backlash vendors will sue because somebody already promised they would buy stuff or have stuff made for the bridge but then they cancelled the project.Sometimes bridges get 'compiled ' or built while having a PHB ( * ahem * Palin * ahem * Ted Stevens * ahem * ) in charge and that 's when you 'll notice ( the famous bridges to nowhere or unnecessary duplicate bridges ) - see also : http : //en.wikipedia.org/wiki/Gravina \ _Island \ _Bridge [ wikipedia.org ] and http : //en.wikipedia.org/wiki/Bridge \ _to \ _Nowhere [ wikipedia.org ] It 's tax payers money , it 's just a line item on the state or federal budget and compared to other items on the list ( defense costs , political advertisements and toilet bowls ) it 's really nothing to mention .</tokentext>
<sentencetext>There are plenty of projects out there that get killed everyday.
Even bridge projects get killed everyday.
It's just that you don't notice because it hasn't gone to the compile stage (the building of the bridge) - most bridges get stuck in the political, feasibleness or 'is this really necessary' stage.
By then a bridge building project has already consumed thousands if not millions in contractors, engineers, lobbyists and hookers and then in the backlash vendors will sue because somebody already promised they would buy stuff or have stuff made for the bridge but then they cancelled the project.Sometimes bridges get 'compiled' or built while having a PHB (*ahem*Palin*ahem*Ted Stevens*ahem*) in charge and that's when you'll notice (the famous bridges to nowhere or unnecessary duplicate bridges) - see also: http://en.wikipedia.org/wiki/Gravina\_Island\_Bridge [wikipedia.org] and http://en.wikipedia.org/wiki/Bridge\_to\_Nowhere [wikipedia.org]It's tax payers money, it's just a line item on the state or federal budget and compared to other items on the list (defense costs, political advertisements and toilet bowls) it's really nothing to mention.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</id>
	<title>Software Projects vs. Traditional Projects</title>
	<author>religious freak</author>
	<datestamp>1247687520000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>I was discussing with a friend how software projects are probably the most difficult to run and predict, especially with very large projects.  He disagreed and said that all large projects are difficult - when you're building a bridge a multitude of things can and do go wrong.  <br> <br>
That's obviously true, but how many bridges never get finished compared to the number of software projects that never get finished?  It seems project management is very difficult for IT related stuff.  So am I just being IT centric in thinking our projects are more difficult than most?</htmltext>
<tokenext>I was discussing with a friend how software projects are probably the most difficult to run and predict , especially with very large projects .
He disagreed and said that all large projects are difficult - when you 're building a bridge a multitude of things can and do go wrong .
That 's obviously true , but how many bridges never get finished compared to the number of software projects that never get finished ?
It seems project management is very difficult for IT related stuff .
So am I just being IT centric in thinking our projects are more difficult than most ?</tokentext>
<sentencetext>I was discussing with a friend how software projects are probably the most difficult to run and predict, especially with very large projects.
He disagreed and said that all large projects are difficult - when you're building a bridge a multitude of things can and do go wrong.
That's obviously true, but how many bridges never get finished compared to the number of software projects that never get finished?
It seems project management is very difficult for IT related stuff.
So am I just being IT centric in thinking our projects are more difficult than most?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707015</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Z34107</author>
	<datestamp>1247689260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My theory:  If you build a bridge, and it falls over, you <i>go to jail</i>.  Additionally, people die.</p><p>I guess the kinds of project managers described ("the know-it-all, the micromanager") that evidently exist in IT would all be felons in the bridge-building world.  But dammit Jim, IANACE (I Am Not a Civil Engineer), nor a project manager, nor an IT manager.</p></htmltext>
<tokenext>My theory : If you build a bridge , and it falls over , you go to jail .
Additionally , people die.I guess the kinds of project managers described ( " the know-it-all , the micromanager " ) that evidently exist in IT would all be felons in the bridge-building world .
But dammit Jim , IANACE ( I Am Not a Civil Engineer ) , nor a project manager , nor an IT manager .</tokentext>
<sentencetext>My theory:  If you build a bridge, and it falls over, you go to jail.
Additionally, people die.I guess the kinds of project managers described ("the know-it-all, the micromanager") that evidently exist in IT would all be felons in the bridge-building world.
But dammit Jim, IANACE (I Am Not a Civil Engineer), nor a project manager, nor an IT manager.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707301</id>
	<title>Re:Too Many Words in Sentence</title>
	<author>FishWithAHammer</author>
	<datestamp>1247690700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Except that there very much is a fifth. A good project manager enables his people to get their jobs done more effectively, and shields them from administrative bullshit.</p><p>Just because your PMs have sucked doesn't mean the rest of us haven't worked for great ones.</p></htmltext>
<tokenext>Except that there very much is a fifth .
A good project manager enables his people to get their jobs done more effectively , and shields them from administrative bullshit.Just because your PMs have sucked does n't mean the rest of us have n't worked for great ones .</tokentext>
<sentencetext>Except that there very much is a fifth.
A good project manager enables his people to get their jobs done more effectively, and shields them from administrative bullshit.Just because your PMs have sucked doesn't mean the rest of us haven't worked for great ones.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706585</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708681</id>
	<title>A better book would be "How New Systems Succeed"..</title>
	<author>russotto</author>
	<datestamp>1247654280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Because why they fail is not all that interesting.  A project specified mostly by people who don't know what the system is supposed to do, implemented by people who don't understand the business, replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present.  What could possibly go wrong?</p><p>Add on top of that a COTS requirement, so it's a matter of making the requirements fit the software's limitations (while still fitting the business), and you have an almost guaranteed recipe for failure.  Particularly when the users \_won't\_ adapt.</p></htmltext>
<tokenext>Because why they fail is not all that interesting .
A project specified mostly by people who do n't know what the system is supposed to do , implemented by people who do n't understand the business , replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present .
What could possibly go wrong ? Add on top of that a COTS requirement , so it 's a matter of making the requirements fit the software 's limitations ( while still fitting the business ) , and you have an almost guaranteed recipe for failure .
Particularly when the users \ _wo n't \ _ adapt .</tokentext>
<sentencetext>Because why they fail is not all that interesting.
A project specified mostly by people who don't know what the system is supposed to do, implemented by people who don't understand the business, replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present.
What could possibly go wrong?Add on top of that a COTS requirement, so it's a matter of making the requirements fit the software's limitations (while still fitting the business), and you have an almost guaranteed recipe for failure.
Particularly when the users \_won't\_ adapt.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707383</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>slodan</author>
	<datestamp>1247691060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In many ways, software engineering (as opposed to programming) is just leaving its infancy.  I think we'll see the industry evolve to become more similar to other engineering disciplines within a decade or two.  We have only recently gained the level of differentiation and specialization that other engineers have had for years.<br> <br>

I also think that the constant comparisons between software engineering and civil engineering (the "bridge" analogy) are misleading.  Plenty of other engineering projects fail in other disciplines, and they do it as silently as software projects.  I don't have any comparison data on failure rates, but I suspect that the rates are more closely related to project size than to engineering discipline.</htmltext>
<tokenext>In many ways , software engineering ( as opposed to programming ) is just leaving its infancy .
I think we 'll see the industry evolve to become more similar to other engineering disciplines within a decade or two .
We have only recently gained the level of differentiation and specialization that other engineers have had for years .
I also think that the constant comparisons between software engineering and civil engineering ( the " bridge " analogy ) are misleading .
Plenty of other engineering projects fail in other disciplines , and they do it as silently as software projects .
I do n't have any comparison data on failure rates , but I suspect that the rates are more closely related to project size than to engineering discipline .</tokentext>
<sentencetext>In many ways, software engineering (as opposed to programming) is just leaving its infancy.
I think we'll see the industry evolve to become more similar to other engineering disciplines within a decade or two.
We have only recently gained the level of differentiation and specialization that other engineers have had for years.
I also think that the constant comparisons between software engineering and civil engineering (the "bridge" analogy) are misleading.
Plenty of other engineering projects fail in other disciplines, and they do it as silently as software projects.
I don't have any comparison data on failure rates, but I suspect that the rates are more closely related to project size than to engineering discipline.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706957</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28713559</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Hognoxious</author>
	<datestamp>1247775840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We've been building bridges for thousands of years.  We've been building software for a few decades.</p><p>Nobody thinks you can turn a bridge into a hospital by moving a few spars.  But changing a stock control program to do invoicing needs "just a bit of typing".</p></htmltext>
<tokenext>We 've been building bridges for thousands of years .
We 've been building software for a few decades.Nobody thinks you can turn a bridge into a hospital by moving a few spars .
But changing a stock control program to do invoicing needs " just a bit of typing " .</tokentext>
<sentencetext>We've been building bridges for thousands of years.
We've been building software for a few decades.Nobody thinks you can turn a bridge into a hospital by moving a few spars.
But changing a stock control program to do invoicing needs "just a bit of typing".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706577</id>
	<title>users?</title>
	<author>Anonymous</author>
	<datestamp>1247687460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>most new systems fail because the user doesn't read what he is doing, and then they blame it on the system</htmltext>
<tokenext>most new systems fail because the user does n't read what he is doing , and then they blame it on the system</tokentext>
<sentencetext>most new systems fail because the user doesn't read what he is doing, and then they blame it on the system</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706931</id>
	<title>Re:Software Projects vs. Traditional Projects</title>
	<author>Dr\_Barnowl</author>
	<datestamp>1247688900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Indeed. With a bridge, the requirements are simple and obvious - you want a structure that permits transit from one side of some geographical divide to the other. All the detail is just detail, the end requirement is invariable.</p><p>With a software project, the requirements are often poorly understood or even unknown - a nebulous sense that things could be better if only we had better software. Often the software itself will reveal the real requirements.</p></htmltext>
<tokenext>Indeed .
With a bridge , the requirements are simple and obvious - you want a structure that permits transit from one side of some geographical divide to the other .
All the detail is just detail , the end requirement is invariable.With a software project , the requirements are often poorly understood or even unknown - a nebulous sense that things could be better if only we had better software .
Often the software itself will reveal the real requirements .</tokentext>
<sentencetext>Indeed.
With a bridge, the requirements are simple and obvious - you want a structure that permits transit from one side of some geographical divide to the other.
All the detail is just detail, the end requirement is invariable.With a software project, the requirements are often poorly understood or even unknown - a nebulous sense that things could be better if only we had better software.
Often the software itself will reveal the real requirements.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708705</id>
	<title>Misperception</title>
	<author>Anonymous</author>
	<datestamp>1247654400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch.</p></div><p>No wonder they have problems!  One doesn't "turn" a switch, one "flips" it!  Problem solved.</p></div>
	</htmltext>
<tokenext>However , the firm ( usually wrongly ) thinks that such a project comprises nothing more than installing the software , training some users , converting some data , and turning a switch.No wonder they have problems !
One does n't " turn " a switch , one " flips " it !
Problem solved .</tokentext>
<sentencetext>However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch.No wonder they have problems!
One doesn't "turn" a switch, one "flips" it!
Problem solved.
	</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707275
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708779
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707383
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706957
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28713559
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707805
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28718347
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28758313
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707015
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707093
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709087
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707003
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707205
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711343
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711525
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708851
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706997
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707407
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707769
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28714017
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707243
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709155
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707563
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28714795
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708681
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709335
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708681
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706953
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707301
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706585
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708145
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706957
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708753
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706997
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708327
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707571
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708225
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706957
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711929
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706931
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_07_15_1255258_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28715159
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706793
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707141
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706663
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708681
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709335
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28714795
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706585
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707301
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707259
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707039
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709889
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706997
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708753
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708851
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706607
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709155
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707769
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707003
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707563
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711343
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28718347
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28715159
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706957
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708145
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707383
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708225
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707093
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711929
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706825
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708779
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707205
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28708327
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707407
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707015
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28758313
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707571
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28709087
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707243
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706931
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28713559
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_07_15_1255258.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706615
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28711525
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28706953
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707805
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28707275
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_07_15_1255258.28714017
</commentlist>
</conversation>
