Peter Skouhus

This blog is about software and IT outsourcing. By reading this blog you will get some ideas of things you need to be aware of as well as some input on whether or not to get a fixed price versusworking on an hourly rate. You are the jobs, do whatever works for you.

The project participants
Everything being equal a project usually have the following project participants

• The product owner (this is the person or company for whom the product is developed)
• The team (this is the person or team/company making the product)

The challenges is to get these two parties to work together harmoniously and efficient. Some IT companies use a system called scrum to achieve this. (read more about the scrum agile development system on Wikipedia) I will not get into a details about scrum that is beyond the scope of this blog, but basically you have the product owners, and you have the team. The product owner represent the customer — the person or company buying the product — and the team are the developers making the product. In addition you have a so-called scrum master whose primar job is to ensure that the product owner and the team works well together. The scrum master is the diplomat in a project. Each project is divided into several phases which in the scrum terminology are called sprints, and both the product owner and the team decides which tasks should be put into a sprint. (This is where the scrum master comes in as the diplomat having the two parties planning the sprint) If you want to know more then read about scrum on Wikipedia, see the link above.

Understanding requirements
Before the project starts it’s very important that the product owner knows what he wants. If the product owner is not sure of what he wants, then the team cannot develop the product. This is where many projects fail right on the beginning, because the product owner has a good idea but when push comes show he/she does not really know what they want. I have seen this countless times.

To know exactly what needs to be developed a so-called demand specification must be created. The demand specifications is a paper, word file, PDF or what ever works for you which demystifies everything about the application, in other words it’s an outline written in the layman’s terms about your project. The demand specifications can aside from the text also include images, suggestive graphical layout etc.
Do yourself a huge favor by writing the demand specifications in English as opposed to writing in your native language (assuming that English is not your native language of course). By having the demand specifications in English you open up and invited a huge amount of potential suppliers, and that is definitely to you advantage.

There are two ways to write the demand specifications, one way is to have a team within your company writing it, another way is to do it together with a consultant. At 1902 Software Development Corporation we often write the demand specifications together with the customer. The advantage is that we can advise the customer what is possible and what is not. Furthermore we can suggest the customer alternative ways of doing things and come up with new ideas and suggestions.

Do whatever works for you, but do not expect a serious IT company to give you a price based on a 15 minute conversation over the phone unless you requirements are a standard website with a contact form!

Development Specifications
The development specifications is likewise a document. The difference between the demand specifications and development specification is that the latter is somewhat more technical in nature. It is designed to be used by the software developers to develop your application/portal. Development specifications usually include things like:

• A functional description
• Graphical layout (not 100% finished, but detailed enough so that all parties know exactly what the application should look like)
• Application flow diagram (this can be a simple flowchart or a more detail UML diagram, this depends on the project)
• A functional class description (this is technical, but sometimes developers needs a very detailed outline of the application, this is especially true for very large or very complex applications)

As a general rule the development specifications are always written by the company making the application. Some companies makes very detailed development specifications other do not. I am not going to pass a judgment on this because there are some very clear advantages and disadvantages for either. The right thing to do often depends on the application and the circumstances.

Pricing the application
Pricing a software application or Web portal can be very difficult because many times there are many unknowns which needs to be taken into consideration. As a general rule there are two ways you can pay for your application

• By paying a fixed price
• By paying an hourly rate

Just before you think you only want to accept an hourly rate, consider the following:

1. When you make software there is an inherent risk of running into problems and complications due to no fault of the software developer but which prolongs the development time, and thereby make the application more expensive to develop.
2. Regardless how you look at things there is only one person to pay for that risk, and that is the customer. I know I’m very direct here and some of you may not like this at all or be turned of by my frankness but think about it for a moment and I’m sure you understand.
3. Any IT company will therefore include a margin on top of the calculated price to cover for the unknown. The margin is higher than in many business and often depends on many things … one of which is how badly does the IT company needed the job. I don’t think I need further explanation here.

The conclusion
Be very careful before you accept the cheapest offer. Many times the cheapest offer ends up becoming the most expensive in the end. What are you going to do if your developer tells you, I need to charge a higher price, I’m not finished and I have no more money after you have paid a 50% down payment?

Sometimes it’s better negotiating a reasonable hourly rate with you IT supplier then work by the hour as opposed to the fixed price. Some of the advantages by having an hourly rate are:

• Much greater freedom because you can make changes as you go along (I am not suggesting changes are good, because they are not and should be kept the absolute minimum regardless if you do work on an hourly rate of fixed price)
• The project is likely to end up being less expensive because you don’t have to pay for the “security margin” the IT company ads on top of a fixed price to cover unforeseen problems as explained above.
• Both you and the IT supplier save time. Neither of you have to spend time negotiating, looking up old e-mails etc. when something new has to be added.
• Less stress because you do not go around thinking whether a particular feature is included or not (and believe me a big project you have enough to worry about towards the end!)

But: If you work on an hourly rate you must be 150% sure that you can trust your supplier. One great way to test if the hours reported by the supplier are truthful is to analyze the timesheets. If all the timesheets reported by the supplier are in 15 minutes 30 minutes or 60 minute blocks, then Houston we have a problem. No company, I don’t care where in the world they are works that way. Another way is to look at when the work was done, if the work was done every day from say 8:00 — 10:00 then again from 10:15 — 12:00 and so on, then you may also have a problem again no company works that way.

Keep an eye out for these small details, they reveal a lot more than may meets the eye at first glance. Needless to say if the supplier cannot give you this then we have a problem, and you should consider choosing another supplier. Any IT company working on an hourly rate must be able to provide you with exact time tracking. (By time tracking, I mean time tracking and not time entry, these are two completely different things!!!)

A reasonable time sheets should look something like this:

08:12 – 9:48 Development module XYZ
10:11 – 12:34 Development module XYZ
13: 02 – 13:19 Scrum meeting (or any other meeting)
13:27 – 16:30 Development module ABC
17:02 – 18:56 Development module XYZ

If you look at the above time sheets you will see that it looks reasonable. It probably looks like something your own company could produce. The coast at the numbers and you will see that the person took breaks, did not exactly start at eight o’clock and did not jump from one task to another or the time.

Reporting
Again, if your supplier works on an hourly rate, you can, and should demand reports for everything which have been done. In other words the supplier must have a system in place allowing his or her developers to file reports so that you know how your money were spent. The reports should of course not be a book, it should be a short preferably a bullet point list outlining what was done on a particular day.

Get your reports/timesheets weekly of biweekly
Always remember to get timesheets and reports weekly or biweekly, and do spent 15 minutes going through them. Do yourself that favor so that you know what’s going on. It’s so easy to forget/ignore reading the reports, then five months all of a sudden wake up wondering how all the time and money was spent. By then it can be too late.

This blog was written by Peter Skouhus. Peter Skouhus is president of 1902 Software Development Corporation, an IT outsourcing company based in Manila, the Philippines.

You can read more about 1902 at http://www.1902software.com in English.

You can read more about 1902 at http://www.1902software.dk in Danish.