One of the definitive movies of the art of movie making is Seven samurai. It is a story of war, love, duty, and plain fun. It was remade into The magnificent seven, which in turn inspired Sholay.

Anyway, the leader of the army does little else than prepare for the war for most of the movie. He gets the ditches ready, he gets the sharpened bamboos ready, he gets the people ready -- all for the last few hours of battle.

Software project is a bit like that. For three months you will be developing a piece of software and in the last few days, you end up cramming so many features, bug fixes, you wonder what did in the early days. If magically you get a time trader (Hint: makes a good science fiction short story; contact me for a fully developed story line), who can grant you few hours extra in the last day, you would be willing to trade away days from the beginning days of the project.

But, even after managing so many projects, why do you get into the same situation? What can you do to avoid these problems? I am going to put down possible answers in this note. Imagine that you are a project manager (PM) for a second.

1. Develop good development processes up front.

   Here is what I observe constantly. Projects do not start using version control from day 1. They do have standards from day 1. They do not have information repository from day 1. Even if they had information repo, it has no means of automated updates.

   Here is what I suggest. Take an empty project. Set it up as your project. That means, put the entire skeleton up, including the placeholders for all the artifacts.

   Also decide on standards. Make it a part of development process. Decide on tools. Get all the people to set them up the right way.

   Before saying that "we do not have requirements yet, the clients are not sure what they want", do all this prep work first.

2. Develop good communications up front.

   In lot of projects I participated in, people thought that they were doing a favor to me by communicating to me. They felt that the extra communication costs more than they could afford.

   Once I hear that, I already know that I am playing a losing game. It is vicious circle -- they can't communicate because it is too costly for them; they can't reduce the cost since they can't communicate.

   But, think of it this way. There is cost going to be associated with doing things right. For example, there is cost with good design. They is cost with good commenting. There is cost with good coding practice.

   Yet, you incur cost with all those activities. Why? The pay off is high, and it comes at the right juncture. Namely, in the last few days of the project.

   There is another secret: once you get the team into these habits, you find that it is not that costly. In fact, you will not even notice the extra cost.

3. Spend time setting up right practices.

   I see that lot of people are fascinated with "architecture". They all think about these fancy boxes and arrows and rectangles laid on one another.

   I think that is baloney. Real architects actually code. They understand the implications of every choice -- libraries, languages, tools, and development practices. What I want to see people do is to make right choices up front.

   For example, which logging system to use? Which programming style to use? Which technologies are to incorporate? How much time does it take to code, test and debug?

   These are the essential things that you need to discuss, evolve, control, and enforce in that order.

4. Reduce the ramp-up time

   I always measure the success of a project manager from the following three questions:

   1. How much time does it take a new developer to set up dev environment? That is, to see the code, change a line of the code, test it and debug it.
   2. How much time does it take a new tester to test the code? That is, take the release, set up the test system and test the application and file a bug report.
   3. How much time does it take to make a release? That is, freeze the code, build, package, and provide to the end user.

   Obviously, the lower the numbers are, the better the PM is. It takes planning from initially to manage these metrics.

Now, these are not the only things you can do as a PM; but these are the ones that are in your control. You need not blame the customer; you need not blame the customer interface; you need not blame the developers; you need not blame the weather. If these things are not done -- you only have yourself to blame.