Risk Free or More Risk?
When it comes to select software providers, many people would be naturally hooked by a seemingly attractive sales pitch such as
“We will complete your project on time, on budget and on scope. If not, we will give you 100% money back.”
I know what you might be thinking now. There is nothing wrong with the statement itself. After all, if someone can promise you to build an software/app for you with everything(scope, time and budget) fixed upfront and also attaches a strong guarantee to it, you will probably feel you are better protected and seem don’t have anything to lose, right?
Well, the above statement might seem to be true in many other traditional industries (e.g. building&construction), when it comes to building software, I strongly suggest you to give it a second thought.
Here’s the reason why I don’t think fixing budget, scope and time will ever work in IT industry and it never did.
There is no such a way for developers to be 100% accurately estimate and map out all the required technical/business details and thus time to be spent on to build a software upfront. Sure, there are industry standard and process to follow to make sure estimation come as accurate as possible. But as we all know, the devil is always in the details.
To name a few:
- Developer not completely understand client’s business requirement
– It’s not uncommon developers might not have the same level of understanding of business requirements as their clients do. Furthermore, there are many times even clients themselves don’t have a very clear picture of what they are going to building.
- Unexpected technical complexity
– When dealing with technology , there will always be some challenges which often are not well anticipated. (either overestimate or underestimate).
- System integration
– System integration has always been a risky part of a project due to its complexity and compatibility.
- External policy change
– Sometimes, external policy change might also creates a huge challenge for the development. (E.g. Facebook might change their user policy at any time and your development have to cope with their change).
I hope you can start to see there are a bunch of inherent risks associated with each IT project and practically it’s not possible to eliminate all of them before the project actually kicks off. Therefore, if somebody tells you that he can build an software for you on time, on budget and on scope, what he is really saying is :
- He understands exactly what application looks like and how it is going to operate
- He has anticipated all the technical challenges he might be facing
- He understands all the details of how current current system is working and how application is going to integrate with current system
- He has predicted Facebook will not update their policy in the next 2 month and won’t effect his project on hand if they do
- Blalalala – anyway, this dude seems to have a magic crystal ball.
Have you seen the big picture? Contrary to your common belief, what it supposes to be a risk reduction for you (by taking a fixed contract) will put your project at a even greater risk. In fact, you are risking the most important aspect for your project – Quality. Thus, instead of trying to avoid all the risk upfront (which we can’t), a better approach is to acknowledge those inherent risks and create a better process around to better adapt and manage them.
At b2cloud, we believe building a software application is an evolving process and along the line there will always be changes, unforeseen problems, technical obstacles and external policy changes etc. So, instead of telling our clients everything will work like a charm and once we build it will come sort of thing, we acknowledge those inherent risks upfront and help our clients to set up a right strategy to adapt to those risks. We use a little tool called “Lever” to achieve this.
Above image is the illustration of the lever for a sample project. On a lever, each row represents a critical component of a project. (Namely Scope, Time, Budget and Polish). Each column represents how flexible the corresponding component can be in the project. Only one entry is allowed for each column. The beauty of setting up a lever is, a client now understands he/she can’t change a project’s budget, schedule, scope or polish without affecting at least one of the other three parts. Therefore, it prepares him/her to better cope with changes and challenges of a project from Day 1 so that there will be no surprise towards the end of the project for both parties.
Take the above project as an example,
- Budget- Most fixed: It tells us and the client no matter what happens, he/she won’t be able to increase any budget.
- Scope- semi fixed: Since budget cannot change, so towards the end of the project, the client is willing to take out features which have lower priority from the app.
- Time – semi flexible: Since budget and scope is the most fixed items among the 4, time need to be a little flexible.
- Polish – Most flexible: The client is happy to take the polish (little bling) out of the app in order to meet the fixed budget.
Well, hopefully this post can steer you into the right mindset of developing a software application. Next time, if someone makes a pitches on you and says “we can do this on time, on budget and on scope” just take this example of lever with you and present to him/her, I’m sure they’ll be deadly impressed by you.
If you are interested in exploring more about agile process, here is a good post written by Martin from Apteko Applying Scrum to Legacy Systems