One of the major headaches of any service business is to prepare accurate budget estimation. In the ever changing world of IT this is even harder. Because IT projects tend to carry out in an iterative approach (Prototyping methodologies) feature creep and later changes are routine things in a developer's life. But sometimes the pressure is too much for the developers to handle and the client's budget will end up going over the agreed amount. This might result in a dispute even. So, getting both parties to the same page is important when considering all of these factors at the early beginning of a project.
But how exactly do you plan to achieve the best of both worlds? Well as per my opinion be upfront and honest about it. If you have a fixed budget or a limited budget and then conveying it early to the web designer may save both of you a lot of time and effort than following a lost course. This might not apply to simple web sites but when it comes to dynamic CMS or ecommerce web sites where the features/requirements list is over the roof surely does come in to play. In some cases doing a requirement analysis report is a separate project.
In south Asian countries doing a preliminary requirement analysis is mostly free of charge because the competition demands it. So what if you do all your hard work to find out and outline the functions of a system and have it rejected due to budget constraints? All your time and effort is down the drain. So where possible follow these points which will surely make your life a lot easier.
1. Try to find out the budget in mind of the client or at least have an idea about how much he can spend
Sometimes asking them (i.e. Client/Prospect) directly works. Some people honestly say how much they can really invest in to a project. Based on that the developer can often tailor-made a solution that satisfy them both. This is the perfect scenario as far as I'm concerned. But some clients think about this a little bit and say something lower than they can actually spend hoping that they could land a deal that is greatly in their favor. At this point the developer must be cautious and really need to express the things he can do a project that is in that budget range. Don't worry about losing the client because even if you do get the project it will become a pain later on. So developer should quote well ahead of their comfort zone for a healthy deal.
2. Give/Ask them a budget range
As per the developer you can initiate the discussion by showing an example/similar web site that he did recently and saying that "This project's budget was around xxx -xxx amount, So is this what you really have in mind?". Then the client will get an idea about what he is talking about. Some people come up asking to projects like cloning Amazon etc. But what they don't understand is they only see what they want to see. Plus no one needs all the features that Amazon has to run an online store. I tried the above technique with several clients and most of the time we worked out a deal that is beneficial for both parties.
3. Try to break up project into coherent chunks
Some projects come with a unique but a frequent problem, Ambiguity. So if the requirements are not clear the best way to go is do it incrementally. Just break up the project in to manageable chunks and finish it step by step. This way each step has it's own budget, deliverables and more control over change requests.
4. Convert your effort in to money
Sometimes a developer who used to charge an hourly rate is requested to put up a fixed quote or vice versa. This is where it gets tricky. Normal way is if you are used to charge hourly is to use previous project knowledge. If you have this knowledge from a previous project then you know how much time you have to spend in creating the new one. So convert that time to money. For people who works for a fixed budget requested to put up an hourly rate then a good strategy is to use the following formula, Hourly rate = number of developers X ( (Developer Salary x 3 /160) )
Subscribe to:
Post Comments (Atom)
0 komentar:
Post a Comment