Estimates - The Buck Stops with You!

Why are people so uncomfortable making a decision?  I admit I scratch my head frequently at some of the issues that land on my plate because someone was uncomfortable making a decision – or because they feel they haven’t accumulated enough information.

This is not a phenomenon unique to my current organization.  I’ve seen it across most organizations that I’ve worked in.  Managers have engrained into people that they are not allowed to make decisions and that they must review everything prior to anything getting done.  YIKES!  And then we wonder why people fail!  Better yet, we wonder why people leave us and move on to a new job – leaving us to spread the workload around to others on the team.

Look, I won’t claim my teams are exempt from this pattern.  But I do try to encourage people to think through problems they are facing and if they are unsure of a direction, at least bring options into the conversation when we sit down to have a discussion.  This at least allows me to see that they have thought through the problem and are attempting to address the issue.  Usually through conversation they’ll come to some type of a conclusion, thank me for the discussion and head back out.

I think where we struggle the most within my current teams is getting people to make estimates on project activity.  This is a personal decision by team members measuring how much work they will be responsible for against requested project activity.  When we first introduced this concept, there was a lot of push-back.  And to be frank, there were a lot of errors in the initial estimates.  But over time, people have grown more confident and are estimates are aligning better with the actuals that we measure over the life of a given project.

We go through regular training with people that are new on our teams.  It really doesn’t matter if they’ve been in development or whether they are new to the ropes.  Most developers have never been trained on how to produce reliable estimates.

So how do you pull together an estimate – well, for one thing, it’s different depending on what stage of the project you’re in: 

1. Discovery Phase: Usually estimates at this stage are done by someone within the management chain along with senior level technology resources.  How?  Well, the truth of the matter is the project scope is looked at in comparison to other projects that have been completed that smell like or look like they have similar impacts.
2. Requirements Phase: Typically this is a minor refinement of the estimate that was given in the Discovery Phase.  Any changes to scope are accounted for and typically there are additional details highlighted that point to previously unconsidered impacts.
3. Technical Design Phase: Now we are putting some meat on the bone.  At this point, technical resources have engaged and identified impacts across current systems/application silos and have also identified where new functionality must be created.  Along with the technical estimates business teams have assessed impacts to current and new processes.  Between the two paths, the full project estimate is considerably more accurate than anything that was put together in the first 2 phases of the lifecycle.
4. Development Phase: Some organizations perform the final detail design in this phase.  If so, this is the last chance to update those estimates both from a technical and business perspective.  This should allow the resources that are going to do the actual work to review the technical designs, identify the specific chunks of code or the business processes that are going to change the final say in what amount of time is necessary to complete project activity.

Rules of the road when it comes to performing estimates:

1. If you’re implementing new technology into your current technology stack – maybe you also need to set aside time to install and integrate the technology.
2. Don’t forget process changes.  Sometimes these changes can be just as critical to the project timeline as the technology changes.  Don’t underestimate the impacts these can have across your teams.
3. Don’t forget testing – and I’m not just talking about QA.  I’m talking about Unit Testing, Integration Testing, Parallel Testing, Performance Testing, Regression Testing, New Feature/Function Testing, and UAT Testing.
4. Don’t forget implementation planning and actual implementation activity.  While the universe may have been created with a big bang – in most instances you are going to see implementation activity spread out over a period of time.  Some implementation activity begins before the code touches production, and some activity happens months after the code is in production – you need to account for all of the activity.
5. Don’t forget to provide a buffer for 3^rd party activity.  I have yet to see a 3^rd party engagement go off without some type of change that has to happen.  The initial timeline provided for the engagement never usually is achieved.

Items for consideration when building the estimates:

• How many screen modifications need to be made?
• How many new screens are there in the project?
• How many web services need to be modified?
• How many new web services are there in the project?
• How many reports/data extracts need to be modified?
• How many new reports/data extracts need to be created.
• How many tables/stored procedures need to be modified?
• How many new tables/stored procedures need to be created?
• How many 3^rd party apps need to be touched?
• How many new 3^rd party integration activities are needed?
• How many processes need to be modified?
• How many new processes need to be created?
• What infrastructure changes are needed – servers, server types, routers, switches, security devices?
• What new infrastructure pieces need to be installed – servers, routers, switches, security devices?

Realize that you’re first efforts are going to be wildly off base.  Don’t be afraid to tell your team that you’re giving them time to get better at creating estimates.  This means when they’re wrong – it’s a conversation not a point against them in their annual review.  Use each estimate as a coaching opportunity when the final numbers come in – what they did right and what didn’t look so good and how do we make it better.

This by no means covers it all, but points you in the right direction.  Now I’ve heard some people say that in an Agile process you don’t need to worry about this.  Yeah, right.  Trust me, someone in the organization is telling the CFO what this thing your building is going to cost – how many 2 week iterations it’s going to take to get full functionality.  If you’re not responsible for making those conversations happen today – you will be at some point.  Better to start figuring this out know, before you’re asked to provide that first estimate.

Realize that you’re first efforts are going to be wildly off base.  Don’t be afraid to tell your team that you’re giving them time to get better at creating estimates.  This means when they’re wrong – it’s a conversation not a point against them in their annual review.  Use each estimate as a coaching opportunity when the final numbers come in – what they did right and what didn’t look so good and how do we make it better.

If you'd like more information on my background: LinkedIn Profile