<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on Three tips for avoiding project estimating mistakes ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-305251/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-06-19T23:44:33-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[Test manager as key stakeholder]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3184743]]></link>
        <description><![CDATA[Seen that, his boss told him it had to pass.......]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3184743]]></guid>
        <dc:creator><![CDATA[Tony Hopkinson]]></dc:creator>
        <pubDate>Mon, 19 Oct 2009 16:17:01 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Three tips for avoiding project estimating mistakes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3183920]]></link>
        <description><![CDATA[In a recent study we did we found that the 3 things that made the difference were:Engaging all the stakeholders in the planning stage.Test Manager as a key stakeholderRegular checkpoints with all stakeholders However personally I used to say to all my stakeholders bad news is not like wine it does not get better with age. Having a sense of humour helps too!If you want to read some of the best &amp; worst practice stories we have a free white paper based on 100 interviews at the Customer Experience Foundation.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3183920]]></guid>
        <dc:creator><![CDATA[resimpa]]></dc:creator>
        <pubDate>Mon, 19 Oct 2009 01:11:03 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[If the PM lets it happen]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3181647]]></link>
        <description><![CDATA[They've failed somewhere or they are just there to replaces the smilies on teh dashboard when 90% of the resource has been used up.If there's on bunch of IT wonks, who should communicate well with management, it's PMs.....]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3181647]]></guid>
        <dc:creator><![CDATA[Tony Hopkinson]]></dc:creator>
        <pubDate>Wed, 14 Oct 2009 13:59:23 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[It isn't the PMs, it's management]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3181257]]></link>
        <description><![CDATA[Estimates mysteriously turn into commitments, management plans projects and staffing, and sales makes promises to customers.When things start to slip (and something always does), the shock spreads quickly through the overconstrained system. Forced overtime leads to abandonment of good practices and defects introduced by tired, stressed people, slowing things down even more.When it's done, we fire the people who we paid to learn the lesson.And we keep doing it, over and over and over and over...]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3181257]]></guid>
        <dc:creator><![CDATA[uFunctional]]></dc:creator>
        <pubDate>Wed, 14 Oct 2009 05:44:02 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Or you can just give up]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3046397]]></link>
        <description><![CDATA[These are all good hints for getting better.But I believe that all the forces on software development are making estimation harder, not easier, and that we will never get accurate enough to make the estimation problem go away.http://wistechnology.com/articles/5190/If you accept this, it leads you straight to the agile methods, because they preserve value better in the face of an estimation error, as this toy example illustrates.http://wistechnology.com/articles/5514/]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3046397]]></guid>
        <dc:creator><![CDATA[uFunctional]]></dc:creator>
        <pubDate>Tue, 31 Mar 2009 09:20:05 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Three tips for avoiding project estimating mistakes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3046091]]></link>
        <description><![CDATA[Thanks for sharing..regardshttp://www.sblgis.com/geospatial-services.aspx]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3046091]]></guid>
        <dc:creator><![CDATA[SBL GIS]]></dc:creator>
        <pubDate>Tue, 31 Mar 2009 02:33:38 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Yes, it makes sense]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3045794]]></link>
        <description><![CDATA[We usually add contingency to our estimates. The less detail in the requirement, the bigger allowance for contingency (or unknowns).A simple example we had just last week was the addition of a new item for a data warehouse extract. We were told the field existed in the tables (always check), however, it was not in the table used for the extract. Only a half day of work, but it wasn't known at planning time. Contingency allowed us to absorb the additional time.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3045794]]></guid>
        <dc:creator><![CDATA[Scott_N]]></dc:creator>
        <pubDate>Mon, 30 Mar 2009 13:27:58 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Good start, but there is more]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042638]]></link>
        <description><![CDATA[For example, creating a common vision of success is key.  As you do this you will find that new requirements or redefinition of existing requirements will occur, and that affects both scope and estimates.Below are links to two relevant white papers that I wrote on Earned Value Management a few years ago.  They discuss scope management and estimating - two things that are essential to project success.http://comp-soln.com/EVM_scope.pdfhttp://comp-soln.com/EVM_estimating.pdfThere are certainly many other reasons that projects fail, but getting a solid start to a project will minimize the chances of failure.  And, using EVM on an ongoing basis will help identify problems early-on, giving you time to make corrections early before things get out of hand.Cheers,Chip]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042638]]></guid>
        <dc:creator><![CDATA[ChipN@...]]></dc:creator>
        <pubDate>Thu, 26 Mar 2009 05:53:06 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Three tips for avoiding project estimating mistakes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042352]]></link>
        <description><![CDATA[As Napoleon said. &quot;A plan is only good until the battle is joined.&quot;]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042352]]></guid>
        <dc:creator><![CDATA[dwwright99@...]]></dc:creator>
        <pubDate>Wed, 25 Mar 2009 17:18:14 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Three tips for avoiding project estimating mistakes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042345]]></link>
        <description><![CDATA[While I agree with the three tips, with respect to tip #2, I am curious about how anyone may have dealt with the inevitable client questions that come up when you add &quot;contingency&quot; as 25%, for example, of a total budget.  I agree with Tony that clients are quick to forget the definition of estimate, but my experience has been that they have a hard time signing off on a reasonable dollar amount to cover unknowns, even though, as you suggest, they are all but inevitable.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042345]]></guid>
        <dc:creator><![CDATA[bobk@...]]></dc:creator>
        <pubDate>Wed, 25 Mar 2009 17:13:31 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Unknown Unknowns]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042235]]></link>
        <description><![CDATA[Mike,Thanks for responding. I appreciate your taking the time to write.I'm not sure I agree that a freight company losing a shipment is a known unknown, as all equipment associated with a project may ship on time. Same thing with a developer getting sick or a hard disk failing; you don't know for certain that those items will fail, whereas, you do know for certain that Windows XP Home systems don't maximize domain membership, for example.I think we agree in principal: you have to budget for things going wrong. I tried to lay out, in the beginning of this piece, that by planning for all contingencies you know can arise (missing licenses, incompatible hardware, etc.) you can minimize known unknowns, but unknown unknowns are just that: things you don't know that can go wrong.I think of unknown unknowns being any of the following.1. Discovering that a device driver that's supposed to provide compatibility with a new software platform actually doesn't work, necessitating hardware replacement.2. Learning that an API that's supposed to provide application interoperability doesn't work as promised.3. Finding that a client didn't realize their inventory includes seven classes of data tracking, not five as may have been planned.Does that make sense?]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042235]]></guid>
        <dc:creator><![CDATA[Erik Eckel]]></dc:creator>
        <pubDate>Wed, 25 Mar 2009 13:06:15 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Most PMs 'forget' the most basic definition]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042170]]></link>
        <description><![CDATA[of estimate.ie it's not an actual.Once you've assumed your estimate is precise, kiss all hope of not being surprised goodbye.Identifying known unknowns is simply a quaestion of how much resource you are prepared to spend up front before you plan, this usually works out at none.Unknown unknowns is simply a contigency estimate, which unfortunately is often confused with the range of error put on the estimate of the known unknowns.....I am not even going to mention tearing out contigency in order to make a cost/timeline look more acceptable.... ]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042170]]></guid>
        <dc:creator><![CDATA[Tony Hopkinson]]></dc:creator>
        <pubDate>Wed, 25 Mar 2009 10:50:47 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[These are known unknowns, not unknown unknowns]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042128]]></link>
        <description><![CDATA[Not to be overly picky, but the risks you identified are known unknowns.  Unknown unknowns are those things that you don't know about (and therefore can't even list in an article).  The first known/unknown refers to whether you know about a potential risk event.  The second unknown refers to knowledge of the state of the risk (probability and impact).You mentioned, &quot;hardware vendors miss shipping dates; freight companies lose shipments; developers and administrators become ill; and platforms that should automatically integrate fail to do so.&quot;  These risks are things that every project manager should think about, and are great starting thoughts for a thorough risk assessment.I enjoyed the article, but I didn't want the risk terminology to slip by (since project risk management is an area of expertise).]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042128]]></guid>
        <dc:creator><![CDATA[MikeFisherAK]]></dc:creator>
        <pubDate>Wed, 25 Mar 2009 10:30:03 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Known Unknowns]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042118]]></link>
        <description><![CDATA[I have learnt from experience to concentrate on documenting what is out of scope, but related to the project.This usually drives an interesting conversation that exposes the clients assumptions and subsequently improves the proposal and the estimate.Of course it provides a nice back stop when you can remind the client later that something is out of your scope, and that in fact you brought this up and they decided not to include it!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-305251-3042118]]></guid>
        <dc:creator><![CDATA[Mark Johnson]]></dc:creator>
        <pubDate>Wed, 25 Mar 2009 09:48:44 -0700</pubDate>
    </item>
    </channel>
</rss>

