Massive Project Failures

A friend of mine who works for a Big-5 consulting firm told me that she started a really big project for a company. She said that there is an army of consultants working on writing use cases, and that they plan to write use cases for a long time because there are hundreds of them. There is no developer on the project yet, but development will take place offshore when the use cases are finished. In the mean time, an architecture group is preparing the work for the future developers.

See any problem here? I do. It reminds me of another big project I worked on when I was also in a Big-5 consulting company. There was more than a hundred people on it. I gave 3 years of my life to this project, the client spent a fortune and I heard it is still not finished. The whole system was to be released at the end when all pieces are finished, instead of component by component.

Programme management is certainly no easy task, but sometimes it just takes common sense. Here is my advice to programme and project managers:

Rule #1: Hire The Right People

Your probability of success is a direct function of the skills and the motivation of your team. No amount of repeatable/optimizing processes will ever change this. Deal with it.

If you want success, hire experienced developers, which means spend the money on them. Be aware that good programmers have no trouble finding a job: they receive job offers every week regardless of the Economy. They will need motivation anyway because they will work 10-to-12-hours days and some week-ends. Of course if you manage to hire veterans you will need much smaller teams. I worked during a year and a half in a team of 12 programmers with an average of 15 years of experience, and I can honestly say that we produced more during this time than the hundred people during 3 years in the past engagement I mentioned earlier (a lot more, and our applications are used everyday by lots of people). Smart people attract smart people, so if you manage to hire a rock-star you are already half-way there.

My past projects succeeded because I was lucky to have a few good men in my teams, sometimes people that are way smarter than me. Here is a question for all project managers working with offshore development teams: have you even met your developers?

Rule #2: Evolution, Not Intelligent Design


Design your software for the next few releases only; you will adapt the architecture later if needed. A recipe for failure is an Architecture Team responsible for all design decisions, throwing application frameworks "over the wall" to the developers who are not empowered to make their own choices. I learned this lesson the hard way.

This rule is also known as: Release Often. If your project didn't put anything in production after 4 or 5 months, you have a serious problem. User feedback is critical to ensure that your application fills business needs, and for evolving the architecture. If you have to integrate mid-project releases with legacy systems so that your application can be used by the business, so be it.

The company I now work for has been one the most successful companies in America during the last 20 years. We must do something right... I noticed two things during my first few days: first, programmers are kings - they are amongst the most respected people in the company. Second, managers push you to get the product as soon as possible in front of the client, even if it is quick and dirty, so we can sell it and refine it. If clients like it we'll spend the money fixing it.