Managing Expectations in Large-Scale Enterprise Projects — Part 1

By: Thomas J. Smart

Welcome to managing expectations.

Here, we will explore a foundational understanding of expectations and how to manage them. Mostly, this managing of expectations is in the context of projects — in my case, based on experiences related to cloud strategy and application development.

Sometimes, projects go off the rails, resulting in a complete breakdown of the relationship, and sometimes projects go off the rails, but together, we work through the issues, the relationships remain strong, and the project ultimately succeeds.

I have found that while a strong underlying relationship with the stakeholders can help, the root cause of successfully making it through such setbacks is often due to how expectations were managed before and during the situation.

Why Expectation Management Matters

Let’s start with two simple project delivery cases to illustrate the value of managing expectations. Note that while both scenarios result in practically the same outcome, each of them is perceived differently based on how expectations were managed.

Scenario A

A team estimates the project will take 25 days. However, it is delayed due to changes or unforeseen circumstances and is only completed after 30 days.

Quality suffered, and mistakes were made as the delivery team was under stress due to missing the deadline and the stakeholders were unhappy due to the delay and the additional five days billed. Such friction can lead to arguments, finger-pointing, and frustration.

Even though the project was eventually delivered, the perception of the experience will be negative.

Scenario B

A team estimates the project will take 30 days. Like scenario A, it was completed after 30 days, but in this case, the delivery team had an extra five days before the agreed deadline.

This resulted in less stress and fewer mistakes. As a result, they even had time to put in some additional effort to improve the quality and user experience before the deadline. The stakeholders are happy as the project is completed as estimated.

Overall, the perception of scenario B is that it was more successful, even though both A and B were completed after, and billed for, the same number of days.

The Takeaway

Perhaps the team calculated a more accurate estimate in scenario B, or a more cautious project manager applied higher error margins. Either way, the crucial difference between these is that the result of scenario B matched the expectations set at the beginning.

Key Factors Impacting Expectation Management

From our mental models to our attitude towards arguments, here are four general factors responsible for how we set and manage expectations.

Human Psychology

At the psychological level, humans are wired to establish mental models that describe how various situations should unfold.

These models are influenced by past experiences, experiences described by others, personal and cultural biases, social norms, education, emotional states, media exposure, peer pressure, cognitive abilities, personality traits, and even seemingly insignificant factors such as mood or environmental conditions at the time of forming the model.

Each component helps shape the mental models that guide our expectations. The ability to identify and understand these influences on stakeholder expectations is powerful in project management.

As projects unfold, circumstances that don’t align with predetermined models are what we refer to as unmet expectations. This discord can be distressing, potentially leading to strong emotional responses such as frustration, disappointment, and even anger.

Assumptions

We make a lot of assumptions, as our brains constantly work to provide us with a complete picture of reality by filling in the gaps. Let’s look at two examples of how assumptions negatively affect expectations management.

Projected assumptions are when we view observed behaviours in a certain light based on our past experiences. For instance, if a team member ignores your call, you might think they are upset at you since you tend to perform similar behaviours when you’re upset. However, the reality could be different since your colleague might be unable to take your call because of a busy schedule.

Assumed mind reading is where we have a particular expected outcome in mind, again, often based on our own personal experiences with similar situations or what we perceive as normal. For example, you might think it’s normal for deliverables to be tested as part of the task of delivering them. If you don’t communicate this assumption to the delivery team, you will be upset when the deliverables arrive untested, while the team will be confused since they didn’t receive the relevant instruction from you.

The best way to mitigate these assumptions is through clear communication. Clarify requests and reasons using curiosity and diplomacy, not accusations. Normal is subjective, so never assume that other people’s approach will match yours.

Being comfortable saying NO

Most of us are happy to help others when we can, but well-intended short-term help can have an undesired negative long-term impact. A strong Agile approach to a project can help mitigate this to a degree, but there are plenty of reasons why not all teams or projects can run fully Agile.

For example, agreeing to fulfil a small stakeholder request alongside your planned work may not seem like a big deal. But it’s all too easy to underestimate the time of completion, especially for inexperienced engineers. The seemingly small request ends up taking a whole day due to additional change requests and sub-tasks for resolving any issues that come up.

This unplanned task causes a delay in completing the work that was actually part of the scope. As a result, other team members’ productivity may be affected, creating unnecessary friction within the team.

In consulting engagements, I tell members of my team that the default answer to new requests is “no, but….”. Following that “but” is typically a response such as “We will add it to the backlog and can discuss prioritisation in the next planning session” or “I will let the site/delivery lead know, and they will get back with a proposal”.

We need to achieve two things with the response:

1. Clarify that we can’t immediately jump on new requests without proper consideration and planning. New requests must be assessed for impact, effort, and potential risks before committing to delivery.
2. Inform them that their request will be taken seriously and an appropriate response will be forthcoming soon (optionally, via the proper channels).

Healthy arguments

Arguments can be a sign of a healthy relationship. It means that there are different views (that team members may feel passionate about) that are being discussed and challenged.

A complete lack of healthy arguments typically means one of three things.

1. There is complete acceptance of the other party by either party. Both parties accept that the other may do things in their own way. It may not be the same approach they would take, but they will accept the result as it is the outcome that matters. This is a very evolved relationship, usually only achieved after many collaborations.
2. Both parties have essentially given up on the relationship and stopped caring. We see this in projects that have gone badly, and both parties have resigned to never working with each other again, but a few tasks must be completed to wrap up this project before they can move on. These relationships have typically already ended, merely going through the final motions due to the demands of work.
3. Frustrations and disagreements are not being discussed but suppressed. There are many reasons for this, from lacking interpersonal skills or trying to be polite to a fear of confrontation or having other priorities. The problem is that the frustrations are still there; they are just not being addressed and resolved in time, creating problems and heated arguments later in the project.

Situation three is the most common, certainly for team members collaborating for the first time. In this context, what may be perceived as being polite is really a form of poorly managing expectations. A strong delivery lead will manage this with regular touch points and create a safe space for open discussion, feedback, and sharing of different perspectives for any given problem.

Final Thoughts

I firmly believe that managing expectations is not merely a side task in project management; it is central to project success. It requires continuous effort and adaptability in the form of adjusting our mental models, communicating assumptions, learning to say “no, but…”, and having healthier arguments.

Over the next few weeks, we’ll explore the six key stages of the project lifecycle, from writing RFPs to the final handover, to see how each can be optimised for successful expectation management.

At each step, we will consider two perspectives: the organisation (the client or stakeholder requesting the project) and the vendor (the team responsible for delivering the project).

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 project delivery headaches with Thomas by reaching out at hello@mission.plus.