Estimating the cost and schedule for an upcoming software project may seem like a daunting task, especially if you have limited information to utilize. PSI shares their estimation process and a few tips and tricks to ensure you cover all your bases, ultimately calculating a comprehensive, well-planned estimate to share with all project stakeholders.

This video features:
Casandra Mann, PSI Marketing & Sales Manager
Rightley McConnell, PSI VP Operations

TRANSCRIPT
(Cas)
Hi everyone, thanks for joining us today as we talk about estimating software projects! As a software engineering firm, we are constantly estimating the level of effort it will take us to complete a new project or an additional software feature in an ongoing project.

If you’re not a software engineer and are tasked with putting together an estimate -or- if you are presenting a budgetary estimate to management or a non-technical individual, you may want to think about how you and your team are coming up with your level of effort and associated costs.

Rightley’s here today to share about PSI’s estimation process and give a few tips that you may be able to adopt into your estimations going forward.

So, Rightley, where should we begin?

(Rightley)
Well, I think the first thing to know is that no one likes estimating. Engineers especially, we like exactitude, we like knowing everything before we go ahead and plan things out, and as we all know, at the beginning of a project that’s just not possible. So, we’ve come to start calling these things that we do, “Estimation Parties” just to make it at least sound like it’s a little bit more fun, also to hopefully relieve a little bit of the stress that people inherently feel any time that they know they’re going to be called into a room to talk about this.

So, we always start off an estimation party with a general understanding of what the project is. We need to either going into a meeting or as part of the meeting depending on the familiarity with the project, it’s good to have a very loose, at least, work breakdown structure of what the software must do. What subsystems and which parts it will contain. Going into the meeting, ideally, you’ll have a set of software requirements. But we all know, when you’re estimating something very early on, having full requirements is not usually possible, usually because management is trying to figure out if they want to do the project or not, so they haven’t gone through and committed the resources to really coming up with full requirements. So, they’re ideal, but if you don’t have them at least create a loose work breakdown structure.

You start by breaking down the whole system into a few subsystems, at least if you know there might be on an embedded device, you might have multiple microprocessors, or a PC or a cloud-based system you might have different components, the database, the UI, the processing, all those sorts of things, figure out a way to logically break down what the system does by areas of responsibility within it. So, once you do that, lay those out and then get the team to talk about what are the subsystems within each of those parts. You need to just kind of flesh out what are they responsible for data intake, how are we storing things, how are we going to encrypt and save information. All those different aspects and get the engineers to think of them as sort of a functional set of groups underneath those groups. You don’t need to break it down to every last detail, I’m talking about designing it out down to the individual function level, but at least get it in some kind of realm where you can wrap your head around each individual part. Once you’ve got that far, then it’s good to just go one more trip through all the parts and make sure everybody has a common understanding of what each part is responsible for. So, you may in addition to checking out all the different functional parts, you don’t want to glance over, you need to have time built in for documentation you should have at least requirements and a basic design up front. If it’s a medical device you’ll have to have a lot of planning documents and other things as well, so you don’t want to forget those. And then, lay out all those different parts and make sure people understand, ok I’m counting the documentation up here not as part of the development. Make sure everybody has a common understanding so when you get the numbers they all kind of make sense and they all jive together, it’s really important when you get to the next step when you start averaging things together and people have a common understanding.

The other thing to not forget is to count in every project has meetings, every project has project management overhead, and if you’re reporting to anybody, which everybody is, then you need to have some time built in for status reporting and other tracking that you need to do. What this ends up looking like in the end is you’ll end up with, we use a spreadsheet, a simple excel spreadsheet that you can put up on a tv, or a board, projector, that everybody can look at. And you’ll have your planning and your documentation at the top, and then your breakdown of your subsystems, which is the actual code writing part. Then you’ll have line items for testing as well, cause you need to execute those test plans that you had up in the initial documentation stage, so you got to figure out how much time to execute those as well. And then don’t forget those overheads for project management and meetings. So, a good way to think of those two is, generally we use just a flat percentage, and you have to think of what works well for you and your team and how your meetings usually go, but don’t forget to account, like think of it as in if we have a weeks worth of work and all of the members of the team are there, how many of those members would normally sit in a weekly status update meeting and then how long does that meeting normally go. And with that, you can kind of figure on a per person basis, what is the percentage of their week that’s dedicated to meetings, to status reporting, to tracking and so on, and you can add those as just straight overheads at the bottom as a percentage of all of the items above.

You can also go so far as to do that for testing, especially unit testing, so if you’ve seen some of our other writings or videos, then you know we’re big on unit testing. A good rule of thumb, it depends how intense you want to go on the unit testing, but you can also include an overhead for unit testing that’s just against the software development portion of anywhere from 25-50%. If you add those overheads at the bottom you now have this spreadsheet, so the next step then, and I think it’s very important that everybody does this independently, the way we found easiest, print a copy of it, just print a copy for everybody in the room, quickly run to the printer, grab it, then bring it back and then have everybody just fill out their numbers, make sure it’s very clear too if we’re estimating in man-hours, man-days, man-weeks, whatever, and fill out their numbers associated with each portion. So this is kind of like a secret ballot, almost.
Once everybody goes through, think about then, going through and getting everybody’s numbers and putting them all into the spreadsheet that you have on the board. Usually, you’ll find that a lot of the estimations across the board for any one item, they start to get fairly tight, but sometimes you’ll have outliers. If there’s an outlier, discuss it, you’re not trying to prove that any one engineer is right or wrong about something, but they may have been thinking about it a little differently and you’ll usually see that the other engineers or that engineer might be willing to adjust their numbers up or down to come more in line with the general consensus. So, once you get to that point, then it’s just a matter of simply averaging all of the estimates together. It’s usually 2 to 4 engineers that are estimating, so you average their numbers and you can come up with a pretty good middle of the road estimate. Another way to do it is take the min and max for each item and get a range. It depends what the folks you’re working with need, what they feel most comfortable with, the middle of the road number or a range. That’s how we generally figure out how to get the effort estimate for a project. It sounds like a lot of steps, but really it’s just basic work breakdown structure, laying out the individual sections, not forgetting the overheads in testing and documentation, and then applying a simple averaging or a range method to the numbers that you get out of it.

(Cas)
Very good. And it seems like once you have the staples, like the requirements, the testing, the overhead, once you have those in every project, you kind of get a sense of what that percentage is going to be moving forward then after you complete one of the projects and then go back and review and see where you were in hitting those numbers, right? Like you can really carry those through to future projects then.

(Rightley)
That is a great point, so keep ahold of that estimate that the team came up with at the end. Then after you can revisit it after you get the requirements if you didn’t have those, because it may be a worthwhile exercise to refine your numbers at that point once you really get the requirements down but especially afterwards, revisit it after the project as part of a project post-mortem and see how you did against the estimates. You’ll get to know, are the overheads reasonable, are the engineers tending to estimate on the high side, on the low side, and then there’s also of course factors for how much scope creep was there during the project because the client or marketing department or whomever needed to add different things and you’ll start to get a feel for those.

(Cas)
Awesome, well it’s definitely a useful tool and I think that those viewing this video could probably take some of these points here and adopt it into their process or if they really didn’t have a process yet for estimating software projects this is a great start. Another important part of aspect of estimation is coming up with a schedule. We talked about cost and we talked about level of effort, how does this process allow everyone to formulate a schedule and then share that with all stakeholders.

(Rightley)
Sure, yeah so of course as you said, anytime that you’re estimating effort of course management, customer, whomever is also going to want to know how long is the project going to go. So what you really need to think about then is resource loading. It may not necessarily be the same engineers in the room that were doing the estimating that’s doing the work, which can present some problems, so you have to be aware of the level of skill or the resource availability you have is. But there’s a couple rules of thumb that might be helpful to you when you do that. It’s really just quick tips to make sure that you don’t forget.

So a nice way to breakdown if you’re working on an embedded project is by microprocessor. If you have a multi-microprocessor system it can lend itself well to working with multiple engineers simultaneously, unfortunately, microprocessors being what they are quite often, maybe if you have 2 engineers working on the same micro at the same time, you tend to step on one another’s toes. It doesn’t always result in great efficiency, you may be more speed but it’s not terribly efficient generally. If you have a system with two or three microprocessors or if you’re in a PC you would have a couple different ways to break down into different subsystems they might be data processing, they might be a UI, and then a database. That would be three good sections that you could probably work on pretty much in parallel as long as you do good design up front. So think about how many engineers can you realistically have working on the code aspect of it at any one time. So that can cut your time possibly in half or a third depending on how many resources you can work on it with at a time, but don’t forget at the beginning of it there’s the requirements and design process and that is something that you’re better to go slow in order to go fast later. Don’t overload the front side of a project with a whole bunch of folks on the requirements and design if you don’t yet have an architecture worked out because you’ll have a lot of people going off in multiple directions and it’ll just end up in rework. So make sure you at least have really good requirements and you have a general idea that can be communicated to everybody on the team how each of the subsections generally are going to interact with one another and then you can kind of turn the individual engineers loose to work on the designs for each of those subsections.

So when you think about that you probably have fewer people in the beginning and then it’ll probably step up slowly over a bit of time and then you can probably reach a peak resource loading somewhere in the development phase and then it’s going to taper off then again towards the end. Likely testing the team might drop back down to a half or a third, or maybe just a single person doing the test execution towards the end. Again, that’s one where if you have a lot of people testing all at once if you run into problems you’re going to end up doing a lot of rework because one persons test results may invalidate another person’s and then you end up with lost work. So it’s kind of a tear drop if you can think of resource loading. A little bit at the top and then it really widens out and then it will hopefully quickly kind of come to a close once you get to the test. So when you lay that out and you think about, come up with it’s one person year of work to do the job you may be able to have on average two people, you can roughly cut the schedule in half. And then of course never forget to add a buffer in there during especially in the requirements and design up front there’s going to be review cycles, you’re going to lose a few weeks here or there potentially on something like that.

And then also if you’re working on embedded devices especially, sometimes parts have long lead times so that’s where you have to coordinate with the hardware folks and see how long does it take to get this microprocessor, is it new, are these other parts, how long does it take to get a board spin. You could have 6 weeks in there from the time you get a board drawn out and get the PCB layout done til you actually get one in your hand, it’s hard to say. You want to try and take some of those things into effect to really come up with a realistic schedule that you can present to management tor a customer. But it all stems again from doing this estimation party and getting the level first and then figuring out the schedule afterwards.

(Cas)
Thank you Rightley for outlining PSI’s process. I think it’s very helpful. And to those of you we’d love to hear from you. In the comment section, share how your process actually differs from or relates to the process that Rightley just outlined here. It would be great to hear and we could always adopt some of your ideas as well.