Quality, Resources, and Communications in Projects

Quality, resource, and communications management are examined here as the operational disciplines that hold a project together rather than as separate administrative functions. This post explains the quality-management process framework, the distinction between resource planning and resource control, the communications-planning and management cycle, and how these three areas interact with the governance structures that direct project work. The analysis is informed by PMI’s established project-management process framework and by documented evidence from NASA’s Apollo Program and NASA’s current quality-management requirements.

By Kateule Sydney — Researcher and Writer | Last Verified: 2026-10-04 | Published by Kat-Syd Resources Hub

Quality, resources, and communications are the operational infrastructure through which a project remains controllable — requirements determine what resources are needed, resources determine what can be performed, and communications determine whether decisions are made with the information required to make them well.

Table of Contents

• Chapter 1 — Quality Management: Conformance to Requirements, Not Simply Excellence
• Chapter 2 — Resource Management: Planning, Acquiring, and Controlling What the Project Needs
• Case Study
• Chapter 3 — Communications Management: The Information That Makes Decisions Possible
• Chapter 4 — Operational Discipline: How the Three Areas Hold a Project Together
• Conclusion
• References

Chapter 1 — Quality Management: Conformance to Requirements, Not Simply Excellence

A common mistake in project quality management is treating it as a search for excellence. That is too narrow. In project management, quality is fundamentally concerned with the degree to which deliverables and processes fulfil applicable requirements. A project can deliver a product that is not considered exceptional yet still meet its agreed requirements. Conversely, a technically impressive product can fail to meet quality expectations if it does not conform to the requirements that apply to it.

Definition. Quality management is the systematic approach used to plan quality requirements and standards, establish and improve appropriate processes, and control the results produced by the project. In the PMBOK® Guide—Sixth Edition process framework, project quality management comprises three processes: Plan Quality Management, Manage Quality, and Control Quality.

The terminology should be placed in historical context. PMI’s Eighth Edition, published in November 2025, retains the principles and performance-domain foundation introduced in the Seventh Edition while reintroducing process guidance in a more flexible, non-prescriptive form. The three-process structure discussed below therefore represents the established PMBOK process framework rather than the principal organizing structure of the current Eighth Edition.

The three processes are:

• Plan Quality Management — identifying applicable quality requirements and standards and documenting how the project will demonstrate compliance.
• Manage Quality — translating the quality-management plan into executable quality activities and improving the processes used to produce project outputs.
• Control Quality — monitoring and recording quality results and assessing whether deliverables and processes conform to applicable requirements. Inspection, testing, measurement, and verification can form part of this work.

The distinction is important because quality planning, quality assurance, and quality control address different questions. Planning determines what quality means for the project and how it will be demonstrated. Quality-management activities address the processes used to achieve it. Control activities examine the resulting work and evidence of conformance.

PMI also distinguishes quality from grade. Quality concerns the degree to which characteristics fulfil requirements, while grade refers to a category or classification of products or services with different technical characteristics. A lower-grade product can therefore be acceptable if it meets the requirements applicable to that grade. A higher-grade product can still be unacceptable if it fails a required specification.

NASA’s quality requirements reinforce the importance of planned processes, verification, and control. NASA’s current Hardware Quality Assurance requirements establish quality-assurance activities across program and project development, including planning, analysis, execution, verification, and risk management.

The Apollo Program provides historical evidence of the same principle. Apollo used formal reliability and quality-assurance requirements, contractor quality provisions, inspection requirements, failure reporting, and corrective-action mechanisms. NASA documentation describes quality control as involving qualification testing, inspection, surveillance, and follow-up of hardware discrepancies.

The lesson is not that inspection is unnecessary. Inspection and testing are essential. The stronger lesson is that inspection alone cannot create quality. Quality must also be addressed through requirements, design, process control, verification, testing, documentation, and corrective action.

Why this matters. A practitioner who understands quality as a requirements discipline makes deliberate decisions about which standards apply, how compliance will be demonstrated, and what corrective action is required when conformance fails. A practitioner who treats quality simply as an aspiration toward excellence risks losing the ability to define, measure, and verify what was actually promised.

The position to carry forward from this chapter is that quality management is fundamentally a requirements-and-process discipline, not simply a pursuit of excellence. It is measured against applicable requirements and intended use, not against an undefined ideal of perfection. For the WBS discipline that helps structure project scope and responsibilities, see my post on Work Breakdown Structure and the Art of Decomposition.

Chapter 2 — Resource Management: Planning, Acquiring, and Controlling What the Project Needs

Resources are the human, physical, material, equipment, facility, and other inputs required to perform project work and produce deliverables. Resource management is the discipline of identifying what the project needs, obtaining those resources, developing and managing the project team where applicable, and controlling the use of physical resources.

Definition. In the PMBOK® Guide—Sixth Edition process framework, Project Resource Management includes Plan Resource Management, Estimate Activity Resources, Acquire Resources, Develop Team, Manage Team, and Control Resources.

These processes are:

• Plan Resource Management — defining how project resources will be estimated, acquired, managed, and used.
• Estimate Activity Resources — estimating the type and quantity of resources required to perform project activities.
• Acquire Resources — obtaining the people, facilities, equipment, materials, supplies, and other resources required for the work.
• Develop Team — improving team competencies, interaction, and the overall team environment.
• Manage Team — tracking team performance, providing feedback, resolving issues, and managing changes affecting the team.
• Control Resources — ensuring that physical resources are available and used as planned and monitoring planned versus actual resource use.

These processes illustrate an important distinction between planning resources, acquiring resources, and controlling resources. Planning determines what is needed and how resources will be managed. Acquisition obtains the required resources. Control examines whether physical resources are available and being used as intended. The distinction matters because each stage can fail independently.

Planning failures can produce unrealistic project plans. Acquisition failures can create delays or prevent planned activities from starting. Control failures can produce waste, shortages, inefficient use, or conflicts between planned and actual resource consumption.

Resource management is also broader than human-resource management. Physical resources such as materials, equipment, facilities, and supplies require their own planning, acquisition, tracking, and control.

NASA’s project and cost-management guidance demonstrates why resource considerations must be connected to project structure and cost planning. NASA’s WBS Handbook describes the WBS as a framework for organizing and controlling project work and notes that it supports responsibility assignment, schedule development, cost management, and project communication.

NASA’s Cost Estimating Handbook Version 4.0 provides guidance for developing cost estimates and includes dedicated material on WBS, cost-estimating methodologies, schedule estimating, risk and uncertainty, and joint cost and schedule confidence analysis. This illustrates the relationship between resources, cost, and schedule without implying that they are the same discipline. Resource requirements influence cost and schedule assumptions, while cost and schedule constraints can in turn affect resource decisions.

Why this matters. A practitioner who understands resource management as a planning, acquisition, team-management, and control cycle can identify resource constraints before they become schedule problems. A practitioner who treats resource management as a scheduling afterthought may discover resource shortages only when activities cannot begin because the required people, equipment, facilities, or materials are unavailable.

The position to carry forward from this chapter is that resource management is a primary project-management concern because resource availability is one of the conditions that determines whether the planned work can actually be performed. For the schedule and cost controls that resource planning feeds into, see my post on Scheduling and Cost Control in Projects.

Case Study

NASA’s Apollo Program provides a useful historical case for examining how quality, resources, and communications operated within a large and technically complex program.

At its peak, approximately 400,000 people were involved in Apollo across NASA, contractors, industry, universities, and other supporting organizations. NASA also describes Apollo as requiring support from more than 20,000 industrial firms and universities.

The Apollo Program Summary Report, published by NASA in April 1975, documents the breadth of the program, including spacecraft development and testing, mission operations, launch facilities, manufacturing, lunar science, and other program activities.

Apollo’s quality-management arrangements were not simply informal engineering practices. NASA documentation describes formal reliability and quality-assurance plans, contractor requirements, inspection provisions, reporting systems, testing, surveillance, and corrective action.

The program also demonstrates the importance of structured interfaces between organizations. NASA documentation concerning Apollo program control describes formal contractual, technical, and schedule interfaces, program-management meetings, formal reviews, cost and schedule control mechanisms, and quality-control procedures.

The Apollo experience therefore supports a more precise conclusion than simply saying that NASA had good project management. The evidence shows that a program of Apollo’s scale required formal mechanisms for defining requirements, allocating responsibility, controlling resources and schedules, verifying technical performance, documenting information, and escalating problems.

Apollo also provides evidence that these mechanisms could fail or prove inadequate. The Apollo 1 review identified deficiencies in design, manufacture, installation, rework, and quality control, demonstrating that the existence of formal procedures does not guarantee that they will be effective in practice.

The case therefore supports the central argument of this article: quality, resources, and communications are not administrative overhead. They are mechanisms through which complex project work becomes controllable.

Chapter 3 — Communications Management: The Information That Makes Decisions Possible

Communications management is not public relations, and it is not limited to status reporting. It is the discipline of determining what information project participants and stakeholders need, when they need it, how it should be produced and distributed, and how the effectiveness of that information flow will be monitored.

Definition. In the PMBOK® Guide—Sixth Edition process framework, Project Communications Management includes Plan Communications Management, Manage Communications, and Monitor Communications.

These processes are:

• Plan Communications Management — developing an appropriate approach for project communications based on stakeholder information needs and the project’s context.
• Manage Communications — collecting, creating, distributing, storing, retrieving, managing, and monitoring project information.
• Monitor Communications — assessing whether communication activities are meeting the information needs of the project and its stakeholders and whether the intended effect is being achieved.

PMI’s guidance makes an important point: communications must be monitored rather than simply assumed to be effective. PMI’s PMBOK 6 material explains that monitoring communications can lead to revisions of the communications-management and stakeholder-engagement plans when communication is not producing the desired effect.

The communications-management plan is therefore a key planning document. It can specify who needs particular information, what information is required, when it should be provided, in what format, and through which communication method or channel.

Communications planning also needs to be connected to stakeholder management. Stakeholder information needs, the stakeholder register, the stakeholder engagement approach, organizational communication assets, and project-management requirements all influence how communications should be designed.

Communication is not a one-time activity. Information needs change as stakeholders change, project phases change, risks emerge, decisions are made, and the project moves from planning into execution and delivery. A communications plan created at the beginning of a project and never updated can eventually describe the information needs of a project that no longer exists in its original form.

NASA and structured communication. The Apollo Program illustrates why communication structures matter in complex programs.

Historical NASA documentation describes formal technical and contractual interfaces, program-management meetings, documentation, reviews, reporting systems, and coordination between NASA and contractors. These mechanisms connected technical information and program-control activities to management decisions.

NASA’s Apollo experience material also emphasizes the importance of open communication and the ability of personnel to challenge technical assumptions. This is important because effective project communication is not merely the movement of information from one person to another. Its value lies in enabling coordination, challenge, escalation, learning, and decision-making.

Why this matters. A practitioner who manages communications as a discipline increases the likelihood that decisions are made using timely and relevant information. A practitioner who treats communications as an automatic consequence of teamwork may discover only after the fact that decision-makers were working with incomplete, outdated, misunderstood, or poorly structured information.

The position to carry forward from this chapter is that communications management is a coordination discipline: it creates the information flows through which project decisions become possible. For the stakeholder-engagement framework that communications supports, see my post on Risk, Procurement, and Stakeholder Management.

Chapter 4 — Operational Discipline: How the Three Areas Hold a Project Together

Quality, resource, and communications management are not parallel activities operating independently. They are interdependent areas of project management.

Quality requirements influence the resources, skills, equipment, materials, processes, and verification activities required to deliver the intended outcome. Resource availability influences what work can be performed and when. Communications determine whether information about quality, resources, risks, and performance reaches the people who need it.

Definition. The term “operational discipline” does not have a single formal PMI definition in this context. It is used here as an analytical term to describe the integration of quality, resource, and communications practices into the daily execution of project work.

PMI’s project-management frameworks classify practices into different areas and domains for purposes of guidance and organization. The practical reality, however, is that project work crosses those boundaries.

The integration can be understood through four operational connections.

1. Requirements to resources. Quality requirements can determine the skills, equipment, materials, facilities, suppliers, testing arrangements, and other resources required to deliver an acceptable result. For example, a specification for aerospace material may require qualified suppliers, specialized inspection equipment, qualified personnel, and additional testing.

2. Resources to schedule. Resource availability affects when activities can be performed. A schedule that assumes unlimited availability of critical personnel, equipment, facilities, or materials may be technically coherent but operationally unrealistic.

3. Performance to communications. Quality and resource information must reach the people responsible for making decisions. A quality deviation that is not communicated to the appropriate decision-maker cannot be acted upon. A resource shortage that is not escalated can become a schedule failure.

4. Communications to governance. Governance decisions depend on the information available to decision-makers. A change-control body or project steering group making decisions without current information about quality, cost, schedule, resources, and risks is making decisions on an incomplete information base.

NASA’s Apollo experience provides historical evidence of this kind of integration. Program-control documentation describes the interaction of cost, schedule, quality, technical interfaces, formal reviews, reporting, and management responsibilities. The important point is not that NASA used the phrase operational discipline. It did not establish that terminology as the framework used here. Rather, the Apollo evidence provides a historical example from which this integrated interpretation can be drawn.

Why this matters. A practitioner who understands the connections between quality, resources, and communications can identify weaknesses at the interfaces between management activities rather than looking only for failures inside individual functions.

A project can have a good quality plan but insufficient resources to achieve it. It can have sufficient resources but fail to communicate a critical quality problem. It can have good information but weak governance that fails to act on it.

The position to carry forward from this chapter is that operational discipline is not a separate project-management discipline. It is the integration of several disciplines into the daily execution and control of project work. For the risk and governance structures that oversee that execution, see my post on Why Large Projects Fail: The Structural Causes.

Conclusion

The chapters and case study establish that quality, resource, and communications management are interconnected operational areas that help hold complex project work together.

Quality management establishes applicable requirements and provides mechanisms for assuring and controlling conformance. Resource management determines what the project needs, obtains or develops those resources, and controls their use. Communications management establishes information flows that allow stakeholders and decision-makers to coordinate action.

My position is that these areas often fail not because their tools are unknown, but because they are treated as administrative overhead rather than as part of project execution. Quality may be planned but inadequately embedded in design and execution. Resources may be assumed to be available without sufficient verification. Communications may be assumed to happen simply because people are working together. The tools exist. The challenge is applying them as an integrated management system.

A strong counterargument is that modern Agile approaches do not require the same formal quality, resource, and communications processes used in traditional predictive project management. Agile teams often handle these concerns through iterative planning, team capacity considerations, a Definition of Done, daily coordination, reviews, retrospectives, and other lightweight mechanisms. That objection is valid as far as the mechanisms are concerned. Agile teams can organize the work differently. But the underlying management questions remain: What does an acceptable result look like? What capabilities and resources are required to produce it? What information must reach the people making decisions? How quickly must the project respond when requirements, resources, or circumstances change? Agile changes the mechanisms. It does not eliminate the underlying management problems.

Five recommendations follow from the analysis:

• Define quality as fulfilment of applicable requirements. Establish measurable quality criteria and acceptance conditions rather than relying on subjective ideas of excellence.
• Consider resource availability before committing to a schedule. Resource assumptions are constraints on execution, not merely scheduling details.
• Design communications around decisions and actions. Reporting should exist because someone needs information to understand, decide, coordinate, escalate, or act.
• Update quality, resource, and communications arrangements as the project evolves. Requirements, resource availability, stakeholders, risks, and information needs change.
• Manage the interfaces between disciplines. Project failures often emerge not within one management area but at the handoffs between requirements, resources, information, and decisions.

The argument in one sentence is this: quality, resource, and communications management are interconnected operational capabilities that help make project work controllable, and projects become vulnerable when any of them is treated as administrative overhead rather than as part of execution.

References

• Project Management Institute. (2025). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and The Standard for Project Management (8th ed.). Project Management Institute.
• Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th ed.). Project Management Institute.
• National Aeronautics and Space Administration. (2010). NASA Work Breakdown Structure (WBS) Handbook (NASA/SP-2010-3404). NASA Technical Reports Server.
• National Aeronautics and Space Administration. (2015). NASA Cost Estimating Handbook, Version 4.0. NASA Office of the Chief Financial Officer.
• National Aeronautics and Space Administration. (1975). Apollo Program Summary Report (JSC-09423). Lyndon B. Johnson Space Center.
• National Aeronautics and Space Administration. (2021). NPR 8735.2C: Hardware Quality Assurance Program Requirements for Programs and Projects. NASA Office of Safety and Mission Assurance.
• Sperber, K. P. (1973). Apollo Experience Report: Reliability and Quality Assurance (NASA-TN-D-7438; JSC-S-371). NASA.

Read Also on Kat-Syd Resources Hub

Why Large Projects Fail: The Structural Causes — Optimism bias, strategic misrepresentation, governance weakness, and complexity, tested against megaproject research and documented cases.

Work Breakdown Structure and the Art of Decomposition — The WBS as a deliverable hierarchy, its decomposition rules, its failure modes, and evidence from NASA’s Apollo-era practice and the Denver airport baggage system.

Scheduling and Cost Control in Projects — Schedule management, CPM, PERT, CCPM, and EVM, tested against a 2026 Indonesian oil and gas compressor case study.

Written by Kateule Sydney — Researcher and Writer

© 2026 Kat-Syd Resources Hub. All rights reserved.

Kat-Syd Resources Hub — Educational case studies and analytical reference