Diamond

You are here

What usually happens before you get started planning, designing, writing and coding is estimation. Your customer wants to know what the party will cost them. It’s a tricky question to answer. This session combines learning from experienced project managers as well as the opportunity to ask the experts your questions.

We'll be updating this session for Portland based on the 2012 Munich Presentation!

The problem

Drupal estimation is risky business for a lot of reasons. Two of the biggest issues are understanding what the client really wants, or can do away with, and knowing what techniques will get you the most accurate estimate.

Why this session is good

Because experts who have been down difficult estimation roads will share their knowledge and help you to interpret the client’s needs.

What you will take away from this session

Ways to identify issues around estimation, and solutions to solve them.

Session Outline

1 – Quick intro

- Why you are here
- Common pitfalls

2 – What are estimates?

- What should be in them?
- What advice can we share from our experiences estimating?

3 – Why we need estimates

- How do they help us plan, budget and communicate?
- What’s the difference between cost and value in estimating?
- How can I use estimations to levelset expectations and garner client trust?

4 – What affects your estimates? => RISK!

- Why should I care about Risk so early on?
- What should I know about my specifications, team, client?
- How do I identify and assess risks?
- How do I manage/communicate about risks?

5 – How do you make an estimate

- What techniques are out there?
- How do they work?
- When should I use what?
- How can I maintain my estimate?
- Estimation Exercise with Audience Members!

Follow-Up BoF TBA :)

Slides from DrupalCon Munich 2012 are attached, and will be updated and revised prior to Portland.

Estimation is always an interesting discussion but I would like to see some content/discussion about:
* Standardisation in estimation? How to get different teams (and perhaps the drupal industry as a whole) in a similar way instead of having to reinvent the "norms" for each team/project
* Capturing uncertainty and/or assumptions in an estimate. Its definitely related to risk, but is different.
* Estimating things that don't have a module or other "special cases" like estimating migrations, integrations, greenfield vs established code bases, refactoring/performance, etc.
* I think it might be useful to have some real-world client requests and show how they are broken down and estimated.