{"id":6750,"date":"2011-08-22T04:51:55","date_gmt":"2011-08-22T11:51:55","guid":{"rendered":"https:\/\/svapm.org\/?p=6750"},"modified":"2011-06-09T05:00:41","modified_gmt":"2011-06-09T12:00:41","slug":"what-are-some-of-the-main-causes-behind-estimating-errors","status":"publish","type":"post","link":"https:\/\/svapm.org\/?p=6750","title":{"rendered":"What are some of the main causes behind estimating errors?"},"content":{"rendered":"

What are some of the main causes behind estimating errors?<\/span><\/strong><\/p>\n

There are several causes behind estimating errors.\u00a0 Some<\/strong> of them are:<\/span><\/p>\n

1) Not enough information or data collected to create an accurate estimate.<\/span><\/p>\n

Executives, clients, and managers want to see progress quickly.\u00a0 Gathering the data and information to create an accurate estimate, budget and schedule is a time-consuming effort with little visible, tangible result.\u00a0 People want to move into the “action” portion quickly – because that’s where you can “see” and report progress.\u00a0 Therefore, people are in a rush to create project schedules, because they believe they can not start the project without estimates and schedules.<\/span><\/p>\n

At the end of the day — since they don’t have enough information to say that the schedule is “unreasonable” — they agree to it. <\/span><\/p>\n

2) Domino affect on trying to make the schedule “look good” versus “accurate”.<\/span><\/p>\n

Often times, because we don’t really have the proper data to give an accurate estimate.\u00a0 We are rushed to provide numbers that we aren’t\u00a0really invested in.\u00a0 If this is a leading-edge technology or next generation service, we also do not have any previous experience to base our estimates on. <\/span><\/p>\n

We think it may take us 8 weeks to do something but we are not sure.\u00a0 It could easily take us 6 weeks\u00a0 – we just don’t know.\u00a0 We don’t really have the data to\u00a0believe in either number.\u00a0 Therefore,\u00a0give the number that we\u00a0“think” our manager will like better.\u00a0 For instance, if your original estimate is\u00a08 weeks on a software coding project, might say —\u00a0but if\u00a0I work a few extra hours on it, over the weekend and everything goes smoothly — I\u00a0think I can do it\u00a0in 6 weeks.\u00a0 The developer may report to his\/her manager that he\/she “could” get it done in 6 weeks (but they don’t have any real data to support it).\u00a0 Their manager may then think — well if we work extra hours and weekends, then we can probably get it done in 5 weeks.\u00a0 Or the manager may feel that the developer is padding the estimates (because they can not provide any\u00a0real data to support the estimate).\u00a0 So the manager reports a number that looks better to their manager.<\/span><\/p>\n

3)\u00a0 Ignoring the inevitable speed bumps or the unexpected.<\/span><\/p>\n

Often times, managers and developers create estimates on how long they think it will take “them” to\u00a0develop or create.\u00a0 They don’t incorporate issues like: vacation, sick days, equipment failure, construction delays,\u00a0 contract delays, legal\/license issues, resource issues, maintenance emergency on another line or product, client issues, or other “unexpected” issues that arises in the natural flow of a project.\u00a0 Because of these unexpected things,\u00a0the\u00a0person actually assigned to that “item” may not have the same experience as the person that created the original estimate. <\/span><\/p>\n

Although you can not know exactly what will happen, you do know something will happen.\u00a0\u00a0 Therefore, you really do need to expect the unexpected.\u00a0 And your project planning needs a way to handle these things.<\/span><\/p>\n

And what specific steps can project managers can take to increase the accuracy of estimations?<\/span><\/strong><\/p>\n

1)\u00a0 Adopt the idea of “progressive refinement”. <\/span><\/p>\n

Project Management isn’t about defining an accurate estimate or schedule at the start of a project.\u00a0 Project Management is about “managing” the natural flow of a project.\u00a0 One way is to adopt the attitude of “progressive refinement”.\u00a0 Define a rough skeleton of your project plan with the data that you current have.\u00a0 You then separate your projects in manageable iterations or segments.\u00a0 Each segment is a “mini-project”.\u00a0 Each “mini-project” has a variety of deliverable components to your clients, stakeholders and team mates.\u00a0\u00a0 You focus on collecting the proper estimates and budget for the items scheduled for Iteration 1 (or segment 1). <\/span> Iteration 1 (or segment 1) of your project will have clear deliverables and time tables for those goals, but Iteration 2, 3, and 4 may still have some fuzzy estimates because you haven’t collected enough data to accurately estimate those segments yet.\u00a0\u00a0 As your team is working and delivering on their Iteration 1 items, you are collected the required data for your Iteration 2 items.\u00a0 If some features originally scheduled for Iteration 1 (segment 1) are falling short in quality or completion, they are quickly reassigned for Iteration 2 delivery (and iteration 2 feature lists are scoped appropriately).<\/span><\/span><\/p>\n

This allows you to create accurate estimates as you progress through the project.\u00a0 This also allows you to deliver portions of the project throughout the development life cycle (at each segment).\u00a0 Clients, executives, and other stakeholders will be receiving tangible evidence of your work throughout the project lifecycle.\u00a0 You will also be receiving feedback on each segment to incorporate into the next iteration or segment.<\/span><\/p>\n

2)\u00a0Agree to a\u00a0Protocol Recovery plan at the start of a project<\/span><\/p>\n

All projects will hit some unexpected issues.\u00a0 By discussing a “protocol recovery plan” at the start of the project, the team will understand how to proceed when time is running out.\u00a0 A “protocol recovery plan” is like a “fire escape route”.\u00a0 At the start of the project, your project sponsors and stakeholder agree in the order to do these things:\u00a0 Add Resources, Remove Features, Change Schedule, Reduce Quality.\u00a0 The idea is to agree up-front (before the project starts) which order you will do them\u00a0 – if\/when you hit a snag.\u00a0 For example:\u00a0 If you team agrees up front that the recovery protocol will be in the below order: <\/span><\/p>\n

\n
\n
\n
    \n
  1. Add Resources<\/span><\/li>\n
  2. Remove Features<\/span><\/li>\n
  3. Lower Quality Standard<\/span><\/li>\n
  4. Change Schedule<\/span><\/li>\n<\/ol>\n<\/blockquote>\n<\/blockquote>\n<\/blockquote>\n

    Then the group understands from the start that the SCHEDULE is the main priority and last to be modified.\u00a0 They also understand the order in which the other items will be attacked.\u00a0 If your group agrees upfront that “QUALITY Standards will be the last to change — then folks understand that the schedule will change to support the agreed quality compliance.\u00a0 Whatever the team decides, it’s known upfront, before the project starts.<\/span><\/p>\n

    For instance, the team can agree to Add Resources (until it doesn’t make sense to add resources anymore).\u00a0 Once you have reached the point where more resources will not help, you agree that the next step will be to start removing features.\u00a0 At the start of the project, you need to understand\u00a0 the minimum set of features or services that make the project worthwhile to the client (with many other “nice-to-have” features or enhancements as well).\u00a0 If you understand the minimum MUST HAVE feature set, you can then start removing or rescheduling the “nice-to-have” items to the next release.\u00a0 Once you have removed all the “nice-to-have” items and are only left with the MUST HAVE, then you look back at your protocol recovery chart to find out what you to do next. <\/span><\/p>\n

    If you have this outlined and approved at the start of the program, then you don’t have people complaining that you’re sacrificing QUALITY in order the make the date.\u00a0 Or that you are\u00a0cutting his\/her features, etc.\u00a0 This is all understood before the project starts.<\/span><\/p>\n

    3)\u00a0 Release early and often<\/span><\/p>\n

    Adopt an attitude of continuous releases.\u00a0 Features or services that do not make it in this release are merely scheduled for the next one.\u00a0 There’s always the next train.\u00a0 Focus on getting early versions out for customer’s feedback and continually improve as you go along.\u00a0 Not everyone needs the product at the same feature set or quality.\u00a0 Allow people to use the product to get to their “next steps” accomplished.\u00a0 Often times the product doesn’t have to be perfect or complete — for the client to make\u00a0use of it.\u00a0 Focus on the features and quality level that is actually required for the client to get “their job” done.\u00a0 The client’s focus isn’t really a “perfect product from you” or a product that “you” feel has “all the bells and whistles” or is the best on the market.\u00a0 The client’s focus is how to get “their job done” quickly and easily. <\/span><\/p>\n

     <\/p>\n

    Conclusion:<\/strong>
    \n<\/span><\/p>\n

    Statistics show that only 36% of products feature are ever really used by the end-clients.\u00a0 Using that logic, only 36% of your feature set\u00a0really need to be working effectively.\u00a0 So, as long as you are helping the client “get their work done” — you’re doing the right thing.\u00a0 Understanding what your clients need and how they work, will allow you to focus on just the features and quality level that will be of value to them.\u00a0 Providing a method to get them exactly what they need in a timely fashion will prove advantageous to you.
    \n<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

    What are some of the main causes behind estimating errors? And what specific steps can project managers can take to increase the accuracy of estimations?<\/p>\n","protected":false},"author":1508,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"give_campaign_id":0,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[2,852,8,846,5,10,20,6,853,854,855,856,847,848,849],"tags":[39,33,64,17,38,1375],"class_list":["post-6750","post","type-post","status-publish","format-standard","hentry","category-leadership","category-pmbok-process","category-priorities-2","category-scope-2","category-time-management","category-cost","category-quality","category-communications","category-pmbok-process-initiating","category-pmbok-process-planning","category-pmbok-process-executing","category-pmbok-process-monitoring-and-controlling","category-self-leadership","category-1-1-leadership","category-team-leadership","tag-best-practices","tag-common-sense","tag-communication","tag-lessons-learned","tag-project-management","tag-risk-management"],"aioseo_notices":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/6750","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/users\/1508"}],"replies":[{"embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6750"}],"version-history":[{"count":0,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/6750\/revisions"}],"wp:attachment":[{"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6750"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6750"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6750"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}