Your digital solutions partner
Your digital solutions partner
4/15/2008 Back
It is important to define what is the purpose of your project before you even start looking for a development company. Even if you are just looking for a simple website there is a purpose to it.
Answer some basic questions such as who is your audience, how will the program be used, is it going to save you time and money or generate revenue, how is it going to help your business, what is the financial threshold that will make it successful, what are the quantitative measures for success, benchmarks etc.
The answers to all these questions will not only help you define the scope of the project but will help your service provider to select the right approach, methodology and resources needed for the production of the program from the very beginning. It will also help your developer point you in the right direction technologically.
The more the clarity the lower the cost and the higher the quality. Take a piece of paper and write all these answers down. You will be surprised how many questions you have not answered yet.
This is actually one of the most difficult tasks. Unfortunately most of the developers out there think that they can produce quality but only 20% actually can. Very few companies will admin that they are not so good in certain areas and will hope to hire good developers if needed which in turn is even more difficult.
When shopping around for a development provider look for a company that has expertise and experience in the same type of work. You should not expect to see exactly the same program previously completed by your development company but you should see similar programs and interfaces or at least programs at the same level of complexity.
When selecting a service provider also look for honesty, integrity and understanding. A good service provider will ask the right questions, understand your business model well enough to produce for you, will not agree to everything you ask, will make suggestions and become part of your team. A good company will admit their weaknesses and propose a way to resolve them
It is OK that in a presentation setting the development company will try to look good. It is a normal sales practice and etiquette. Beware of companies that avoid the difficult questions by saying that this is not a problem and they will figure it out or companies that make big promises. They will not figure out anything and will not deliver simply because they do not know who to outsource the work to just yet. Things like these only show lack of experience and professionalism and create a risk for you.
You should feel comfortable with the company in a technical and business discussion and feel that there is enough experience and knowledge to handle the proposed project. Prior experience, knowledge and expertise in the same area and level of complexity result into lower cost and better quality.
You have done anywhere from none to a few development projects all in the same setting. Your service provider does this everyday for many clients in different settings. When expressing a concern regarding something in your project it originates mostly from experience and relevant knowledge. It is ultimately your decision but always consider the advice of your software provider.
Beware if your development company agrees with everything you want.
You should also expect your development company to address concerns. Such understanding will help you and the developers to make intelligent decisions. This results in better product quality and lower cost on the long run.
Disclose all relevant information even if you do not see it’s importance. Many details can cause a drastic change of development methodology. It is very important especially in cases when legacy systems are involved. Even a small detail can cause change of database structure and if this happens in a later stage of the project the result is either more development time and higher cost or lower product quality when the developers try to patch the program.
It is a big mistake to hide information to get a lower estimate and later try to sneak in additional specs. In these cases either you will have to go over budget or developers will have to absorb the cost. In the best scenario case this will push the deadline forward and reduce the time truly needed to address the issue. Either case is a sure step towards failure or will cost you more later.
Always be reasonable when negotiating prices. Do not forget that whatever you are asking for takes time to produce. If you push the price down too much you are basically asking for a donation or a free gift.
Development companies build their estimates based on the time it takes to produce, their rates and in consideration with the competition. It is true that sometimes amateur developers try to quote the rates of experienced software engineers. You will see through that when you look at their samples of work and you will see if they are honest when talking to them.
Assuming that you are working with the right company, the correct way to reduce the price is to choose a different option or reduce the scope by breaking the project into phases. An honest development company will present options to you and explain the pros and cons of each. You can make intelligent business decision based on that. Not forcing the developers to absorb cost will result in better product quality and lower cost on the long run. Most development companies appreciate this and will give you extra product value.
Request that the project is broken into phases representing logical elements and ask for a review after each phase. Most development companies propose two revisions. You should ask for more but be reasonable. The number of your revisions is higher because the number of phases is higher. In other words you do not want more revisions per phase. You need less revisions per phase but more phases.
Development companies ask for less revisions because each revision means extra work not included in the estimate. This is a valid concern in cases when clients make drastic changes after product is almost complete.
It is a common mistake on behalf of the development company to ask for less revisions due to fear of scope change and going over budget. When you agree to more phases and a revision of each one both you and your development company are on track from the early stages of the project. You will understand the project better and the developers will avoid future drastic changes. This will warrant that both you and the developers are moving according to specs and you are getting what you are paying for.
Scope creeping is a term used in a situation when the project scope changes during the development cycle of the project. Nothing hurts both parties more than the scope change. A scope change results in prior work becoming useless, project is never completed and is never done according to specs.
Changing the scope is basically an introduction of a new project within improper budget and scope. It is a scope of work that no one planned and budgeted for. Imagine building a house and after putting the walls deciding to make it a stadium or vice versa. Scope creeping results in wasted time and budgets, lower quality and unknown completion dates.
That is why it is very important do define the objective clearly from the very beginning and stick to them.
Always require a technical specs document describing what will be done and how it will work. Do not force the developers to make assumptions. They are in most cases wrong. Developers know how to develop but they do not know your business in and out the way you do.
You should revise the technical specs document and discuss it with your development company. Developers have no problem changing a specs document. They have a problem changing the specs after the work is done.
Most serious development companies want to build successful projects and have happy clients. Take advantage of this the right way. Communicate and come to agreements before the work is done. This will insure that you will get the dedication and your project will be done the way you want it and within budget.
When changing small things be fair and relay this to your developer. If you address these edits as bugs you are basically saying that the developers did not do their job. Developers know what was scoped and work according to technical specifications. They know that you are not being fair.
Negative feedback frustrates developers and causes them to lose interest in the project. The more dedicated the developers the more you will frustrate them. Be fair and address these edits as edits and not as bugs. After all the developers are part of your team and there is no reason to lose your teammates over ego reasons.
It is very easy to explain the changes and provide reasoning related to the technical aspect of the matter. This will guarantee that developers will understand your expectations better. This will help you get better product for your budget done on time.
The more your developers know about your idea and business model the better work they will be able to do. The more you know about the technology aspect of your project the better feedback you will be able to provide. This two-way communication not only helps development move faster but also eliminates many setbacks. This is very helpful for each party and translates directly into lower cost and higher quality.
When providing feedback while reviewing the program be specific. Comments like “this is not user friendly”, “this does not work right” or “I don’t like this” carry no information to the developers. They need to know what exactly the problem is so they can fix it. The same applies to changes and edits, upgrades etc. Do not let the developers make assumptions. In most cases they will go the wrong way unless you have worked with the company for a long time and they know your expectations and business model very well.
Buying cheap is a way to waste money. Super cheap rates mean lower quality and slower delivery. The only goal you will reach when buying cheap is keeping the budget low but nothing else. It is normal for your provider to give you discounts in a longer relationship situation. Or your development company may have smaller overhead and pass the saving to you. Take advantage of that but do not get lured by cheap rates. There is always a reason for them. You cannot cheat the laws of economics. You will get what you pay for – like in anything else. Make sure your provider understands the level of complexity required. This will save you time and money.
You can overpay even when paying low rates. When a project is getting out of budget pause and analyze. Talk to your software provider. A good company will explain why it is getting expensive and what can be done about it. In most cases projects go out of budget when the client tried to save money upfront or the developers did not understand the project or proposed low cost just to get the business. When you start overpaying most likely there is problem of a non-financial nature. Stop and solve it. This will put everyone back on track and get you closer to a good product within budget.
Try to accept advice and technical guidance. It is provided to you for free in most cases and is meant to help you in an area that you need help. Do not discard everything that contradicts your ideas but rather think about it. Majority of web designs and websites are nice until the clients touch them. You asked for a nice product and you got it. Keep it that way.
A good relationship helps a lot in the development process. It makes problems being solved easily and quickly, gets you more attention and dedication which is a free bonus for you. Take advantage, it does not cost anything.
by: Ben on 10/22/2016 10:58:05 AM
dsdsd sd sd sds sd sd sdsd sd
AT Integrated Inc. | 913 Ridgebrook Rd Suite 109, Sparks, MD 21152 | T: 410-472-2490
Copyright © 2024 AT Integrated Inc. All rights reserved.
by: John Doe on 10/22/2016 10:12:09 AM
Testing 1