Silver platter and the doom of custom made software

Silver plattering is a made up verb that refers to giving to the customer more that what is in the scope of the agreement. Basically, you give them your work for free while smiling, you give them what they want in a silver platter.

As any good negotiator might tell you, it can be a good deal if by giving a little you get something else, but it can be the doom of a project if the silver platter starts and never ends. When working in projects, be aware of the risk of silver plattering. I  sank a 7 year old company just because I was not paying attention to it. Believe me, its a high risk.

The expectation that the contractor change indefinitely a software is quite common in organisations that don't have mature processes and don't have a clear understanding of software development practices. It basically describes most organisations working in a undeveloped software market, Colombia for example.

For example, they want the software to fit the process, but they keep changing the process and expect you to develop the change again and again. One that is happening to me right now is that the requirements are given to you with little or no details, for example lacking special cases or precise data that needs to be saved. Then, when the testing starts you are expected to change it again and again for not being a good psych and developed exactly what the customer had in mind but forgot to write down.

What to do? Its as clear as water. Don't give your work for free, no matter what happens. It you loose a client because of it, it might be better for you. First, be sure to include in the contract a clear definition of change and defect. Second, include in you plan a specific milestone for client approval of the requirements and don't start development until you have a valid signature. Then, stick to your process like a fly to honey.

When asked to do a new change because its the "last one", just say no!

Project Management is not fighting

While developing custom software with a difficult client, it is frequent to see inexperienced Project Managers thinking their job is to fight the client.


I read The Art of War many years ago, but it took me a while to understand most of it. In war, all sides lose much. You must only go to war if you have certainty you will win, and that you will win will be more valuable to you than what you will lose. These three simple concepts have to be in the mind of anyone dealing with a client.


Fighting and conflict might win a small battle but will get you into losing the war. You need to pick your fights since having constant communication and being able to negotiate with the client is one of your main responsibilities as a Project Manager.

A Project Manager should not fight, but solve problems. Use force and conflict only if it's the only way, you have certainty you will win and are sure that what you will get is more than what you will lose.

When they want uncontrolled changes and you don't have a boss to blame

As Project Manager, one of your main responsibilities is to control changes. Its the only way to deliver maintaining the triple restriction: scope, cost and schedule. When ever a client ask for a change, what is expected from you is to determine the impact in scope and translate it into impact in cost and schedule. Then, a committee decides what to do about it. PMI recommendation is that the PM must never decide on his/her own, some one else needs to make the decision, to avoid you being crucified latter on. It must involve Senior Management, the project sponsor o who ever gave you the authority to be Project Manager.
So far, so good. Looks like a simple procedure. But when you are both Project Manager and head of your company? You are as Senior as it gets. Its your call and the client knows it. Then, there is a big difference in how to handle it all.
In the early days, my partner didn't work full time in Sincronía. It came quite handy to help me with this situation. When the client was asking for a change and I really didn't wanted to do it, I said after a few days that the change was not approved by my partner. He off course, knew it, so in the rare occasions he went to project meetings, he sat there with an angry face and talked very little. He was the mean partner that didn't allow changes to be considered minor and therefore be done without charging extra.
But now, we are both working full time in the Company, and most of clients know us both, having a good and a bad partner doesn't work anymore. So, what to do? Well, it depends on the project.
Ideal scenario is to have documented requirements and the complete base line at the start of the project. Any change that implies a change in the document, implies a change in base line. Easy to handle.
But if you are developing with extreme programming methods, it might not be that simple. The idea here is that the development team works and change functionality as required by the client. There is no complete documentation before its built. But you will eventually face the problem that your client has bad memory (as most of them have) and makes you change functionality from A to B, then decides B is not so good and you go C, and then he wants it to be A not even remembering that it was the first version he/she ever saw. At some point, you need to stop allowing changes or you will go bankrupt.
It you are lucky, you will have a conscient client, that after being pointed the obvious will decide to stop the change. To be honest, we have some of those conscient clients, and then we can easily manage their projects. But with the others, the only way is to use negotiating techniques and dead lines.
- Define a dead line for changes to be introduced. It's very unlikely you can actually make this happen, but the threat that if they don´t make the change now will not be able to do it, will make them gather and test the application. In this way, big changes will come fast, the at the end only little things will follow. If you still have many developers working on the project, its easy to introduce big changes.
- Say yes to little things so you can keep the no on the big ones. Many changes are easy to implement. Don't fight on little things, its easier to just do them than fight them. Even if they sound stupid to you, just do them. Leave your ego home if you have to.
- Don't be afraid to say no when you have to. Don't let the fear of "damaging the commercial relationship" bug you. Remember that broke software companies can do anything with great commercial relationships. Some of the changes will imply changing the whole application or even imply new modules that are not really needed. Be fair, do what is needed for the system to be good, but don't bend on things that are not fair to you as the developing company. Some times the client is not right.
- Clients don't like to hear no. They will scream, threaten, insult and call their bosses into the fight. Be cool. Remember its a tantrum and don't overreact. I usually win this fights the Gandhi way. Just be not violent, but don't move an inch from where you are standing. Be prepared, you will not be popular, but you will win the fight and save some good money for your company.
- And finally, be prepared to loose some fights. Remember that to win a war you sometimes have to retreat or even loose in a few battle fields. Don´t forget what the war is about: have happy clients that will bring new clients while having a profitable company. It can be done, but its up to you.