Upload
michaelcummings
View
4.212
Download
0
Tags:
Embed Size (px)
Citation preview
Project Estimation
When the design out grows the back of the napkin
Michael Cummingsdevelopment.realtimedata.com
@realtimemichael
Estimating is Important
• Your customer asks for an estimate to make decisions• Hire you?• Fire you?
• Typically, the project specifications are bad
• You must question the specifications • Look for holes – missing pieces• Look for bad design• Make sure it really is a Drupal project
Who Wins?
– If you win:• You can get more money later• You can actually complete the project on time and on
budget• Your customer wins too
– If your customer wins:• You will be working all day and all night for no pay• It will be your fault• He will be mad about a late / over-budget project• He won't really win
What is an Estimate?
• Your customer thinks an estimate is a price• An estimate is not just a price• An estimate without a specific, limited list of functionality is
the road to developer hell
How to Estimate?
• Estimate based on specific list of items (Scope of Work)• Also list items discussed but not included • Your Scope of Work is your Fortress Walls
• Resist adding additional items • OR Get additional money and TIME for additional
items• OR Agree to push additional items to version 2
1. How Strong is Your Fortress?• Can you defend against:
• “But, I just assumed xyz feature was included.”• “We talked about xyz feature, where is it?”• “The project is useless without xyz feature, you should
have known that was in there.”• “The business changed, and we really need xyz feature
now.”
1. Understand the problem
• Skip this step – you die• Pretend you understand when you don't – you die• Your customer does not understand the problem either• Customer participation is key
• If your customer looks at your very first draft and says “It looks fine to me.” Run for your life!
• If your customer looks at your first draft says you are wrong, this is the first step to a good understanding – he is working with you
But I Don't Get Paid for Writing Documents!
• Nobody will pay you for writing an “Estimate” • Good customers will pay for “Project Design”• You decide what you call this work.
4. Mock ups / Wireframes
Should be Low-Fi to begin with
Using full Photoshop mockups will take much too long and spend time on pixels too early in the process.
Tools• Google docs/drawing• Paper• I like Balsamiq Mock-ups
Examples : www.wireframeshowcase.com
• Print them out. Users should mark them up
photo credit:http://www.wireframeshowcase.com/wireframes/detail/medstars/
2. Use the skills of your people
An estimate made by anyone that does not fully understand the work that is to be done is going to be poor.
Giving your team a look at the project can help you avoid potholes
Don't Poison the well - don't give leading information
It is better to ask how long did this take you the last time than "How long will this take"
Use caution with developer estimates
3. Estimating Time
Time only comes in 2 sizes:
• 1/2 Day • Full Day
Round up to nearest ½ day – it forces developers to be more realistic
Beware of estimates for a single item that are larger than 2 days
You DO NOT understand the steps if you make it larger than 2 days.
Our experience is that an estimate of 3 days will be 5 days to weeks.
Photo Credit: h. koppdelaneyhttp://www.flickr.com/photos/h-k-d/
5. Customer Must be Involved• The customer must understand the functionality and
appearance of what is going to be delivered.• You know they are participating if you get complaints• Do not accept "Ya, that's fine"• I have had customer who had signed a contract in blood
demand additional features because they did not understand my text only description
Photo credit:http://www.flickr.com/photos/marine_corps/
• Involving the customer and frequent interaction helps both of you keep the expectations in check
6. Make a list
Modified Delphi Estimation method.Developed by Rand Corporation in the 40'sFancy word for list - Work Breakdown Structure (WBS)
Members of the team make their list of tasks SEPARATELY
After lists are made members meet and compare lists. Everyone must participate. If there is no conflict and you didn't get any additions you are doing it wrong.
Team should agree on a list of tasks then go back and and add time to the items
About those listsHow do you Estimate something you haven't done before?• You can't• Do a prototype• Find someone who has done it before sub-contract/buy
training
Common pitfalls • overoptimistic/pessimistic team members• undiscovered requirements• "you don't know how much you do not know"• uncommitted members of team (includes customer)
If I add up all the time..its too much
• Add up all the time then decide if you want to buy/discount the project
• Check your assumptionso maybe you can re-factor the solutiono some features may have to be cuto Since the customer is involved. Let them decide what to
cut. Or to add budget. • Reality will not change to no matter how much you need it to
or how convenient that might be. • Some projects should be avoided.
Real Time Estimation Method
1. Understand the problem2. Use the skill of the people you work with.3. Estimate time in fixed amounts4. Make a Wireframe.5. Customer must be involved6. Make a list of tasks (Work Breakdown Structure)
Source books
Extreme Programming by Kent BeckGetting Real by 37 SignalsApplied Software Project Management by Stellmane and Greene
Further Contact:
Michael CummingsTwitter: @realtimemichaelDevelopment.realtimedata.comMichael@RealTimeData.com
Project Manager, Programmer.
This Slide Deck at:
SlideShare.com