|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/srakitin/OLD/newsletter/vol4/no8/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Food for Thought: Estimating and Scheduling for Dummies, Part 2</title>
<link href="/newsletter/StyleSheet.css" rel="stylesheet" type="text/css">
</head>
<OpenTracking/>
<!-- Do NOT delete previous line if you want to get statistics on the number of opened emails -->
<body>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0">
<tr align="center" valign="top">
<td colspan="2"><img src="/newsletter/images/FoodForThoughtLogo.gif" alt="Food for Thought" width="600" height="105"></td>
</tr>
<tr class="Reference">
<td align="left" valign="top"><p>An e-newsletter published by<br>
Software Quality Consulting, Inc. </p>
</td>
<td align="right" valign="top"><p>October 2007, Vol. 4 No. 8 <br>
[<a href="/newsletter/vol4/no8/vol4no8.txt" target="_blank">Text-only Version</a>] </p>
</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top"> <p> Welcome to <em><strong>Food for Thought™</strong></em>, an e-newsletter from <strong> <a href="/index.html?Intro" target="_blank">Software Quality Consulting</a></strong>. I've created free subscriptions for my valued business contacts. If you find this newsletter informative, I encourage you to continue reading. Feel free to pass this newsletter along to colleagues by clicking this <strong><a href="http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6">Forward Email</a></strong> link. If you’ve received this newsletter from a colleague and would like to subscribe, please click this <strong> <a href="/newsletter/Subscribe.htm?Newsletter" target="_blank">Enter New Subscription </a></strong>link. If you don't wish to receive this newsletter, click the <strong><a href="#bottom">SafeUnSubscribe</a></strong>™ link at the bottom of this newsletter, and you won’t be bothered again.</p>
<p>Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to <strong><a href="mailto:[email protected]">[email protected]</a></strong>.</p></td>
</tr>
</table>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/InThisIssue.gif" alt="In This Issue" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p>In <a href="#article"><strong>This Months’ Topic</strong></a>, I discuss practical techniques to improve your estimating and scheduling skills…<br>
<br>
Regular features to look for each month are:</p>
<ul>
<li> <a href="#morsel"><strong>Monthly Morsels</strong></a><br>
Hints, tips, techniques and reference info related to this month’s topic</li>
</ul>
<ul>
<li> <a href="#calendar"><strong>Calendar</strong></a><br>
Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development</li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<a name="article"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><p align="center"><img src="/newsletter/images/ThisMonthsTopic.gif" alt="This Month's Topic" width="114" height="37"><br>
</td>
<td width="15"> </td>
<td width="471" align="left" valign="top" class="BodyText"><p align="center" class="Headline">Estimating and Scheduling for Dummies</p>
<p align="center" class="Headline">Part II - Estimating </p>
<p>What is it about schedules that cause seemingly rational people to behave so irrationally? How many times has this happened to you…</p>
<ul>
<li> Your boss asks you for a schedule for a set of new features described only by a few bullets in a Marketing PowerPoint presentation. </li>
</ul>
<ul>
<li> You reply, “We don’t have enough information to create a schedule.” </li>
</ul>
<ul>
<li> Your boss says, “Either you come up with a schedule or I will make one up for you! And by the way, it has to be done by end of the quarter.” </li>
</ul>
<p>So you make up a bogus schedule that you know can’t be met. The project starts and eventually encounters problems (what a surprise!). Features are cut and testing time is reduced. The software is released very late, with far too many bugs, and doesn’t have all the promised features. Needless to say, your boss and your customers are not happy.</p>
<p><strong> The Games We Play </strong></p>
<p>In my recent e-newsletter on <strong><a href="/newsletter/vol4/no6/vol4no6.html" target="_blank">Mission Critical Software</a></strong>, I discussed the incredible accomplishments of the Space Shuttle Team in developing highly reliable software for the on-board computers. One of the basic tenets of the Space Shuttle development team was:</p>
<p align="center"><strong> To deliver grown-up software,<br>
we need to behave like grown-ups. </strong></p>
<p>As Watts Humphrey [2] observed: </p>
<blockquote>
<p>“[...] management’s undisciplined approach to commitments contributes to every one of the five most common causes of project failure:</p>
</blockquote> <ul>
<ul>
<li> Unrealistic schedules </li>
<li> Inappropriate staffing </li>
<li> Changing requirements </li>
<li> Poor quality work </li>
<li> Believing in magic” </li>
</ul>
</ul>
<p>Of all the things software development organizations do, scheduling is one where we rarely behave like grown-ups. Ed Yourdon [1] identified some of the childish scheduling games we play:</p>
<ul>
<li><strong> Doubling and Add Some</strong></li>
</ul>
<blockquote>
<p>In this game, your boss asks you how long it will take you to perform some task. After thinking about the task, you figure it would take you about 1 month to complete the work. Since you were recently burned by bad estimates, you decide to double your estimate to 2 months. Knowing your boss, you decide to add a bit extra just to be on the “safe side”. So a task that should take about one month is estimated at 2.5 months.</p>
</blockquote>
<ul>
<li><strong> Reverse Doubling</strong></li>
</ul>
<blockquote>
<p>In this game, your boss takes your estimate, which he/she knows is inflated, and simply cuts it in half.</p>
</blockquote>
<ul>
<li><strong> Guess the Date</strong></li>
</ul>
<blockquote>
<p>In this silly game, you boss already knows the answer he/she wants. You have to guess until you come up with the answer that the boss wants to hear. </p>
</blockquote> <p>People often make commitments to customers to deliver something without consulting the development and test organizations. As a result, the project team has to develop a schedule by working backwards from the end date. This is what I call a “<strong>scheduled-backwards</strong>” project. On a typical <strong>scheduled-backwards project</strong>:</p>
<ul>
<li> The project starts with a predetermined end date that is set before the requirements are set. </li>
</ul>
<ul>
<li> Customers are promised more than can reasonably be delivered in the promised timeframe. </li>
</ul>
<ul>
<li> Tasks are estimated based on how much time is available rather than how much time the tasks actually require. </li>
</ul>
<ul>
<li> Task interdependencies are not identified since there’s no time to factor them in. </li>
</ul>
<ul>
<li> It is assumed that all the unexpected things that <strong>ALWAYS</strong> happen on every project will somehow <strong>NOT</strong> happen on this project. For example, we know that:</li>
</ul>
<ul>
<ul>
<li> The requirements <strong>WILL</strong> change. </li>
<li> A key member of the project team <strong>WILL</strong> leave. </li>
<li> A key assumption <strong>WILL</strong> prove wrong. </li>
<li> Previously unknown or ignored dependencies <strong>WILL</strong> arise. </li>
<li> Key resources <strong>WILL</strong> be pulled off to fight the next “fire”. </li>
</ul>
</ul>
<p>What happens on <strong>scheduled-backwards projects</strong>? Eventually, the schedule slip can’t be ignored so the Project Manager cuts features and cranks up coding. Whatever process the development team was using is abandoned. Design Reviews are cancelled and testing time is drastically cut. Does this sound familiar? </p>
<p> The result is everyone loses!</p>
<ul>
<li> The <strong>Organization loses</strong> because the release is late, lacks keys features and is very buggy. </li>
</ul>
<ul>
<li> Your <strong>Customers lose</strong> because they have to deal with a late release, without the key features they were expecting, and with far too many bugs. </li>
</ul>
<ul>
<li> Your <strong>Company loses </strong>as your reputation for meeting commitments and delivering quality products suffers. </li>
</ul>
<p> I think it is time to establish some basic <strong>scheduling principles</strong>…</p>
<p><strong> Scheduling Laws of Nature</strong></p>
<p> Here are some basic principles that always apply for schedules:</p>
<ul>
<li><strong> Good schedules can only come from good estimates.</strong></li>
</ul>
<blockquote>
<p>In <strong><a href="/newsletter/vol4/no7/vol4no7.html" target="_blank">last month’s e-newsletter</a></strong>, I defined good estimates as:</p>
</blockquote>
<ul>
<ul>
<li> An estimate is good if it is within X% of how long it actually takes to do the work.</li>
</ul>
</ul>
<blockquote>
<p>Similarly, a <strong>good schedule</strong> is defined as:<strong></strong></p>
</blockquote>
<ul>
<ul>
<li> A good schedule is a schedule based on factual information and one that completes within X% of the predicted end date.</li>
</ul>
</ul>
<blockquote>
<p>As with estimates, you decide <strong>how good</strong> the schedule needs to be based on factors such as business targets, customer commitments, risk, etc.</p>
</blockquote>
<ul>
<li><strong> The goodness of schedules is directly related to the level of detail of the information upon which schedules are based. </strong></li>
</ul>
<blockquote>
<p>Here’s an example of what this means…</p>
<table width="400" border="1" cellpadding="5" cellspacing="0" bordercolor="#000000" class="BodyText">
<tr bgcolor="#D9D9D9">
<td valign="top"><p><strong> With this information available to develop schedules... </strong></p></td>
<td valign="top"><p><strong> You can create schedules accurate to… </strong></p></td>
</tr>
<tr>
<td valign="top"><p> Marketing bullet points </p></td>
<td valign="top"><p> Year </p></td>
</tr>
<tr>
<td valign="top"><p> Software Requirements Spec (SRS) </p></td>
<td valign="top"><p> Quarter within the year </p></td>
</tr>
<tr>
<td valign="top"><p> SRS + High Level Design</p></td>
<td valign="top"><p> Month within the Quarter </p></td>
</tr>
</table></blockquote>
<ul>
<li><strong> When things (such as requirements, resources, assumptions, etc.) change, schedules need to be adjusted to reflect these changes.</strong></li>
</ul>
<blockquote>
<p>One of the most common reasons schedules are not accurate is because we fail to adjust schedules to reflect changes. For some reason, we assume that changes can be accommodated without any impact to the schedule.</p>
</blockquote>
<ul>
<li><strong> There’s no such thing as a schedule-neutral change.</strong></li>
</ul>
<blockquote>
<p>Every change, whether it is to a requirement, a resource, or an assumption clearly has an impact on schedules. Removing features has a schedule impact - and not always the impact you might expect. Often, taking features out means more work, not less.</p>
</blockquote>
<ul>
<li><strong> The best people to develop schedules are people who are actually going to do the work.</strong></li>
</ul>
<blockquote>
<p>Most of us have had to work on projects where schedules have been handed down from on high by who knows who. How motivated are you to meet a schedule set by someone else? Most people aren’t motivated to meet someone else’s schedule - usually because whoever created the schedule has no idea what you do and how you do it.</p>
</blockquote>
<ul>
<li><strong> Microsoft Project (or any other tool) can’t create schedules - only people can create schedules.</strong></li>
</ul>
<blockquote>
<p>The tendency in our industry is to use tools to do everything. Tools can’t create schedules - only people can. Once you have created a schedule, tools can be used to track progress, identify critical paths, etc.</p>
</blockquote>
<p> Now that we have identified some problems and basic principles, let’s look at examples of good scheduling skills.</p>
<p><strong> Good Scheduling Skills</strong></p>
<p>As illustrated in the diagram below…</p>
<ul>
<li> Good requirements lead to good estimates. </li>
</ul>
<ul>
<li> Accurate schedules are based on good estimates. </li>
</ul>
<ul>
<li> Estimating and scheduling activities need to reflect actual resources and dependencies. </li>
</ul>
<ul>
<li> Estimating and scheduling are iterative activities based on many assumptions - documenting these assumptions is critical. </li>
</ul>
<p><img width="471" height="323" src="/newsletter/vol4/no8/vol4no8_clip_image002_0000.jpg"></p>
<p>Once a schedule is created, there <strong>WILL BE GAPS</strong> between what is desired and what can be accomplished. These gaps result from factoring in <strong><a href="/newsletter/vol4/no7/vol4no7.html" target="_blank">targets</a></strong> and <strong><a href="/newsletter/vol4/no7/vol4no7.html" target="_blank">commitments</a></strong>. <strong>Beware!</strong> When a schedule aligns perfectly to the targets and commitments, it usually indicates that this is a <strong>scheduled-backwards</strong> schedule.</p>
<p> Managing the GAPS - the difference between what can be done and what the business would like - is what Project Management is supposed to be about. Good project managers are expert at reconciling these differences and reaching reasonable compromises…</p>
<p><strong> Scheduling Best Practices</strong></p>
<p> Here are a few examples of scheduling best practices…<br>
<br>
</p>
</td>
</tr>
<tr>
<td align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><img width="110" height="166" src="/newsletter/vol4/no8/vol4no8_clip_image002_0001.jpg"> </td>
<td> </td>
<td align="left" valign="top" class="BodyText"><ul>
<li><strong><a href="/training/yellow.html" target="_blank">Yellow Sticky Method</a></strong></li>
</ul>
<blockquote>
<p>My favorite method for developing accurate schedules is the <strong>Yellow Sticky Method</strong>. I like this method because it is simple and works extremely well for small to medium (up to say 25 people or so) project teams. I have taught this method to dozens of project teams who have reported excellent results.</p>
</blockquote>
<ul>
<li><strong><a href="http://www.netmba.com/operations/project/gantt/" target="_blank">Gantt Charts</a></strong></li>
</ul>
<blockquote>
<p>A Gantt chart is a bar chart that illustrates a project schedule. Gantt charts illustrate start and finish dates of terminal elements and summary elements of a project. Some Gantt charts also show the dependency relationships between activities. Gantt charts can show current schedule status using percent-complete shadings and a vertical TODAY line.</p>
<p>Some project management tools (like Microsoft Project) can represent a schedule as a Gantt Chart.</p>
</blockquote>
<ul>
<li><strong><a href="http://www.netmba.com/operations/project/pert/" target="_blank">Program Evaluation and Review Technique (PERT)</a></strong></li>
</ul>
<blockquote>
<p>PERT is a method for analyzing tasks involved in completing a given project, especially time needed to complete each task, and identifying minimum time needed to complete total project. </p>
PERT is used where time rather than cost is most critical factor. Some project management tools can represent a schedule as a PERT chart.</blockquote>
<ul>
<li><strong><a href="http://www.netmba.com/operations/project/cpm/" target="_blank">Critical Path Method (CPM)</a></strong></li>
</ul>
<blockquote>
<p>CPM is a mathematically based algorithm for scheduling a set of project activities. Any project with interdependent activities can apply this method of scheduling. Construct a model that includes the following:</p>
</blockquote>
<ul>
<ul>
<li> A list of all activities required to complete the project. </li>
</ul>
</ul>
<ul>
<ul>
<li> Time (duration) that each activity will take to complete.</li>
</ul>
</ul>
<ul>
<ul>
<li> Dependencies between the activities.</li>
</ul>
</ul>
<blockquote>
<p>CPM is often used in conjunction with PERT. Some project management tools can represent a schedule as a CPM network.</p>
</blockquote>
<ul>
<li><strong><a href="http://en.wikipedia.org/wiki/Critical_chain" target="_blank">Critical Chain Methodology</a></strong></li>
</ul>
<blockquote>
<p>This is without a doubt one of the more complex techniques I’ve seen. The C ritical chain methodology is based on methods and algorithms developed in theory of constraints [4]. In this approach, terminal-element start and finish dates function as random variables. The project is managed not by traditional schedules but rather by using buffer management and a relay race mentality.</p>
</blockquote>
<p><strong> Summary</strong></p>
<p> As Fred Brooks observed:</p>
<blockquote>
<p> “It is difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of managers”. [3]</p>
</blockquote>
<p> Applying basic <strong>Principles of Scheduling</strong> listed above with the <strong><a href="/newsletter/vol4/no7/vol4no7.html" target="_blank">Estimating techniques</a></strong> discussed last month can result in a significant improvement in your ability to become a more Predictable Software Development organization…</p>
‘Til next time…</td>
</tr>
</table>
<br>
<br>
<a name="morsel"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/MonthlyMorsels.gif" alt="Monthly Morsels" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Every month in this space you’ll find additional information related to this month’s topic.</p>
<ul>
<li><strong> References:</strong></li>
</ul>
<blockquote>
<p>[1] Yourdon, E., Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects, Upper Saddle River, NJ: Prentice-Hall PTR, 1997 </p>
<p>[2] Humphrey, W., Winning with Software: An Executive Strategy, Addison-Wesley, 2002</p>
<p>[3] Brooks, F., The Mythical Man-Month, 25th Anniversary Edition, Addison-Wesley, 1995</p>
<p>[4] Goldratt, E., Critical Chain, Gower Publishing, 1997</p>
</blockquote>
<ul>
<li><strong> Estimating and Scheduling Training Courses and Workshops</strong></li>
</ul>
<blockquote>
<p>The following are some public courses and workshops on estimating and scheduling:</p>
</blockquote>
<ul>
<ul>
<li><strong><a href="http://www.construx.com/Page.aspx?nid=17&id=10" target="_blank">Software Project Management Boot Camp</a></strong></li>
</ul>
</ul>
<ul>
<ul>
<li><strong><a href="http://www.construx.com/Page.aspx?nid=15&id=32" target="_blank">Software Estimation in Depth</a></strong></li>
</ul>
</ul>
<ul>
<ul>
<li><strong><a href="http://www.ieeeboston.org/edu/2007fall/course_building_schedules.htm" target="_blank">Building Accurate Schedules from Software Requirements</a></strong></li>
</ul>
</ul>
<ul>
<ul>
<li><strong><a href="http://www.processimpact.com/seminars.shtml#pmbp" target="_blank">Project Management Best Practices</a></strong></li>
</ul>
</ul>
</td>
</tr>
</table>
<br>
<br>
<a name="calendar"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/Calendar.gif" alt="Calendar" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Every month you’ll find news here about local and national events that are of interest to the software community…</p>
<ul>
<li><strong> Software Quality Calendar</strong></li>
</ul>
<blockquote>
<p>There are many organizations that sponsor monthly meetings, workshops, and conferences of interest to software professionals. <strong><a href="/links/upcoming.html" target="_blank">Find out what’s happening…</a></strong></p>
</blockquote>
<ul>
<li><strong> Workshops Offered by Software Quality Consulting</strong></li>
</ul>
<blockquote>
<p>Software Quality Consulting offers workshops in many topics related to software process improvement. <strong><a href="/seminars/courses.html" target="_blank">Get more info…</a></strong></p>
</blockquote></td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/AboutSQC.gif" alt="About SQC" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Software Quality Consulting provides consulting, training, and auditing services tailored to meet the specific needs of clients. We help clients fine-tune their software development processes and improve the quality of their software products. The overall goal is to help clients achieve Predictable Software Development™ – so that organizations can consistently deliver quality software with promised features in the promised timeframe. </p>
To learn more about how we can help your organization, <strong><a href="/index.html?AboutSQC" target="_blank">visit our web site</a></strong> or <strong><a href="mailto:[email protected]">send us an email</a></strong>.</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top"><p> I hope this newsletter has been informative and helpful. Your comments and feedback are most welcome. <strong><a href="mailto:[email protected]">Send me your feedback…</a></strong></p>
<p>Thanks,</p>
<p> <img src="/newsletter/images/BusinessCard.gif" width="270" height="121" align="right"><img src="/newsletter/images/Signature.gif" width="90" height="68"><br>
Steve Rakitin<br>
<br>
<strong><a href="mailto:[email protected]">[email protected]</a></strong></p></td>
</tr>
</table>
<div align="center"><br>
<FONT class="Reference">Food for Thought, Predictable Software Development, Act Like a Customer,<br>
and ALAC are trademarks of Software Quality Consulting, Inc.<br>
Copyright 2007. Software Quality Consulting, Inc. All rights reserved.<br>
Graphic design by <B><U><FONT color=blue><a href="mailto:[email protected] ">Sage Studio</a></FONT></U></B></FONT></div>
<a name="bottom"> </a></body>
</html>