What I learned, and re-learned all over again in Custom Software development

Custom Software Development (CSD) - This blog entry should have been in my other blog. But this entry is more towards business and life rather than Information Technology/Software. We all live in the world full of people. Software development should be people-ware development more than computer-related development.

Custom Software development is not just writing software for specific person, company. It is writing software to work with people. A person is nice, polite, easy to work with. Even though people is a group of persons. People turn themselves into demanding, inflexible, and at times rude. If Custom Software Development is a good business, Microsoft + Apple + HP + IBM should have been in this business. But they don't.

Why CSD is not a good business? What have I learned? While a person is nice and easy to work with. Once they become a group of "people". There are things such as politics in workplace, personal boundaries, job securities, lack of project management skill, making ultimatum, etc. All these problems will come into a CSD-type project.

The problems that I learned:

1. Politics in workplace:
Programmers need to capture all activities (input/output) for any given process. The best case is that programmers only deal with one person. In reality, there could be a number of people who programmers have to talk to. In addition, these people may understand the process differently making it difficult to capture the right information the first 5 times. After the 10th time, the people start to feel annoyed. Programmers start to feel confused, frustrated, and ready to give up.

2. +3. personal boundaries and job securities
Sometimes a new software module may make few positions or worse a department obsolete. These people will try their best to undermine a project. They do not know their management's plan whether or not they will be fired. Since their job will be automated. The obsolete people can learn new skills, work in a new department, rather than spending their days in a job that could be replaced by computers. Most people don't think of it this way. What if everyone thinks how nice it would be that they now have more time to serve, more time to improve the work, and more time to spend with their families.

4. lack of project management skill
This is the hardest problem. In the beginning of a software development project, lead programmer needs to train all the end-users how to manage a project. People with no project management skill will not set their priorities on project schedule nor programmers' budget. They could demand a new feature at the end of the project and extend Phase 1 project into Phase 1+2+3+. So it's better to start early to educate what's in this phase and what's not.

5. making ultimatum
This is the last of this series, this is when user gives ultimatum. Things like 'if you don't do this, i will not do that'. This is natural following from #4. So preventing this to happen at any cost.

To avoid the top 5 problems, programmers need to set the expectation in the contract. If user requirement phase is completed, any change to user requirement document (URD) is considered a change request. Any change request will come with a price (payable by customer or not depends on negotiation). So end users can change 10 times a week and double the project duration. But they need to pay for extended time that they keep programmers working. I was in awed while watching Accenture took on AIS. Accenture is doing this very well. I keep their methodologies close to heart.

What have I re-learned? I learned the first 5 problems years ago. I thought I knew it all..

The new lessons:

1. Business is business -
#1 If a customer does not pay any invoice, you most likely will roll out the team and wait until they pay before you continue.
#2 If a friend does not pay and tells you that he/she will pay, so you most likely keep your team there until the project is completed. Then he/she doesn't pay. You lose a lot of money rather than #1. And yes, you lose a friend.

2. Doing work with no contract - continue from above
If there are no contracts, it means the customer does not have to pay you. Doing a project with no contract is like driving a car blindfolded. You will definitely lose. No friendship is worth more than a contract. Sign a contract with anybody before you work with them.

3. Check your milestone diligently and specify it in the contract
Even though you have a contract, putting a loose milestone in the contract will not help. Milestone such as the following is still not good:
30% of the amount after contract signing
40% of the amount after phase 1 completion
15% of the amount after project closure
15% of the amount 30 days after project closure

It should be:

40% of the amount after phase 1 completion -
1. 2 document deliverables for phase 1 are signed off (user has 3 days to review documents, if no response by e-mail within 3 days, documents are considered accepted and signed-off, and only 2 revisions are allowed)
1.1 user requirement document
1.2 business process analysis document
2. payment will be made 7 days after all deliverables are signed off
...

If the customer doesn't pay, you only lose 7 days of work. Normally the first 30% should carry your team throught the first payment milestone. So losing 7 days of work is not going to kill your business. Move on.

4. Prevent yourself from not paying the last payment.
This depends on what type of projects you're in. Do your best to make sure that you have delivered all promised work and product. Then trust in your good service team that customer will want to keep you around to help them along the way. So they pay you on time.

Good luck!