Managing Expectations in Large-Scale Enterprise Projects — Part 3

By Thomas J. Smart

Previously, I explored the why and how of managing expectations during the first stage of the project lifecycle: creating and managing stakeholder briefs such as Requests for Proposals (RFPs). The next step focuses on the critical phase of gathering requirements, with an emphasis on identifying and mitigating project risks.

Requirements and Risk Management

Defining requirements and assessing risks are particularly challenging for large-scale projects, such as organisational cloud adoption. While these projects may have defined strategic objectives, they often lack clarity on how exactly to achieve them — how to go from the current state to the target state.

If we had the foresight of a crystal ball, we could define the precise steps up front and avoid any changes and mistakes. In reality, even with the most experienced project leader, actual outcomes typically deviate from the predicted. This article offers a practical guide to help with requirements gathering for large, complex projects.

Project Management Methodology

The chosen project management methodology significantly impacts gathering requirements and managing risks.

• Waterfall is linear and sequential, making it good for clarity but inflexible to change.
• Agile is iterative and incremental, making it easy to evolve but effective implementation requires familiarity with Agile principles.
• Kanban offers visual workflow management, making it good for entry-level Agile adoption but it’s difficult to predict project delivery dates without set timelines.

Each method serves different organisational maturity levels, with the trend being a gradual shift from Waterfall to Agile/Kanban in large enterprises due to the latter’s emphasis on flexibility and responsiveness to change.

Balancing Requirements and Risks

For effective large-scale project management, we must strike a balance between the structured predictability of the Waterfall methodology and the dynamic adaptability of Agile practices.

In my previous article, I discussed the importance of a discovery phase in large projects. This phase is crucial in understanding the current state, defining the target state, and performing a gap analysis to chart a clear roadmap.

Requirements gathering continues with those insights to add more detail where we need it. The key here is to concentrate on areas identified as high-risk during the discovery phase. This helps us to invest our time in understanding only those areas in greater detail.

This focused approach ensures that while significant risks are meticulously planned for, other areas of the project remain flexible, benefiting from the adaptive nature of Agile.

Risk Register

A risk register is a document containing identified risks, their severity, potential impacts, priority, and mitigation strategies. It is essential for guiding decision-making and proactive risk management.

A fundamental element in successfully balancing project requirements with risk is emphasising transparency and communication. Agile ceremonies, such as daily standups, sprint planning meetings, and retrospectives, provide platforms for regular communication among team members and stakeholders.

Assumptions and Constraints

Understanding assumptions and constraints in project planning is another part of balancing requirements and risks.

Assumptions are statements or conditions presumed to be true without concrete evidence at the planning stage. They are made to move forward with the planning process when complete information isn’t available. For instance, a project team might assume they’ll have continued access to certain resources throughout the project or that market conditions will remain stable. The higher the uncertainty around a particular requirement, the higher the risk of making assumptions will be.

Constraints are factors that limit or define the project’s scope, timing, budget, or quality. These are often considered the boundaries within which the project must be delivered. Common constraints include a limited budget, a fixed deadline, specific quality standards, or available technology. Unlike assumptions, which may be false and need constant validation, constraints are typically known from the start and directly impact how the project is planned and executed.

To manage assumptions and constraints effectively, project managers should identify and validate all assumptions early, enabling timely course corrections. Constraints must be clearly documented, communicated to stakeholders, and creatively addressed within the project plan to ensure delivery within defined limits.

Requirements Gathering

With the methodology established and a good understanding of the high-risk areas, the requirements can be gathered. This largely involves discussions with stakeholders to understand their needs and expectations during a discovery phase.

Refining and Prioritising

After the initial collection phase, where every piece of input is gathered, the next step is to make sense of this raw data and transform it into a structured, prioritised set of requirements that will guide the project. Here are the key steps to follow:

1. Start by combing through the collected data to identify and remove duplicates. Consolidate various stakeholder inputs into a single, clear requirement to avoid redundancy and confusion.
2. Work with stakeholders to clarify any vague or ambiguous requirements. This may involve asking for more details, exploring the underlying needs, or discussing the implications of certain requests.
3. Standardise the format and language of the requirements. This might involve adopting a specific template or set of terminology that is used consistently across all requirements.
4. Group similar requirements together into categories or streams. Categories might be based on the type of requirement (e.g., strategy vs engineering), the project area they relate to, or the stakeholder group they come from.
5. Revalidate the refined requirements with stakeholders to ensure accuracy and agreement. This step confirms that the refined requirements accurately reflect stakeholder needs and expectations.
6. Prioritise the requirements crucial to the project’s success. Evaluate each requirement in terms of its impact on the project and its urgency. Distinguish between ‘nice-to-haves’ and ‘must-haves’ to create a focused and manageable plan.

Requirements Documentation

To manage and reference requirements efficiently, storing them in a table can be helpful. Such a table should include the following columns:

• Name and Description: A concise yet descriptive title of the deliverable or requirement, followed by a brief description. Larger projects can include a category or stream for additional context.
• Functionality/Goals: Specify the functionality or goals associated with the requirement. In technical projects, this typically details the specific functions the software or system must perform. For strategy or educational projects, it might outline the objectives that the task aims to achieve.
• Non-functional Requirements: Detail the standards the task should adhere to, not what it does, but how well it performs from different perspectives. This could include performance benchmarks, compliance requirements, scalability, maintainability, and usability.
• Requestor(s): This column identifies the primary stakeholder for the requirement. It can be an individual, a department, or an external client. Identifying the requestor helps prioritise the requirements and directs whom to consult for further clarification.
• Dependencies: List any tasks or conditions that the item relies on. Dependencies are crucial in planning as they impact the sequence and timing of tasks.
• Risks/Notes: Document any potential risks associated with the requirement and any additional notes or considerations that need to be considered. Include risks in the project risk register for tracking and management.

This structured approach aids in clarity and accessibility, ensuring that each requirement is thoroughly understood and agreed upon by all stakeholders involved.

Collaborative Project Managers

Implementing a collaborative Project Manager (PM) strategy, where both the organisation and vendor have active PM roles, can be a game-changer in managing large, complex projects.

The client-side PM brings in-depth knowledge of the organisation’s internal processes, culture, and specific needs. The vendor-side PM offers expertise in the technical aspects of the project, along with a deep understanding of the product or service being implemented.

However, there are potential challenges that must be acknowledged. The client and vendor may have different priorities or business objectives, leading to potential conflicts that must be managed diplomatically. There’s a risk of overlapping responsibilities, leading to confusion and inefficiencies.

A clear RACI (Responsible, Accountable, Consulted, Informed) chart is essential to mitigate these challenges. This chart delineates each PM’s responsibilities and levels of involvement, ensuring clarity and accountability.

Therefore, the key to a successful dual-PM strategy lies in clearly defining roles, maintaining open lines of communication, and effectively managing any challenges that arise. This strategic approach can transform the client-vendor relationship into a powerful partnership for project success.

Change Management Strategies

Despite our additional up-front research for high-risk items, it’s crucial to keep in mind that changes to the requirements — also known as scope creep, are inevitable.

A change management strategy helps manage these changes and reduce their impact — keeping any additional effort within our calculated risk margin. The strategy features the following four processes:

Scope Baseline

The scope baseline is a reference point against which all changes are measured. It outlines the project’s deliverables, deadlines, and resources. By enabling provisions for amendments, we can build flexibility into this baseline without falling victim to uncontrolled scope creep.

Impact Analysis

This analysis considers how the proposed change will affect the project’s timeline, cost, quality, and dependencies. It’s a process of weighing the benefits of the change against its potential disruptions. This step is crucial in managing expectations and setting priorities, as it allows stakeholders to make informed decisions based on a complete understanding of the change’s implications.

Communication and Approval

This process begins with a well-defined communication chain that handles change requests and ensures everyone, from the developers to the decision-makers, is informed about the proposed changes, reasoning, context, effort, and implications.

Once a change request is communicated, it enters an evaluation stage, where the proposed change is scrutinised and either approved or rejected by the appropriate authority.

This systematic approach ensures that each change is understood, documented and aligned with the project objectives, controlling scope creep, managing expectations, and keeping the project on track.

Documentation and Traceability

I believe that having good documentation helps prevent issues in the first place, certainly before they can escalate.

Requirements change management documentation should include the details of all scope changes throughout the project. This includes each change’s impact analysis, communication log, decision date, and decision maker. This documentation provides a clear audit trail, ensuring all changes are traceable and accountable.

Accurate record-keeping manages expectations, providing a historical account of the project’s evolution and helping stakeholders understand the decisions made and their impact throughout the project lifecycle.

Final Thoughts

Managing expectations in large-scale projects with enterprises requires balancing upfront planning with agility and adaptability. Effective communication, clear role delineation, and proactive risk management are essential to this strategy, ensuring the project remains on track and aligned with its objectives.

In the next article, we’ll explore how creating a well-crafted Definition of Done becomes a powerful tool for managing expectations and ensuring that delivery truly meets stakeholder needs.

Who is Thomas?

Thomas is a highly accomplished digital transformation leader and Fractional CTO at MISSION+. With 21+ years of experience across FinTech, telco, logistics, and cloud transformation, he excels at bridging C-level strategy with actionable execution. As a prolific author, Thomas has written multiple blogs and whitepapers in which he shares his ideas around technology, project management, and problem-solving. Feel free to discuss your large-scale project delivery headaches with Thomas by reaching out at hello@mission.plus.