SE423 // SUMMARY TABLES
SE423 · Software Project Management · Shoug Alomran

Summary tables, chapter by chapter

Every comparison from Chapters 1–3 with the keywords to spot, the traps, and a worked example. Violet is Chapter 1 (with its part, 1, 1.2 or 1.3, on each table), orange is Chapter 2, pink is Chapter 3. Tables marked Key table are the ones you starred.

Show
CHAPTER 1Introduction, Performance Domains & Tailoring37 tables
  1. Foundations 17
  2. Stakeholders & Team 1.22
  3. Development Approaches 1.22
  4. Planning 1.25
  5. Project Work 1.23
  6. Delivery & Quality 1.22
  7. Measurement 1.24
  8. Uncertainty & Risk 1.24
  9. Tailoring 1.33
  10. Models, Methods & Artifacts 1.35
CHAPTER 2The Organizational Context12 tables
  1. Strategic Management & Organizational Strategy2
  2. Stakeholder Management1
  3. Organizational Structures4
  4. Project Management Offices (PMOs)2
  5. Organizational Culture1
  6. Exam Scenario Recognition2
CHAPTER 3Team29 tables
  1. Team Development, Skills & Influence3
  2. Team Development Stages & Objectives3
  3. Building Trust, Managing Conflict & Commitment4
  4. Responsibility Assignment & Resource Planning4
  5. Team Organization & Team Models8
  6. People, Motivation & Group Composition5
  7. Group Cohesiveness & Communication2
CHAPTER 1

Introduction, Performance Domains & Tailoring

37 tables · 10 key

Foundations

Part 1 · Introduction

CH 1Project vs Program vs Portfolio vs Product vs Operations

What it is Key words to spot Time frame Example
Project A temporary endeavor to create a unique product, service, or result "temporary", "unique" Has a start and an end Building a mobile banking app
Program Related projects managed together to get benefits not available individually "related", "coordinated", "benefits" Longer; ends when benefits are delivered A "Digital Bank" program: mobile app + website + new ATM system
Portfolio Projects, programs, and operations grouped to achieve strategic objectives (they can be unrelated) "strategic objectives", "managed as a group" Ongoing All of a bank's IT initiatives for 2027
Product An artifact that is produced, is quantifiable, and is an end item or a component "quantifiable", "artifact" Has its own life cycle The banking app itself
Operations Ongoing business functions that support projects "payroll", "supply chain", "maintenance" Continuous The support team that runs the app after launch

CH 1The value chain

Step Meaning Example (banking app)
1. Deliverable The verifiable thing produced The working app
2. Outcome The end result of using it Customers bank from their phones
3. Benefit The gain the organization realizes Fewer branch visits, lower costs
4. Value Worth, importance, or usefulness Higher profit and customer loyalty

CH 1Types of value

Type Measured by Example
Customer Being able to use specific features "I can transfer money in 10 seconds"
Business Benefits − cost (financial) App saved SR 5M, cost SR 2M → SR 3M value
Societal Contribution to communities or the environment Paperless statements reduce waste

CH 1Internal vs external environment

Comes from Items on the slides Trap Example
Internal Inside the organization Process assets, governance docs, data assets, knowledge assets, security & safety, infrastructure, IT software, resource availability, employee capability Data assets = internal Lessons learned from the company's last app project
External Outside the organization Marketplace, social & cultural, regulatory, commercial databases, academic research, industry standards, financial, physical Commercial databases = external New SAMA banking regulations

CH 1Information flow in the value delivery system

Direction From → To What flows
↓ Down Leadership → Portfolios Strategic information
↓ Down Portfolios → Programs/Projects Desired outcomes, benefits, value
↓ Down Programs/Projects → Operations Deliverables + support/maintenance info
↑ Up Operations → Programs/Projects Adjustments, fixes, updates
↑ Up Programs/Projects → Portfolios Performance and progress
↑ Up Portfolios → Leadership Portfolio performance evaluations

CH 1Principles vs DomainsKey table

12 Principles 8 Performance Domains
What they are Guides for behavior Groups of related activities
Prescriptive? No, they guide No, they're areas of focus
How they relate Internally consistent (no contradictions) but can overlap Interactive, interrelated, interdependent, and run concurrently
Sounds like… An attitude ("be a steward", "focus on value") A phase of work ("planning", "delivery")
In both lists Stakeholders, Team Stakeholders, Team
Only here Stewardship, Value, Systems thinking, Leadership, Tailoring, Quality, Complexity, Risk, Adaptability & resiliency, Change Development approach & life cycle, Planning, Project work, Delivery, Measurement, Uncertainty
Memory hook Each statement contains its own name ("Navigate complexity") "Stakeholders & Team pick a Development approach, Plan, do Project work, Deliver, Measure, under Uncertainty"

CH 1Code of ethics vs principles

Principles Code of ethics
Related to morals? Can be, but not necessarily Yes
Contents 12 principles 4 values: Responsibility, Respect, Fairness, Honesty (RRFH)
Example "Tailor based on context" Not hiding a budget overrun from the sponsor (Honesty)

Stakeholders & Team

Part 1.2 · Performance Domains

CH 1.2Management vs leadership

Management Leadership
Focus The means of meeting objectives People
Activities Processes, planning, coordinating, measuring, monitoring Influencing, motivating, listening, enabling
Who does it Can be centralized or distributed All team members
Example Building the sprint schedule and tracking progress Motivating a discouraged developer after a failed release

CH 1.2Centralized vs distributed

Centralized Distributed
Who manages One person (the PM) Shared, or the team self-organizes
Accountability Assigned to one individual Shared
Authorizing document Project charter Not required
Coordinator role Designated PM Facilitator, and the role can shift
Example A government IT project with an appointed PM A Scrum team where a different member facilitates each sprint

Development Approaches

Part 1.2 · Performance Domains

CH 1.2Predictive vs adaptive vs hybridKey table

Predictive (Waterfall) Adaptive (Agile) Hybrid
Requirements Known and stable upfront Uncertain and volatile Some uncertainty or risk
Planning Mostly upfront Vision upfront, details per iteration Mixed
Delivery Usually one at the end Every 1–2 week iteration, with a demo Varies by module
Stakeholder involvement Mostly at the start and at gates Heavy, continuous (product owner) Mixed
Also used when (watch out) Big investment + high risk that needs reviews and change control Funding is uncertain (MVP) or early delivery is needed Deliverables can be modularized or built by different teams
Example A payroll system with fixed legal rules A startup's new social app Data center: predictive building + iterative computing

CH 1.2Delivery cadence

Type Meaning Example
Single One delivery at the end A new office building
Multiple Several deliveries during the project A website launched page by page
Periodic Deliveries on a fixed schedule Quarterly app releases
Continuous Increments delivered immediately, with small batches + automation (DevOps) Netflix pushing updates many times a day

Planning

Part 1.2 · Performance Domains

CH 1.2Accuracy vs precisionKey table

Accuracy Precision
Means Correctness: close to reality Exactness: level of detail and consistency
Question to ask "Was it right?" "Was it detailed?"
Darts picture Hits the bullseye Darts tightly grouped (anywhere)
Example Estimated SR 100K, actual SR 102K A line-by-line breakdown of every license
Trap Precise but not accurate: detailed, but the cost doubled

CH 1.2Product scope vs project scope

Product scope Project scope
Defines Features and functions Work performed to deliver them
Question "What is it?" "What do we do?"
Example "App has login, transfers, bill payment" "Design, code, test, and deploy those features"

CH 1.2Predictive vs adaptive planning

Predictive Adaptive
Scope breakdown Scope statement / WBS Themes/epics → features → user stories
Scheduling 5 steps: Decompose → Sequence → Estimate → Allocate → Adjust Release plan → iterations (2+ per release) → timeboxes
Future work Planned in detail Kept high-level
End of cycle Phase gate Demo, then reprioritize the backlog

CH 1.2The 4 dependency typesKey table

Type Key words Can be changed? Example
Mandatory "contract", "nature of the work" ✗ Usually not You can't test code before it's written
Discretionary "best practice", "preference" ✓ May be Finishing UI design before coding the frontend
External "non-project activity", outside party ✗ Usually not Waiting for a government regulator's approval
Internal "between project activities" ✓ May be Backend API must exist before the frontend connects to it

CH 1.2Contingency vs management reserve

Contingency reserve Management reserve
For Identified risks ("known unknowns") Unknown events, unplanned in-scope work ("unknown unknowns")
Controlled by Project manager Upper management / sponsor / PMO
Part of Cost baseline Total budget (on top of the baseline)
Memory C = Clear risks, PM Controls M = Mystery risks, Management controls
Example SR 20K set aside in case the payment API vendor raises prices SR 50K for a surprise no one predicted

Project Work

Part 1.2 · Performance Domains

CH 1.2Explicit vs tacit knowledgeKey table

Explicit Tacit
Can it be written down? ✓ Yes (words, numbers, pictures) ✗ Hard to articulate
Made of Documents, manuals, diagrams Beliefs, experience, insights
Memory Explicit = expressed Tacit = silent
Example The API documentation A senior developer's gut feeling about where bugs hide

CH 1.2RFI vs RFP vs RFQ

RFI RFP RFQ
Stands for Request for Information Request for Proposal Request for Quote
You know… Very little What you need Exact specs
You want… To learn what's out there Vendors to propose how The price + delivery time
Order 1st 2nd 3rd
Example "What platforms exist for e-learning?" "Bid to build our e-learning platform" "Price for 500 laptops, i7, 16GB"

Delivery & Quality

Part 1.2 · Performance Domains

CH 1.2Cost of Quality (PAF)

Type When What it is Example
Prevention Before defects Stopping nonconformance Training developers in secure coding
Appraisal (تقييم) Checking for defects Assessing conformance Testing, code reviews, inspections
Failure After defects get through Cost of not meeting requirements Fixing bugs after release, refunds

CH 1.2Scope vs quality vs DoD

Scope Quality Definition of Done
Answers What to deliver How well it must perform When it's ready for the customer
Form Requirements Performance levels A checklist
Example "App has a login page" "Login completes in under 2 sec" ✓ Coded ✓ Tested ✓ Reviewed ✓ Documented

Measurement

Part 1.2 · Performance Domains

CH 1.2Metric vs baseline vs dashboard

Metric Baseline Dashboard
What An attribute + how to measure it The approved version, used for comparison Charts showing progress against measures
Example "Work progress %" "Approved cost: SR 500K" A Jira/Power BI screen with charts

CH 1.2Leading vs lagging indicatorsKey table

Leading Lagging
Looks Ahead (proactive) Back (reactive)
Tells you What might happen What already happened
Slide examples Rate of scope change requests, team workload balance Cost variance, deliverables completed, customer satisfaction
Extra example Number of open blockers this week Defects found after release

CH 1.2The 7 metric categoriesKey table

Category About… Examples
Deliverable The product's quality Errors/defects, technical performance
Delivery Flow of work WIP, lead time (need → delivery), cycle time
Baseline performance Plan vs actual Start/finish dates, schedule variance
Resources People and materials used Planned vs actual utilization or cost
Business value Money returned Cost-benefit ratio, ROI, NPV
Stakeholders People's feelings NPS, mood chart, morale, turnover
Forecasts The future ETC, EAC, VAC

CH 1.2Ways to present information

Dashboard Information radiator Visual controls
What Charts against key measures A large, visible display for everyone Task boards, burn charts, other charts
Example A Power BI report A big screen on the office wall A Kanban board, a sprint burndown chart

Uncertainty & Risk

Part 1.2 · Performance Domains

CH 1.2The 5 uncertainty terms

Term Core idea Example
Uncertainty Not knowing (the umbrella term) "We don't know how users will react"
Ambiguity Unclear, or multiple options "Which of 3 architectures should we choose?"
Complexity Many interconnected parts that behave unpredictably Integrating 15 government systems
Volatility Rapid, unpredictable change → hits cost and schedule Cloud prices change weekly
Risk An uncertain event with a + or − effect "The vendor might deliver late"

CH 1.2Conceptual vs situational ambiguity

Conceptual Situational
Problem Words or meaning are unclear Multiple outcomes or options
Example "Schedule was reported on track last week" Three possible architectures, unclear which is best

CH 1.2Complexity approaches vs volatility responsesKey table

Bucket Changes… Methods Example
Systems-based The system Decoupling, Simulation Split a monolith into microservices; study malls to plan airport shops
Reframing Your view Diversity (brainstorm, Delphi), Balance (mix data types) Workshop with people from 5 departments
Process-based How you work Iterate, Engage, Fail safe Redundant servers for the payment component
Volatility (not complexity!) Money and options Alternatives analysis, Reserve Outsource when developers leave; extra budget for steel price swings

CH 1.2Threat vs opportunity strategiesKey table

Threat (−) Opportunity (+) Shared idea Threat example Opportunity example
Avoid Exploit Guarantee (100%) Remove the risky library entirely Assign top devs to make sure you get the early bonus
Mitigate Enhance Change the odds Add tests to reduce bug risk Add testers to increase the chance of finishing early
Transfer Share Third party Buy insurance Partner with another firm to win a big contract
Escalate Escalate Beyond the PM's authority Send a legal risk to senior management Send a company-wide opportunity to the PMO
Accept Accept Acknowledge, no action Accept minor UI delays Take savings if they happen, without chasing them

The slides list the strategy names; the meanings are the standard PMBOK definitions.

Tailoring

Part 1.3 · Tailoring, Models, Methods & Artifacts

CH 1.3What to tailor

Aspect What gets tailored Example
Life cycle & approach Phases, predictive/adaptive/hybrid Data center: predictive building + iterative IT
Processes Add, Modify, Remove, Blend, Align Remove weekly status reports and use the Jira dashboard instead
Engagement People, Empowerment, Integration Let the team choose its own sprint goals
Tools Software and equipment Use Trello instead of MS Project for a small team
Methods & artifacts Methods, documents, templates Use a 1-page charter instead of a 20-page one

CH 1.3What influences tailoringKey table

Group About… Factors Example
Product/deliverable The thing being built Compliance/criticality, type, industry market, technology, time frame, stability of requirements, security A medical device needs more rigor than a game
Project team The people Size, geography, org distribution, experience, access to customer A remote team across 3 countries needs more formal communication
Culture How the organization behaves Buy-in, trust, empowerment, org culture A hierarchical ministry vs a flat startup

CH 1.3The 4 tailoring steps

# Step Example
1 Select initial approach "We'll use Scrum"
2 Tailor for the organization "Our company requires monthly reports to the PMO"
3 Tailor for the project "This project has a regulator, so we add a compliance review"
4 Implement ongoing improvement Adjust after each retrospective

Models, Methods & Artifacts

Part 1.3 · Tailoring, Models, Methods & Artifacts

CH 1.3Model vs method vs artifact

Model Method Artifact
Definition A thinking strategy The means to achieve an outcome A template, document, output, or deliverable
Quick test A way of thinking Something you do Something you can open or hold
Example Tuckman Ladder Estimating, stand-up meetings Risk register, project charter

CH 1.3All models by category

Category Model Purpose Example
Leadership Situational Leadership® II Adapt style to each person's development level Direct a junior dev, delegate to a senior
Leadership OSCAR Coaching conversations, problem-solving A 1-on-1 coaching session
Communication Cross-cultural Communicating across cultures A Saudi-German team agreeing on meeting norms
Communication Channel effectiveness Clarity, speed, richness, recordability, accessibility, suitability Bad news delivered face-to-face, not by email
Communication Gulf of Execution/Evaluation Gap between a user's goal and the system, and between the system's response and the user's understanding Users can't find the "submit" button
Motivation Herzberg Hygiene vs motivators See the table below
Motivation Maslow Physiological → safety → belonging → esteem → self-actualization Job security (safety) before recognition (esteem)
Motivation Theory X / Y / Z Assumptions about workers X = needs control; Y = self-motivated
Change ADKAR® Individual change Helping one employee adopt a new system
Change Kotter 8 steps Organizational change, starting with urgency Company-wide digital transformation
Change Virginia Satir Emotional response to change A dip in performance after a new tool launch
Change Transition model The psychological journey through change Staff grieving the old system
Complexity Cynefin Avoid rigid processes on unpredictable work Don't force waterfall on an R&D project
Complexity Stacey Matrix Choose Waterfall / Agile / Hybrid Picking an approach for a new project
Team Tuckman Forming → Storming → Norming → Performing → Adjourning A new team arguing in week 2 (storming)
Team Drexler/Sibbet O-T-G-C-I-H-R (7 stages) Commitment comes before Implementation
Stakeholders Salience Prioritize stakeholders Ranking the regulator above end users

CH 1.3Hygiene vs motivational factors (Herzberg)

Hygiene Motivational
Effect Missing → dissatisfied Present → motivated
Items Salary, benefits, working conditions, policies, job security Achievement, recognition, advancement, responsibility, the work itself, growth
Example A low salary makes people quit Public recognition makes people work harder

CH 1.3Intrinsic vs extrinsic motivation

Intrinsic Extrinsic
Source The work itself External rewards
Example Enjoying solving hard bugs Working for a bonus

CH 1.3Tuckman vs Drexler/Sibbet

Tuckman Ladder Drexler/Sibbet
Stages 5 7
Order Forming → Storming → Norming → Performing → Adjourning Orientation → Trust → Goals → Commitment → Implementation → High performance → Renewal
Memory "Form, Storm, Norm, Perform, Adjourn" "Our Team Gets Coffee In Huge Rounds"

The slides give Tuckman's purpose; the 5 stage names are the standard ones.

CHAPTER 2

The Organizational Context

12 tables

Strategic Management & Organizational Strategy

CH 2Strategic management, elements & TOWS matrix

Concept Explanation Example
Strategic Management Formulating, implementing, and evaluating cross-functional decisions to achieve organizational objectives. A university develops a strategy to become a leader in cybersecurity education.
Vision & Mission Establish what the organization wants to accomplish or become. A university aims to provide high-quality technology education.
Formulating, Implementing & Evaluating Develop strategies, put them into action, and evaluate results. Includes assessing strengths, weaknesses, opportunities, and threats. A university identifies demand for cybersecurity, launches a program, and evaluates enrollment.
Cross-functional Decisions Decisions involving multiple organizational departments. IT, Finance, and Academic Affairs collaborate on a university portal.
Achieving Objectives Ensuring activities and projects contribute to organizational goals. Developing an online learning platform to improve educational accessibility.
TOWS — SO (Maxi-Maxi) Use internal strengths to maximize external opportunities. A company uses its skilled developers to enter the growing AI market.
TOWS — ST (Maxi-Mini) Use strengths to minimize threats. A company uses its cybersecurity expertise to address increasing cyber threats.
TOWS — WO (Mini-Maxi) Minimize weaknesses by taking advantage of opportunities. A company trains employees in cloud computing to benefit from cloud adoption.
TOWS — WT (Mini-Mini) Minimize weaknesses and avoid threats. A company replaces outdated systems to reduce vulnerability to cyberattacks.

CH 2How projects reflect strategy

Organizational Strategy Project Explanation & Example
Technical or operating initiatives Construction or modernization Improve operations by upgrading factories or equipment.
Greater market penetration and acceptance New product development Develop a new product to attract customers and increase market share.
Streamlining and efficiency Reengineering Redesign an inefficient loan approval process to reduce time and costs.
Changing strategic direction or product portfolio New product lines A company enters the smartwatch market by introducing a new product category.
Creating strategic alliances Supplier/distributor negotiations Negotiate partnerships to reduce costs or improve product distribution.
Improving competitors' products Reverse engineering Examine a competitor's device to understand its functionality and develop an alternative.
Improving cross-organizational communication Enterprise IT Implement a system connecting suppliers, warehouses, and distributors.
Improving cross-functional coordination Concurrent engineering Design, development, and testing teams work simultaneously instead of sequentially.

Main connection: strategy defines what the organization wants to achieve; projects implement that strategy. The Airbus A380 case (slide 4) shows how strategic assumptions affect project selection: Airbus emphasized larger aircraft, while Boeing favored medium-sized wide-body aircraft.

Stakeholder Management

CH 2Stakeholder types, relationships & responsibilities

Stakeholder / Concept Explanation or Responsibility Example
Project Stakeholder An individual or group with an active stake in a project that can positively or negatively affect its development. Customers, employees, managers, or suppliers.
Stakeholder Analysis Identifies stakeholders and helps understand their interests, influence, and potential conflicts. Identifying that customers want faster delivery while Finance wants lower costs.
Internal Stakeholders Individuals or groups within the organization. Top management, accountants, functional managers, project team members.
Top Management Controls project managers and regulates their freedom of action. Management requires approval before increasing a project's budget.
Accountants Support and actively monitor project budgets. An accountant reviews project spending.
Functional Managers Provide employees temporarily assigned from functional departments. The IT manager assigns two developers to a project.
Project Team Performs the work required to complete the project. Developers, designers, and testers build a software system.
External Stakeholders Individuals or groups outside the organization. Clients, competitors, suppliers, intervenor groups.
Clients Want the project delivered quickly so their investment can generate returns. A company wants its e-commerce platform launched before a sales season.
Competitors Influence the external business environment. A competitor releases a similar product before the project's launch.
Suppliers Provide materials, equipment, or services. A cloud provider supplies hosting infrastructure.
Intervenor Groups External groups with the power to intervene in or disrupt projects. Environmental groups use legal action to delay construction.
Parent Organization Provides the organizational environment within which the project operates. A university establishes policies for its IT projects.

Main distinction: internal stakeholders belong to the organization; external stakeholders are outside it. Both can influence project success.

Organizational Structures

CH 2Organizational structure: elements & types

Concept Explanation Example
Organizational Structure Defines reporting relationships, employee groupings, and systems for coordination. A company organizes employees into IT, Finance, Marketing, and HR.
Formal Reporting Relationships Determines who reports to whom, hierarchy levels, and span of control. Developers report to a Development Manager, who reports to the CEO.
Departmental Groupings Organizes individuals into departments and departments into the overall organization. Developers belong to IT; accountants belong to Finance.
Communication & Coordination Systems Ensure departments communicate and integrate their efforts. IT and Finance coordinate the implementation of a payment system.
Functional Structure Groups employees performing similar activities into departments. All developers work in Development, regardless of the projects they support.
Project Structure Groups employees into dedicated project teams on temporary assignments. Developers, designers, and testers are assigned exclusively to Project Alpha.
Matrix Structure Creates a dual hierarchy combining functional and project authority. A developer reports to both a functional manager and a project manager.

CH 2All organizational structures: strengths, weaknesses & examples

Structure Strengths — explanation & example Weaknesses — explanation & example
Functional 1. No organizational disruption: existing departments can handle projects without restructuring. Example: IT develops an application using its current employees. 1. Functional siloing: departments resist collaboration. Example: Development ignores Marketing's input.
2. In-depth knowledge and intellectual capital: employees develop specialized expertise. Example: developers continuously improve their programming skills. 2. Lack of customer focus: departments prioritize internal goals over customer needs. Example: developers ignore usability complaints.
3. Standard career paths: clear advancement opportunities. Example: Junior Developer → Senior Developer → Development Manager. 3. Longer completion time: slow communication and structural problems delay projects. Example: waiting for another department's approval.
4. Varying commitment: departments prioritize projects differently. Example: IT considers a project urgent, while Marketing does not.
Project 1. Sole project manager authority: one manager controls project decisions. Example: the PM directly assigns tasks and priorities. 1. Expensive: dedicated teams require significant resources. Example: two projects each maintain separate testing teams.
2. Improved communication: dedicated team members communicate directly. Example: developers and testers work closely together. 2. Project loyalty over firm loyalty: employees identify more strongly with their project. Example: team members prioritize Project Alpha over organizational needs.
3. Effective decision-making: clear authority enables faster decisions. Example: the PM approves changes without multiple departmental approvals. 3. Difficulty maintaining intellectual capital: knowledge may leave with temporary staff. Example: contractors leave after completing the project.
4. Project management expertise: managing dedicated projects develops experienced PMs. Example: a manager becomes skilled after leading several projects. 4. Uncertain future: employees worry about what happens after the project. Example: a developer does not know whether another assignment is available.
5. Rapid market response: dedicated teams act quickly on opportunities. Example: launching a product before competitors.
Matrix 1. Dynamic environments: resources can be adjusted as needs change. Example: developers are reassigned between projects. 1. Two bosses: employees report through dual hierarchies. Example: a developer receives instructions from both the functional and project managers.
2. Equal emphasis on projects and functions: balances project objectives with functional efficiency. Example: developers support projects while keeping departmental expertise. 2. Resource negotiation: managers must negotiate resource sharing. Example: two projects request the same database specialist.
3. Cross-functional coordination: encourages departments to collaborate. Example: IT, Finance, and Marketing work together. 3. Competing demands: employees face conflicting project and departmental responsibilities. Example: a PM requests testing while a functional manager assigns maintenance work.
4. Maximizes scarce resources: specialists can support multiple projects. Example: one cybersecurity expert works across three projects.

CH 2Heavyweight project organization & Skunk Works

Characteristic Explanation Example
Heavyweight Project Organization A highly dedicated project organization with substantial independence. A company creates an autonomous team for a high-priority product.
Skunk Works Model Small, autonomous team of highly skilled, hand-picked individuals. Lockheed's Skunk Works model.
Expanded PM Authority The project manager receives extensive authority and responsibility. The PM can make major decisions without ordinary departmental approvals.
Reduced Functional Alignment The team focuses on market opportunities instead of traditional departmental boundaries. A team is formed specifically to respond to an emerging market need.
Direct Executive Reporting Project leadership reports directly to senior executives. The PM reports to the CEO.
External Customer Focus Customer needs and market opportunities guide the project. Developing a product to address urgent customer demand.

CH 2Quick organizational structure comparison

Feature Functional Project Matrix
Organized by Departments Projects Both
Authority Functional hierarchy Project manager Shared
Main advantage Specialization Project focus Resource efficiency
Main disadvantage Functional siloing High cost Dual authority
Employee responsibilities Departmental Project-specific Both
Resource arrangement Within departments Dedicated to projects Shared
Communication Can be slow across departments Improved within teams Requires cross-functional coordination
Example All developers belong to IT Developers work exclusively on Project Alpha Developers support multiple projects while belonging to IT

Slide 18 note: the survey suggests managers perceived more project-oriented structures as generally more effective for the project types studied. This is not a universal ranking for every organization.

Project Management Offices (PMOs)

CH 2PMO definition, responsibilities, levels, forms & models

Category Concept Explanation Example
Definition Project Management Office (PMO) Centralized unit that oversees or improves project management. A university establishes a PMO to support its technology projects.
Responsibilities Technical Support Provides technical project management assistance. Helping create project schedules.
Expertise Provides specialized project management knowledge. Advising project managers on planning techniques.
Repository Stores project information, templates, and resources. Maintaining project reports and lessons learned.
Center for Excellence Improves project management practices. Providing standardized methods and training.
Administrative Support Assists with scheduling, resource allocation, monitoring, and control. Preparing progress reports and tracking resources.
Levels Level 1 — Project Provides direct support to an individual project. A project office supports Project Alpha.
Level 2 — Business Unit Supports projects within a specific business unit. An IT PMO supports all IT department projects.
Level 3 — Corporate Provides organization-wide support. A corporate PMO supports IT, Finance, and Operations projects.
Forms — Control Supportive Low control: provides consultation, resources, and training. A PMO offers optional templates and training.
Controlling Moderate control: requires compliance with standards and procedures. All projects must use standardized reports.
Directive High control: directly manages projects. The PMO assigns PMs and manages project execution.
Models — Purpose Weather Station Monitors and tracks project status without directly controlling projects. Collecting cost, schedule, and progress reports.
Control Tower Improves project management methodology and helps PMs apply it. Establishing project management practices and guiding teams.
Resource Pool Maintains and supplies skilled project professionals. Assigning qualified PMs to projects.

CH 2Distinguishing PMO classifications

Classification Question it answers Categories
PMO Levels Where does the PMO operate? Level 1, Level 2, Level 3
PMO Forms How much control does it have? Supportive, Controlling, Directive
PMO Models What is its primary purpose? Weather Station, Control Tower, Resource Pool

These classifications are independent. A corporate-level PMO, for example, can operate as a supportive PMO.

Organizational Culture

CH 2Culture: definition, characteristics, factors & effects

Category Concept Explanation Example
Definition Organizational Culture Unwritten rules and norms that guide organizational behavior. Employees are expected to collaborate even without a written policy.
Characteristics Unwritten Cultural expectations are often not formally documented. Employees know they should help colleagues.
Rules of Behavior Norms guide how employees respond to situations. Employees report mistakes rather than hide them.
Shared by Members Norms may exist within certain groups or the entire organization. Development encourages experimentation while Finance emphasizes caution.
Taught to New Members New employees learn culture by observing existing employees. A new developer learns the team's communication practices.
Development Factors Technology Technology influences how employees work and interact. Collaboration tools encourage digital communication.
Environment External conditions influence organizational behavior. A competitive industry encourages rapid decisions.
Geographical Location Location influences workplace norms and practices. International offices may have different communication practices.
Reward Systems Rewards encourage specific behaviors. Bonuses for teamwork promote collaboration.
Rules & Procedures Formal policies influence behavior. Strict approvals encourage cautious decisions.
Key Organizational Members Influential people shape organizational values. A CEO encourages innovation and experimentation.
Critical Incidents Important events reveal the organization's actual culture. A major system failure shows whether employees are blamed or supported.
Effects on PM Departmental Interaction Cooperative cultures improve collaboration between departments and projects. IT and Marketing coordinate to complete a project.
Employee Commitment to Goals Culture influences employee dedication and willingness to contribute. Team members work extra hours to meet an important deadline.
Project Planning Culture affects estimation honesty and planning accuracy. In a trusting environment, developers provide realistic time estimates.
Performance Evaluation Culture influences how performance and risk-taking are judged. A risk-averse company rewards cautious decisions rather than experimentation.

Exam Scenario Recognition

CH 2Identify the concept from the scenario

Scenario / keyword Correct concept Explanation
A company chooses projects to support long-term objectives. Strategic Management Projects implement organizational strategy.
A manager identifies people who can affect the project. Stakeholder Analysis Identifies stakeholder interests and influence.
Environmental groups use legal action to delay construction. Intervenor Groups External groups can disrupt projects.
Employees are grouped by specialization. Functional Structure Departments are organized by similar activities.
Departments refuse to collaborate. Functional Siloing Cross-functional cooperation is weak.
A PM has sole authority over the project. Project Structure Project authority is concentrated in the PM.
A project is expensive because it uses dedicated employees. Project Structure Weakness Dedicated teams increase costs.
Employees report to two managers. Matrix Structure Dual reporting hierarchy.
Multiple projects share one specialist. Matrix Structure Strength Maximizes scarce resources.
A small autonomous team reports directly to executives. Heavyweight / Skunk Works High autonomy and authority.
A PMO provides optional training and advice. Supportive PMO Low control.
A PMO requires standardized reporting. Controlling PMO Moderate control.
A PMO directly manages projects. Directive PMO High control.
A PMO monitors project progress without controlling it. Weather Station Monitoring and tracking.
A PMO improves project management methods. Control Tower Methodology support.
A PMO assigns skilled professionals to projects. Resource Pool Supplies project professionals.
A PMO supports only one project. Level 1 PMO Project-level support.
A PMO supports one business unit. Level 2 PMO Business-unit support.
A PMO supports the entire company. Level 3 PMO Corporate-level support.
Employees follow unwritten workplace expectations. Organizational Culture Culture shapes behavior.
Employees exaggerate task estimates because lateness is punished. Culture Affecting Project Planning Culture can encourage inaccurate estimation.
Departments cooperate because teamwork is rewarded. Culture Affecting Departmental Interaction Cooperative culture supports project coordination.

CH 2Final concept connections

Related concepts How they connect
Strategy + Projects Strategy establishes goals; projects turn those goals into deliverables.
Stakeholders + Project Success Stakeholder interests and influence can support or disrupt project development.
Organizational Structure + Project Authority Structure determines reporting relationships, authority, and resource allocation.
Functional + Project + Matrix Three approaches to organizing employees and project work, each with different trade-offs.
Heavyweight Organizations + Project Structures Heavyweight organizations extend project autonomy and project manager authority.
PMO Levels + Forms + Models Describe organizational scope, control, and purpose respectively.
Organizational Culture + Project Management Culture influences cooperation, commitment, planning, and performance evaluation.
CHAPTER 3

Team

29 tables

Team Development, Skills & Influence

CH 3Team development and management responsibilities

Concept Explanation Example
Team Development Building the skills, relationships, cooperation, and commitment needed for a team to achieve project objectives. A project manager helps developers and testers communicate effectively and resolve disagreements.
Team Member Responsibilities Contribute technical skills, complete assigned work, cooperate, communicate, and support project objectives. A developer completes assigned features and helps teammates troubleshoot problems.
Project Manager Responsibilities Plan, organize, motivate, coordinate, and guide team members toward project success. A PM assigns responsibilities, manages conflicts, and monitors progress.
Team Development and Project Triangle Team performance influences schedule, cost, and scope delivery, including the quality of results. Poor communication creates rework, increasing costs and delaying delivery.
Individual Strength vs. Team Strength Individual expertise is important, but effective collaboration is necessary to turn individual contributions into successful project results. Five excellent programmers may perform poorly if they refuse to cooperate.
Knowledge and Resolve Steve McConnell identifies two general reasons software teams fail: insufficient knowledge or insufficient determination and commitment. A team understands the technology but lacks the discipline to finish the project.

CH 3Five types of influence

Type Explanation Example Recognition keyword
Formal / Legitimate Influence obtained from authority granted by an organizational position or hierarchy. A PM assigns tasks because they are officially responsible for managing the project. Position, title, authority
Reward Influence through the ability to offer incentives or benefits. A manager offers a bonus for completing a milestone early. Bonus, promotion, incentive
Penalty / Coercive Influence through the threat or use of punishment. A manager threatens disciplinary action if deadlines are repeatedly ignored. Threat, punishment
Expert Influence based on specialized knowledge, skills, or experience. A senior developer persuades the team to choose an architecture because of technical expertise. Knowledge, expertise
Referent Influence based on personal traits, charisma, admiration, or respect. Employees follow a leader because they admire and trust them. Respect, admiration, charisma

Important distinction: formal influence comes from someone's position, expert influence from what they know, and referent influence from how others perceive them.

CH 3Leadership styles

Style Explanation Example
Autocratic Leader makes decisions with limited team participation. During a critical outage, the PM assigns emergency actions immediately.
Democratic Leader involves team members in discussing and making decisions. Developers collectively evaluate which database technology to use.
Laissez-faire Leader provides considerable independence and limited direct supervision. Experienced developers decide how to organize their technical work.
Transactional Leader emphasizes agreed responsibilities, performance expectations, and rewards or consequences. Employees receive recognition for achieving specified milestones.
Servant Leader prioritizes supporting the team and removing obstacles. A PM secures resources and resolves administrative barriers so developers can work effectively.

The slides name these styles but do not define all five in detail; the explanations and examples here are supplementary.

Team Development Stages & Objectives

CH 3Tuckman's five stages of team development

Stage Explanation Team behavior Example
1. Forming Team members come together, get to know each other, and begin forming a group. Polite interactions, uncertainty, learning responsibilities. Students meet their software project teammates for the first time.
2. Storming Members compete for leadership, influence, or control, and test group processes. Disagreements, competition, confusion about authority. Two developers disagree about who should lead the technical work.
3. Norming The team reaches agreement about how it will operate. Established rules, accepted roles, improved cooperation. Members agree on coding standards, meetings, and task allocation.
4. Performing The group works effectively toward its objectives. Productivity, trust, coordination, and effective execution. Developers independently coordinate their tasks and deliver features successfully.
5. Dissolving / Adjourning The team completes its work and disbands. Project closure, transition, and separation. After delivering the system, members return to their departments.

CH 3Three types of team objectives

Objective Explanation Team traits Structure implication Example
Problem Resolution Solving complex, poorly defined problems, usually focusing on 1–3 specific issues. Urgency, pressure, rapid problem-solving. Flexible roles, rapid decisions, possibly a temporary task force. Fixing a showstopper defect that prevents a registration system from operating.
Creativity Generating new ideas, products, or approaches. Divergent thinking, experimentation, tolerance of ambiguity and iteration. Looser hierarchy, diverse skills, support for risk-taking and idea sharing. Designing a new AI-based learning application without knowing its final form.
Tactical Execution Carrying out a well-defined plan with clear tasks and responsibilities. Coordination, timelines, accountability. Hierarchical or matrix structure with tight controls and performance tracking. Developing, testing, and deploying a system according to approved requirements.

CH 3Team objective comparison

Feature Problem Resolution Creativity Tactical Execution
Main question How do we fix it? What can we create? How do we execute the plan?
Problem definition Complex or poorly defined Open-ended Well-defined
Priority Urgent solution Innovation Completion and control
Team behavior Fast, flexible response Exploration and experimentation Coordinated execution
Structure Temporary task force Looser hierarchy Hierarchical or matrix
Important concept Showstopper defect Divergent thinking Accountability
Example Fixing a critical database failure Inventing a new application Implementing approved features

Building Trust, Managing Conflict & Commitment

CH 3Building and maintaining trust

Principle Explanation Example
Trust is the foundation of teamwork Teams need trust to collaborate, share ideas, and resolve conflicts. A developer openly reports a mistake because they trust their teammates.
Vulnerability-based trust Members feel comfortable admitting mistakes, asking for help, and saying they do not know something. A junior developer admits they need assistance with database security.
Trust takes time Trust develops through consistent behavior, shared experiences, and fulfilled commitments. A PM repeatedly delivers on promises, gradually earning team confidence.
Trust must be maintained Trust can deteriorate if people become unreliable or dishonest. A PM communicates openly when a milestone cannot be met.
Behavioral profiling Tools such as Myers-Briggs can help members discuss strengths, weaknesses, and working preferences. A quiet teammate receives opportunities to contribute through written discussions.
Open communication Communication barriers create project risks and weaken trust. The PM shares schedule changes with the entire team.
Admit and correct mistakes Leaders should take responsibility and explain how they will avoid repeating errors. A PM acknowledges an incorrect estimate and revises the plan.
Lead by example Demonstrate expected behavior instead of relying only on authority. A PM follows the same deadlines and reporting rules as the team.
Fulfill commitments Complete promises on time or provide advance notice and an explanation. A developer warns the team early that an assigned task will be late.
Friendship vs. leadership Good relationships are valuable, but leaders still need boundaries and accountability. A PM addresses a friend's missed deadline professionally.

CH 3Healthy conflict vs. harmful conflict

Concept Explanation Example
Healthy Conflict Constructive, honest debate about issues, supported by trust. Developers challenge each other's architectural proposals using technical evidence.
Disagreement Different opinions that can still be discussed and resolved constructively. Two developers prefer different database technologies but remain open to discussion.
Conflict Positions become rigid and difficult to reconcile. Two developers refuse to cooperate because each insists their solution is the only acceptable one.
Conflict Norms Rules of engagement defining acceptable tone, language, timing, and emotional expression. The team agrees to criticize ideas rather than attack individuals.
Groupthink A group prioritizes harmony and agreement over critical evaluation. Everyone accepts a flawed design because nobody wants to disagree with the leader.
Suppressing Dissent Preventing or discouraging disagreement and criticism. A PM refuses to hear concerns about a risky release.
Neutrality Members outside the conflict should remain neutral even when they personally agree with one side. A team leader mediates without openly supporting either developer.
Conciliator A neutral person who helps conflicting parties communicate and resolve differences. A PM mediates a dispute between two developers.
Reconciliation Restoring cooperation between conflicting parties. Two developers agree on a technical evaluation process and resume working together.

CH 3Six conflict resolution techniques

Technique Explanation Example
Confronting / Problem Solving Address the root cause directly through open, honest discussion. Investigate why developers disagree about a database choice and evaluate technical requirements.
Compromising Reach a middle ground through mutual concessions. Two teams agree to divide a shared specialist's time between their projects.
Withdrawal / Avoidance Delay, sidestep, or temporarily avoid the conflict. A PM postpones a minor disagreement until after an urgent production issue is resolved.
Smoothing / Accommodating Preserve harmony by emphasizing agreement and downplaying differences. A PM reminds team members of their shared goal instead of focusing on a minor disagreement.
Collaborating Combine multiple perspectives to develop a creative solution. Developers combine useful features from two competing architecture proposals.
Forcing Impose a solution through authority or pressure. During a critical incident, the PM requires the team to follow a particular recovery plan.

Important distinction: compromising involves concessions, while collaborating seeks a solution that integrates different perspectives. Confronting focuses on addressing the underlying problem directly.

CH 3Achieving commitment, accountability & results

Concept Explanation Example
Clarity Everyone understands what was decided, why it matters, and what happens next. The PM confirms the selected database, responsible developer, and implementation deadline.
Buy-in Members support a decision even if they initially disagreed with it. A developer supports PostgreSQL after the team selects it, despite originally preferring MongoDB.
Consensus vs. Buy-in Buy-in does not require unanimous agreement; members can disagree and still commit. The team chooses one architecture, and all members support its implementation.
Peer Accountability Team members hold each other responsible instead of relying only on the PM. A tester reminds a developer about an agreed deadline.
Leader Accountability Leaders demonstrate transparency, fulfill commitments, and address underperformance. A PM discusses missed sprint commitments and improvement actions.
Focusing on Results Team outcomes take priority over individual or departmental interests. Developers prioritize delivering a reliable system rather than competing for personal recognition.
Visible Goals Desired results should be publicly clarified and kept visible. A project dashboard displays the team's milestones and delivery objectives.

Responsibility Assignment & Resource Planning

CH 3RACI / RASCI matrix

Role Explanation Example
R — Responsible Performs the work needed to complete a task. A developer implements the login feature.
A — Accountable Ultimately owns the task outcome and its completion. A technical lead is accountable for delivering the login feature.
S — Support Provides assistance to the responsible person. A database specialist helps implement authentication.
C — Consulted Provides input or expertise, generally through two-way communication. A cybersecurity specialist advises on authentication security.
I — Informed Receives updates about decisions or progress. The project sponsor receives a completion notification.

RACI contains Responsible, Accountable, Consulted, and Informed. RASCI adds Support.

CH 3Responsibility Assignment Matrix (RAM): illustrative RASCI

Activity Project Manager Developer Tester Security Specialist
Define requirements A R C C
Implement login A R I S
Test login A S R C
Security review A C S R
Approve release A R C C

A RAM is a resource planning tool identifying who does what. It supports both planning and tracking; its columns may be individuals, teams, or departments, and it can include totals such as the number of contributors per task.

CH 3Skills matrix (1 = beginner, 5 = expert)

Team Member Frontend Backend Database Security Testing
Developer A 5 3 2 2 3
Developer B 2 5 4 3 3
Security Specialist 1 3 3 5 4
QA Engineer 2 2 3 3 5

A skills matrix is another resource planning tool: resources on one axis and skills on the other. Cells may hold X marks, proficiency levels, or years of experience.

CH 3RAM vs. skills matrix

Comparison RAM / RACI Skills Matrix
Main question Who is responsible for what? Who has which skills?
Main purpose Responsibility and authority assignment Skills assessment and resource planning
Information Roles assigned to tasks Skills and proficiency of individuals
Example Developer A is responsible for login implementation Developer A has advanced frontend skills

Team Organization & Team Models

CH 3Team organization philosophies

Philosophy Explanation Example
Decentralized / Democratic Decision-making is distributed among members rather than concentrated in one person. Experienced developers collectively decide how to implement a feature.
Centralized / Autocratic A central leader makes major decisions and directs the team. A chief programmer determines the system architecture and assigns technical work.
Controlled Decentralized Combines centralized coordination with distributed technical participation. A technical lead coordinates the project while developers participate in technical decisions.

CH 3Business, democratic & agile teams

Model Explanation Characteristics Example
Business Team The most common general team model: a technical lead and team members of equal status beneath the lead. Hierarchical, one principal contact, adaptable; strong or loose hierarchy. A technical lead coordinates five developers building a business application.
Democratic Team Members act as a group and reach consensus on decisions affecting the system. Self-organizing; tasks allocated by ability and experience; works best with experienced, competent members. Senior developers discuss tasks together and decide who is best suited to each one.
Agile Programming Group A variation of democratic organization where some management decisions are delegated to group members. Shared responsibility, collaboration, self-management. An Agile team organizes its work and decides how to implement backlog items.
Extreme Programming (XP) An Agile approach in which programmers work in pairs and take collective responsibility for code. Pair programming and collective code responsibility. Two programmers work together on one feature and share responsibility for its quality.

CH 3Business team vs. democratic team

Feature Business Team Democratic Team
Leadership Technical lead Leader serves as external interface
Decisions Led or facilitated by technical lead Consensus among team members
Task allocation May be coordinated by lead Based on group discussion, ability, and experience
Hierarchy Strong or loose Relatively flat
Suitable environment General business and software projects Experienced and competent teams
Development May evolve toward democratic organization Self-organizing model

A Business Team may naturally evolve into a Democratic Team as members gain trust, experience, and shared working norms.

CH 3Chief-programmer / surgical team: roles

Role Explanation Example
Chief Programmer Highly skilled programmer responsible for the core technical development. A senior engineer designs and implements the most critical system components.
Backup Programmer / Co-pilot Equally capable programmer who can step in and often reviews or shadows the chief. A second senior engineer understands the core architecture and reviews major changes.
Program Clerk Maintains documentation, version control records, and technical information. Maintains documentation and development records.
Administrator Handles administrative responsibilities so technical staff can focus on development. Organizes meetings, schedules, and administrative paperwork.
Tool-smith Develops and maintains programming tools and development environments. Builds automated development tools.
Language Lawyer Expert in the programming language and its detailed rules. A C++ specialist helps resolve a difficult language-specific issue.

The chief-programmer team puts an exceptionally capable programmer at the center, supported by specialists.

CH 3Chief-programmer team: advantages, limitations & applications

Category Explanation Example
Main Advantage Makes effective use of an exceptionally talented programmer by providing specialist support. The chief focuses on complex coding while others handle supporting work.
Creative Projects May be appropriate when exceptional technical ability is valuable. Building an innovative software component.
Tactical Execution May also be appropriate for well-defined technical work. Implementing a critical subsystem under a strong technical leader.
Talent Scarcity Exceptional programmers and designers are difficult to find. The organization cannot find someone qualified to act as chief programmer.
Ego and Resentment Other members may resent the chief receiving recognition. Developers feel their contributions are overlooked.
High Project Risk Losing both chief and deputy creates a major single point of failure. Both senior programmers leave before the system is completed.
Organizational Compatibility Existing organizational grades and reporting structures may not support the model. Company policy prevents giving one programmer substantially more authority.

CH 3Skunk works vs. SWAT teams

Feature Skunk Works Team SWAT Team
Main Objective Creative exploration and innovation Rapid, critical intervention
Members Talented, creative developers Highly skilled specialists whose skills match the problem
Organization Separated from the parent organization, physically or operationally Specialized group, often with members who have worked together before
Main Strength Strong ownership and buy-in Rapid response with relevant expertise
Main Limitation Limited visibility into progress Depends on having the right specialized skills
Suitable Situation Exploratory projects with uncertain outcomes Urgent, critical problems
Example Independent team exploring a new AI product Security response team handling a serious vulnerability

The slides state that Skunk Works suits exploratory projects needing creativity, not narrow, well-defined problems.

CH 3Team size & communication complexity

Concept Explanation Example
Large Teams Communication complexity grows rapidly as team size increases. A team of 50 programmers has 1,225 possible pairwise communication paths.
Communication Formalization Large teams require structured communication and hierarchy. Separate team leads coordinate work between multiple development groups.
Optimal Team Size About 4–6 developers, with QA, operations, and design potentially added. One technical lead and four developers form the core development team.
Small Team Recommendation Groups should generally have fewer than 10 members; an optimal group is fewer than seven. A project is divided into several small teams rather than one group of 25.
Cohesiveness Smaller teams can encourage stronger identification and closer cooperation. Five developers communicate regularly and understand one another's work.
Breaking Down Large Projects Large projects should be divided into smaller projects or teams. A large platform is split into frontend, backend, and infrastructure teams.

CH 3Communication paths: n(n − 1) / 2

Team members (n) Possible communication paths
4 6
5 10
6 15
10 45
20 190
50 1,225

Key point: communication complexity grows roughly with the square of team size.

People, Motivation & Group Composition

CH 3People in the software process

Management responsibility Explanation Example
Problem Solving Using available people and their capabilities to solve project problems. Assigning an experienced database developer to resolve a performance issue.
Motivating Encouraging employees to contribute effectively. Recognizing the team's successful completion of a difficult milestone.
Planning Determining what employees will do. Dividing system development into assigned tasks.
Estimating Determining how quickly employees can complete work. Estimating the time required to implement authentication.
Controlling Monitoring and guiding employee activities toward objectives. Reviewing task progress and correcting schedule deviations.
Organizing Determining how employees work together. Dividing developers into smaller feature teams.

Main idea: people are an organization's most important assets, and effective management requires understanding human behavior.

CH 3Maslow's hierarchy of needs

Level Need Explanation Workplace example
1 Physiological Basic physical needs such as food, sleep, and rest. Reasonable working hours and breaks.
2 Safety Security, stability, and protection from harm. Safe working conditions and employment stability.
3 Social Belonging, acceptance, and positive relationships. Shared spaces, informal communication, and team interaction.
4 Esteem Recognition, respect, achievement, and self-worth. Recognizing achievements, promotions, or certificates.
5 Self-Realization / Self-Actualization Personal growth, learning, responsibility, and fulfilling potential. Training employees and allowing them to make meaningful decisions.

Lower-level needs generally need satisfying first. Social, esteem, and self-realization needs matter most to managers once basic needs are met; if lower needs stay unmet for long, attention shifts back to them.

CH 3Three personality / motivation types

Type Main motivation Explanation Example
Task-Oriented The work itself Enjoys performing technical tasks and solving problems. A programmer enjoys developing algorithms because the work is intellectually satisfying.
Self-Oriented Personal goals Views work as a means of achieving individual objectives. A developer works hard to gain recognition, earn a promotion, or increase income.
Interaction-Oriented Coworkers and relationships Motivated by interacting and cooperating with others. An engineer enjoys work because of the team environment.

CH 3Motivation types & group composition

Group composition Potential problem Explanation Example
All Task-Oriented Everyone wants to do their own thing. Members focus on their individual technical interests instead of coordinating. Every developer chooses their preferred feature without considering project priorities.
All Self-Oriented Everyone wants to be the boss. Members compete for leadership, authority, or recognition. Several developers argue over who should become technical lead.
All Interaction-Oriented Too much chatting and not enough work. Social interaction becomes more important than completing tasks. Meetings turn into long conversations with little progress.
Balanced Group Better balance of motivations Different types complement one another and support effective group performance. Task-oriented members do technical work, self-oriented members pursue achievement, interaction-oriented members support communication.

Achieving this balance can be difficult because many engineers are task-oriented.

CH 3Group leadership

Principle Explanation Example
Leadership Based on Respect Effective leadership depends on respect, not merely holding a title. Developers follow a technically competent colleague even without a management title.
Technical and Administrative Leadership A group may have separate leaders for technical and administrative matters. A technical lead oversees architecture while a PM manages scheduling and resources.
Democratic Leadership Democratic leadership is more effective than autocratic leadership in this group-working context. Experienced developers participate in important technical decisions.
Technical Career Paths Organizations should allow advancement based on technical competence. An engineer becomes a principal architect without needing to become a people manager.

Group Cohesiveness & Communication

CH 3Group cohesiveness

Concept Explanation Example
Group Cohesiveness Members identify with the team and prioritize collective success. Developers help one another complete shared project goals.
Group Quality Standards Cohesive groups can establish shared expectations for quality. All developers agree on coding and testing standards.
Reduced Inhibitions Working closely together helps members become comfortable sharing information and asking questions. A junior developer asks for a code review without embarrassment.
Mutual Learning Members understand one another's work and learn from each other. Backend developers learn testing practices from QA engineers.
Egoless Programming Members improve each other's code without treating criticism as a personal attack. A developer accepts improvements suggested during peer review.
Social Events Informal activities can strengthen relationships. A team outing helps members become familiar with one another.
Group Identity Shared identity encourages belonging. A team adopts a shared project identity and workspace.
Team-Building Activities Activities designed to strengthen cooperation and trust. A team completes a collaborative problem-solving exercise.
Information Openness Sharing information helps everyone feel included. All members have access to project updates and decisions.
Groupthink Excessive group loyalty causes members to preserve agreement at the expense of technical or organizational considerations. Developers accept a poor design because nobody wants to challenge the group.
External Involvement Outside perspectives help prevent groupthink. An independent architect reviews the team's proposed design.

A cohesive group is one in which members consider the group more important than any individual member.

CH 3Group communication

Factor Explanation Example
Work Status Communication Members need information about progress and outstanding activities. Developers report completed and blocked tasks during stand-ups.
Design Decisions Technical decisions must be communicated to affected members. The backend team informs frontend developers about API changes.
Changes to Previous Decisions Teams must communicate revisions to earlier agreements. A change in authentication design is shared with developers and testers.
Member Status Higher-status members may dominate discussions. A senior engineer speaks so frequently that junior developers hesitate to contribute.
Personality Composition Too many members with similar personalities can affect communication. A group of highly independent developers struggles to coordinate.
Communication Channels Routing all communication through one central coordinator can be ineffective. Every developer must wait for one coordinator to pass on information, so updates arrive late.

SE423 · Summary tables by Shoug Alomran · Chapters 1–3