Classic Mistakes – GigaLease Case Study, Part 2

In the Part 1 of this case study I talked about how the project was set up. Now I’ll continue my story with the project’s execution, the team’s growing up and some truths that we revealed during the project.

Building up the team

I was so eager to succeed with this project so I and the PM pressed the management very hard to recruit more people to build up our team. Unfortunately, they weren’t looking for the best talents but hired whoever was available.

The first new member of the team was Jannice. She was hired by the HR department without asking for our opinion. Anyway, she claimed to be a very skilled and experienced developer (she was my age) but I gave her a very simple task – to create a form with two simple controls and to bind it to the corresponding record in the database. I knew she needed some time to get acquainted to the development style I established so I gave her a couple of days although I could do it in a couple of hours. Three days later she still had no progress and she told me she still doesn’t understand how to do the task. After a thousand explanations and examples, on the fifth day I understood that she has no idea of software development. She was absolutely useless and from that moment on I assigned her the simplest and the least important tasks. I was still alone and I continued my pressure upon the management to assign more people to the project.

Several months later, when we started to write the user documentation and the help system, Jannice told me that she is really skilled to do that and gave her one more chance. Luckily, she was really good and I was very happy that we finally found her place but we still wasted all those months trying to make a developer out of her.

Next hire was Zoe. This time we insisted to participate at the interview so we were able to ask her some technical questions and we understood that although she was not perfect, she was a developer with some experience and with the great desire to learn and to improve.

Zoe was really fast learning and soon she took responsibility on some of the program’s modules. I was very proud of her for she understood the business logic very quickly and soon she was able to discuss some of the requirements with the customer.

Although Zoe was a hit, the work still remained too much and I kept asking for more developers. Soon the management assigned Frank. He was already an employee but he was famous as the company’s “black sheep”. He had no respect for the company’s rules nor the working hours. I could never be sure when he will come to work and how long he was going to stay. He used to play games during the nights and usually used to come to work at noon. Then he worked for some time and about 5 p.m. left to meet his girlfriend.

Frank was very unproductive and was another peer who reported hours but had no real contribution to the project. We worked on VB6 and it was common situation Frank to commit code that wasn’t compilable (VB6 had that feature “Compile on demand”) and to break off the work of the other team members.

I am still wondering why they kept him in the company. He couldn’t contribute not only to my project, but to all the others he worked on before.

Anyway, we managed to work somehow with this weird team. Unfortunately, we couldn’t hope at all to finish on time.

The first deployments

At some point we were ready with the first release of our product. We decided to make incremental deliveries to show our progress to the customer and to get their feedback as soon as possible in order to understand better the requirements because we didn’t have clear requirements during the whole life of the project.

What was my surprise when I realized that nobody in the customer’s office was using our product! The all boycotted it. Then we started asking questions and a whole new picture arose before us.

The ugly truth

Some time ago, in GigaLease there was a guy, about fifty, who was the chief accountant of the company and who was the only person who kept track of the client’s dues using some magic formulas in Excel spreadsheets. He used to present the reports to his management with no explanation where those figures came from and happily no one asked.

It happened that they hired a young lady on the position of Financial Director and she became a superior manager to the chief accountant. She wanted to know how the reports were generated but he refused. He was insulted of the fact that so young and inexperienced girl happened to be his boss and he boycotted her. Then she decided that their company needs a software product to do the calculations. The formulas will be publicly known and everybody will use that product. And finally, she will show her subordinates who is in command.

Then she came to our company with her 3-page request…

It turned out that there were political intrigues inside that company and they decided the most stupid thing – to solve them using a software program! And our management involved us into somebody else’s war not understanding that nobody wanted or cared about our product. The project was defined as “not important” in our camp and in customer’s. The project was just doomed.

Soon the project was canceled by the customer after nine months of hard work and a lot of problems.

Classic mistakes made

This is a summary of the classic mistakes (according to Steve McConnell) that I see in this part of the case study.

1. Weak personnel (#2). Jannice’s assignment as a developer was a big mistake. We wasted too much time to understand that the development is not her strength.
2. Uncontrolled problem employees (#3). Frank was really uncontrollable. The management had many conversations with him but he couldn’t change. I believe he just should have been fired.
3. Friction between developers and customers (#7). This friction occurred because the customers couldn’t define their requirements during the whole life of the project. And the requirements were just undefinable since the company had very different problems and those problems couldn’t be solved with software.
4. Lack of stakeholder buy-in (#10), Lack of user input (#11), Politics placed over substance (#12). All these mistakes relate to the customer and their political problems. I understand that this is difficult but our management should have understood earlier all those issues and should not have gotten us involved in this farce.
5. Feature creep (#29). The requirements were so unclear and unstable so they were changing all the time.

In my opinion, the biggest mistake was the lack of ability to understand the customer’s problems and needs. We should have understood that their problems were organizational and we couldn’t help with a technical solution. There was no vision about what the product should do and this doomed it to fail.

Do you have such stories? I would highly appreciate your feedback.