Freelance Software Job in Malaysia: Specification Document

Once upon a time, there is a craze about software freelancing in Malaysia. Every Tom, Dick and Harry think it would be cool to finish college (or go just half way through), do software freelancing, earn tons of money and be our own boss. Anyway, a good programmer should be able to write about 99% of the software required by the business world out there. So, since we can deliver the service quite well, why work for others which do exactly the same.

After a few years venturing in this business, I slowly discovered the challenges of this business, and it might not seem promising as a long term career. When we are doing freelancing, we are actually running a business, and programming is just a fraction of our job scope. We have to do some PR and Marketing (word of mouth usually), find some work, collect business/system requirement (what need to be build), decide on the price and negotiate, develop, test, deploy and support. As you can see, the sales cycle is pretty long, and software development is a small fraction. So our skill as a good programmer only provides us 10-20% of advantage, and there is a lot more to pick up to be successful in this business.

Let looks further into the challenges of this business.

Specification Document
When you work in a big software/consulting house, you have corporate clients and nice thick system requirement documents are produced to cover your ass before you start programming. When you do freelancing, most of your clients is SMB/SME (small and medium-sized), and it seems almost impossible to create a complete specification before start of work.

When you meet up for system study or collect system specification, they usually tell you their requirement verbally, or if you are lucky, you have a few sheets of paper with some sketches and points. If you ask them to create the complete specification to cover every aspects of the system before you would start work, it would seems almost impossible for that to happen, and even when it does, the specification wouldn’t be very useful. Why?

• The customer have a rough idea on what they want, but they don’t know exactly what they want, and definitely don’t have the details for you (you have to help them make some decisions and suggestions)
• Somehow, full blown specification documentation is tiring and boring. Remember, this is not a large corporation, and people are not used to such procedure.
• Even if the guy is hardworking enough to create a full specification using his imagination and assumption, the specification wouldn’t be really accurate in reflecting the system actual needs and users’ expectation. At the initial stage, we can’t foresee a lot of things.
• Even if the full specification is created with good accuracy (does this ever happened?), it still will not cover you ass totally. A specification is still a specification, it can never be complete and it never will. The clients will eventually require something which might not be covered (or vaguely covered) by the specification, and he wouldn’t be very happy when you tell him you can’t do it because it is not covered in the specification (or you wanna increase the fees).

So, is a specification totally useless? Hmm, not really. We still need a basic specification (does not cover every imaginable aspects), as a point of reference on what actually need to be done and delivered. You can be sure they will ask for more, and lots of changes as well, so be prepared for it. Whenever they raise something which is not within the original specification, add it into the documentation. Whenever they request changes, add it into the documentation. Label what is covered originally, what is chargeable and what is free of charge. This document is important to give the client an overall pictures of what they had actually done and requested, and it kinda helps in price negotiation if the needs arise (it does cover your ass, just not entirely, and negotiation skills kicks in at this point).

Basically, no one is gonna read a 100 pages specification, but people will take notice of a 5 pages simple specification in point forms with drawings, well labeled and categorized using color for the changes and request along the way.

Why not to create a 100 pages specification?

• No one will read it once it crossed the 10 pages hurdle
  
• It takes a lot of time to write that, and you are not paid for it (and the customer aren't going to write that for you, or pay you to write it)
  
• Does it matter if a requirement in in a specification or not? If the customer wants something, it needs to get in there. If something is good for the system or uers, you should put it in nevertheless. So what does the specification governed?
• It is impossible to cover all grounds, and changes will happen, so just accomodate it along the way (you can't anticipate everything before it starts)

Again, specification for SMB is supposed to be simple and straight to the point. Record down:

• What need to be developed initially (original specification)
• What changes had been made along the way
• What additions had been made along the way
• List down components which are FOC, to show your goodwill effort
• List down components which require a lot of extra effort and chargeable, and justify (and the FOC section does helps)
  

I know, I know, a lot of the items listed above are covered in other type of documentation. So? You don't need more documentation to confuse and burden you and your customer. One document to rule them all. Remember: simplicity, readability, useful and most of all, show your values and helps you get what you want. Forget about the formal methods they taught you in school, those are just meant as guidelines and references.

So, how to fully cover my ass? I am afraid this is not possible. This is business, in fact business with SMB, and it is partially done on goodwill and trust basis. If you don’t trust them, or if they are very difficult to handle or being unreasonable, cut your losses and pull out, no matter how desperate you are (unless they are paying you BIG MONEY). Since the specification document can’t cover our ass, we need goodwill and certain level of trust and confidence. My mantra is if I satisfied their needs and do a reasonably good job, they will be more willing to pay my fees.

I am afraid specification document is just a small part of the initial stage. I’ll try to cover next areas such as

• Who you shouldn’t deal with
• How to decide on the price and negotiate
• Business Application Development
• Testing and Deployment
• Support is inevitable