Common Pitfalls in Software Project Initiation

The following are the common pitfalls of SPI.

• Ineffective Project Management Office (PMO) or No PMO

Many organizations fail to visualize the importance of an efficient and effective Project Management Office (PMO). Often I have observed that merely an adjunct role is assigned for the PMO. It is sometimes attached to the secretary of the Delivery Head. Sometimes, a refugee is settled in PMO and their role is just to raise the Project Initiation Note (PIN)- the first document in a Project folder- and be custodian of project records. This type of PMO cannot aid the SPM effectively when needed; it cannot provide correct references to the SPM during project initiation, and every project is started from scratch always. I have seen this happen in more than one organization that has executed multiple projects in similar domains. It is not always possible to get the best resources for the project and in such cases PMO can play an important role by being the mentor and provide expert assistance when needed by the project. As well, during project execution, PMO can measure the project health with metrics such as earned value, quality and productivity and assist the Project Manager in course correction midway through the project. My suggestion is to have robust PMO – the benefits outweigh its cost.

• Identification of Wrong SPM

Sometimes an SPM is selected more because they are available rather than that they are most suitable, due to expediency. Sometimes, the selection becomes political when there is prestige associated with the project. I have seen this happen in many projects- SPMs vie with each other to handle a prestigious project, and in such cases cronies of the top boss will become the SPM, rather than the most suitable candidate. Needless to say, that SPM will only play politics and try to manipulate the people executing the project rather than lead it from the front. Sometimes, the most suitable SPM is unavailable –for a host of reasons; like being engaged on a different and equally important project, not willing to take up the project, etc... Hence the second best SPM is to be selected. In such cases, PMO has a greater role to play – it can play the role of a mentor to the SPM and ensure project success.

• Identification of Inappropriate Resources

Human resources are crucial for success in software development projects. Ideally a project team should consist of resources that are proficient in the development platform and have worked in similar domains. Practically, it is not always possible due to reasons such as; resources not being available, or tied up in another project, or the resource is not willing to join the project. But it can be arranged that the project team has a balanced mix of experts and not-so-experts, some people with experience in the domain, and some people who can mentor juniors. I have seen situations in which all experts are allocated to one project and other projects are starved.

• Wrong Service Level Agreements (SLAs)

Another frequent pitfall I saw is providing wrong Service Level Agreements (SLAs) to the project. A project needs timely response to its needs; especially provision of resources, troubleshooting when an issue arises, provision of expert assistance when stuck with an issue, and so on. If the SLAs provided are not in tune with project requirements – due to reasons like inadequate infrastructure, lack of experts, or due to political reasons – the consequences will be undesirable.

• Delays in SPI Activities

Sometimes, PMO takes more time in identifying the SPM; sometimes, identification and allocation of resources gets delayed; sometimes the project kickoff meeting and arriving at satisfactory SLAs consume excess time – and all these delays have to be absorbed by the project execution. Sometimes, delays are used as a tool to get the SPM agree to SLAs, resources etc.. Whatever is the reason, any delay in SPI will put more pressure on the project execution, as until the SPI is completed, execution cannot start.

• Poor Software Estimation

Robust software estimation helps in the correct identification of resources and the quantity of resources required to execute the project efficiently. Both over estimation as well as under estimation results in imbalance in the project team, which does not augur well for project health during execution. Many organizations do not treat software estimation as an important activity. They do not collect metrics on effort spent and contrast them with estimated effort and come out with properly adjusted norms. Many organizations do not even standardize a software size measure for their organization. Ball Parking is the most commonly used software estimation technique. Training in software estimation and provision of metrics to aid accurate estimation are vital for a software development organization.

• Poor Standards and Guidelines for Development

Standards and guidelines assist the development team in achieving predictable quality for the end product. A high quality set of these will go a long way to executing the project efficiently and effectively. Many organizations pay either lip service to this concept or implement them poorly just for the sake of saying it was done.

• Poor Project Planning

A saying attributed to Abraham Lincoln says,"If given six hours to fell a tree, I would use the first four in sharpening the axe," emphasizes the importance of planning. More often than not, SPMs take project plans of an earlier project and do a "save as" for project plans for the new project. While I do not argue doing away with this practice, I would suggest that project plans be made afresh, and use "cut & paste" from the earlier project plans – as this encourages fresh thinking about the requirements of the current project.

PIN - Project Initiation Note

PMO - Project Management Office

SLA - Service Level Agreements

SPM - Software Project Manager