Estimating a custom software project is a difficult necessity that usually occurs before the project kickoff (what we like to call the “point of maximum ignorance”). And getting estimates right can have a significant impact on the overall success of a product. Read more on Get Better Software Estimates by Combining Different Perspectives…
When we’re running a client’s project using our Atomic Process, our team will assign an estimate of points to each item in the product backlog.
In general, we classify backlog items into three buckets:
- Features (new or enhancements)
- Chores (dev work not resulting in tangible product changes)
- Bugs (fixing unexpected behavior or regressions)
We work with clients to define custom software proposals and create a responsible budget. In this task, we’re always going to be in a position where there are unknowns. For example, a project may need to integrate with a third party service we’ve never used before. We have to assume the service works as advertised. We really won’t know until we do some additional research and start working with the service. Read more on Making Smart Assumptions in a Project Budget…
Atomic Object builds custom software for our customers. Because of the complexity involved in building a great software product, software development projects are always more difficult to price than a product.
As a result two different strategies for pricing services, such as building software, have traditionally been used by most companies. These are called “Fixed Price” and “Time And Materials”.
A Fixed Price strategy locks in the total price of the project upfront.
- Static Variables: Scope, Cost
- Flexible Variable: Quality
- Assumption: The estimate and plan are correct and will not need to be changed.
- Risk: On Consultant (Responds by inflating cost; may compromise quality if estimates are inaccurate.)
- Effect of New Information: Causes conflict about what’s covered by the scope vs. what requires a change order. New ideas are rarely incorporated.
In this strategy, the vendor is taking on all the financial risk of a project. They have committed to completing the project for a specific price. If they complete the job early, it’s a bonus for the vendor (and you the client has overpaid), if they don’t then the vendor loses. In order to mitigate this risk, they will want to know all that can be known about this project and the risks before it will commit to a fixed price. Read more on Fixed Price vs. Time & Materials vs. FBSC (Fixed-Budget, Scope-Controlled)…
I’ve been at Atomic Object for approximately 8 years, and during that time I’ve had the opportunity and the challenge of managing relatively large software projects. I’ve learned quite a bit from fellow Atoms and picked up a few tricks of my own throughout the years. One of the best practices I’ve picked up is keeping a well-organized and properly-categorized budget.
Software projects are generally given an overall budget that a team can work against. However, the realities are that a budget can be made up of a number of different components — some of which have nothing to do with actively creating features and are instead meant to be used for upfront processes (Kickoff and RDP Phase), customer communication, project management, technical documentation, etc. Depending on the overall complexity of your project, you may have one or two of these categories or all of them. Read more on Breaking Your Budget into Categories…
Estimating a new project is hard and time consuming. Why? Because when you start a new project, you are at the point of maximum ignorance. In most cases there is a solid idea, but the required functionality is ambiguous.
The business is depending on you — the engineering team — to identify a high-level timeline.
I estimate a lot of projects like this every year. Here are a things I do to cope with that ignorance and ambiguity.
1. Select the Right Magnitude
Begin by deciding a uniform level of precision for your estimates. If you think the project is going to take years, then your estimates should be in weeks. If you are guessing months, your estimates should be in days. And if you think the project is going to take weeks, you should estimate in hours. Read more on 5 Tips for Estimating at the Point of Maximum Ignorance…
When you are developing initial requirements for a new software product development project, you may find yourself questioning the appropriate level of detail to provide for specifications.
You may feel compelled to provide a high degree of specificity so the development team can create an accurate estimate of cost and time to build the defined solution. You may feel worried that if you miss something in the software requirements, the project — or even you — may be viewed as a failure. The good news is that you can loosen up! There is a better way to develop requirements, and it doesn’t include specifying every detail at the start of the project.
Detailed Specifications – Too Much Definition, Too Soon
The first step is to realize you probably should not be creating a detailed set of functional or technical specifications for a development team to build. It’s usually too early to focus on detailed specifications before the development team has an opportunity to creatively engage in the project at a broader level — including business and user motivations. Providing detailed functional and technical specifications too early can create a false sense that the problem or opportunity is completely understood, which can result in missed opportunities or inaccurate project plans.
Buying custom software design and development services, especially for the first time, can be scary. There is clearly a knowledge imbalance between you and your service provider. They (hopefully) understand the effort required to successfully build your product, and you don’t. This puts you at risk of being taken advantage of.
I understand this fear. Any time my car is in need of repairs, I am paranoid that the mechanic will take me for a ride. Other than being able to drive a car, I know very little about them. There is a clear imbalance between my and the mechanic’s understanding of labor and parts costs. This puts me at risk. Read more on Why You Should Trust Your Software Vendor – From a Guy who Fears the Mechanic…
I gave a talk entitled “Time-Based Estimates Are For Suckers! Size-based is The Way to Go” at this year’s GLSEC on April 29. It’s meant as a call to action for those who haven’t made the leap to size-based estimation, or who have been beaten back by some of the challenges you’ll encounter when trying, such as:
- Breaking things down by value, not by task
- Thinking in terms of “size” (not time)
- Making estimates
I did this because, even though we’re all a bunch of Agile know-it-alls by now, and estimation is a remedial topic from 10 years ago, there are still plenty of people who haven’t been introducted to size-based estimation. Besides, making the switch from time-based estimation to size-based isn’t as easy as some of the books and blogs out there make it sound.
I recently came off a project where it is clear, in retrospect, that we operated in a rush throughout much of the last half of the project. The budget got extended more than once so that we could “just get it out the door.” It was a small project: a month or two initially, then another month part time working on “that last detail” and helping to transition it to the customer’s internal team.
This has led me to the conclusion that, when coming to the end of a budget, deciding under pressure to extend the work for “just another week” is a very bad idea. The technical decisions driven by a project size of six months are probably not the same decisions that you’d make on a one year project. When you find that your schedule is slipping, it’s important to make an honest review as soon as possible.