13. Elicit Management Requirements, Revisit Assumptions and Constraints

Note: In this framework, the term initiative refers to programs and projects. The term work execution unit refers collectively to programs, projects, phases, releases, and work packages, all of which are considered temporary organizations.

The Nature and Importance of Management Requirements

Defining Management Requirements

Management requirements are the specific conditions and expectations that stakeholders place on the processes used to manage a program or any of its constituent parts, such as projects, phases, releases, or work packages. These requirements are separate from “business requirements,” which define the capabilities the business aims to acquire, and “functional requirements,” which detail the attributes of the solution being developed. The focus of management requirements is on the operational characteristics of the work itself for the work execution unit concerned. Gathering these inputs from stakeholders is essential for creating the plans that will govern execution. The less documented an organization’s standard management guidance is, the more critical it becomes to actively elicit these requirements for each work execution unit.

Key Stakeholder Expectations

Various stakeholders influence how a program and its components should be managed. Their expectations must be understood and incorporated into the management plans for the relevant work execution unit. Key groups and their hierarchical influence include:

• Sponsor or Customer: Defines high-level expectations for governance and reporting, typically at the program or project level. These expectations then provide a framework for subordinate work execution units.
• Execution Team: Has expectations regarding team management, collaboration, and work processes relevant to their specific project, phase, or work package.
• Project Management Office (PMO): May mandate adherence to a specific organizational management method. Such standard methods apply across the organization but may require customization for a particular program or project.
• Internal Departments: Groups like finance or procurement often have specific requirements for how activities that affect them are to be managed. These requirements typically apply to any work conducted within the organization, regardless of how the work is organized within the hierarchy.

Areas Influenced by Management Requirements

The requirements elicited from stakeholders provide direct inputs for creating management plans across numerous domains. These domains are relevant to all work execution units, from program to work package.

Illustrative Examples of Management Requirements

To clarify the concept, the following examples demonstrate specific requirements applicable across the execution hierarchy:

• Human Resources: Stakeholders may have requirements concerning team management, including factors related to origin, gender, or specific cultural considerations. These can apply at as a program-wide diversity policy, or at the level of a specific work package for the specific staffing plan.
• Planning Effort: A central requirement is to determine the planning approach. This decision can be made for any work execution unit. Some stakeholders may prefer a purely agile (progressive and iterative) method for a software release. Concurrently, a finance department might request a more predictive approach for the overarching project or program to facilitate budgeting and financial oversight. This allows for hybrid approaches within a single program structure.
• Procurement: If the organization has a dedicated procurement department, it will likely have established processes and requirements that dictate how all procurements must be handled. These rules form a baseline constraint for any program, project, or work package that needs to acquire external goods or services.

The Continuous Assessment of Assumptions and Constraints

The Transition from Initialization to Planning

The period between the end of initialization and the beginning of detailed planning is an ideal time to formally revisit all previously identified assumptions and constraints. This checkpoint is relevant at the inception of a program and recurs at the start of each constituent project, phase, release, and work package. This review is necessary because significant time may have passed since the parent level was planned, and the group of stakeholders involved may differ.

Managing Assumptions

Assumptions are statements believed to be true about necessary elements or future events. They must be actively managed and updated for all work execution units.

• Definition: Assumptions may concern elements necessary for the work, events that are expected to occur, or potential risks that are presumed not to happen. They can be strategic at the program level or tactical at the work package level.
• Review and Update: The process of eliciting management requirements at any level presents a suitable opportunity to update the “Assumptions Log.” The log for a subordinate work execution unit, such as a phase or a work package, must be consistent with the assumptions established for its parent project.
• Reclassification as Risks: Upon review, it may become evident that some items initially classified as assumptions are, in fact, risks. These items should be moved from the assumptions log to the risk log to undergo formal risk analysis at the appropriate work execution unit.

Managing Constraints

Constraints are limitations that are beyond the control of the team for a specific work execution unit and must be managed. Like assumptions, they require periodic review and updating.

• Definition: Constraints are external or internal limitations that affect execution. They often cascade down the hierarchy; for example, a program’s overall budget becomes a cost constraint for its constituent projects.
• Review and Update: Initial constraints are identified during the initialization of a program or project. This list must be updated during planning for that work execution unit and for all subordinate units. Some initial constraints may no longer exist, and new ones often become apparent as planning progresses.
• Examples of New Constraints: As a product is defined and work is planned in greater detail, new constraints may emerge. These can include firm deadlines for specific milestones or mandates that particular technologies must be used or avoided within a release.

Conclusion: Integrating Management Requirements for Success at All Levels

The elicitation of management requirements is a foundational activity that provides the necessary inputs for planning how work will be managed for the work execution unit concerned, from a program to a specific work package. This directly contributes to the potential for success of the respective work execution unit and the overall endeavor. It ensures the management approach aligns with stakeholder expectations for each work execution unit and its governance. Furthermore, assumptions and constraints are not static; they must be captured and regularly updated throughout the entire duration of the work. The recurrent transition from initialization to planning serves as a crucial, recurring checkpoint to perform a thorough review and revision of both the assumptions log and the list of constraints applicable to each program, project, phase, release, and work package.