IT Project Management -- the vital Qs:

1. What to do? -- what is it that we are trying to achieve? Most often, IT projects are done not to solve a problem. In stead, most often the objective may be to improve the state of affairs, improve productivity, reduce the number of errors, organize the work better to increase throughput and decrease response time, etc. (That makes me wonder my most companies look to hire problem-solvers. My pennyworth - hire engineers that may identify problems.)

2. Who benefits and how? -- once all stakeholders understand what is to be done, the next important (though obvious) Q is to ask for justification of why to do the project. In other words, who are the beneficiaries. This Q is tightly-coupled with the funding requirements of the project. At the end, all is business; the project is done to make more money, and the project costs money. It is important for everyone involved in the project to understand who is the sponsor for the project, and to know how the project will benefit the beneficiaries.

A project has 3 needs; customer, business, and technology. A project manager has to look at meeting all the 3 needs from the project. A project that does not meet all the 3 needs has not been dealt properly, and needs a re-look.

Once we know the beneficiary, the next task should be to find out what does the beneficiary do to be benefitted from the project. It is important for everyone to understand the business of the beneficiaries so as to offer the best value in the project.

3. Who pays, and how much? -- I guess programmers and testers may not be interested in the answer to this Q, but, nonetheless, they should be aware of the importance of this Q.

The project manager is the person who should ask this Q, and understand the answer in depth. The answer to this Q will determine the schedule, the resources, etc. More importantly, the answer will be cardinal when a schedule-slippage happens :-).

4. Does the project fit? -- As earlier stated, there are 3 perspective of a software product; the business, the customer, and the technology. Just because we have a customer ready to pay for work does not mean that we should do that work. We have a bigger responsibility than just making money. For instance, a company that is numero uno if telecom software segment should not develop an investment banking software just because there is a customer ready to pay. This is because this project does not fall in the vision of the company. The disadvantages of doing this project will likely outweigh the advantages.

Similarly, consider a customer approaches this telecom s/w company and asks it to create functionality spec of some Perl scripts that run on some telecom s/w stack. Although this line-of-business is met here, but doing this project does not help the technology needs of the company.

Consider the third case now. There is a customer that is ready to pay for a customized enhancement to a product. The project manager needs to understand that the vision of the company is to create products, and not start producing customized releases that fit just one or two customers. Here, the business perspective is not being met.

A plausible problem with the technology-savvy people is that they believe that technology is only for the good. Right? Wrong. Technology may be bad, if we are blind-folded to ignore its side-effects. Just because someone has a high-tech does not mean that this idea makes business sense. Similarly, just because the CEO wants to introduce a new product does not mean that the product should be introduced. See, we are talking business here, and it is OK for people to be emotional, and follow their egos. But at the end, there has to be a business justification of everything that is done. And for this to happen, we have a team of people who challenge and reason each other's thoughts and actions.

The bottom line is that the project manager should see overall rationale behind doing the work, and he is responsible for ensuring that the project meets all 3 needs.