MuraCon Notes - Requirements and Estimating
October 02, 2013
Requirements and Estimating - Ryan Thompson
the problem - never really wrote a detailed spec up front
so...don't have a scope to go back on, so we start digging ourselves into a hole...
reasons:
didn't provide a good estimate
did no estimate at all
why some estimates go wrong, how to fix
lack of information
i want to build a shack -- need detailed info about the shack
need to ask ? up front to get the right info. is it really a shack? or a mansion?
req's are not understood, not clearly defined
think you have enough to do an estimate and you don't
Estimate process is rushed
desire to GET the job outweighs the desire to SPEC it correctly
often will cut corners to make things happen
(can happen internally too, not just with a client relationship)
not all items / phases are accounted for in estimate
(missing QA, documentation, training, etc)
"you don't know until you build it"
-- especially true in world of custom development
if we can be better at writing a SOW that's clean / detailed, when things come up later, we have something go to back to that we can change without upsetting the client-relationship
Poorly estimating a project can...
create tension between vendor and client
impact your prod schedule
impact cash flow
lose credibility with clients / staff
can lose current/future business
can even shut your business down
--- if you do everything at a discount, you'll end up discounting yourself out of business
so now do we overcome this?
know when to use different estimate methods
create an estimate model to work from
leverage a req's gathering phase
know when to "raise the flag"
-- even if done a good job estimating, you'll run into issues. understand WHEN to waive a flag and talk to your clients
-- know when it's YOUR issue vs your CLIENT's issue
- track, report, and adjusting
- track ALL your time/effort w/ a project
- so you can report on it
- then you can adjust how the project is going, and use that for future projects too, what did we learn before, etc
estimating models
fixed fee estimate
define a SOW, this many hours for these tasks, here's your budget
easy to contract because it's a fixed fee
get scheduled payments based on milestones
can plan resources on that b/c you know the LOE for each task
CONs
LITTLE room for error if you missed something
hard to go back to a client that's already committed to a budget
delays in the project due to underestimating will impact payment
(works well for repeatable services -- if you do a type of project all the time and you know what goes into it. preconfigured packages, etc)
ideal for clearly defined scope and timeline
Time and Materials
we're just going to bill you as we go and we'll check in with you
rare. most clients aren't ok with continuous infinite billing
all time spent on project is paid for
client can dictate priority
payments on regular interval
CONS
hard to estimate
hard to plan resources around it
may become expensive
---
handy for custom projects that are loosely defined
often these will narrow over time and turn into a fixed fee estimate
Resource Allocation Estimate
client says "we need to do THIS", it's not 100% clear, but need to be done by a set date
can use this to map out a traditional project schedule, flow, etc. to say who many people will be needed over time
good for ball parking estimates
but not entirely accurate
will probably be higher than actual costs
good for clients that say "we want to build the next amazon"...okay, it'll take 10 dev's for 3 years to do that...gets the clients into reality a bit about what they're asking for, to reign in projects
ESTIMATION MODELS
Requirements Gathering Phase
rather than sign off on a WHOLE project, let's spend a week together and map out what really this project is all about
work client and team together
at the end, give them a document, very clear on what's going to happen
THIS IS BILLABLE TIME! (for a certain block of time. b/c they get a deliverable at the end -- the req's doc, and that's what they paid for...or rather they paid for a lot of talking and information, that may not end up in an "official" document, but it still gets handed off to the client somehow)
Guess & Change Approach
gets you in the door
requires little up front effort
know what tasks go into a project (even the little ones)
things we often over look are the little tasks,
and docs
and training
and migrating to their prod server (do they have 2 servers? 3? 4?)
can do a lot of this in a spreadsheet
need to establish rates for tasks
(using a "blended rate" -- 1 rate for all the tasks. sometimes for gov't projects they need different rates
need to know how long COMMON tasks take
ex: for graphic design, building a logo is 32 hours
need to leave room for custom/one-off tasks
establish % factors for variables tasks
ex: PM is 15- 25% of time
so if 100 dev hours, you'll need 15 - 25 hours of PM time
use the model EVERY time (whatever model you come up with)
fixed model -
list all tasks by phase
set hours of reach task
rate x task
subtotal
total project cost
ensures all tasks are accounted for
can help w/ project schooling and resource allocation
know when to use which model
T&M Estimate
leverage the fixed fee model or resource model as a best guess
establish time tracking parameters
Resource Allocation Estimate
list all resources involved in project
project hours allocated per week/month per role
include variables (PM, QA etc)
extend role allocation over a period of time
"we have 7 wks to do prom, scope is loosely defined" - can say "okay we'll take these roles over 7 weeks, and here's the budget you'll end up with"
works well when scope is not exactly clear
Requirements Gathering Phase
a block of time allocated to defining a project scope
bigger projects, need more time for this
should include ALL the necessary team members AND the client
-- this is their opportunity to ask the questions about what we're building
low risk approach for everybody
at the end, should have a detailed SOW, and info needed to make a decision, and as a vendor, you should feel like you were paid fairly for your time
when to raise the flag
poor estimate = vendor's fault
change in scope = on the client
no scope / unclear scope = CANT raise the flag, we didn't do a detailed statement first, we have no leg to stand on
clients SHOULD appreciate this
Developers will appreciate it
Finance Dept will appreciate it
Track Report and Adjust
leverage time tracking software
run reports at end of each major task or phase
-- have to see how close you are to your original estimate
compare vs original est
archive info for future reference
helpful tools for estimating
spreadsheets (things you can share internally are nice)
InVision App -- static, clickable prototypes out of your wireframes
-- can demo how something SHOULD work before we actually write code
TimeTracking -- various ones (Mura uses an internal one)
Mura CMS - for building functional prototypes
Merlin - project management software for Mac
the problem - never really wrote a detailed spec up front
so...don't have a scope to go back on, so we start digging ourselves into a hole...
reasons:
didn't provide a good estimate
did no estimate at all
why some estimates go wrong, how to fix
lack of information
i want to build a shack -- need detailed info about the shack
need to ask ? up front to get the right info. is it really a shack? or a mansion?
req's are not understood, not clearly defined
think you have enough to do an estimate and you don't
Estimate process is rushed
desire to GET the job outweighs the desire to SPEC it correctly
often will cut corners to make things happen
(can happen internally too, not just with a client relationship)
not all items / phases are accounted for in estimate
(missing QA, documentation, training, etc)
"you don't know until you build it"
-- especially true in world of custom development
if we can be better at writing a SOW that's clean / detailed, when things come up later, we have something go to back to that we can change without upsetting the client-relationship
Poorly estimating a project can...
create tension between vendor and client
impact your prod schedule
impact cash flow
lose credibility with clients / staff
can lose current/future business
can even shut your business down
--- if you do everything at a discount, you'll end up discounting yourself out of business
so now do we overcome this?
know when to use different estimate methods
create an estimate model to work from
leverage a req's gathering phase
know when to "raise the flag"
-- even if done a good job estimating, you'll run into issues. understand WHEN to waive a flag and talk to your clients
-- know when it's YOUR issue vs your CLIENT's issue
- track, report, and adjusting
- track ALL your time/effort w/ a project
- so you can report on it
- then you can adjust how the project is going, and use that for future projects too, what did we learn before, etc
estimating models
fixed fee estimate
define a SOW, this many hours for these tasks, here's your budget
easy to contract because it's a fixed fee
get scheduled payments based on milestones
can plan resources on that b/c you know the LOE for each task
CONs
LITTLE room for error if you missed something
hard to go back to a client that's already committed to a budget
delays in the project due to underestimating will impact payment
(works well for repeatable services -- if you do a type of project all the time and you know what goes into it. preconfigured packages, etc)
ideal for clearly defined scope and timeline
Time and Materials
we're just going to bill you as we go and we'll check in with you
rare. most clients aren't ok with continuous infinite billing
all time spent on project is paid for
client can dictate priority
payments on regular interval
CONS
hard to estimate
hard to plan resources around it
may become expensive
---
handy for custom projects that are loosely defined
often these will narrow over time and turn into a fixed fee estimate
Resource Allocation Estimate
client says "we need to do THIS", it's not 100% clear, but need to be done by a set date
can use this to map out a traditional project schedule, flow, etc. to say who many people will be needed over time
good for ball parking estimates
but not entirely accurate
will probably be higher than actual costs
good for clients that say "we want to build the next amazon"...okay, it'll take 10 dev's for 3 years to do that...gets the clients into reality a bit about what they're asking for, to reign in projects
ESTIMATION MODELS
Requirements Gathering Phase
rather than sign off on a WHOLE project, let's spend a week together and map out what really this project is all about
work client and team together
at the end, give them a document, very clear on what's going to happen
THIS IS BILLABLE TIME! (for a certain block of time. b/c they get a deliverable at the end -- the req's doc, and that's what they paid for...or rather they paid for a lot of talking and information, that may not end up in an "official" document, but it still gets handed off to the client somehow)
Guess & Change Approach
gets you in the door
requires little up front effort
know what tasks go into a project (even the little ones)
things we often over look are the little tasks,
and docs
and training
and migrating to their prod server (do they have 2 servers? 3? 4?)
can do a lot of this in a spreadsheet
need to establish rates for tasks
(using a "blended rate" -- 1 rate for all the tasks. sometimes for gov't projects they need different rates
need to know how long COMMON tasks take
ex: for graphic design, building a logo is 32 hours
need to leave room for custom/one-off tasks
establish % factors for variables tasks
ex: PM is 15- 25% of time
so if 100 dev hours, you'll need 15 - 25 hours of PM time
use the model EVERY time (whatever model you come up with)
fixed model -
list all tasks by phase
set hours of reach task
rate x task
subtotal
total project cost
ensures all tasks are accounted for
can help w/ project schooling and resource allocation
know when to use which model
T&M Estimate
leverage the fixed fee model or resource model as a best guess
establish time tracking parameters
Resource Allocation Estimate
list all resources involved in project
project hours allocated per week/month per role
include variables (PM, QA etc)
extend role allocation over a period of time
"we have 7 wks to do prom, scope is loosely defined" - can say "okay we'll take these roles over 7 weeks, and here's the budget you'll end up with"
works well when scope is not exactly clear
Requirements Gathering Phase
a block of time allocated to defining a project scope
bigger projects, need more time for this
should include ALL the necessary team members AND the client
-- this is their opportunity to ask the questions about what we're building
low risk approach for everybody
at the end, should have a detailed SOW, and info needed to make a decision, and as a vendor, you should feel like you were paid fairly for your time
when to raise the flag
poor estimate = vendor's fault
change in scope = on the client
no scope / unclear scope = CANT raise the flag, we didn't do a detailed statement first, we have no leg to stand on
clients SHOULD appreciate this
Developers will appreciate it
Finance Dept will appreciate it
Track Report and Adjust
leverage time tracking software
run reports at end of each major task or phase
-- have to see how close you are to your original estimate
compare vs original est
archive info for future reference
helpful tools for estimating
spreadsheets (things you can share internally are nice)
InVision App -- static, clickable prototypes out of your wireframes
-- can demo how something SHOULD work before we actually write code
TimeTracking -- various ones (Mura uses an internal one)
Mura CMS - for building functional prototypes
Merlin - project management software for Mac