Software Project Initiation: Role of the SPM and Common Pitfalls

Page content

Activities for the SPM

In part one of this two-part series, you read about the role of the organization in a software project initiation. Part two reviews the Software Planner Initiation (SPI) activities, which are carried out by either the Software Project Manager (SPM) or a person designated by him. The SPM takes ownership of all the SPI activities. SPM may take networking and Sys Admin personnel to set up a network and development environment. Let us consider each of the SPI activities below.

The SPM Studies the Specs Received from the Client Including:

  1. Technical specs
  2. Delivery commitments
  3. Milestone details
  4. The SPM studies all of these to be certain they are complete and make an assessment of achieving them. He will interact with Project Management Office (PMO) or the customer as required and fill the gaps in the specs, if any.

The SPM Carries Out Software Estimation:

  1. Size of software to be produced
  2. Effort needed for executing the project successfully along with needed skill sets of the personnel
  3. Schedule for the project execution
  4. Cost estimation for the project

The SPM estimates the size of the software product to be produced. He chooses an appropriate size measure based on the organizational standard and customer preference, if any. Then he converts the size into effort in person days or hours using appropriate productivity figures. He then works out the schedule of development and the cost of development.

Obtains Budgetary Sanctions for the Estimates.

The SPM would submit the software estimates to the appropriate authority in the organization and interface to obtain necessary sanctions for the budget. This sanction is necessary to obtain the required resources for the execution of the project. The SPM would follow the organizational processes for this activity.

Provides Requests for Necessary Resources:

  1. Personnel– the necessary mix of skills, development platform experience, domain expertise and level. This is normally carried out by the HR department. In larger organizations it is common to have a resource cell that is vested with the authority of allocating people to projects. If people were to be recruited, this department would interact with HR for recruitment.
  2. Hardware resources – this request falls to the Sys Admin department which allocates necessary hardware for the execution of the project. Sys Admin would procure special hardware, if any is required for the project, and make it available to the SPM.
  3. Software resources - this request would be given to the Sys Admin department who allocates necessary system software and a development kit for the execution of the project. Sys Admin would procure special software, if any were required for the project, and make it available to the SPM.
  4. Seating facility – this would be assigned to the Administration or Facilities department. They would provide a necessary seating facility for the project team in such a way that the team is collocated.
  5. Networking and Internet – this would be for the Sys Admin department, who would provide necessary interconnection for the project team, providing required security and Internet facilities.

Prepares Project Plans

Project Planning is an involved activity and is probably the single factor that can cause project success or failure. Since this is a large subject I addressed a separate paper on this subject. However, in a nutshell, the following plans are prepared.

  1. Project Management Plan – this contains details of the project scope, milestones, tools & techniques used in the project, communication and issue resolution mechanisms, etc. are detailed.
  2. Configuration & Change Management Plan – this plan contains details of development configuration, development state promotion, change management procedures, naming conventions and so on.
  3. Quality Assurance Plan – this plan contains quality assurance activities proposed for the project, metrics to benchmark the project, quality assurance roles and responsibilities for the project etc..
  4. Project Execution and Delivery schedule – this is a detailed work breakdown-based schedule listing all the activities with resources and dates assigned for each of the activities, giving the probable dates of reaching the set milestones, deliveries and project completion.
  5. Product Integration Plan – this plan contains the proposed approach for integrating the product and integration testing along with roles and responsibilities for product integration.
  6. Deployment Plan – this plan contains details of hardware and software required for deploying the solution, the schedule of deployment, roles and responsibilities for deployment etc.
  7. Induction Training Plan – this plan contains the details of topics to be covered for training new entrants to the project, pointers to course material, roles and responsibilities for conducting the induction training and its evaluation etc.
  8. Handover Plan – This plan contains details of hardware and software components to be handed over to the client’s representatives, acceptance mechanisms, roles and responsibilities of persons involved in handing over the completed project to the customer etc..
  9. Issue Resolution Plan – this plan contains details about reporting issues, obtaining resolution, roles and responsibilities etc..

Sets Up Development Environment

Development environment involves seating the project team together, ensure that all the developers have the necessary development tool kit and access to communication facilities, that the QA personnel have all necessary testing tools and a separate test environment, and so on. The following activities are included:

  1. Set up seating facility – take possession of the seats provided by the Admin/Facility department and allocate them to team members in such a way that each member is located in the related group and ensure that the complete team is seated.
  2. Set up hardware – provide necessary hardware resources to the team members.
  3. Set up system software and development tool kit – ensure that all team members are provided with necessary system software, database management system, development tool kit including editors, compilers, debuggers and so on.
  4. Set up information sharing directories – organize the information such as user requirements, design documents, project plans, training materials, issue reporting formats, test plans and all other formats and templates needed for the team working in convenient directories and providing need-based access to all the team members and ensuring security thereon.
  5. Set up networking and Internet – ensure that all the hardware of the project team is interconnected and Internet is provided to the team on an as needed basis.
  6. Set up work allocation and execution mechanisms – deploy work registers at commonly accessible places and inform the teams of communication protocols for making work allocation, as well as reporting work completion and keeping the team informed of the same.
  7. Identification of appropriate standards and guidelines for coding, designing, testing, reviewing, and defining them where they are not available.
  8. Arrange project-specific skill training required, if any, to project team members; as needed, arrange classroom or self-study training to the team members and all activities connected with such training.
  9. Train project team on all aspects of project execution as specified in the project plans.
  10. Organize the project team into its constituent functions, module teams, QA teams, Database team etc.
  11. Conduct a Project Kickoff meeting with other concerned departments and obtain commitments for project-specific service levels and issue resolution mechanisms. This is carried out with the help of the PMO (Project Management Office) who would arrange the meeting and invite all necessary department representatives to be present. In this meeting, the SPM presents the details of the project including milestones and the support needed from those present as well as the SLAs needed. After negotiating the SLAs, all present note their commitments and implement and adhere to those during the project execution. Typically, SQA (Software Quality Assurance), Sys Admin, Admin/Facility, Networking, Marketing & CRM (Customer Relationship Management) department representatives would attend this meeting.

Phase-End Audit

This is the last activity of the SPI. The SPM invites the Internal Auditor designated for the project to audit the project for conformance with the defined Project Initiation Process of the organization. The audit may unearth non-conformances, if any, and report them to the SPM. The SPM arranges for the rectification of the non-conformances and closes them.This concludes the Software Project Initiation, and the project execution phase starts.

Common Pitfalls

  • 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. He 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 the PMO can play an important role by being the mentor and provide expert assistance when needed by the project. As well, during project execution, the 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 a robust PMO – the benefits outweigh its cost.

  • Identification of Wrong SPM

Sometimes an SPM is selected based more on availability rather than suitability. Sometimes, this happens for expediency, or the selection becomes political when there is prestige associated with the project. I have seen this happen many times, 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, such as 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 and if that occurs, the 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 if resources are not available or 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. In situations in which all experts are allocated to one project, the other projects are starved.

  • Wrong Service Level Agreements (SLAs)

Providig the wrong Service Level Agreements (SLAs) to the project will delay a timely response to its needs. This could be 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, the 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 to agree to SLAs, resources etc.. Whatever is the reason, any delay in the SPI will put more pressure on the project execution.

  • 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.

This post is part of the series: Software Project Initiation

This paper by Murali Chemuturi describes the role of Software Project Manager (SPM) in initiating a Software Development Project. He gives detailed guidelines for what the SPM does, and the steps needed to bring diverse elements together to begin the project.

  1. Initiating a Software Project - Organizational Role Checklist
  2. Understanding the Role of the SPM in Software Project Initiation