Chapter 7: Project Management Concepts in Software Engineering

People

the 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

Stakeholders

Senior managers who define the business issues that often have significant influence on the project.

Project Managers

who must plan, motivate, organize, and control the practitioners who do software work.

Practitioners

who deliver the technical skills that are necessary to engineer a product or application.

Customers

who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome.

End-users

who interact with the software once it is released for production use.

Team Leader

The MOI Model

Motivation

The ability to encourage (by "push or pull") technical people to produce to their best ability.

Organization

The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.

Ideas or innovation

The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

Team Structure Factors

the difficulty of the problem to be solved

Team Structure Factors

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

Team Structure Factors

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

Team Structure Factors

the degree to which the problem can be modularized

Team Structure Factors

the required quality and reliability of the system to be built

Team Structure Factors

the rigidity of the delivery date

Team Structure Factors

the degree of sociability (communication) required for the project

Organizational Paradigms

closed paradigm—structures a team along a traditional hierarchy of authority

Organizational Paradigms

random paradigm—structures a team loosely and depends on individual initiative of the team members

Organizational Paradigms

open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm

Organizational Paradigms

synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves

Team Toxicity

A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed.

Team Toxicity

High frustration caused by personal, business, or technological factors that cause friction among team members.

Team Toxicity

"Fragmented or poorly coordinated procedures" or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment.

Team Toxicity

Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing.

Team Toxicity

"Continuous and repeated exposure to failure" that leads to a loss of confidence and a lowering of morale.

Agile Teams

Team members must have trust in one another.

Agile Teams

The distribution of skills must be appropriate to the problem.

Agile Teams

Mavericks may have to be excluded from the team, if team cohesiveness is to be maintained.

Self-organizing team

A team structure that adapts and organizes itself without external direction.

Adaptive team structure

A flexible arrangement of team roles and responsibilities that can change based on project needs.

Constantine's paradigms

Elements of random, open, and synchronous paradigms used in team organization.

Team autonomy

The significant independence of a team to make decisions and manage its own work.

Formal impersonal approaches

Methods that include software engineering documents, technical memos, and project control tools.

Quality assurance activities

Procedures applied to software engineering work products to ensure quality, such as status review meetings.

Informal interpersonal procedures

Methods like group meetings for information sharing and problem solving among team members.

Electronic communication

Methods of communication that include email, bulletin boards, and video conferencing.

Interpersonal networking

Informal discussions with team members and external contacts for insights and assistance.

Product scope

The boundaries and deliverables of a software project, including context, objectives, and performance.

Problem decomposition

The process of breaking down a problem into smaller, manageable components.

Task set

A defined collection of software engineering tasks, work products, quality assurance points, and milestones.

Project trouble indicators

Signs that a project may fail, such as poor customer understanding and unrealistic deadlines.

Common-sense approach to projects

A strategy that emphasizes understanding the problem, maintaining momentum, and tracking progress.

Postmortem analysis

A review conducted after project completion to extract lessons learned.

Project essence questions

Key questions to clarify project purpose, tasks, timelines, responsibilities, and resource needs.

Formal risk management

A systematic approach to identifying, assessing, and mitigating risks in a project.

Empirical cost estimation

Estimating project costs based on historical data and actual performance metrics.

Metrics-based project management

Managing projects using quantitative measures to assess progress and performance.

Earned value tracking

A method to measure project performance by comparing planned progress with actual progress.

Defect tracking

Monitoring and managing defects in a project against established quality targets.

People aware project management

An approach that considers the human factors and team dynamics in project management.