- More than 1 person to do the estimation independently. Then compare the estimations. Large offsets on the estimations need more internal discussion.
- Split functionalities into subtasks that make sense (eg a search, a display page etc)
- What "question" is the estimation trying to answer?
- Provide lots of details to an estimation.
- Do not give only numbers to customers (eg the price and the deadline).
- Try to not be strict about delivery dates and set the variables that may affect delivery.
- Keep useful statistics that can be reused on future estimations.
- Determine which parameter is flexible on the Project (time, budget or scope).
- Consider using the Three-point estimation.
- There is no such thing like an "accurate" estimate.
- Do not make promises, provide information.
- More than 1 person to make the estimation.
- If the budget is strictly fixed to not provide an over-budget estimation.
- Who is available?
- What type of work can each person do?
- Try to have people 100% on a single project. Else there is a minimun of 15% reduced productivity for each person (known as "context-switch penalty").
- Try to have some alternates for the Project.
- Determine skills of each person.
- Know your team and their pace.
- Determine which parameter is flexible on the Project if any (time, budget or scope).
- A "good" developer is not a "great" developer. Plan for the "average" skills person.
- Varying degrees of effectiveness.
- Do not pretend estimates are accurate because they are not.
- Watch out for burnout.
- Ideal Team size of 3-4 people.
- In large Teams create smaller Teams that can work independenly
- Create a matrix with Tasks (work streams) and assign to the Teams.
- Communication (meetings, calls, investigation etc) requires effort too and must be taken into account.
- Goals per Team must be clean.
- With independent smaller Teams it is easier to make quick and nimble progress.
- Ensure all the right people are present (including the vendor decision makers).
- Introduce the Team and the vendor decision makers.
- Describe how Communication, Tracking and Reporting will be done.
- Set rough excpectations.
- Make imeddiately tactical decisions (eg find out how an internal process works vendor side).
- Cast vision: Why this project?
- The Task (what's the main site functionality?)
- The Deliverables (bullet point list)
- Background information (what eas the reason to write this brief?)
- The Objectives (Explain any key challenges and opportunities)
- The target Audience (user profiles etc)
- Choice of channels (eg web, email, mobile app etc)
- The key Message (what are we saying?)
- The Budget (by phases)
- Measurement (KPI, how will we measure success?)
- Any mandatories (is there anything that we should include or avoid?)
- Possible ideas
- Tone of voice (eg branding, UX defined etc)
Source: Drupalize.me - Introduction to Project Management
- Break down the work into smaller tasks
- Don’t assume without asking questions
- Propose adjusting the requirement
- Factor in your degree of confidence
- Agree on a sequence for estimating
- Set a maximum time limit for each task
- Do not forget about the extra things