I estimated on projects that took less than a month to more than a year. I find estimating is an art and a science. There are inherent difficulties with this.
- You are asked to predict the future that you have no control of.
- You are not given a lot of information. Sometime the requirements are very vague.
- You are forced to give one because that’s what everyone wants to know when they ask you to do something. It’s also needed for business planning and approvals.
- Contact the requester, get a quick feel of the idea and its origin, and confirm the financial situation about implementing that idea.
- Schedule a meeting (bring in an expert, if necessary) to gather information and gauge if the idea is good, beneficial and in the right domain.
- Repeat as often as you need.
High Level Estimates
“Lack of confidence” in the high-level estimates is common. I would do more due diligence to improve it.
- Based it on actual past experience by looking at previous projects you’ve done.
- Determine complexity. Is it something more/less complex because of the amount of work (for example, cooking a burger vs 10 burgers) or the amount of unknown (for example, cooking a burger vs a butter croissants – don’t laugh. I found a recipe that take 19 hrs).
- Peer review. Ask a co-worker with a lot of relevant experience to review your estimates.
- Always record your assumptions and update every periodically. You will be defending your work now and 6 months in the future.
- Do not pad your estimates. Identify risks up front and explain how the risks could drive the estimates up/down. Proactively work to mitigate/eliminate/transfer/accept the risks.
- Have a plan to develop detailed estimates and share that plan with team and management.
- Team preparation – do requirement gathering, initial architecture design, application impact and user impact analysis. The team should completely understand what is being asked of them to do and the relationships between major functionalities . It is ok at this point to know exactly how to implement all of the details yet.
- Break everything down to a level that is easy to understand and estimate them. Get the person who performs the work to estimate.
- Add everything up. The devil is in the details. You’re not done yet. Go further because I know the follow up question is “how long is it going to take with the resources you have with the existing work commitments?“
- Do resource leveling by identifying available future capacity and detailed estimates.
- Use software tool like Microsoft Project.
- Look at team’s capacity and utilization.Account for everyone’s time, holidays, task estimates and relationship between tasks.
- Identify bottlenecks, critical resources and critical paths. The software automatically calculates the beginning and the end of the project.
- Go through every task line-by-line and agree with the underlying logic. Sweat the details now. Show you’re confident of your information and you’re on top of things.
Communicate the Estimates
Be a good storyteller. Here’s how to communicate estimates.
I learned about the product idea from Bob. He told me the product must do feature A, feature B, …. I broke features down into concrete deliverable A, B, … I estimated by consulting with Mary, who is senior architect.Based on existing platform capabilities and previous product releases, we think it’ll take 6 months to deliver them. I also recommend we break out them out into multiple releases so that it gets to the market faster.
KEEP IN MIND
- Do not provide estimates without do preparation work. If estimates are worthless, that reflects on the PM.
- Estimates are not supposed to be owned solely by PM. I make sure the right questions are asked and the due diligence is done by the right experts. So at the end good estimates are collectively responsible.
- Cone of uncertainty
- There are many times you will be told to deliver features in a specific time frame by someone. I would recommend you do the following, at the minimum, to avoid shooting yourself in the foot before you even start.
- Ask follow up questions on what drives the features and the timeline. The better you get to know the origin of the person and the problems the product is going to solve, the better you can communicate and work with later.
- Record that as a cost/schedule/technical risk and proactively manage it. In early stages, you may note risks in your own notebook and that’s ok. But as the progress is made, you want to formally record and manage the risk’s information (such as situation, probability, impact to stakeholders and users).
- You should make sure your estimates are based on specific deliverables that are clearly understandable. For example estimating a task called “Work on requirements” is not very good. “Define online shopping card requirements” is better.
- Guard against scope creep, especially you have tendencies to please everyone.
- Negotiate with customers and your team and revise your plan and estimates. Do NOT put everyone in a tough situation where customers don’t get what they want and the team don’t have time to build a quality product.
- When you give detailed estimates, you’ll be asked to commit to it. That’s just unavoidable. So at the minimum you should’ve done the following already to cover your ass later on.
- Estimates are done by the one who does the work and confident of the estimates.
- Review with everyone on your team and get their buy in on the entire plan.
- Review with your manager and other managers as needed. After that, you are ready to explain and commit when you present it to the decision makers on your project – usually senior managers and directors.
- Plans and estimates should be updated whenever there are major changes in scope and features. Look into rebaselining the plan while keeping sponsors and management closely up to date.