Classic Mistakes – GigaLease Case Study, Part 1

I was wondering for quite a long time how to organize my series of posts on classic mistakes and finally I decided to share some true stories from my professional experience as case studies and to discuss on the classic mistakes made there. Of course, all the names are changed – I don’t want to embarrass anyone, even those who made the biggest mistakes.

How it started

Some time ago I was working at a company called Mega Solutions. It was known as the biggest and the best software company in my country. They claimed that the company hired only the top experts in the area of the software development, used the newest technologies and charged the highest rates.

GigaLease was a small company which offered leasing solutions for industrial equipment and thus had serious customer base and pretty good income.

One day they decided that they needed a custom software product to track all the contracts they had signed, all the credits they had given and all the installments and interests due. So they turned to Mega Solutions to develop such system. They provided a three-page request and they wanted to have the software in four months. The Mega management agreed immediately and they signed a contract before any of the team members was available.

The first clash

I was hired a month later when only the PM was on board. He was a Business System Analyst also and I was the Team Lead and everything else since there was nobody else in the team. Being the only technical person in the team and a person with significant experience in building similar financial systems, the PM asked me to give him an estimate of all the project tasks to help him produce a reasonable project plan. My estimates were more than shocking – I predicted the project to take approximately 12 months if we had a team of 4 or 5 members, depending on their skills. In other words – about 50 man-months. Instead, we had a signed contract for 4 months and a promise from the management that I could have one junior developer added later to the team. It meant that their estimate was about 8 man-months. What a difference, ah!

Ed Yourdon in his famous book Death March defines a project for which one of the constraints – time, scope, or resources – is shortened in half as a “Death March”. What should I say when my project’s effort estimate was shortened at least 6 times?!

Looking for a solution

I and the PM (who agreed completely with my estimates) decided to ask the project sponsor for more staff and for new negotiations with the customer for more time and money since the actual contract conditions were impossible to meet. The answer from the customer about the money was very simple – GigaLease, although very profitable company, had a very small budget for IT solutions and we contracted all of their available money. They were more tolerant on the subject of the total duration and agreed to negotiate it if we reach some significant obstacles during the execution of the project. So, in fact we started the project without a clear idea how many people we would have and without a detailed project plan.

The “Death March”

My concerns about the project’s duration were based on the fact that the customer wasn’t sure what exactly they wanted. The time showed that I was right (as I will explain later). I had some experience with people who wanted to make a revolution in their business with a “small software program” (in their minds) ending with a product, which was a constantly changing and buggy mess of code.

So we shared our concerns with the project sponsor presenting him some simple calculations showing that the project would be a great loss for our company. He said: “Don’t worry! This project is not for profit. It is to make a strategic relationship with the customer and to use their services in the future at a lower cost.” Not only we were put in a “Ultra Death March” and we had to work day-and-night but we had no spark of motivation – there would be no reward, no recognition, no bonus.

This was my first project in the company. I was very flattered when they decided to hire me – it meant that I was one of the best developers in the country since they don’t hire average people. But now I realized that couldn’t prove my abilities – I was entitled “Team Lead” but I had no team and I had no chance to show my leadership skills; the product was decided to be a client-server system build with Visual Basic 6, which was considered already a fading technology, so I didn’t have the chance to improve my technical skills, too.

The classic mistakes made

In this part of the case study I can see the following classic mistakes (according to Steve McConnell):

1. Undermined motivation (#1). Putting the team in a Death March project is a huge risk. Leaving them no straw to catch destroys the motivation totally and gives the project almost no chance for success.
2. Lack of effective project sponsorship (#9). The project sponsor didn’t take our opinion in consideration. He never discussed the great possibility of failure with the customer on a management level. He didn’t approve (at the beginning) our requests for more people in the team so we could finish the project in shorter terms.
3. Overly optimistic schedules (#14). The fact that contract was signed and the schedule was agreed upon without asking the team and without having some estimate was the major reason for the project’s failure.
4. Feature creep (#29). Since the initial request was too general and there was no detailed specification before the contract, it was obvious that a lot of requirements will be revealed during the implementation phase and the feature creep was inevitable.
5. Push me, pull me negotiation (#31). It happened several times when we negotiated more time with the customer. They agreed to give us more time and to delay a milestone but they insisted for some more features in exchange. As a result this made the schedule heavier and more difficult to fulfill.

The biggest mistake in my opinion was putting the team into a Death March project with no motivation. Our company created the “Marine Corps” mentality – if you cannot succeed then you are not suitable for our company. This kind of thinking could never bring a Death March project to success.

What’s next?

The next part of the case study shows how the team was built and how the customer reacted to our product. More classic mistakes!

Meanwhile, if you have some similar projects or similar classic mistakes, tell me about them in a comment, in an email, or in your blog. I believe that telling our stories we can help each other avoiding such mistakes and achieving our projects’ success.