26 nov 2009

The ones we miss, the ones we don´t.

What makes people a good employee… according to me!


Last night, we were talking among other things about all the people that have helped us in projects since our company started. We remember a few because we really missed them when they left, and others because we were so happy they left, we almost made a party.

I was a lousy employee when I was one. But after being a “boss” for many years I think I will now be a fairly decent employee. (Same when you start driving, you suddenly become a very good pedestrian. You are aware of what bad pedestrians do and endanger their lives quite stupidly.)

These are some of the things I leaned:

Good employees help solve problems, bad employees create problems. I have so many many things in my mind, that what I appreciate the most is someone taking some of the load from me. When employees complicate the simple, or interrupt me to tell me some really silly problem, it’s really annoying.

Good employees work even when I am not watching. Bad employees need me to be on their back all day in order to achieve minimum goals. The typical bad employee spends most of his/her day chatting, doing homework or working in their second job, the funny thing is that they all think I´m stupid and don´t know.

Good employees tell the truth even when things are bad, bad employees will always lie and say everything is perfect and suddenly resign when they can’t keep up the lie. As a manager, when there is trouble in a project, and you know it soon, you can do something about it. As an employee you will never be punished for raising issues when they come. Hiding it and resigning the day before the dead line is the best example of a bad employee.

Good employees know they still have to do their jobs, even if I am friendly to them. Bad employees assume they can stop doing what they are supposed to because they share a beer or lunch with me. I finally learned my lesson and no longer share any beer with any employee. Have to say I learned it the hard way.

Good employees will help with ideas and new perspectives when a decision needs to be made, but then follow my lead even if they don’t understand or agree. Bad employees always want to do what they want and fight every single day about it. You cannot lead a team that does not understand you are the leader. In my experience, it happens a lot with very young employees (like a pack of teenagers fighting their parents).

I have a mental list of all my employees. They are listed in good or bad employees. But, why keep the bad ones? Well… It’s all about the money. Some times it’s cheaper to keep the bad ones that finding new ones, training them and taking the risk they are worst employees than the ones I already have.

16 nov 2009

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.