Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

When creating technical documentation it's good to know how long it will take. This presentation (delivered to the STC in Calgary Alberta) explores estimating such projects as well as an overview of the estimating process.

Published in: Business
  • Very nice tips on this. In case you need help on any kind of academic writing visit website ⇒ ⇐ and place your order
    Are you sure you want to  Yes  No
    Your message goes here
  • Want to preview some of our plans? You can get 50 Woodworking Plans and a 440-Page "The Art of Woodworking" Book... Absolutely FREE ●●●
    Are you sure you want to  Yes  No
    Your message goes here
  • Grab 5 Free Shed Plans Now! Download 5 Full-Blown Shed Plans with Step-By-Step Instructions & Easy To Follow Blueprints! ✤✤✤
    Are you sure you want to  Yes  No
    Your message goes here
  • There are over 16,000 woodworking plans that comes with step-by-step instructions and detailed photos, Click here to take a look ●●●
    Are you sure you want to  Yes  No
    Your message goes here
  • Get access to 16,000 woodworking plans, Download 50 FREE Plans... ▲▲▲
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this


  1. 1. Bernard Aschwanden Estimating Projects 16:45 1 @aschwanden4stc
  2. 2. Outline 16:45@aschwanden4stc 2  Management faces challenges due to poor or non- existing estimates  Benefits of accurate estimates, and how to get there. As part of this, we will explore:  Reasons for estimating  Estimate types  How to build real estimates with numbers and deliverables  Project execution based on developed estimates  Concrete estimate creation examples, components, and tools
  3. 3. Thanks and… 16:45@aschwanden4stc 3  STC Alberta and the volunteers  Cohort Technical Communications  My audience
  4. 4. Housekeeping and note taking 16:45@aschwanden4stc 4  Not all slides or topics are equally weighted  Use some, discard others  Slides speed varies  Questions? Ask any time!  Good stuff? My wife did it   I’d love to claim errors/typos is on purpose… they isn’t, weren’t never, and ain’t; I’ll fix ‘em as I can…
  5. 5. About your speaker 16:45@aschwanden4stc  Publishing Smarter: President  Content strategist, publishing technologies expert, author, and geek-enough  Solves communications problems to help businesses be efficient and profitable  Society for Technical Communication  Past President  STC Associate Fellow  All around great guy 5
  6. 6. Before we begin 16:45@aschwanden4stc  How long does it take  To get downtown?  Now  Noon  5pm  2am  To the airport  To Edmonton  To Toronto  By plane  By train  By car  How much does it cost?  Big Mac combo  New vehicle  Bicycle  Compact car  Loaded pickup  Loaded Porsche  Condo downtown  House in suburbs  House 2 hours from Calgary  These are ALL estimates 6
  7. 7. Way under Way over Just right @aschwanden4stc 16:45 7 Estimates can go three ways
  8. 8. Way under and… 16:45@aschwanden4stc 8  You likely overestimated things  Added unrealistic risks, dependencies  Thought things would be more complex than they are  All is not lost  Use this as a baseline to improve  Always keep the previous versions and do compares  Given history and more clarity estimates become better  Consider the almighty cookbook as a great estimation tool
  9. 9. When it’s done wrong… 16:45@aschwanden4stc 9  The “Big Dig” in Boston rerouted major parts of the inner traffic of the city  Planning in 1982, expected to be done by 1998, cost of $2.8b  Escalating costs, scheduling overruns, leaks, design flaws, criminal arrests  Actual work from 1991—2006, completion date Dec 31/07  Cost was $14.6b (adjusted to the time would be $8.1b in 1982)  Overrun of 190% (so triple the price)  Boston Globe estimates total will be $22b, paid off in 2038  Due to issues restitution of over $450m were paid (do your own math based on all the numbers above, it’s still a lot of money)
  10. 10. When it’s done right! 16:45@aschwanden4stc 10  Gotthard Tunnel: Switzerland (first built in 1882)  In 1909 the railway took over the running of the tunnel  In 1992 a referendum decided to build the longest/deepest train tunnel in the world  Trains will travel 155mph (250km/h)  35 miles (57km) in length and 2km deep  2400 people working in the dig  50 Celsius internal temps reached  28m tonnes of material excavated  Project was 24 years (7 to just plan/prep)  Construction estimated to take 17 years, cost $10.3b (ran up to $12b)
  11. 11. @aschwanden4stc 16:45 11 Reasons to estimate
  12. 12. An estimate can identify 16:45@aschwanden4stc 12  Initially  How much will it cost  How long will it take  Funding and resources needed  As you work  If you are on track  Where to shift resources  Where to add/cut resources/expectations
  13. 13.  Secure buy-in and funding at the start of a project  Establish general size, cost, duration expectations early on  Determine or refine project scope based on above Purpose of an estimate pre-project 13 @aschwanden4stc
  14. 14. Purpose of an estimate during a project 16:45@aschwanden4stc 14  Agreed upon guideline of tasks, deliverables, and timelines  One document everyone can reference  Allows tracking of resources, milestones  Can be used to adjust what teams do if falling behind  Allows resources to be freed up if ahead  A “you are here” for all teams
  15. 15.  Create more accurate project estimates next time  Determine the right time/money to bill/expect  Talk clearly/numerically about why it took longer than expected–speak with authority  Justify expenditures (e.g. students, contractors), tools (licenses, upgrades), or services (trainers) Purpose of an estimate post-project 15 @aschwanden4stc
  16. 16. Estimates help other teams 16:45@aschwanden4stc 16  Size, complexity mean that other teams can plan  HR can hire more people for larger projects, or deal with reorg  QA can come up with projections (i.e. lots of code, many variables)  ID can determine  How many people do they need  How many writers  How much hardware do they need  What scripting is required  Manufacturing can scale up (or down) production  Many others in any org need this data to make decisions
  17. 17. With an estimate you can plan 16:45@aschwanden4stc 17  Start early and come up with one question  HOW MUCH WILL THIS COST (time, resources, dollars)  WILL THIS DELIVER (what the client needs)  Whatever…  ID number and type of resources needed  ID time required, and time to market  Put a time and cost on it  Decide if it will be funded, or be cancelled  Continued maintenance of existing projects
  18. 18. For example, plan dependencies 16:45@aschwanden4stc 18  I cannot ID how many writers until I know how much content and how complex. I don’t know that until I know how many developers. I don’t know that until I know how many new features (and complexity). I don’t know that until management has an overall scope/plan/idea.  Estimates have dependencies  Allow for a ratio (for example, 1 QA per 2 devs, 1 writer per x features or # of dev)
  19. 19. Two main types to explore @aschwanden4stc 16:45 19 Types of estimates
  20. 20. Top Down 16:45@aschwanden4stc 20  Set a goal (i.e. “Upgrade HW & SW”)  Major tasks get ID’d (often by Project Mgr) then details get refined  Break it into smaller chunks  Install server  Upgrade OS  Install most current software  Works when the goal is clear
  21. 21. Bottom Up 16:45@aschwanden4stc 21  To begin, set a goal (i.e. “Upgrade HW & SW”)  The entire team brainstorms all tasks; tasks grouped into main categories  For example, group a bunch of stuff into “Install server” and others into “Upgrade OS” and the rest into “Install most current software”  People who DO the work collaborate to create estimates  Task level  Smaller components  Add them up to come up with a final estimate
  22. 22. Initiating the estimate @aschwanden4stc 16:45 22 Research phase
  23. 23. Ball park estimate 16:45@aschwanden4stc 23  High level, no details  “I think, based on experience, this is how much/long”  Input from different groups  Compare against past projects (baseline)  For example, ID talks to DEV, dev says “6 months” and ID knows from past projects that 6 months of DEV is about 3 months of ID
  24. 24. Strawman schedule 16:45@aschwanden4stc 24  Called strawman as it has no spine, easy to blow away, change, bend based on input…but has some shape and definition  When it moves to the next level it may be changed/approved/denied
  25. 25. General estimates on major deliverables, next level of detail @aschwanden4stc 16:45 25 Early planning
  26. 26. Detailing major tasks 16:45@aschwanden4stc 26  We knew we had to do upgrade  Now we know that we have to do it on Mac/Win, but need to buy new Win servers (and OS, training for IT, etc)  We knew we had to install most current software  Now we know that we need to document “How To” and meet accessibility standards for the USA, and we need to translate to Chinese  More knowns, but also gone from 1 big task to (maybe) a few bigger ones, but with more internal definition  Funding likely given/denied based on this  Details may not yet be final, but the company is backing the next steps
  27. 27. Brainstorm on topics (Research) 16:45@aschwanden4stc 27  In groups  What topics can we cover as “Intro to Word”  Imagine having to prep a course to teach new users how to effectively use MS Word  Done as a group  Come up with ALL the things a new user should know to work well
  28. 28. Did you… 16:45@aschwanden4stc 28  Set a high level goal?  Explore the function of the software?  Discuss the goal of the user (the business goal)?  Hopefully you did ask “what docs do users create”?  Word is used for newsletter, business plans, biz cards, letters, user guides, admin guides, API, legal docs, medical docs  ID what the user needs to do to create content?  Consider: Can you adapt this to “FrameMaker” or “Google Docs” with ease, or is it too product based, too early
  29. 29. @aschwanden4stc 16:45 29 Create a project plan
  30. 30. All the details 16:45@aschwanden4stc 30  This is the one you commit to, and track against  The others helped you talk to execs, secure funding, set roadmap  This one allows you to track against what you promised  Very detailed
  31. 31. Time estimates 16:45@aschwanden4stc 31  How long does each thing users should know take to teach?  Is it something that they can be taught in 15m? 1hr? A week?  As a group, ID the time to deliver the training (minutes/hours)
  32. 32. Now, meet the reality (TOP DOWN) 16:45@aschwanden4stc 32  Bernard only has 3 hours to deliver training  Includes “hands-on” for ⅓ to ½ of the time  STILL, working as a group, limit what we will cover  Based on experience/history, similar projects
  33. 33. Once we have 3 hours (BOTTOM UP) 16:45@aschwanden4stc 33  Every piece from previous (for example, styles, tables, images) gets the detailed treatment  To do so, work in small teams  Each may end up with a writer, an editor, a QA tester, a trainer  Come up with specifics for each module  ID the goal, exercises people do  How much concept/task/reference is delivered  Break these into smaller bits (i.e., for tables: How to insert / format / size / add / delete)  How long do each of the bits take to teach?  Iterative approach to scope (adapt if tasks total 3+ hours)  Creates an agreed upon plan of what we have  Everyone owns the estimates, agrees to estimates, and to schedules
  34. 34. Now decide on a specific detail 16:45@aschwanden4stc 34  Pick a few short parts and estimate how long to write  Use ones you generally know (i.e., work with styles, images, or tables)  Estimate how long to create course materials  Concept to teach (what is the key takeaway: “Use styles”)  Core task to teach that exact thing (with example: “Create basic doc, assign Title, Heading 1, and Heading 2”)  Related technical references (useful lookup: “List of template styles”  Pick one from the list, ID how long to teach it  For example, to teach “how to apply styles” and related info is 10 minutes, including “create sample content”
  35. 35. Weekly, monthly, whenever @aschwanden4stc 16:45 35 Status
  36. 36. Estimating amount done 16:45@aschwanden4stc 36  Compare during project and compare with goals (actual vs projection)  ID where there is slippage  Plan for what to do  Scale back  Add resources  Delay delivery  Parallel development
  37. 37. Estimates don’t just die 16:45@aschwanden4stc 37  Use them to hold people accountable  Compare against them the next time  Used to track progress
  38. 38. Once done, they have another use 16:45@aschwanden4stc 38  Explain delays  ID why a schedule was off, estimates off  Maybe forgot risks  Sizing was off  Unexpected change (layoffs, downsize)  Missed components (oops, we needed to write more)  Scope change (developer added new features)  Can be used for justification in overages
  39. 39. Review them “the next time” 16:45@aschwanden4stc 39  Use the estimates as a baseline  Don’t overwrite with the new “actual” but refine  Continue to do so to build the best estimates you can  Effective estimates CAN be achieved with history
  40. 40. Let’s put this to the test! @aschwanden4stc 16:45 40 Class project
  41. 41. Plan to write (time estimate) 16:45@aschwanden4stc 41  Create the first full lesson, compare with the estimate  Adjust the estimate, create a second full lesson, compare  Compare your estimates  Which was closest? Why?
  42. 42. Compare expectations and reality @aschwanden4stc 16:45 42 Development vs estimates
  43. 43. “A Guide to Estimating Writing Projects” 16:45@aschwanden4stc 43
  44. 44. According to that one estimate sheet 16:45@aschwanden4stc 44  For instructor-led training, the time required is roughly 10:1 to 80:1  For a 10 minute module it should take 100 to 800 minutes, likely 1.5 to 13 hours  Basic content, most of us should know how to do it  For example, apply styles  From personal experience I can create this in 45 minutes to an hour  Let’s build and check in for milestones every 10 to 15 minutes
  45. 45. Once we are done 16:45@aschwanden4stc 45  Adjust the estimates, do it again  Pick another basic topic  Let’s build and check in for milestones every 10 to 15 minutes
  46. 46. Move beyond 2 estimates 16:45@aschwanden4stc 46  Create the first full lesson, compare with the estimate  Adjust the estimate, create a second full lesson, compare  Adjust, create third, compare  Adjust, create 4th, compare  Adjust, create 5th, compare  Compare five estimates  Which was closest? Why? Expand this to others, such as editors, reviewers. Can you find patterns?
  47. 47. Summary What we have explored as well as ideas on what you can consider next
  48. 48.  Incorrectly estimating a project makes managing the project difficult. To correctly estimate costs you need a baseline to work with, accurate details on the time and costs of historical projects, and an easy way to track differences. The more accurate you are on estimation, the easier the overall management becomes, and the sooner you can identify issues that impact the bottom line.  Beginning with an overview of estimating a documentation project we explore what to estimate and how to come up with initial numbers. Then we track the actual time and cost involved, automate the tracking of differences, and explore how to estimate more accurately the next time. Every round of estimating helps establish a better baseline.  Using simple to follow, but real-world based examples, we create a complete estimate (take it with you at the end of the session!). We compare ways to estimate (start with a deadline, ID what you can do OR identify the things to do and set an end-date), discuss why estimates are important, and explore how to deal with setting scope (and how to manage changes to scope) when estimating.  Leave with a concrete example of an estimate that you help build, a good understanding of the components of an estimate, and the tools to more accurately estimate your projects.  For those who have their own business (or are considering one) the estimate provides a good way to work with clients, set expectations, and see where you are with projects (especially when it comes to billing!).  For those who work in a business the estimate provides a way to justify resource allocation, defend the need for more (people, time, resources), and establish a track record of success (great at performance review time, or when starting to work with new teams). In closing, remember 48
  49. 49. More reading 16:45@aschwanden4stc 49  rojects.pdf  and_schedule_estimating  me-estimation-method-for-technical.html  ing-effort-for-technical-writing-projects/
  50. 50. Even more to read 16:45@aschwanden4stc 50   nd_schedule_estimating  Documentation-Projects--1.shtml
  51. 51. Publishing Smarter helps clients 16:45@aschwanden4stc 51
  52. 52. Follow up contact information 16:45@aschwanden4stc 52 905 833 8448 (Eastern Time) @aschwanden4stc