Teams, Leadership, Communication, and Stakeholders

Introduction

Software projects are performed by people before they are performed by processes and tools. A technically sound plan can fail when responsibilities are unclear, information is withheld, decisions are delayed, or stakeholders lose confidence. Conversely, a team with clear accountability, constructive leadership, effective communication, and disciplined stakeholder engagement can respond to uncertainty and deliver valuable outcomes even when requirements change.

Software project management therefore includes more than scheduling tasks and controlling budgets. It involves designing an effective team system: deciding how work is organized, establishing authority and accountability, developing trust, resolving conflict, communicating information, facilitating decisions, and maintaining productive relationships with customers, users, sponsors, suppliers, regulators, and other affected groups.

This chapter presents practical foundations for organizing and leading software teams. It applies to predictive, agile, hybrid, co-located, and distributed projects.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain how team structure, role clarity, and accountability affect software project performance.
2. Distinguish leadership from management and apply appropriate leadership behaviours.
3. Support motivation, psychological safety, collaboration, and professional development.
4. Recognize and manage task, process, and interpersonal conflict.
5. Design communication and meeting practices for different audiences.
6. Identify, analyse, and engage software project stakeholders.
7. Adapt leadership and communication practices to cross-functional and distributed teams.
8. Evaluate ethical, governance, and contemporary technology issues in team and stakeholder management.

1. The Software Team as a Socio-Technical System

A software team is a socio-technical system: people, organizational arrangements, technical practices, tools, and external relationships interact to produce an outcome. Team performance cannot be explained solely by individual technical ability. A group of highly skilled specialists may still perform poorly if integration responsibilities are absent, decision rights are ambiguous, or communication is fragmented.

Important characteristics of software work include:

• Knowledge intensity: Much of the work depends on expertise that is difficult to specify in advance.
• Interdependence: Requirements, design, coding, testing, deployment, security, and operations influence one another.
• Uncertainty: Requirements, technologies, estimates, and risks may change during delivery.
• Creativity: Teams must interpret problems and create solutions rather than merely follow repetitive instructions.
• Visibility of quality: Defects and misunderstandings often appear late unless collaboration and feedback are continuous.

These characteristics favour structures that make dependencies visible, shorten feedback cycles, and allow responsible people to make timely decisions.

Team structures

A software project may use a functional, matrix, projectized, or product-oriented structure.

No structure is universally superior. The appropriate choice depends on project size, risk, organizational maturity, regulatory demands, and the stability of the product or service.

2. Roles, Responsibility, and Accountability

A role describes expected contributions and authority. A responsibility is an obligation to perform work or make a decision. Accountability is answerability for the result. These concepts are related but not identical. A developer may be responsible for implementing a feature, while a product owner is accountable for prioritizing its business value. A project manager may coordinate delivery without personally performing every technical task.

Useful role categories include:

• Sponsor: Provides strategic support, resources, escalation authority, and high-level decisions.
• Project manager: Integrates scope, schedule, cost, risk, communication, and stakeholder expectations.
• Product owner or business representative: Clarifies value, priorities, acceptance conditions, and user needs.
• Technical lead or architect: Guides technical direction, quality attributes, and major design decisions.
• Developers: Design, build, review, integrate, and maintain software.
• Test and quality specialists: Design verification activities and provide evidence about product quality.
• User-experience specialists: Investigate user needs and shape usable, accessible interactions.
• Security, data, operations, and compliance specialists: Address non-functional, operational, legal, and governance requirements.
• Users and customer representatives: Provide domain knowledge, feedback, validation, and acceptance.

Responsibility assignment

A responsibility assignment matrix can clarify who performs, approves, contributes to, and receives information about each major deliverable. One common version uses four categories:

• R — Responsible: Performs the work.
• A — Accountable: Owns the result and approves completion.
• C — Consulted: Provides input before a decision or activity.
• I — Informed: Receives relevant information after or during the activity.

A practical matrix should avoid assigning several people as ultimately accountable for the same decision unless the governance arrangement explicitly requires joint accountability. It should also avoid making every stakeholder “consulted,” because excessive consultation slows decisions and obscures ownership.

For example, for a security design review, the security specialist may be Responsible, the technical lead Accountable, the compliance officer Consulted, and the sponsor Informed. The exact assignment depends on organizational authority and contractual obligations.

The cost of unclear roles

Role ambiguity commonly produces duplicated work, neglected work, approval delays, blame, and inconsistent decisions. A project manager should review role assignments when the project enters a new phase, when membership changes, or when a significant decision repeatedly stalls. Role descriptions should include authority boundaries, expected outputs, dependencies, escalation routes, and decision time limits.

3. Leadership and Management

Management coordinates resources and processes to achieve agreed objectives. Leadership influences people toward a shared purpose, especially when the path is uncertain. A project manager requires both. Planning without influence may produce a technically complete plan that nobody follows; inspiration without control may create enthusiasm without reliable delivery.

Situational leadership

Effective leadership is contingent on circumstances. A new team facing a safety-critical deadline may require clear direction, explicit standards, and frequent review. An experienced team solving an uncertain design problem may perform better when the leader establishes constraints and outcomes but allows the team to choose the method.

Leadership behaviour should vary according to:

• team competence and confidence;
• urgency and consequence of failure;
• complexity and uncertainty;
• degree of stakeholder alignment;
• maturity of the organization and delivery process.

This does not mean changing values opportunistically. Respect, honesty, fairness, and accountability should remain stable while the level of direction, participation, coaching, and delegation changes.

Servant and enabling leadership

In agile and knowledge-intensive environments, leaders often improve performance by removing obstacles, protecting focus, developing capability, clarifying purpose, and improving the system in which people work. This is sometimes described as servant or enabling leadership. It does not mean avoiding difficult decisions. An enabling leader can challenge poor quality, stop unsafe work, resolve resource conflicts, and make unpopular decisions while preserving dignity and transparency.

Trust and psychological safety

Trust develops when commitments are credible, information is shared, mistakes are treated as learning opportunities rather than concealed liabilities, and people experience fair treatment. Psychological safety means that team members can raise concerns, ask questions, admit uncertainty, and report defects without fear of humiliation or retaliation. Psychological safety is not the absence of standards; it enables earlier discovery of problems and more honest discussion of standards.

Leaders build trust by:

1. making commitments carefully and keeping them;
2. explaining decisions and constraints;
3. admitting errors promptly;
4. distinguishing a failed experiment from negligent behaviour;
5. inviting dissent before major decisions;
6. applying rules consistently;
7. recognizing contributions specifically and fairly.

4. Motivation, Collaboration, and Performance

Motivation is influenced by both intrinsic and extrinsic factors. Software professionals often value mastery, autonomy, purpose, recognition, meaningful challenge, and the opportunity to produce quality work. Salary, promotion, job security, and benefits also matter, but rewards cannot compensate indefinitely for chaotic priorities, disrespect, impossible workloads, or poor engineering practices.

A project manager can support motivation by:

• connecting tasks to user and organizational value;
• providing achievable but demanding goals;
• enabling appropriate autonomy;
• removing avoidable impediments;
• giving timely, specific feedback;
• making learning and mentoring possible;
• recognizing collaborative as well as individual achievement;
• protecting sustainable workloads and recovery time.

Collaboration mechanisms

Collaboration is not simply placing people in the same communication channel. It requires shared work objects, agreed decision practices, and opportunities for rapid feedback. Useful mechanisms include peer review, collaborative design sessions, pair or ensemble work, backlog refinement, demonstrations, retrospectives, shared documentation, automated integration, and cross-functional planning.

Collaboration should be purposeful. Meetings and shared tools become counterproductive when they replace individual concentration, duplicate information, or create continuous interruptions. Teams should distinguish synchronous collaboration, which is useful for ambiguity and negotiation, from asynchronous communication, which is useful for updates, reference information, and geographically distributed work.

Feedback and performance conversations

Effective feedback describes observable behaviour, its effect, and a desired future action. “Your work is poor” is neither specific nor useful. “The change was merged without the required security review, which increased release risk; please request the review before merging future changes” is clearer and more actionable.

Performance conversations should address both results and behaviours. A person who delivers quickly while damaging trust, bypassing controls, or creating technical debt may require coaching even if short-term output appears high. Conversely, a person who raises difficult risks and helps others may be making an important contribution not visible in simple activity counts.

5. Conflict and Negotiation

Conflict is disagreement between people or groups. It is not automatically harmful. Constructive conflict can expose assumptions, improve designs, and prevent groupthink. Destructive conflict attacks identity, reduces information sharing, and shifts attention from the problem to personal victory.

Common sources of software project conflict include:

• competing priorities and scarce specialists;
• unclear requirements or acceptance criteria;
• technical disagreement;
• estimates and deadline pressure;
• ownership of architecture or data;
• differing professional values;
• communication style and cultural differences;
• perceived unfairness in workload or recognition.

A useful first step is to classify the conflict:

1. Task conflict: disagreement about what should be done.
2. Process conflict: disagreement about how work, decisions, or responsibilities should be organized.
3. Relationship conflict: personal tension, disrespect, or damaged trust.

Task and process conflict can often be addressed through evidence, explicit decision criteria, experiments, and clarified roles. Relationship conflict requires attention to behaviour, listening, boundaries, and sometimes formal intervention.

A practical conflict process

1. Address the issue early, before positions harden.
2. Separate people from the problem and describe observable facts.
3. Allow each party to explain interests, constraints, and evidence.
4. Identify shared objectives, such as safety, customer value, or reliable delivery.
5. Generate alternatives rather than arguing only between initial positions.
6. Decide using agreed criteria and authority.
7. Record the decision, owner, rationale, and review point.
8. Escalate when the issue exceeds the team’s authority or involves misconduct, safety, discrimination, or legal risk.

Compromise is not always the best outcome. A decision that merely splits the difference may satisfy neither technical quality nor user value. Collaboration seeks a solution that addresses the important interests, while a clear decision by an authorized person may be necessary when time is limited.

6. Communication in Software Projects

Communication transfers meaning, not merely data. A message is effective only when the recipient interprets it sufficiently for the intended action or decision. The project manager should select communication methods according to urgency, ambiguity, sensitivity, audience, and need for a durable record.

A simple communication planning model asks: Who needs what information, for what decision or action, by when, through which channel, and how will understanding be verified? The answer should be recorded in a communication plan, but the plan should remain lightweight enough to use.

Communication complexity

If every participant in a group could communicate directly with every other participant, the number of possible two-way communication paths is:

Here, C is the number of possible pairwise paths and n is the number of participants. This relationship assumes that each pair creates one potential two-way path and that communication paths are counted without regard to message volume or quality. For five participants, C = 5×4÷2 = 10. The formula does not predict actual communication effectiveness; it simply illustrates why larger groups need coordination structures, shared repositories, and deliberate communication norms.

Status reporting

A useful status report is decision-oriented rather than activity-oriented. It should normally include:

• current outcome or milestone status;
• completed and forthcoming work;
• significant variance from the plan;
• top risks, issues, and dependencies;
• decisions required and their deadlines;
• changes in scope, quality, cost, or schedule;
• confidence level and supporting evidence.

Status should be truthful and comparable over time. Green, amber, and red indicators can help scanning, but colour alone is insufficient. Each exception should state its impact, owner, response, and expected resolution date. Leaders must not pressure teams to conceal bad news; early escalation usually increases the set of available responses.

7. Meetings and Decision Records

A meeting is justified when people must interact to share meaning, make a decision, solve a problem, or coordinate interdependent work. It is not justified merely because a recurring calendar slot exists.

Effective meetings have:

• a clear purpose and outcome;
• the minimum necessary participants;
• an agenda distributed in advance;
• relevant information available before discussion;
• a facilitator who manages time and participation;
• explicit decisions, actions, owners, and due dates;
• a concise record accessible to those affected.

The facilitator should prevent domination by senior or highly vocal participants, invite quieter expertise, separate exploration from decision, and make unresolved issues visible. A meeting should not create false consensus. If participants disagree, the record should identify the disagreement, decision authority, rationale, and conditions for revisiting it.

A decision record can use the following structure:

8. Stakeholder Identification and Engagement

A stakeholder is a person, group, or organization that can affect the project, is affected by it, or perceives itself to be affected by it. Stakeholders may include sponsors, customers, end users, product managers, developers, operations staff, suppliers, regulators, auditors, accessibility advocates, security officers, unions, and communities affected by the system.

Stakeholder management is not manipulation. It is the ethical process of understanding interests, providing appropriate influence and information, managing expectations, and ensuring that legitimate concerns enter decisions.

Stakeholder analysis

Stakeholder analysis should consider:

• interest in the project and its outcomes;
• influence over resources, decisions, or acceptance;
• impact experienced by the stakeholder;
• knowledge, expectations, and concerns;
• preferred communication and accessibility needs;
• possible conflicts of interest;
• legal, contractual, safety, or ethical obligations.

A power–interest matrix can guide attention. High-power, high-interest stakeholders generally require close engagement. High-power, low-interest stakeholders need assurance and concise escalation information. Low-power, high-interest stakeholders should receive meaningful updates and opportunities to provide evidence, especially when they are significantly affected. Low-power, low-interest groups may require monitoring, but should not be ignored if their impact or rights are substantial.

The matrix is a planning aid, not a justification for silencing people with less formal power. Affected users may have low organizational authority but high ethical importance.

Engagement strategies

Engagement should occur throughout the project, not only at approval gates. Discovery interviews can reveal needs; prototypes can test interpretations; demonstrations can obtain feedback; pilot releases can expose operational problems; and acceptance reviews can establish evidence for release decisions.

Stakeholder expectations should be converted into explicit, testable needs where possible. When a request cannot be accepted, the project manager should explain the reason, alternatives, trade-offs, and route for reconsideration. Overpromising damages trust more than acknowledging uncertainty.

9. Cross-Functional and Distributed Teams

Cross-functional teams combine different expertise. Their diversity improves problem framing and quality when members share a goal and respect one another’s authority. It can also create language differences, conflicting standards, and disagreement about what “done” means. A team charter should define purpose, working agreements, decision rights, quality expectations, escalation routes, core hours, and communication norms.

Distributed teams add time zones, network reliability, cultural variation, and reduced informal awareness. Good practice includes:

• documenting decisions and rationale;
• using asynchronous updates where immediate discussion is unnecessary;
• publishing response-time expectations;
• rotating meeting times fairly;
• recording essential briefings when appropriate;
• ensuring tool and document accessibility;
• creating deliberate social connection without making it compulsory;
• measuring outcomes rather than online presence;
• protecting uninterrupted work periods.

Remote monitoring that captures keystrokes, screenshots, or constant webcam presence can damage trust and encourage performative activity. Monitoring should have a legitimate purpose, be proportionate, transparent, secure, and compliant with applicable employment and privacy requirements.

10. Governance, Ethics, and Responsible Use of Technology

Team and stakeholder practices have ethical consequences. Managers should avoid discrimination in recruitment, allocation, recognition, and promotion. Accessibility and inclusion should be considered in products, meetings, documentation, and communication channels. Confidential information must be shared only with authorized people, and conflicts of interest should be declared.

AI tools may assist with drafting meeting summaries, identifying action items, translating information, or analysing communication patterns. However, generated content can be inaccurate, biased, incomplete, or based on confidential data. Human review remains necessary for decisions affecting employment, safety, security, legal compliance, or stakeholder rights. Teams should establish rules for approved tools, data handling, attribution, verification, retention, and accountability.

A project manager should also consider whether stakeholder participation is genuinely informed. Consent, privacy, accessibility, and the ability to challenge decisions matter particularly when software affects health, finance, employment, education, public services, or vulnerable communities.

Applied Case: The Atlas Service Release

The following is an illustrative case.

Background

Atlas is a cloud-based service being developed by a cross-functional team of nine people: a product owner, project manager, technical lead, four developers, a tester, and a user-experience specialist. Operations and information security contribute part time. The team is distributed across three time zones. A public pilot is planned in ten weeks.

Problem

After six weeks, the schedule appears healthy because most development tasks are marked complete. However, the tester reports that acceptance criteria are changing, the security review has not been scheduled, and operations has not received deployment information. Developers complain that the product owner changes priorities through private messages. Two team members rarely speak in meetings because meeting times favour one region. The sponsor receives optimistic status reports but is unaware of the release dependencies.

Analysis

The central problem is not simply schedule performance. It is a governance and communication failure involving:

• unclear decision and prioritization channels;
• incomplete accountability for release readiness;
• weak cross-functional integration;
• insufficient stakeholder visibility;
• distributed-team inequity;
• risk concealment caused by activity-based reporting.

Approach

The project manager facilitates a short team workshop. The group creates a responsibility matrix for requirements, security, testing, deployment, and release approval. The product owner agrees that priority changes will be recorded in the shared backlog. The technical lead and security specialist establish a review date. Operations defines deployment prerequisites, and the tester helps convert major acceptance conditions into visible examples.

The team replaces the status report’s “percentage complete” with milestone evidence: accepted stories, unresolved defects, security review status, deployment readiness, and top dependencies. Meeting times rotate weekly, while routine updates move to an asynchronous channel. A decision log records the rationale for scope changes. The sponsor receives an amber status report explaining the risks and decisions required.

Outcome

The pilot scope is reduced, but the release is better prepared. The security review identifies a permissions defect early enough to correct it. Operations completes a rehearsal deployment, and stakeholders understand which features are excluded from the pilot. Team members report greater confidence because concerns can be raised without being treated as failure.

Learning points

1. Activity completion is not the same as delivery readiness.
2. Role clarity must include decision rights and cross-functional dependencies.
3. Honest escalation enables scope adjustment before failure becomes unavoidable.
4. Distributed collaboration requires deliberate asynchronous practices and fair scheduling.
5. Stakeholder confidence is strengthened by evidence, transparency, and reliable follow-through.

Challenges and Limitations

Team models and stakeholder matrices simplify reality. Power and interest can change rapidly, and a person with little formal authority may possess essential safety or domain knowledge. Leadership frameworks can also be misused as labels that excuse stereotyping or ignore context. Communication tools do not remove ambiguity; they may amplify it when messages are rushed or fragmented. Metrics such as velocity, response time, or number of meetings are proxies, not complete measures of team health or value.

Managers should therefore combine structured tools with judgement, direct observation, feedback, and ethical reflection. They should ask whether a practice improves outcomes and dignity, not merely whether it creates more data.

Best-Practice Checklist

Before and during delivery, a project manager should verify that:

• the team has a shared purpose and definition of success;
• roles, responsibilities, accountability, and authority are visible;
• decision and escalation routes are understood;
• communication is tailored to audience and purpose;
• meetings produce decisions or useful coordination;
• status reports show evidence, risks, and required decisions;
• conflict is addressed early and respectfully;
• stakeholder concerns are recorded and answered;
• distributed members receive equitable participation;
• quality, security, privacy, accessibility, and compliance are integrated into planning;
• AI and monitoring tools are used transparently and proportionately;
• lessons are captured and applied rather than merely archived.

Chapter Summary

Software project performance depends on the interaction of people, technology, processes, and stakeholders. Effective teams require clear roles, accountability, decision rights, shared purpose, and collaboration mechanisms. Leadership complements management by building trust, enabling expertise, removing obstacles, and adapting the level of direction to the situation. Motivation is supported by autonomy, mastery, purpose, recognition, learning, and sustainable working conditions.

Conflict can improve decisions when it concerns tasks or processes and is managed through evidence and shared objectives; relationship conflict requires particular attention to respect and behaviour. Communication should be designed around audience, purpose, urgency, ambiguity, and the need for a durable record. Well-run meetings clarify decisions and actions rather than merely consume time. Stakeholder engagement involves identifying interests and influence, communicating honestly, obtaining feedback, and addressing legitimate concerns throughout the life cycle.

Cross-functional and distributed teams need explicit working agreements, asynchronous documentation, equitable participation, and outcome-based management. Ethical practice requires fairness, accessibility, privacy, responsible monitoring, and human accountability when AI tools are used. The project manager’s central responsibility is to create conditions in which people can coordinate effectively, raise risks early, and remain aligned with valuable and responsible outcomes.

Key Terms

Accountability: Answerability for a result or decision.

Agile team: A team organized to deliver value iteratively and respond to feedback and change.

Communication plan: A structured agreement about information needs, audiences, channels, timing, and responsibilities.

Conflict: A disagreement between people or groups concerning goals, methods, resources, or relationships.

Cross-functional team: A team containing people with complementary professional specialisms.

Decision record: A concise record of a decision, context, alternatives, rationale, owner, and review conditions.

Facilitator: A person who helps a group communicate, make decisions, and achieve its meeting purpose.

Interest: The degree to which a stakeholder cares about a project or its effects.

Leadership: The process of influencing and enabling people toward shared objectives.

Matrix structure: An organizational structure in which authority is shared across functional and project dimensions.

Psychological safety: A climate in which people can raise concerns, ask questions, and admit mistakes without fear of humiliation or retaliation.

Responsibility: An obligation to perform work or carry out a decision.

Responsibility assignment matrix: A tool that maps roles to activities or deliverables.

Servant leadership: Leadership that enables others by removing obstacles, developing capability, and supporting shared goals.

Stakeholder: A person, group, or organization that can affect, is affected by, or perceives itself affected by a project.

Status report: A communication describing progress, variance, risks, issues, decisions, and outlook.

Team charter: An agreement defining a team’s purpose, norms, roles, decision practices, and working arrangements.

Trust: Confidence that another person or group will act competently, honestly, and reliably.

Review Questions

Short Answer Questions

1. Distinguish responsibility from accountability and give a software project example of each.
2. What is psychological safety, and why is it important for software quality?
3. Identify three characteristics that make software work socio-technical.
4. What information should normally appear in a useful status report?
5. State two practices that support effective distributed teamwork.

Long Answer Questions

1. Compare functional, matrix, projectized, and product-oriented team structures. Explain when each may be appropriate.
2. Explain how a project manager can combine management, situational leadership, and enabling leadership.
3. Describe a complete process for identifying and resolving conflict in a cross-functional software team.
4. Explain how stakeholder analysis can guide communication and engagement without unfairly silencing low-power groups.
5. Discuss the ethical responsibilities involved in using AI tools and employee-monitoring technologies in software projects.

Analytical / Application Questions

1. A project has many completed development tasks but no security review, deployment plan, or agreed acceptance criteria. Diagnose the management and communication failures and propose corrective actions.
2. A distributed team repeatedly misses decisions because discussions occur in private messages and meetings favour one time zone. Design a communication and meeting system to improve transparency and equity.
3. A sponsor demands an unrealistic release date while testers and operations report serious readiness risks. Explain how you would communicate the situation, negotiate options, and maintain stakeholder trust.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes accountability from responsibility?

A. Accountability is answerability for the result, while responsibility concerns performing the work.

B. Accountability belongs only to technical specialists, while responsibility belongs only to managers.

C. Responsibility is always shared, while accountability can never be assigned.

D. They are identical terms with no practical distinction.

Correct Answer: A. Accountability is answerability for the result, while responsibility concerns performing the work.

Question 2

What is the primary purpose of a responsibility assignment matrix?

A. To calculate the project budget

B. To map roles to activities and clarify ownership

C. To measure customer satisfaction statistically

D. To replace all project communication

Correct Answer: B. To map roles to activities and clarify ownership

Question 3

Which leadership behaviour is most consistent with enabling leadership?

A. Keeping all decisions with the project manager

B. Removing obstacles and developing team capability

C. Avoiding difficult performance conversations

D. Measuring commitment by online presence

Correct Answer: B. Removing obstacles and developing team capability

Question 4

Which example is task conflict?

A. Two colleagues disagree about whether to use event-driven or batch processing

B. A team member insults another person in a meeting

C. A developer refuses to speak to the tester

D. A manager excludes a colleague from meetings because of personal dislike

Correct Answer: A. Two colleagues disagree about whether to use event-driven or batch processing

Question 5

For five participants, how many possible pairwise communication paths are given by C = n(n − 1) ÷ 2?

A. 5

B. 8

C. 10

D. 20

Correct Answer: C. 10

Question 6

Which item is most appropriate for a decision record?

A. Only the names of meeting attendees

B. The decision, alternatives, rationale, owner, and review conditions

C. A ranking of employees by activity count

D. An unverified prediction of final profit

Correct Answer: B. The decision, alternatives, rationale, owner, and review conditions

Question 7

A stakeholder has high power and high interest. Which engagement approach is generally most appropriate?

A. Monitor with minimal contact

B. Keep informed only through an automated newsletter

C. Manage closely through regular, substantive engagement

D. Exclude the stakeholder from technical decisions

Correct Answer: C. Manage closely through regular, substantive engagement

Question 8

Which practice best supports an equitable distributed team?

A. Schedule every meeting in the manager’s time zone

B. Require continuous webcam and keystroke monitoring

C. Rotate meeting times and document decisions asynchronously

D. Treat written communication as unnecessary

Correct Answer: C. Rotate meeting times and document decisions asynchronously

Question 9

Why should status reporting emphasize evidence rather than percentage complete alone?

A. Percentage complete always violates accounting rules

B. Activity completion may not demonstrate quality, readiness, or stakeholder value

C. Evidence is useful only for regulatory projects

D. Evidence eliminates the need for project decisions

Correct Answer: B. Activity completion may not demonstrate quality, readiness, or stakeholder value

Question 10

What is a responsible practice when using an AI tool to summarize sensitive project meetings?

A. Upload all confidential information without review

B. Allow the tool to make employment decisions automatically

C. Use approved tools, protect data, and have a person verify the output

D. Treat the generated summary as accurate by definition

Correct Answer: C. Use approved tools, protect data, and have a person verify the output