<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Deadline First, Plan Second</title>
	<link>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/</link>
	<description></description>
	<pubDate>Mon, 08 Sep 2008 08:34:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Chip Temm</title>
		<link>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/#comment-21829</link>
		<dc:creator>Chip Temm</dc:creator>
		<pubDate>Tue, 24 Jun 2008 09:56:59 +0000</pubDate>
		<guid>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/#comment-21829</guid>
		<description>Agree with the commenters above. There is nothing wrong with a deadline first approach... as long as scope is treated as a variable.

The idea that any project can be successful if it is just given a long enough schedule is just as harmful as the idea that any project can be successful if it is just given enough resources.

We need deadlines and budgets to set boundaries. We can then determine how much scope we can acheive within those bounds.

I think the idea of internal and external "release dates" for the deadlines is an important nuance that gets missed. If marketing publishes externally your deadline and feature list before discussing it with the dev team, you're screwed. But if marketing says we need a release by Sept 30 (the internal deadline) and mgmt says you have these five folks to do it, you can then come back and talk about which lower priority features will not ship. This may end up adjusting the budget and external deadline eventually- or not.</description>
		<content:encoded><![CDATA[<p>Agree with the commenters above. There is nothing wrong with a deadline first approach&#8230; as long as scope is treated as a variable.</p>
<p>The idea that any project can be successful if it is just given a long enough schedule is just as harmful as the idea that any project can be successful if it is just given enough resources.</p>
<p>We need deadlines and budgets to set boundaries. We can then determine how much scope we can acheive within those bounds.</p>
<p>I think the idea of internal and external &#8220;release dates&#8221; for the deadlines is an important nuance that gets missed. If marketing publishes externally your deadline and feature list before discussing it with the dev team, you&#8217;re screwed. But if marketing says we need a release by Sept 30 (the internal deadline) and mgmt says you have these five folks to do it, you can then come back and talk about which lower priority features will not ship. This may end up adjusting the budget and external deadline eventually- or not.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jermayn Parker</title>
		<link>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/#comment-10117</link>
		<dc:creator>Jermayn Parker</dc:creator>
		<pubDate>Thu, 08 Nov 2007 02:44:18 +0000</pubDate>
		<guid>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/#comment-10117</guid>
		<description>Tend to agree with this. With major releases some stuff does not need to be completely finished and finalised (agreeing with what Richard said) and they can be implemented at a later release.

In saying all that however, it is best to try and get as much as possible done before the main release.</description>
		<content:encoded><![CDATA[<p>Tend to agree with this. With major releases some stuff does not need to be completely finished and finalised (agreeing with what Richard said) and they can be implemented at a later release.</p>
<p>In saying all that however, it is best to try and get as much as possible done before the main release.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Morton</title>
		<link>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/#comment-9948</link>
		<dc:creator>Richard Morton</dc:creator>
		<pubDate>Tue, 06 Nov 2007 14:02:02 +0000</pubDate>
		<guid>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/#comment-9948</guid>
		<description>Given a DFPS project, the only sensible thing to do is to prioritise the requirements into must-haves, should-haves, and could-haves. In other words if the time is fixed, then the requirements or the quality needs to change. Of course there could still be the problem that there are too many must-haves to fit, and it is still very difficult to persuade a stakeholder that although they might not get all the should-haves and may not get any of the could-haves, it would still be a successful project.</description>
		<content:encoded><![CDATA[<p>Given a DFPS project, the only sensible thing to do is to prioritise the requirements into must-haves, should-haves, and could-haves. In other words if the time is fixed, then the requirements or the quality needs to change. Of course there could still be the problem that there are too many must-haves to fit, and it is still very difficult to persuade a stakeholder that although they might not get all the should-haves and may not get any of the could-haves, it would still be a successful project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Max Design - standards based web design, development and training &#187; Some links for light reading (6/11/07)</title>
		<link>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/#comment-9939</link>
		<dc:creator>Max Design - standards based web design, development and training &#187; Some links for light reading (6/11/07)</dc:creator>
		<pubDate>Tue, 06 Nov 2007 11:51:26 +0000</pubDate>
		<guid>http://blog.geekmanager.co.uk/2007/10/30/deadline-first-plan-second/#comment-9939</guid>
		<description>[...] Deadline First, Plan Second [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Deadline First, Plan Second [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
