UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
Estimating time-tracking
1. You need it WHEN?!
Estimating and time-
tracking documentation
projects
February 8, 2012
STC Wisconsin
Leigh White
ElementalSource, LLC
2. Points I wanna make
• Why it’s important to track time
• Why it’s important to estimate
– with consistent metrics
• How a solid estimate can save
your
at crunch time
3. Points I’m not gonna make
• Step-by-step how to
• Specific tools
4. Estimating vs. project plan
• Project plan more detailed
– Includes specific dates, milestones,
resources, etc.
• Estimate is a much narrower view of
the total time effort
– Regardless of when effort takes place
– Regardless of specific resources
6. Independents/contractors
• You’d better be tracking if you want
to get paid!
• This is more for salaried writers
– Not to make you more money or justify
your paycheck
– To help you get reasonable timelines
– Maybe to help your company become
more efficient
7. Where to start?
• You need to track time to have a
basis for estimating
BUT…
• You need to
estimate so
you can track
time
meaningfully
9. The reality
• Time
• Resources (you!)
• Scope
• Quality
10. Where is the wiggle room?
• If it’s got to go out the door by July
10, maybe you can get another
writer to help you.
• If there’s no other writers available,
maybe you can get a few items
knocked off the plan.
11. BUT…
• If you can’t prove that you need
more time, more resources, smaller
scope…
…you’ll get squat because
you have nothing to negotiate with.
12. So how do you prove it?
• Historical data!
• Time-tracking records from past
projects that show how much time
the job took
13. Uh oh…I don’t track that stuff
• START!
• START NOW!
• Your next couple of projects might
be a little painful
• But then you’ll have the data you
need going forward
14. Basic approach to time-tracking
• Determine work to be done
• Break into separate tasks
• Categorize task
• Create activity categories for
EVRYTHING you do
• Track time spent in each category
for each task
15. Activity categories?
• Keep as detailed an account as
possible of exactly how you spend
your time
• Identify black holes
in your processes &
in others’ processes
16. What do I record?
• Everything!
– time you spend in meetings, phone calls,
e-mail
– time you spend locating specs & other info
– time you spend talking to developers, BAs
– time you spend planning
– time you spend writing
– time the content spends in edits
– time the content spends with SME
– time it takes to revise & finalize
– time it takes to publish
17. How do I record my time?
• Any way that works for you
– spreadsheet
– database
• Free Access template:
http://office.microsoft.com/en-
us/templates/CT010375245.aspx#ai:TC101
898281|
– other time-tracking software
• Toggl: https://www.toggl.com/
• Harvest: http://www.getharvest.com/
18. Making sense of it all
• You’ve got all this raw time data,
now it’s time to use it in an
estimation
20. Bottom-up estimating
• Break the project down into
individual tasks
• Estimate each task
• Add each task estimate together for
the project total
• “How big a bag do I need to hold all
these rocks I have?”
21. Top-down estimating
• Develop a timeline for the project as
a whole
• Fit the individual tasks into the
project timeline
• Often less accurate than bottom-up
– But often favored by PMs unfamiliar
with documentation projects
• “How can I fit this pile of rocks in
this size bag?”
23. Parametric estimating
• Estimate the time required for one
deliverable/feature and multiply it
by the total deliverables/features
• Tricky, because
– You have to be sure you’re estimating
based on a typical deliverable or
feature or you risk
under/overestimation
– You risk not seeing potential red flags
in items you didn’t specifically look at
24. Comparative estimating
• Basing estimates on the time it took
to do similar tasks in other projects
• Excellent if you have the historical
data to use as a basis
25. Matrix-based estimating
• Develop standard times for
– Complex, average, simple tasks
– New content vs. updated content
– Other standard variations
• Gives you a more accurate per-task
estimate than pure parametric
• Very useful if you don’t have
historical data
• Easy to adopt across team
29. So far…
• Why you need to track time
• What kinds of things to track
• Estimation methods
30. Track what you estimate
• As much as practical, correlate what
you track with what you estimate
• Two sides of the same coin
– Estimating: how long is it going to take
me to do XYZ?
– Time tracking: how long is it actually
taking me to do XYZ?
• Maybe not always exact
correlation – estimate
can be more general
31. Example correlation
• Estimation factor:
– Developer Dave availability: reliable
• Time-tracking:
– 1 hour spent waiting on response from
Dave
– 12 hours spent waiting for response
from Dave
32. Important!
• Identify risks and deal-breakers for
your estimate
• Get all stakeholders’ agreement on
the estimate up front!
[Example]
33. OMGweforgottoincludeisittoolatecan
wehavethistoo?
• There will always be last-minute
changes, additions, oops-we-forgots
• Usually not negotiable (not by you,
anyway)
• Your estimate is your weapon:
– “Sure I can add that but as
you see, it will put us
behind. What would you
like to adjust?”
34. Contact me
Leigh White
ElementalSource, LLC
elementalsource@gmail.com
678.467.7706
36. Don’t go chasin’ waterfalls…
• Traditional project estimation
– task-based
– attempts to predict a specific number of
hours for a task
– estimates don’t change to match reality;
delays cascade thru plan
• Agile project estimation
– feature-based
– more focused on relative size of
features--“small, medium, large” scale
– estimates are adjusted for each iteration;
constant correction
37. Three-point estimating
• Best case
– If you develop this, don’t give it to a PM
because that’s what they’ll try to hold you to!
• Probable case
– This is what will probably happen so this is
what is probably useful.
• Worst case
– The Chicken Little school of estimation.
• PERT (Program Evaluation and Review
Technique) formula
– (best+[4x probable]+worst)/6
38. Critical Path Analysis
• Graphical representation of
– What needs to be done
– What can be done at the same time
– When it needs to be done