<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Getting Better to Stay the Same?</title>
	<atom:link href="http://www.projectmanagementguide.org/project-management/getting-better-to-stay-the-same/feed" rel="self" type="application/rss+xml" />
	<link>http://www.projectmanagementguide.org/project-management/getting-better-to-stay-the-same</link>
	<description>Your own project management guide</description>
	<lastBuildDate>Fri, 27 Jan 2012 18:16:20 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://www.projectmanagementguide.org/project-management/getting-better-to-stay-the-same#comment-1548</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Mon, 11 May 2009 09:06:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.projectmanagementguide.org/?p=85#comment-1548</guid>
		<description>Things don&#039;t look better and I don&#039;t expect they will anytime soon. PM tools aren&#039;t the problem. People are.

From my perspective the basic thing which drove, drives and will drive results like those in last CHAOS report is people mentality. We accept mediocrity. When we install new software we expect to find bugs there. Heck, we believe our operating systems should be restarted from time to time and fully reinstalled every couple of years.

Do we expect our vacuum cleaners or cars sometimes won&#039;t work like they should? Do we expect food we buy to turn out crappy on occasions? We don&#039;t.

With software it is different. And since &quot;everyone delivers crappy software projects&quot; and &quot;everyone lies in schedules&quot; and &quot;everyoneover-promise and under-deliver&quot; we won&#039;t be appalling if we do too.

Even when people don&#039;t admit that I believe it&#039;s common way of thinking. And it doesn&#039;t surprise me in any way to see poor statistics as a result.</description>
		<content:encoded><![CDATA[<p>Things don&#8217;t look better and I don&#8217;t expect they will anytime soon. PM tools aren&#8217;t the problem. People are.</p>
<p>From my perspective the basic thing which drove, drives and will drive results like those in last CHAOS report is people mentality. We accept mediocrity. When we install new software we expect to find bugs there. Heck, we believe our operating systems should be restarted from time to time and fully reinstalled every couple of years.</p>
<p>Do we expect our vacuum cleaners or cars sometimes won&#8217;t work like they should? Do we expect food we buy to turn out crappy on occasions? We don&#8217;t.</p>
<p>With software it is different. And since &#8220;everyone delivers crappy software projects&#8221; and &#8220;everyone lies in schedules&#8221; and &#8220;everyoneover-promise and under-deliver&#8221; we won&#8217;t be appalling if we do too.</p>
<p>Even when people don&#8217;t admit that I believe it&#8217;s common way of thinking. And it doesn&#8217;t surprise me in any way to see poor statistics as a result.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ed Taaffe</title>
		<link>http://www.projectmanagementguide.org/project-management/getting-better-to-stay-the-same#comment-1541</link>
		<dc:creator>Ed Taaffe</dc:creator>
		<pubDate>Sat, 09 May 2009 15:35:54 +0000</pubDate>
		<guid isPermaLink="false">http://www.projectmanagementguide.org/?p=85#comment-1541</guid>
		<description>I&#039;m not buying the Red Queen theory. If any trend has emerged, it is that we do a lot less custom software and a lot more COTS implementations.

When we did Custom systems, there were a great many skilful people involved who primarily followed SDLC processes designed to deliver systems that met busyness requirements.  That part of projects worked pretty well, it was the time to test and stabilise them that caused problems.
Today we have no process to do any of this and no few skilled people involved.
Project managers can’t deliver software without a proper software training any more than butchers can fly to the moon and that is the big mistake.

Much of the cause is the relationships developed between business and suppliers who are adept at driving a wedge between businesses and their IT staff in order to serve their own ends.
If project managers are to take responsibility for the problems and start fixing them then first they need to either be trained or properly advised and secondly they need to have the power to make those decisions.
Currently neither case are generally the case.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not buying the Red Queen theory. If any trend has emerged, it is that we do a lot less custom software and a lot more COTS implementations.</p>
<p>When we did Custom systems, there were a great many skilful people involved who primarily followed SDLC processes designed to deliver systems that met busyness requirements.  That part of projects worked pretty well, it was the time to test and stabilise them that caused problems.<br />
Today we have no process to do any of this and no few skilled people involved.<br />
Project managers can’t deliver software without a proper software training any more than butchers can fly to the moon and that is the big mistake.</p>
<p>Much of the cause is the relationships developed between business and suppliers who are adept at driving a wedge between businesses and their IT staff in order to serve their own ends.<br />
If project managers are to take responsibility for the problems and start fixing them then first they need to either be trained or properly advised and secondly they need to have the power to make those decisions.<br />
Currently neither case are generally the case.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Phillips</title>
		<link>http://www.projectmanagementguide.org/project-management/getting-better-to-stay-the-same#comment-1540</link>
		<dc:creator>Richard Phillips</dc:creator>
		<pubDate>Sat, 09 May 2009 12:45:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.projectmanagementguide.org/?p=85#comment-1540</guid>
		<description>Interesting comments.  My background is slightly different coming from business side (rather than IT) project management within Financial Services, where projects tend not be massive.  However, one theme I have seen is a correlation between success and those projects where business and technology work together throughout the project life cycle.  E.g. if the project is primarily a business change/process improvement one then the business is responsible for the success of the project and lead-manages the overall project.  I am interested in other views on how much of project failure is not just because we are doing more complex things but is also down to lack of / inappropriate: (i) project ownership; and (ii) rigorous analysis of what we want to do and how we want the process to be once it is changed.  Or put another way, are we disappointed with the family outing because we all got in the car without thinking where we wanted to go or what we wanted to do when we got there?</description>
		<content:encoded><![CDATA[<p>Interesting comments.  My background is slightly different coming from business side (rather than IT) project management within Financial Services, where projects tend not be massive.  However, one theme I have seen is a correlation between success and those projects where business and technology work together throughout the project life cycle.  E.g. if the project is primarily a business change/process improvement one then the business is responsible for the success of the project and lead-manages the overall project.  I am interested in other views on how much of project failure is not just because we are doing more complex things but is also down to lack of / inappropriate: (i) project ownership; and (ii) rigorous analysis of what we want to do and how we want the process to be once it is changed.  Or put another way, are we disappointed with the family outing because we all got in the car without thinking where we wanted to go or what we wanted to do when we got there?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

