Six Simple Steps to Set Expectations with Software Estimation

Transcript:

Hi! Do you need any help estimating your risk in your projects? VP of operations at PSI, Rightley McConnell, is going to give a high-level overview of the steps of the Risk-Based Estimation Process so that you can begin to provide an idea of the schedule and costs associated with your next software project. There are six basic steps in the Risk-Based Estimation Process as we here a PSI perform them. First, get a product requirements document from your customer, whether they be internal or external. Second, create a basic work breakdown structure. Next, investigate subsections of the high-level breakdown, followed by clarifying customer expectations. Then, make an estimation with a group of developers, taking into account the risks – technical and otherwise. And lastly, account for overheads that are associated with the development of the project.

Rightley is going to go in depth with how these six steps can help you in your Risk-Based Estimation Process. If you take this step-by-step process and break it down this way, we think that you will get a much better estimation, and you’ll be able to set expectations with your customers as well, when you start any new software development process. 

Step 1 – Get Written Requirements from Customer

So, the first step is to get any sort of written requirements you can from your customer. This may take the form of a Product’s Requirement Document, marketing requirements, or anything else that really puts on paper what they’re looking for in the software of this new product or project. So, any helpful documentation is probably useful at this point.

Step 2 – Create a Work Breakdown Structure

From the documentation, you need to distribute it to a couple of folks on a team and have them create a work breakdown structure – a very high-level work breakdown structure – just enough to understand the different sub systems that are going to be within the larger software system.

Step 3 – Investigate Subsections of High-Level Breakdown

Then, you need to investigate each of those high-level systems and break them down into smaller components. So, the idea here is to take a look at all of the different parts and then really think about what technologies and subsystems are within those parts – and start looking at those as functional implementation blocks that your team is going to have to put together. You really just want to distill it down until it is a small enough chunk that an engineer can look at it, think about it, and start putting it in terms of days, or maybe weeks, for estimation. You don’t need to get all the way down to the hours, but you still want to have smaller chunks that they can assign days to it – on any larger sized projects. 

Step 4 – Clarify Scope of Customer Expectations

Next, you want to make sure that you discount or get rid of any scope that you can’t estimate well. And, you need to make sure that you make a good note of what that scope is. So, those assumptions need to be conveyed to your client – whoever they are, whether they be internal or external – about items that are included in the scope, because those are often the things that get forgotten about until near the end of the project and then can cause panic. So, it’s very important to make sure that if there is anything that is ruled out of the estimations, that you figure that out upfront. You may need to do that because:

1. Something is not available or not going to be available
2. It might be something that is a future consideration for a future iteration of a project
3. It might just be completely un-estimate able due to the information that you have on hand at the time

So, again, it is very important to be specific about what those items that are out of scope that someone may consider to be in scope otherwise – and very clearly delineated those being out and if at all possible, why. That will help everybody stay on the same page throughout the entire project.

Step 5 – Group Estimation

Next is really the meat of the estimation process. Here at PSI, we generally like to get at least three software engineers that are fairly experienced into a room and have them go through together, along with a project lead, all of the different parts of the work breakdown structure that either the team – or a smaller or different group – has come up with delineating the systems and subsystems within the project. So, first it’s important to discuss and make sure that every engineer understands what is included in and not included in different subsystems. So, oftentimes if you don’t do this you’ll end up with estimations that look incongruous because you’ll have some engineers estimating the U.I. for a particular feature, whereas another engineer may estimate the U.I.’s completely separately – so then they can throw your numbers off. You need to just talk about it as a group to make sure that everybody is pretty much on the same page about the methodology under which this breakdown is going to be estimated. Then, we highly recommend going through each of the subsystems independently that are in the work breakdown structure and each engineer thinking about and writing down how many hours or days they think each individual sub component is going to take in order to implement. So, it’s important – we think – that you do this independently so that they can each independently think about how they would do this, or what the risks are, and what the numbers should be, for that part. This is also a point where risk really comes into the whole Risk-Based Estimation Process. So, the risk may result and have ranges for certain items. For example: What if this item implementation goes well? What if it doesn’t go well? So, you may get ranges that you may have to take into consideration at this point. And this is actually a good thing because it can help set expectations and make sure that everybody is on the same page about what parts of the project are more difficult and riskier and which ones are more straightforward. So, after each person writes down what they think each sub system is going to take, then go through and create a group estimate based off of those. It’s important to discuss any large discrepancies any of the engineers may have. Whether it be that some of them think that some of the parts are risky, and other parts are not – or they could just have large gaps in the numbers of days or hours that they think that each subsystem is going to take. So, we find that if the engineers can talk about this a little bit after they come up with their numbers, often times you’ll find that somebody may have been thinking about something incorrectly. Or, more often than not, they may identify a risk that the other engineers didn’t, and often times the groups range will end up matching the larger ranges on the project. This is, again, usually a good thing because it helps set expectations about which parts of the projects need to be more straightforward and which ones are going to be a little bit more difficult. So, finally, if trying to cut a ride out a single estimation point, it’s usually a good idea to average out the three estimates that you then get from the three participants and come up with an individual number for each sub component – and then add those up at the end, of course. If you can’t tolerate a range in your estimate, this would probably be a good recommended next step. If the range is OK, then it is usually good to keep that range and then use the bottom range that each individual engineer may have and average those together to come up with a low end, and then likewise for the high-end to come up with a higher end of each sub component, and then by adding those up – you’ll end up with a total range for the overall project. 

Step 6 – Calculate Overhead

Finally – and a step that often gets missed but it’s very important – is to think about the overheads associated with any sort of project. Here at PSI, we have historical data that we can look back at (such as other projects) and see what overheads are associated with it. So, what are those? One thing could be implementation of automated unit tests. Those are very important, and they often don’t get thought about by the engineers when they are thinking about how much time it takes to implement something. So, you can oftentimes use overhead percentage for development tasks and figure that in for your time to develop automated unit tests. Another one that often gets overlooked is project management time. This includes status reporting on a weekly basis, reporting into team foundation server or another code repository you may have, code checkouts, check ins, and those sorts of things – and again, performance of your team based on your tools and the engineers that you have working on this type of thing is a good place  to start for getting this type of overhead. And then, of course, there are meetings. So, clients – whether they be internal or external – obviously would like to be kept in the loop of what is going on with software development. So, it’s important to factor in that that you may be holding a meeting with different stakeholders once, maybe twice a week. The important part to think about with that – is if you have three engineers in that meeting along with a project manager, that’s four hours of effort for every one hour of clock time that gets spent in a one hour meeting. So, that’s an important thing and again – in an overhead, you have to figure in based on what your customers’ needs are (again whether they be internal or external) and past performance.

We hope that by giving you some insight into our risk-based estimation process here at PSI, we can help you and your own product development estimation process.

If you take this step-by-step process and break it down this way, we think that you will get a much better estimation, and you’ll be able to set expectations with your customers as well, when you start any new software development process. 

Risk-Based Estimation Process:

1. Get Written Requirements from Customer
2. Create a Work Breakdown Structure
3. Investigate Subsections of High-Level Breakdown
4. Clarify Scope of Customer Expectations
5. Group Estimation
6. Calculate Overhead

If you have any questions or would like to learn more, feel free to reach out to PSI.