Software Project Governance – Using SDLC Metrics

Software Project Governance – Using SDLC Metrics

Software project costs generally form 40% of the total IT budget in most companies. However, seldom a software project meets all user requirements, is within the budget and is completed on time. Most software Projects fail to provide the required functionality in the scheduled time and budget. Thus, the results do not meet the required quality criteria. Therefore, focus of most organizations is on improving   software development processes and technology controls. Although, most dashboards track software projects, one area that does not get the required attention is the project governance aspect of software development.

Consider a Case study of a fairly large software company.

The Company uses metrics to measure a completed software project:

1. Information that is sought for the metrics :
   1. The overall project effort, schedules, cost and the total number of defects found. Data information to compare planned v/s actual.
   2. Project tasks wherein details of the resources, effort, schedule and cost. The documents produced at the end of it and the size of the deliverables.
   3. Project environment, where in participation of the users, customers, effort, schedule, cost of user, customer, external personnel per task and total project.

2. Details of the project management aspects
   1. Project management training (training possibilities offered to project managers)
   2. Methods and tools used for progress tracking
   3. Methods and tools used for cost tracking
   4. Methods and tools applied for controlling quality and productivity
   5. Risk management (methods used for the analysis and monitoring of risk factors)

The results of the case study showed that, the amount of time Invested for Project Management activities is only 5 or 10% of the total project time. This led to overruns in the cost and time schedules. Most project managers work in multiple projects at the same time. Ongoing risk assessments are not performed. Risks are assessed only in the beginning of the project. There is no support from senior management.

The above is true for most organization. While majority of Companies might document the costs and benefits of a software project for the purposes of seeking Project Approval, only one percent of the total number of Companies tracks actual costs and benefits versus the stated benefits in the Project Approval Requisition (PAR) document. The only way of communication to the senior management is through status reports. This proves the point that project governance is inadequate in the software industry.

Along with training for the project managers, Software Measurement program should be used for effective project management. This would include methods to improve estimation of the software product, software measurement for project tracking and software metrics to control software quality.

Based on the above findings once can initiate policy and organizational changes.

Risk management needs to be done continuously from start to end of the project. The different types of risks that an Organization faces are:

People risks are associated with the availability, skill level, and retention of the people on the development team.

Size risks are associated with the magnitude of the product and the product team. Larger products are generally more complex with more interactions. Larger teams are harder to coordinate.

Process risks are related to whether the team uses a defined, appropriate software development process and to whether the team members actually follow the process.

Technology risks are derived from the software or hardware technologies that are being used as part of the system being developed. Using a new or an emerging or a complex technology increases the overall risk.

Tools risks, similar to technology risks, relate to the use, availability, and reliability of support software used by the development team, such as development environments and other Computer-Aided Software Engineering (CASE) tools.

Organizational and managerial risks are derived from the environment where the software is being developed. Some examples are the financial stability of the company and threats of company reorganization and the potential of the resultant loss of support by management due to a change in focus or a change in people.

Customer risks are derived from changes to the customer requirements; customers lack of understanding of the impact of these changes, the process of managing these requirements changes, and the ability of the customer to communicate effectively with the team and to accurately convey the attributes of the desired product.

Estimation risks are derived from inaccuracies in estimating the resources and the time required to build the product properly.

Sales and support risks involve the chances that the team builds a product that the sales force does not understand how to sell or that is difficult to correct, adapt, or enhance.

COBIT 5 framework for Risk describes the IT programme and project delivery risk i.e. Risk Associated with the contribution of IT to new or improved business solutions, usually in the form of projects and programs. (Fig. 1 below)

‘P’ indicates a primary (higher degree) fit and an ‘S’ represents a secondary (lower degree) fit. Blank cells indicate that the risk category is not relevant for the risk scenario at hand.

Project Management (PM) is an important aspect of Software Development.   Software projects are time bound and a Project Manager has to manage different aspects of the software project, coordinate different tasks to ensure timely delivery without exceeding the costs approved.

Project Manager is responsible for making the work go as smoothly as possible, so management of issues is another critical PM function. Further, due to unlimited variety of project issues that can be encountered, this is also a time-consuming activity. Some of the PM issues include inability to perform risk assessment and identify risk issues, track issues identified to completion and implement a mitigating solution.

His major responsibilities include

• Developing the project plan
• Managing the project stakeholders
• Managing Communication
• Managing the project team
• Managing the project risk
• Managing the project schedule
• Managing the project budget
• Managing the project conflicts
• Managing the project delivery

Planning is an important aspect of SDLC. This involves estimating duration and effort to ensure timely delivery. Project Managers should continuously monitor project risks that would come in the way of the success of the project.

Project managers should as far as possible adopt a quantitative approach to measuring software processes and products. This is essential for effective project control, planning future projects and improving the software development process in the organization.

Metrics play an important part in helping the Project Manager achieve his responsibilities.

Project Management Metrics can be the following:

1.   Monitoring Percentage Completion of the Project

1. Will give u an overall perspective about the progress of the project
2. Includes work that is completed, as well as in progress

(As shown in the below figure)

2.  Effort Analysis

1. Provides perspective of work completed, not started, and in progress

3.  Earned Value by Effort

1. Indicates how much work is completed, and where the project is vis-à-vis the planned effort
2. Will indicate slippage in effort for tasks that were supposed to be completed by a given date.

(As shown in the below figure)

4.  Earned Value by Tasks

1. Indicates how much work is completed, and where the project is vis-à-vis the planned number of tasks.
2. Will indicate slippage in number of tasks that were supposed to be complete by a given date.

5.  Time sheet analysis for project

Software Projects – Defect Cycle Metrics

Features of software projects

• Time and Cost over runs
• One last bug
• 90% Complete 90% of the time

Note that it is 75 times more expensive to fix an error during installation than during Analysis.

• There are approximately 60 defects per 1000 Program Line Of Code (LOC)
• 2/3 of defects occur in the RS and Design phases. (This is an average over a large number of applications) (It means only a few occur in the programming phase).
• Early QC is the most cost effective way to kill project risks
• Therefore Review, Review and Review is the only path
• Testing on the other hand is perhaps a measure that is a bit too late!

Thus, Quality Management is another important aspect of Software Development.  Software defects are expensive.  Moreover, the cost of finding and correcting defects represents one of the most expensive software development activities. To do this development teams need to implement a defect management process that focuses on preventing defects, catching defect as early in the process as possible, and minimizing the impact of defects.

Defect Metrics can be the following:

6.  Defect by Injection Phase

1. Will give u an overall status of how many defects are found during each phase of the software development.
2. As shown in the following figure.

7.  Defect by Priority

1. Provides perspective of defects that have greater impact on the programmes.

8.  Defects by severity

1. Indicates how many defects are critical to the delivery of the functionality and have effect on the customers.

9.  Defect by Pattern

1. Describes the total defects found during the life cycle of the project.
2. Of these Open or close and how many of them would remain towards the end of the project.

Conclusion:

Metrics determine if

• There are changes necessary to be incorporated for the project schedules or no changes are required to be applied for refining the project schedules
• Whether to redistribute the work or Re-allocate the work
• Re-estimate the remaining work if necessary
• Track progress versus previous week for overall effectiveness
• Identify risks if any and monitor or control for project completeness.

Before Metrics Weekly tasks for Project Manager would involve

• Get data from the team leads.
• Consolidated and discuss in team meetings.
• Assess Risks.
• Then prepare a report for the Project
• Time consumption in this process is high

With Metrics the tasks are

• Understand the project status from the Metrics Charts.
• Only in case of doubt ask the team.
• Then prepare a report for the Project.
• Time consumed is very less for reporting