In this blog post, I’d like to give an overview of how we come up with project estimates and business proposals for our clients. Working as a Project Manager (PM) for the past 5 years in a software agency setting has led me to all kinds of different theories and methods for tackling the “How much will it cost?” question. From do-no-estimates-at-all, to write (and apparently foresee) everything up-front in a huge Tome of Specification, there are many different approaches but none of them quite fit the way our teams in Locastic work.
After some trial and error, I came up with a “method” of creating estimates for each project, both time and price-wise. I’m sure some of you reading this will be flabbergasted that we even dare put working hour estimates on anything, and some of you will find this method too imprecise, but it has worked quite well for us in the past year or so. Anyway, I’ll leave a link to a shared google sheets file at the end of the blog post that we use for all types of projects, and if anyone finds it useful I suppose typing this was worth it.
Before we dip our feet in the great unknown of estimates, there are 2 important categories that we need to define:
- Types of Projects
- Preconditions of good estimates.
Types of Projects
In an agency setting, there are a number of ways a project can be perceived, but right now I want to focus on how we categorize projects based on budget and requirements. A project can have a:
- Flexible budget + Project idea
- Fixed budget + Project idea
- Flexible budget + Project specification (and/or wireframes/prototypes)
- Fixed budget + Project specification (and/or wireframes/prototypes).
I think we can all agree that fixed budgets and agile methodologies don’t go so well together, but let’s face it, if you’re in the business of offering software development services, you are most likely to work with a client that is not tech-savvy and doesn’t care about sprints and story points. He cares about the final cost of the project, how much funds he needs to raise and how long will it take. Honestly, I expect these questions from every client, and find it confusing that anyone would ever accept a business proposal without even a range of possible costs and deadlines.
With that said, we always try to avoid giving a single fixed number for the budget. Try and negotiate a range, and make sure that if the budget is fixed at least the scope is flexible. If both are fixed (yes, those exist too) then the specification should be considered the Law, and the contract should protect you if even minor changes are made to the scope. These are definitely the hardest to deal with, and should be avoided if possible.
Much more troubling is the difference between project ideas and real specifications. Project ideas are basically the “specifications” the client provides you with, which is usually a simple set of explanations, drawings, sketches that represent how the client envisioned the final product. It is nowhere near a working prototype or a decent technical spec, and if you base your estimate on those, you’ll be in a lot of trouble real soon. Even with real project specifications that include wireframes and working prototypes, if you look close enough, I’m sure you will find more than a few plot holes and logical mistakes in the application workflow.
Looking at the types of projects mentioned above, the worst case scenario is fixed budget + project idea, and the best one is flexible budget + project specification. In both cases, the method of coming up with an estimate will be the same. The easier (better) one will be more precise and usually faster to do, but both estimates should keep you out of trouble.
Preconditions of good estimates
With this in mind, let’s talk about the preconditions behind good estimates. For this process to work you will need:
- Clickable wireframes/prototypes
- Engaged clients
- Contracts that are adjusted to agile methodologies.
In the best case, where the client actually gives you a working prototype and has a great technical specification where everything is properly explained, you can skip no.1 in the list above and go straight to estimation. In my 5 year career, I might have had one or two such cases. Usually, upon closer examination, these wireframes and specifications contain a lot of mistakes, missing screens and features that are crucial for the application to work properly.
That is why we always separate the process of working on a project in 2 steps. One would be creating a clickable prototype which will also serve as “living” specification of the project. The second step would be developing the project, with the business proposal based on the prototype we developed in the first phase. These two steps are completely divided, in a way that the client can actually only ask for a working prototype + specification from our team, and do his own inhouse development. Of course, the goal is to work on the development of the project, but there were cases where we only delivered wireframe and UX services which were beneficial for both the client and the agency.
Without going into too much detail (because this will be covered by one of our UX experts in the near future), the first thing we do is have a number of time-intensive meetings with the client where we write down and sketch each feature as detailed as possible in the given timeframe. User Experience (UX) guys start developing a prototype in Axure on the spot, and refine it afterwards.
Once we’re sure that each scenario that we managed to come up with works on the prototype, we consider it good enough to act as a specification and a frame for a business proposal. It usually takes a couple of iterations to get it done. If possible, try and have the whole team (that will work on this project) participate in these meetings. As you can see, here is where the “engaged client” precondition comes into play. The client needs to be a part of the whole process, give feedback, provide necessary materials and explanations etc. This is actually important during development as well, so make sure to have a dedicated individual on the client’s side that will be available and engaged as the rest of your team.
Good contracts are also a huge part of working in an agile software development company. This is really a whole other subject in itself, but for now let’s say that you need to form them in a way that will support agile principles. If the scope changes, the number of working hours must change as well; if a client doesn’t provide you with materials on time, they can’t expect the same deadline; estimates are estimates, and estimates can be wrong, which should also be clearly stated in the contracts with defined steps what to do in that case; work is always done incrementally etc. I think you get the gist of it – don’t use old school contracts that aren’t really fit for software development. If your process is agile, your contracts should also be.
How we do estimates
Now that we defined different types of projects and preconditions for a good estimate, here is how it looks like in practice. This is a fictional project with fictional numbers (I combined a couple of different estimates here) so some numbers might not be realistic, but should serve the purpose of explaining how the estimate table works:
Depending on the project and team size, the number of rows and columns will vary, but the structure should be pretty much the same. As you can see, on the left side of the table, rows will be used to list features (or sections) of the project based on the prototype. There are a couple of miscellaneous sections as well, like Project Setup, Test coverage, Speed optimization that aren’t directly connected to a single feature.
Columns are used to define team roles and min and max working hour estimates for each feature per team role.
As you can notice, the Design column doesn’t have min and max hours defined per feature, because designers like to give estimates based on larger sections (whole pages for example), so they sum it up at the bottom of the table.
The section above is the first part of creating an estimate. As we explained before, our UX team creates a clickable wireframe that through contracts becomes the project’s living specification. A PM should prepare this estimate table – list all feature, add columns for team members, set up formulas etc. The same team that hopefully attended these UX meetings will now go together through the wireframes and features in the table and give their minimum and maximum estimates.
Regarding PM and Quality Assurance (QA) hours, it’s difficult to give estimates based on features, so a number that seems to work very well for us is to calculate one third of working hours from the team member that has the highest TOTAL min and max estimates. In the example above, that would mean that for the first feature, our IONIC developer has 18-22h. One third of that would be 6-7h for PM and QA team roles (we always round to whole numbers).
After the min and max estimates are done by the team, it’s time to come up with a frame for the business proposal. The first thing to do is to calculate the total number of working hours per role and for the whole team:
These calculations are very simple, you just sum up the number of working hours by column for team roles, and then sum them up by min and max for the whole team. The next part is figuring out the timeframe:
- Divide the number of min and max working hours by 6.5h (which I consider to be an average effective working day for a team member) to get the number of working days
- Then divide the number of working days with an average number of working days in a month (about 22) to get the min and max number of months needed to finish the project
- Add a 20% buffer to the timeframe because you can’t always plan for the unexpected – team member illness, vacations, paid leave etc.
The last thing remaining is coming up with a budget. We always try to have one team dedicated to only one project until it’s completely done. That means that the client pays for the whole team per working day. That is why we take the total number of working hours, divide it with 7h to get a number of effective working days (1h of daily break) and multiply it with 8h and the hourly rate of let’s say €50 to get the estimated min and max budgets.
As you can see, the difference between min and max is quite big, and in the business proposal we usually give a range 20-30% larger than the min estimate and 20-30% smaller than the max estimate to make it more even. We also tend to round up the months in the timeframe if we end up with decimal numbers.
Fin
We always try to be as transparent as possible with our clients, so we always share this estimate table with them and include it in the business proposal. They can see how we came up with our estimated numbers and have a detailed breakdown feature by feature. You might have noticed that some of the rows are in orange color – they represent features that can be dropped out of the first MVP phase of the project. It’s also easier for the client to plan his budget and timeframe this way, and it’s not unusual for them to remove (or even add) a feature or two once they have the development plan laid out like this to better fit their budget and release schedule.
In some rare cases (for us at least), a client will take a full-time team for a long period without a predefined scope, and you would only need to do these estimate on a feature by feature basis. The timeframe will most likely be enough in that case, since the budget is based on the working hours of a full-time team on a monthly basis.
As promised at the beginning of this lengthy blog post, here’s the link to a view only estimate table (you can download it, or c/p it for yourself though).
I’m sure the format of this table can be much more aesthetically pleasing, but we use the business proposal for that. This is just a tool to come up with a decent estimate that won’t cause us issues later on in the project. Just to be clear, we did sometimes go over budget with these estimates but it was in a reasonable amount and it was much easier to discuss these extra costs with our clients. Afterall, they were involved in creating the prototypes and estimates and are fully aware of what goes into the development of their project feature by feature.
I hope some of you at least will find this blog post helpful, and I would love to hear your way of dealing with project estimates, and ideas to improve the process.
