Last year I had a few rooms in my house repainted. In order to determine which company I would use for the work, I invited them to the house to quote the work. I showed them the rooms, told them the type of paint and color I wanted, and told them when I wanted the work done by.
Each company was able to calculate the amount of paint they needed, the cost of the paint and how many people would need to work on the project in order to have it done by my deadline. Having painted a multitude of rooms before my request, they were able to imagine potential obstacles before they happened and be fairly sure that they were not missing anything in their quote.
The resulting quotes were very precise and given to me with a high degree of confidence.
Quoting a job for a new custom application is a lot like that, except that we can’t see the rooms ahead of time. In fact, we can’t see the rooms, because first we have to build them. The rooms that we see in our mind’s eye are often very different from what our client sees in their imagination.
Let’s ponder a request to build a rabbit hole. The rabbit hole needs to be 8 inches in diameter, be set in a yard full of lush, green grass, preferably under an apple tree and near a babbling brook. Beyond the tree should be a field of ripened, winter wheat; golden and dancing in the breeze.
Seems easy enough, except that getting the blossoms correct on the apple tree may take some doing. But, all in all, everything is out in the open.
That is, of course, until we build that rabbit hole and take a trip inside. Suddenly, there is a rabbit late for an important date; a grinning, invisible Cheshire cat; a hookah-smoking caterpillar, a mad hatter and an irate Queen of Hearts. And let’s not even get into the pills and potions that can change the user’s size and shape at will!
The client is completely nonplussed by our discovery. Of course the rabbit hole contained an entirely new world full of anthropomorphic creatures and nonsensical laws of physics! What other types of rabbit holes could there be?
Sounds a bit far fetched, doesn’t it? And yet, similar scenes happen in the software development world all of the time.
A problem is presented by a client in a short paragraph of needs and requirements.
A software engineer conjures up thoughts of similar software that have been built in the past as a basis for their quote.
A quote is given based on myriad undocumented assumptions and risks.
Three months later, the proud software engineer presents their creation to the client and is flummoxed as to why the client is so flabbergasted at the result!
It doesn’t have to be that way, and at MINDSCAPE, we do our best to eliminate as many doubts as we can before we begin coding.
The MINDSCAPE Process
1) Our sales team meets with a client to determine what needs to be built.
2) Our quoting committee meets to understand the client’s needs. If it’s a simple project for a client that we’ve worked with in the past, we may be comfortable enough to give a fixed price cost right then. Most times, however, we need more information before we can give a granular cost. Instead, we’ll give a large range of costs based on what we know of the project, but more importantly, based on what we think may be hiding down that rabbit hole. We’ve been down there a few times and know what sort of exotic features are lurking.
3) If the client finds that part of the range will fit their budget, we engage them for a one day, on-site (if possible) requirements gathering session. Two of our team members will sit down for an in-depth discussion about what the system needs to do, why it needs to do it and what benefits are expected.
The result of this meeting is a much better understanding of the system and leads to two courses of action.
A) If the project is manageable enough, we’ll have been able to document the vast majority of functionality and even have some rough outlines for what the different screens will need to do. This will give us enough confidence to bring back a fixed cost estimate for development.
B) If the project is very large, we’ll have a better understanding of the scope of the project, as well as potential risks. The next action is to engage in a Technical Design Document phase. Based on the on-site discussion, we’ll be able to give a better budget range and a cost for the Technical Design Document. If the more-defined scope is agreeable to the client, we’ll start on the Technical Design Document.
4) The Technical Design Document deserves its own post later on, but for now it’s enough to know that our engineers will grab their spelunking gear and head down into that rabbit hole. They will survey the landscape and draw out what it is they see. The client will give feedback during this phase to make sure that we are seeing the same thing in that rabbit hole that they are seeing.
5) Once the Technical Design Document is done, we present it to the client along with a final, fixed cost price for the development. The client can then work with us to complete the development or take our Technical Design Document to another firm for quoting. Either way, we’ve done the hard work to determine what’s down the rabbit hole; for our own sake, but also for our client’s sake and the sake of any developer that may work on the project in the future.
Even with all of this due diligence, it takes constant communication and interaction with the client to make sure the project is on course. The final scope of the project can change due to many issues (who can foresee a croquet game with flamingos as mallets and hedgehogs as balls?), but we do our best at MINDSCAPE to keep ahead of the game.
If you have an idea or need for a custom application, let us know.
(And if you have not had the pleasure of reading Lewis Carroll’s Alice in Wonderland, you should at least browse the Wikipedia article so that this blog post doesn’t seem completely off the wall.)
Aaron Brander is the VP of Technology for MINDSCAPE at Hanon McKendry.
