Estimating a software development project – in terms of cost and schedule – doesn’t have to be difficult when the project is focused and defined. When key elements get overlooked, and internal budgets are developed without a holistic view of a software project, your expectations may result in disappointment upon receipt of external bids higher than anticipated. We’re sharing some of our best software estimation tips to help you put together, or receive, a really focused software project estimate.

 

 

 

 
If you need software development related assistance, we can help. Please schedule a complementary consultation with one of our consultants.

GET STARTED

Transcript:

Importance of a Great Software Estimate

Before starting a software development project, it is important to understand the approximate cost, timeline, and scope of the project. This may be an internal effort amongst your software engineering team – or – this may be an activity requested of your software development partner. It is important that all project stakeholders are aware of the software development effort’s cost and timeline so that there are no surprises down the road. Both the technical team, as well as the, perhaps, less technical business, marketing, and operations teams should be on the same page regarding the software development effort’s budget and milestones. With over 40+ years of experience in estimating software development projects, we’re sharing some of our best software estimation tips to help you put together or receive a really focused software project estimate.

Software Requirements & your Estimate

We truly can not stress enough the importance of software requirements. Not only are software requirements the key to a successful software development effort; they are also the key to creating a very focused and sound software development estimation. When a product owner or engineering manager is able to thoroughly convey the software specifications to either internal software engineers, or their external software development partner, they can expect to get the same results in an estimate. Conversely, if a product owner or engineering manager is unable to provide a focused vision for the software development effort in question, then they’re likely to receive the same type of software estimate – likely a range, or best guess estimate that may not accurately represent the intended software development effort.

To quickly summarize that message – having a low-level software requirements specification is a sure way to get an accurate software development effort.

Software Partners & Software Requirements

With this said, it may be challenging to develop low-level software requirements without the assistance of your software development partner. The investment in a small engagement to develop low-level software requirements can really pay off. In our experience, this effort should take between 3 to 6 weeks, depending on the complexity of your software system. During this time, your software development partner can work with you and your team – which may include stakeholders from engineering, marketing, operations, investors, etc. to accurately define how the software system must function as it relates to the product’s desired functionality.

During this period, it’s important to discuss the software system as a whole – this may include embedded, web, and mobile components, as well as GUIs, communication protocols and APIs, along with microprocessors and various chips and hardware to be used. Getting all of the software system’s requirements out there will give a holistic view of the development effort and allow the software team to have a clear vision for the work product in question.

So, if you are following along, the first step in getting a really focused software development estimate is to make sure you have a low-level Software Requirements Specification to work off of.

The second step in the estimation process is to take the Software Requirements Specification and transform that into a Work Breakdown Structure. Within the work breakdown structure, there’s a few different components you’ll want to include:

Components to Include in a Work Breakdown Structure:

  1. First, you’ll want to define the subsystems.
    • For example: GUI versus backend cloud database, compared to physical devices or firmware components. In the work breakdown structure, determine the high-level development activities, like logging, error handling, authentication and authorization, just to name a few.
  2. Second, consider what documentation you may need.
    • For example: Software Design Specification, Sprint Plans, Software Verification Protocols, User’s Guide and any other documents that you may need to satisfy regulatory requirements.
  3. Third, determine the testing activities required for this effort.
    • This may include unit testing, development testing, and even formal Software Verification – or execution of the software verification protocols.
  4. Fourth, think about the various overheads that may be applicable to the development effort.
    • For example, time to set up the project in a build environment, project management, packaging sprint releases, status meetings.
  5. Fifth and finally, there are often miscellaneous items that would contribute to a greater software development cost that very often get overlooked.
    • This may be time spent in knowledge transfer sessions amongst various engineering disciplines, and even troubleshooting hardware issues that were not expected, but rely on a software engineer to help diagnose the root cause.

Applying Numbers to Work Breakdown

Once you have a good handle on all of the elements contributing to the software development effort, the actual estimation can begin – and by this, we mean applying numbers to the work breakdown structure. We find it particularly helpful to estimate in person-days. This can then translate into person-hours or person-months, depending how you need to show the estimation breakdown. After the estimation activity is complete, sum up the estimate numbers and apply the appropriate hourly rate to get your total. Keep in mind, the cost estimate should be accurate, but the duration of the project in person-days may not be indicative of the project’s duration as the number of engineers applied to the project can likely shorten the development timeline if there is a clear division of labor.

Conclusion

If you are not looking at your software development effort and including the elements that we have specified here, then you may be disappointed when putting your project out to bid. When key elements get overlooked, and internal budgets are developed without a holistic view of a software project, your expectations may result in disappointment upon receipt of external bids higher than anticipated. Estimating a software development project – in terms of cost and schedule – doesn’t have to be difficult when the project is focused and defined.

If you need help creating a software requirements specification – or, if you’d like to receive a competitive software development estimate, please don’t hesitate to contact us. You can visit us at www.psi-software.com or send us an email at info@psi-software.com – we look forward to assisting you in your next software development effort!

 

CONTACT US


No Comment

You can post first response comment.

Leave A Comment

Please enter your name. Please enter an valid email address. Please enter message.