Lean Six Sigma projects involving software development are an increasingly popular option for IT departments that are seeking to improve their efficiency. However, a number of research studies demonstrate that the average percentage of software projects that achieve all project objectives is significantly less than might be expected.
For instance, a Standish Group survey conducted in the United States report that only 16 percent of projects meet all of their original objectives. Many of these projects fail because they were not on schedule, were subject to cost overruns or did not meet their desired quality standards. One of the major reasons these software projects can spin out of control is a lack of proper planning. The solution to many of these problems stems from having a well-defined, project-specific process in place to ensure adequate planning and communication occur at the start of each project, which increases the probability of success for a project.
To help practitioners stay on target with software development projects, one helpful tool is the project-specific software process model (PSPM), which outlines the necessary steps to be followed in a project. Results show that the use of PSPM has improved projects’ performance, based on the key performance indicators (KPI), and enables organizations to meet most, if not all, project objectives.
The PSPM maps out the complex interactions of all project activities and includes tools that can be implemented to achieve project goals. The activities consist of development, management and reporting functions. The PSPM also addresses the requirement of collecting metrics to monitor project progress. It provides insight into how quality is built into the product by highlighting reviews planned, testing processes followed, and relevant metrics collected, analyzed and carried out.
The objectives of the PSPM are as follows:
- To bring clarity to a software process
- To enhance teamwork
- To enable process measurement
- To provide opportunities for continuous improvement
- To bring clarity in communication
- To clearly delineate roles and responsibilities
- To depict external dependencies
Along with its own business objectives, each project must meet organizational objectives. The organizational business process model is built based on an organization’s business objectives, which are supported by various international quality models such as capability maturity model integration (CMMI) or ISO standards. Each project also has its own constraints and nomenclature, depending on stakeholder needs.
The PSPM then modifies the organizational business process model by superimposing the project’s constraints, tools, metrics and reporting requirements. Because PSPM is derived from the organizational business process model, it will satisfy the process areas of CMMI/ISO.
Basics Elements
Each PSPM lists the following elements for a software project:
- Development activities
- Management activities
- Reporting requirements
- Stakeholder roles and responsibilities
- Decisions/approvals
The PSPM diagram depicts the process to be followed during a project’s life cycle, beginning with the initial study of the project by the process expert. The process expert establishes a dialogue with the project team to discuss the project requirements. The process expert then prepares a draft process model, based on the understanding of the project and organizational requirements, as well as international standards such as CMMI and ISO.
Next, the project manager reviews the PSPM model diagram (Figure 1) and the PSPM is updated accordingly. The updated PSPM is then discussed with the project team. Each member of the project team validates the activities and tasks described in PSPM as per their role in the project. During this discussion, the roles and responsibilities are crystallized. In some cases, finalizing the PSPM can take up to two working days.
After incorporating suggestions from the project team, the PSPM model is then released for the project. Typically, the model is included as part of the project plan.
The PSPM diagram details the software engineering workflow of the project. The complete PSPM for a particular project would consist of several more diagrams depicting different phases of the project. The horizontal swim lines represent the stakeholder, while the vertical swim lines represent the project phases in the software development life cycle. The arrows indicate preceding and succeeding tasks/inputs required for a specific task and output expected from the task.
For example, say a technical leader is entering the coding phase of a software development project. The tech lead is expected to look at the intersection of the coding phase and tech lead role on the PSPM to understand the required tasks. If the tech lead is expected to conduct test plan reviews and code reviews, they should log the defects in the defect logging system and ensure that the defects are fixed. If there are no review defects, the tech lead is expected to provide a go ahead for moving to the next phase, which is software testing.
Diagramming the PSPM process may look simple, but in reality it involves a lot of discussions, reviews and effort to approve and release the process to all stakeholders. The common understanding of the detailed process workflow – for project management as well as software engineering activities – helps remove confusion, misunderstanding and numerous unwritten assumptions.
The PSPM diagram is very useful when a new person joins the project. By looking at the chart, he new person gets a clear idea of the expectations, activities and tasks involved in their role. It is recommended to include in the PSPM a list of relevant tools required to complete a particular task, as well as a schedule for when reports should be made for a given task. Also, practitioners should be sure to add the customer as one of the stakeholders in the PSPM chart. Customers should always be aware of their responsibilities, such as to provide inputs and approvals as per the plan.
Feedback on Using PSPM
To test the usefulness of PSPM, the model was deployed on three different projects conducted by Atos Origin. Feedback was obtained from 20 project managers and senior members of these project teams. The people were asked to rate their agreement with 10 statements regarding the use of PSPM on a five-point scale (5 = Strongly agree; 4 = Agree; 3 = No effect; 2 = Disagree; 1 = Strongly disagree). The table below gives the average and standard deviation for the ratings obtained.
Ratings of PSPM Effectiveness
| Statement | Average | Std. dev. | |
|---|---|---|---|
| 1 | The process flow diagrams helped the project teams bring clarity to the process. | 4.53 | 0.51 |
| 2 | The detailed process flow diagram has brought clarity in roles and responsibilities. | 4.26 | 0.45 |
| 3 | The process flow diagram has helped or will help in improving communication between the global teams. | 4.21 | 0.71 |
| 4 | Agreed process flow diagrams have indirectly helped or will help to improve the project KPIs. | 3.74 | 0.45 |
| 5 | The process flow diagram provides one way of working for global teams. | 4.11 | 0.81 |
| 6 | The process flow diagram has brought alignment in geographically distributed teams. | 4.05 | 0.52 |
| 7 | It is difficult to get agreement on the process flow diagram from all stakeholders. | 3.05 | 1.13 |
| 8 | I find or anticipate positive difference in the team’s performance after using the process flow diagram. | 4.00 | 0.58 |
| 9 | The use of process flow diagrams will reduce some of the project-related issues. | 4.16 | 0.37 |
| 10 | I will definitely use a similar process flow diagram in my next project. | 4.32 | 0.82 |
For all the statements, the standard deviation was fairly low, indicating that the average is a good fit and can be treated as a representation of the population. The teams had strongly agreed that the use of PSPM brought clarity to their processes. Having a clear understanding of the process to be followed in a project plays a significant role in success of the projects, especially when the projects teams were geographically distributed. The teams said that use of PSPM also brought clarity to their roles and responsibilities. Typically, project plans mention roles and responsibilities, but sometimes they get lost in heavy documentation. Use of PSPM, however, helps in emphasizing these roles and improving communication between global teams.
The exercise of conducting brainstorming sessions to review and update the PSPM brings additional clarity about the way software project teams work. Through the PSPM, the customer also becomes aware of the inputs that are required to meet the project objectives. The release of such a model as part of project plan can help project teams improve their performance.
The analysis stated above demonstrates that the use of PSPM had definitely helped the project teams in meeting the project goals. The success of the model lies in the high level of agreement with the last statement on the questionnaire: Most of the project managers (average rating: 4.32) said that they will definitely use such models in the next project.
