13 Project Management

MANAGEMENT SPECTRUM

 

Effective software project management focuses on the four P’s: people, product, process, and project. The order is not arbitrary. The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management. A manager who fails to encourage comprehensive customer communication early in the evolution of a project risks building an elegant solution for the wrong problem. The manager who pays little attention to the process runs the risk of inserting competent technical methods and tools into a vacuum. The manager who embarks without a solid project plan jeopardizes the success of the product.

 

THE PEOPLE

 

The cultivation of motivated, highly skilled software people has been discussed by software engineering researchers for very long time. In fact, the “people factor” is so important that the Software Engineering Institute has developed a People Management Capability Maturity Model (PM-CMM), “to enhance the readiness of software organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and retain the talent needed to improve their software development capability”. The people management maturity model defines the following key practice areas for software people: recruiting, selection, performance management, training, compensation, career development, organization and work design, and team/culture development. Organizations that achieve high levels of maturity in the people management area have a higher likelihood of implementing effective software engineering practices.

 

Productivity and People

 

Figure 1 shows the amount of productivity which is varying based on the number of people appointed for the project

Figure 1. People Vs. Productivity

From figure 1, it can be observed that the increase in people increases the productivity up to a certain level. After this optimal level, the productivity decreases with the increase in number of people. Therefore, it is necessary to appoint only optimal number of people for a software project.

 

Software Team Roles

 

Software teams must be formed with a balance on skill set. In addition to the technical skill set, the people characteristics must also be considered in the team formation. Figure 2 shows the structure of a software project team which consists of members for analysis, design, programming, testing and maintenance separately. There must be some members from the analysis team with design experience, some members from the design team with programming experience, some members from the programming team with testing experience and some members with programming and testing experience in the maintenance team. The testing team must have team leaders who can perform unit testing, integration testing and system testing experience, team members with experience in unit testing and also in test case generation and finally, team members who can use the tools and also carry out manual testing by using the test cases generated by the senior members of the testing team. Requirement collection must be performed by the analysis team.

 

 

Figure 2. The structure of a software project

team Matching People to Tasks

 

In the formation of the software project teams, the behaviour of the members play a major role and hence it is necessary to match the people to tasks. Figure 3 shows the matching of people to tasks. People are divided into introverts and extroverts based on their behaviour in discussions. Moreover, they are also divided into intuitive and rational type of people. By combining these two types of classifications the people are classified into four types namely intuitive introvert, intuitive extrovert, rational introvert and rational extroverts. While forming a software project team, the team must be selected in such a way that a mixture of all these four type of people are chosen for the project. If the same type of people are selected for the project, the management of such people will be a difficult task.

Software Team Organization

 

The software team organization can be any one of the following namely democratic decentralized, controlled decentralized, controlled centralized and chief programmer team. In democratic de-centralized teams task coordinators are rotated and decision making is by group consensus. In controlled de-centralized, there is a permanent leader to look after the team. However, problems of solved by both group problem solving and subgroup implementation of solutions. In controlled centralized teams top level problem solving technique is used and internal coordination is managed by the team leader. Figure 4 shows the structure of the chief programmer team

 

Here, the members namely programmer, librarian, administrative team and test team are working under either the chief programmer or assistant chief programmer if the chief programmer assigns the duties to the assistant chief programmer. The factors affecting the team organization are as follows:

  • Difficulty of problem to be solved
  • Size of resulting program
  • Team lifetime
  • Degree to which problem can be modularized
  • Required quality and reliability of the system to be built
  • Rigidity of the delivery date
  • Degree of communication required for the project

Communication and Coordination

 

The communication and coordination among the team members are performed in the following ways:

  • Formal, impersonal approaches
    • Documents, milestones, memos
  • Formal interpersonal approaches
    •  Review meetings, inspections
  • Informal interpersonal approaches
    •  Information meetings, problem solving
  • Electronic communication
    •  E-mail, bulletin boards, video  conferencing
  • Interpersonal network
    •  Discussion with people outside project team

THE PRODUCT

 

Before a project can be planned, the product objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress. The software developer and customer must meet to define product objectives and scope. In many cases, this activity begins as part of the system engineering or business process engineering and continues as the first step in software requirements analysis. The objectives must identify the overall goals for the product (from the customer’s point of view) without considering how these goals will be achieved. The scope identifies the primary data, functions and behaviors that characterize the product, and more importantly it attempts to bound these characteristics in a quantitative manner. Once the product objectives and scope are understood, alternative solutions must be considered. The alternatives for this enable managers and practitioners to select a “best” approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability, technical interfaces, and myriad other factors. The product dimensions include software scope, context, information objectives and performance. The product development also depends on problem decomposition which includes partitioning or problem elaboration and the focus on functionality to be delivered and the process used to deliver it.

 

Problem Decomposition

 

Problem decomposition, sometimes called partitioning or problem elaboration, is an activity that sits at the core of software requirements analysis. During the scoping activity no attempt is made to fully decompose the problem. Rather, decomposition is applied in two major areas: (1) the functionality that must be delivered and (2) the process that will be used to deliver it. Human beings tend to apply a divide and conquer strategy when they are confronted with a complex problems. Stated simply, a complex problem is partitioned into smaller problems that are more manageable. This is the strategy that applies as project planning begins. Software functions, described in the statement of scope, are evaluated and refined to provide more detail prior to the beginning of estimation.

 

THE PROCESS

 

A software process provides the framework from which a comprehensive plan for software development can be established. A small number of framework activities are applicable to all software projects, regardless of their size or complexity. A number of different task sets namely tasks milestones, work products, and quality assurance points enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. Finally, umbrella activities such as software quality assurance, software configuration management, and measurement overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process. The umbrella activities include quality and configuration management. The frame work activities include customer communication, planning, risk analysis, engineering, construction and release and finally customer evaluation.

 

Process Considerations

 

The Process model chosen must be appropriate for the customers, developers and the characteristics of the product which include project development environment and the project planning begins with melding the product and the process. Moreover, each function to be engineered must pass though the set of framework activities defined for a software organization. Work tasks may vary but the common process framework (CPF) is invariant (e.g. size does not matter). Therefore, the software engineer’s task is to estimate the resources required to move each function though the framework activities to produce each work product.

 

THE PROJECT

 

After conducting the project must be planning, the project must be controlled by perfect monitoring. In order to avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring and controlling the project. According to the 90/10 rule, 90% of the effort on project to accomplish 10% of the work. Therefore, it is necessary to manage the project by performing the following:

     1.   Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objects and expectations for everyone who will be involved in the project. It is reinforced by building the right team and giving the team the autonomy, authority, and technology needed to do the job.

 

 2.   Maintain momentum. Many projects get off to a good start and then slowly disintegrate. To maintain momentum, the project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way.

 

3.     Track progress. For a software project, progress is tracked as work products (e.g., specifications, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity. In addition, software process and project measures can be collected and used to assess progress against averages developed for the software development organization.

  1. Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple.” Whenever possible, decide to use commercial off-the-shelf software or existing software components, decide to avoid custom interfaces when standard approaches are available, decide to identify and then avoid obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks.
  1. Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project. Evaluate the planned and actual schedules, collect and analyze software project metrics, get feedback from team members and customers, and record findings in written form.

Finally, it is necessary to follow the 5WHH Principles listed below o Why is the system being developed?

 

o  What will be done and When?

 

o  Who is responsible for a function?

 

o  Where are they organizationally located?

 

o How will the job be done technically and managerially? o How much of each resource is needed?

 

SUMMARY

 

The activities namely formal risk management, empirical cost and schedule estimation, metric-based project management, earned value tracking, defect tracking against quality targets and people-aware program management must be carried out in software project management (SPM) so that the project will provide a good product with optimal number of people and resources.