The most common question I get asked by prospective new clients is ‘How much willMyBigProject cost?’ This is no surprise, as custom software development projects require a reasonable investment and you want to know what the AsLittleAsPossible cost will be so you can justify your business case and return on investment.
References to lengths of twine aside, ‘How much will MyBigProject cost?’ is by far the hardest question to answer. For the most part, because there are multiple ways to implement any solution, and I don’t know what’s important to you. So I ask you a bunch of questions, like whether you value time to market over feature completeness, do you have a specific budget in mind or do you need to scale / support high availability? (This is the modern day equivalent to asking if you want it fast, cheap or reliable, pick 2). What it comes down to is a 30 minute conversation and then I’m going to make an educated guess.
The formulae for my educated guess is pretty simple: scale the size of the team to match the scope of MyBigProject and multiply the result by the number of person weeks I think it will take to achieve. Which I’m hoping you will agree with me in a few moments is a thoroughly stupid way of estimating AsLittleAsPossible.
What’s wrong with this approach is that it is so laden with assumptions that there is no way it could possibly result in value for money.
At one end of the assumption scale is where we assume that only exactly what you asked for is required to be estimated. Most people have little experience with commissioning custom software projects, and it’s unfortunate that this is often taken advantage of by what is commonly known as the race to the bottom. The theory goes, that by only estimating *exactly* what has been asked for, the work can be won ‘cheaply’, and everything else can be charged as a variation. Imagine building a house and on moving in day you discover it has no internal doors, no plumbing, no floor coverings, and while you specified a loft, you didn’t specify that you wanted a staircase to connect the upstairs with the down. Sound far-fetched? The media is ripe with IT projects that are over budget by orders of magnitude because of ‘race to the bottom’ tendering.
At the other end of the assumption scale is where we over anticipate everything you haven’t specified, and allow provision for it. To my detriment, this is the side of the scale that I tend to lean towards as I hate having to go back and ask for more money. If I give you a price of AsLittleAsPossible, I feel you should have the expectation thatAsLittleAsPossible will be all that is required to complete MyBigProject, and because I’m reasonably conservative, and as a company we value engineering awesomeness, we have on occasion over-provisioned and come in well under-budget.
Which brings me back to why asking ‘how much will it cost’ isn’t in your best interest, and a stupid way for me to estimate MyBigProject. You can get hit with never ending variations, or overspend more than was necessary to actually realise MyBigProject.Both approaches leave you spending more than you had too, and that sucks.
Asking me (or any vendor) ‘how would you achieve project MyBigProject for AsLittleAsPossible’ allows you to measure the value you will get in return for a set amount that you specify. Not only does this make comparing across vendors easier (interestingly it also allows you to measure expected effort, which is a great indicator of the calibre of your vendor), but it allows you to adjust AsLittleAsPossible up or down to understand the trade-offs, or extras involved.
Start with an amount that you would like to spend, I recommend 10% to 20% less than your break-even point. I like to do this with car shopping. What can I buy for $20,000 right now? Well, I could get a 15 year old supercharged Mercedes, or a 3 year old Mazda Rx8. Both meet my criteria for a sports coupe, one I can service myself, and the other is far newer and has more recent technology. From here, I can evaluate the pros and cons of each vehicle, specific to my needs. I can assess the market, adjusting for where I see value and like Goldilocks find what is just right.
By working collaboratively in this manner, we start to break down our assumptions, uncover what we don’t know and shape the approach around the areas that you see as having the most value. My favourite example of this is an eCommerce solution I architected where the majority of the budget was spent designing a beautiful, intuited shopping experience – while the back end administration was implemented in Microsoft Access. For the client, it was far more cost effective to train 5 people to use Access and far more valuable to provide a market leading online retail experience for her customers than it was to follow conventional wisdom and implement a homogenous solution.
What I really love about this approach is that it challenges us to think creatively to come up with the best solution for you, based on your priorities. We let you know what features can be implemented, and how they will be implemented for AsLittleAsPossible. If that’s not enough to meet your minimum viable product, adjust AsLittleAsPossible to include the bits you want (you kept back that 10% to 20% right?), or if it’s getting a little too fancy, scale AsLittleAsPossible back. You’re now in the driver’s seat, and able to evaluate the merits of a solution against exactly what you wanted to spend in the first place, no sticker shock or awkward negation required.
So for MyBigProject, try starting with AsLittleAsPossible and challenge your provider to design a solution to fit your budget.