Project Management Concepts

Management Spectrum

Effective software project management focuses on the four P’s:

People, Product, Process and Project

• The manager who forgets the software engineering work is an intensely or extremely human endeavor or effort will never have success in project management.
• The manager who fails to encourage comprehensive or broad customer communication early in the evolution or development of a project with risk of building an elegant solution for wrong problem.
• The manager who pays little attention to technical methods and tools concerning to process run with risk of inserting into a vacuum.
• The manager who embarks or get on without project plan jeopardizes or endanger the success of the product.

People

· Most important element of a successful project

Product

· The software to be built

Process

· The set of framework activities and software engineering tasks to get the job done

Project

· All work required to make the product a reality

People

People factor is so important that the Software Engineering Institute (SEI) has developed a People Management Capability Maturity Model (PM-CMM) to enhance the willingness or readiness of software organizations to undertake or take on increasingly complex software 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 areas for software people:

Recruiting, training, selection, performance, management, career development, compensation (repay, return), organization and work design and team/culture development.

Product

Before a project can be planned:

· Product objectives and scope should be established

· Alternative solutions should be considered

· Technical and management constraints (limitations) should be identified

i.e. estimates of cost, effective assessment (evaluation) of risk, realistic breakdown of project tasks, or manageable project schedule.

Process

A software process provides the framework for which a comprehensive plan for software development can be established

• Task sets – task, milestones, work products, and quality assurance points
• Umbrella activities – software quality assurance, software configuration management, and measurement

Project

Reasons for doing a software project

• To manage complexity
• To avoid failure

To develop a common sense approach for planning, monitoring, and controlling the project

People

• The Players
• Team Leaders
• The Software Team
• Coordination and Communication Issues

The Players

Five categories:

· Senior Managers: defines business issues that often have significant influence on the project

· Project (technical) managers: plan, motivate, organize and control the practitioners

· Practitioners: deliver the technical skills that are necessary to engineer, a product or application

· Customers: specify the requirements for the software to be engineered or made

· End-Users: interact with the software once it is released for production use

Team Leaders

Project management is a people-intensive activity and for this reason, competent practitioners often make poor team leaders.

· MOI model for leadership:

o Motivation: ability to encourage technical people to produce to their best ability

o Organization: ability to mold existing processes (or inventing new ones) will enable the initial concept to be translated into a final product

o Ideas for innovation (originality): ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

Software Team

The following options are available for applying human resources to a project that will require n people working for k years:

· n individuals are assigned to m different functional tasks. Coordination is the responsibility of a software manager who has six other projects to be concerned with.

· n individuals are assigned to m different functional tasks so that informal teams are established. An adhoc team leader may be appointed; coordination is the responsibility of a software manager.

· n individuals are organized into t teams; each team is assigned one or more functional tasks; each team has a specific structure that is defined for all teams working on a project.

Mantei suggests three generic (broad) team organizations:

· Democratic decentralized (DD): no permanent leader, rather than task coordinator are appointed for short duration. Decisions on problems and approach are made by group consensus (cooperation).

· Controlled decentralization (CD): this software engineering team has defined leader who coordinates specific tasks and secondary leaders that have responsibility for subtask. Problem solving is a group activity, but implementation of solutions is partitioned among subgroups by the team leader.

· Controlled Centralized (CC): Top-level problem solving and internal team coordination are managed by a team leader.

Mantei describes seven project factors that should be considered when planning the structure of software engineering teams.

· The difficulty of the problem to be solved

· The size of the resultant program(s) in lines of code or function points

· The time that the team will stay together (team lifetime)

· The degree to which the problem can be modularized

· The required quality and reliability of the system to be built

· The rigidity of the delivery date

· The degree of sociability or friendliness (communication) required for the project

Coordination and Communication Issues

There are many reasons that software projects get into trouble

Scalability: The scale (extent, range) of many development efforts is large, leading to complexity, confusion and significant (important) difficulties in coordinating team members

Uncertainty: Uncertainty is common, resulting in a continuing stream of changes that ratchets (group) the project team.

Interoperability: Interoperability has become a key characteristic of many systems. New software must communicate with existing software and conform to predefined constraint imposed by system or product.

Kraul and Streeter examine a collection of project coordination techniques that are categorized in the following manner.

Formal, impersonal approaches

Include software engineering documents including project milestones, schedules and project control tools, change requests and related documentation, error tracking reports etc.

Formal, interpersonal procedures

Focus on quality assurance activities applied to software engineering work products. These include status review meeting and design and code inspections.

Informal, interpersonal procedures

Include group meetings for information distribution and problem solving

Electronic communication

Encompasses electronic mail, electronic bulletin boards and video conferencing systems.

Interpersonal networking

Includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members.

Critical Practices

The Airlie Council (a team of software engineering experts chartered by U.S Department of Defense to help to develop guidelines for best practices in software project management and software engineering).

Formal risk management

· What are the top or main risks for the project?

· For each of the risks what is the chance that risk will become a problem and

· What is the impact if it does?

Empirical cost and schedule estimation

· What is the current estimation size of the application software that will be delivered into operation (excluding system software) i.e. what is the development cost estimation.

· How was it derived and can be derived?

Metric-based project management

· Do you have in place a metric program to give an early indication of evolving problems? If so, what is the current requirement instability concerning to problems?

Earned value tracking

· Do you report monthly earned value metrics? If so are these metrics computed from an activity network tasks for the entire effort to the next delivery?

Defect tracking against quality targets

· Do you track and periodically report the number of defects found by inspection (formal technical review) and execution test from the start of program and the number of defects currently closed and open?

People-aware program management

· What is the average staff proceeding for the past three months for each of the developers involved in the development of software for this system?