By Mikhail Zavileysky
Overall Project Cost = Price per Hour x Hours for the Project
The first thing you should remember is that the cost of a project is comprised of two components – price per hour and the number of hours required for the project. This principle may seem obvious, but it is too often forgotten. It’s common practice to first choose vendors with the lowest price and only then ask how many hours will be needed for completion of a particular project. With this strategy, you may miss vendors who might charge more, yet who work faster and more efficiently, thus reducing the total cost of the project..
Project Budget
It is a good idea to decide right away how much you are ready to spend on a project. Our practice shows that you can find a better vendor and significantly reduce risks by disclosing the allotted budget to the vendor. This information allows the vendor to better estimate the project and determine what can/can’t be done for the specified sum of money.
If both the goal and the price are known, the project can be implemented more efficiently with reduced risks and higher ROI.
Simplicity – Nothing Redundant
You should ask you potential vendor for their vision of the basic structure of your system. If the vendor proposes something very sophisticated, make sure it is absolutely necessary. Some vendors tend to complicate the system trying to foresee possible additions and improvements later on, new versions etc. With this approach, you are actually forced to pay for something you may never need. This also greatly increases the risks, as the system become more complex, which might lead to additional difficulties. We do our best to fulfill your exact requirements most efficiently, which results in creation of more stable and reliable systems.
Using Home Developed Tools and Components
Some vendors may offer faster project implementation than others. One of the reasons can be the existence of their own custom made tools, libraries, products, which may facilitate the creation of your system. The time and money savings advantage is evident. However, there is one serious hidden drawback in this practice and it lies in the system maintenance. You may experience serious problems when you hire another vendor to improve and support the system built by the previous vendor. For the new team, it is inevitably difficult to understand the structure of the system if it was developed with the use of non-standard means. Maintenance becomes much more troublesome and expensive. However, this practice can be used successfully in a few cases.
First, it can be safely used if there is a good long-term relationship with your vendor and you are sure he will continue to maintain your system after initial deployment. Second, all the tools and components were created according to common standards. In this case the use of the existing code can be very effective. DataArt uses only standard products and development tools and has a vast collection of reusable code that conforms to the common coding style and can be used to facilitate future development. This makes the system easily maintainable by any developer.
Documentation and Coding Style
In the majority of cases, the systems will inevitably require additional support, tuning or improvements and documentation plays a very important role. Very often, the software requirements are outlined at the early stages of the project. Yet the system inevitably changes in the course of the development, and not everything goes according to the original plan. The documents, however, remain the same, which results in the inconsistency between the system and its documentation at the completion of the project. This leads to many additional problems, especially in the system maintenance or improvement as nobody can determine if the system is flawed or the documentation is wrong.
DataArt always provides the systems it developed with up-to-date documentation, which reflects the system’s contents. What’s more, we use a standard clear and easily understandable coding style, which includes extensive comments allowing for better understanding of how the system works even if the documentation is lacking for some reason.
Why Faster is Usually Better than Cheaper
There are several reasons for choosing a slightly more expensive, yet faster vendor, over a slower and cheaper one. First, you save time by choosing the faster vendor. Second, a change of a vendor’s team working for you is less probable if it works a shorter period of time. This means lower risks and less time spent on communication and control. Last but not least, companies that charge more are willing to share the risks, while cheaper and smaller ones rarely take any kind of risk at all.
Knowledge Transfer
Apart from the actual development much time is taken by the knowledge transfer. This procedure is of utmost importance, as its efficiency and success influence all other processes. With better knowledge transfer, there is better overall development. Proper understanding of a client’s requirements will help a vendor to avoid many mistakes and perform the development much faster.
The knowledge transfer mostly depends on a project coordinator on the vendor’s side, which makes his role utterly important. One very simple but essential idea is to have the same person coordinating the project from start to completion. This helps the vendor to get a better vision of the client’s project, without loosing any details, however minor they might be. The latter happens quite often when a new project coordinator is assigned in the middle of the project. This is especially important for information not mentioned in the specifications or other documents. The client is often falsely safe in knowing that all the necessary information was conveyed to the vendor, while one of the vendor’s coordinators failed to properly convey a piece of essential information to another. This can have serious implications on the client/vendor communication and cause problems, as issues obvious for the client may be quite surprising to the vendor, especially if some information was lost. DataArt is well aware of this possibility and we change the coordinator only when it is absolutely necessary and useful for the client’s project. This saves a lot of time, efforts, and significantly reduces the risks.
Project Tracking and Review
Another important item for consideration is project tracking. It’s essential that a client can observe the flow of the project development and have the latest information at hand. A client must be able to reach a vendor at any time. All of DataArt staff is available by E-Mail, phone, ICQ, MSN, Skype – which creates the effect of a continuous presence, a comfortable white noise. With DataArt, clients are never alone with their technical and organizational problems.
Team
You should ask your potential vendor about a team they plan to provide for a project. Our practice shows that the most efficient teams consist of five to 10 people (depending on the size of the project). If the project is truly grand, there should be several teams five to 10 people. Using a greater number seriously reduces the speed and quality of the teamwork.
We also suggest having a core team employed in the project full time. This saves a significant amount of time spent on knowledge transfer and raises the involvement of team members in the project. At DataArt, core teams are a common practice. Since our team members can perform a variety of tasks (i.e. developers can be easily employed as testers) no time is ever wasted on idle tasks.
About the Author: Mikhail Zavileysky has been Chief Operations Officer of DataArt’s St. Petersburg’s office since the company’s inception in 1997. Under his direction, DataArt acquired its driving force – an outstanding team of managers and software developers. Visit http://www.dataart.com
Source: www.isnare.com
No related posts.
Comments on this entry are closed.