This is the cornerstone of stakeholder satisfaction.
The anchor to success in the complex world of delivering software projects is deliberately setting and hitting delivery expectations.
The team owns the definition of what to expect and when. Of course there are negotiations and often debated scope items, trade-offs, etc. but ultimately the team is in control to define what a “successful delivery” looks like before you are in the throes of project execution.
To do this, one must be intentional, factual, crisp, and respectfully blunt, so that everyone gets on the same page. It’s a delicate, and sometimes long, process to ensure all team members and stakeholders are aligned on the plan.
There are a lot of subtleties in communication depending on your stakeholder, team members, user base, etc. so tap into your EQ and tailor, negotiate, repeat, and reinforce to achieve this alignment.
Pay special attention during pivotal moments like project planning, recalibration, and key decision-making.
It’s easy to assume people are aligned, or have heard/read information disseminated. This is dangerous and often leads to future misalignment further into a project or people “forgetting” or disagreeing on what was previously agreed upon.
Where to start?
Make sure to confirm that people read/hear what you are writing/saying by using some of the following methods to ensure (or force) this alignment:
- Asynchronous document reviews: Can people review what is planned offline? Is there engagement with project documents like commenting and suggesting edits?
- Live kickoff (or plan reset) sessions: A more formal stage to review (updated) scope, goals, and timelines, and get live approvals.
- Individual stakeholder meetings: One-on-one time with key individuals to guarantee detailed review and personal buy-in.
Alignment on delivery expectations doesn't stop once you have a plan everyone agrees on.
Over-communicating known issues, maintaining a feature list, keeping a log of decisions and out-of-scope items, and sharing release notes are all practices that keep expectations managed and trust intact throughout the course of a project.
If a date is going to be missed, immediacy and transparency in communication is key. Don’t wait to sound the alarm or keep a known risk under wraps. Delaying this message can result in losing your client's/team/stakeholders’ trust.
Building and maintaining this mutual trust is the foundation upon which all successful relationships and projects are built. Communicate early and often. That's how you turn projects into partnerships, and clients into advocates.
When to reset expectations
Everyone should know where a project stands. Always.
Projects inevitably hit bumps in the road: a lost or distracted resource, unforeseen challenges, scalability issues of a 3P tool, new scope requests, slow response times, etc.
So, what's the formula for deliberately, & tactfully, resetting expectations when faced with these various scenarios?
- Recognize that your plan is off track, i.e. expectations will not be met. It’s easy to keep on motoring with your head down but you have to take time to zoom up and look at the broader delivery picture.
- Recalibrate your plan ASAP with the new information such as a change in headcount, additional effort for new scope or challenges, etc. Do this due diligence and don’t commit to new timelines or scope items on the spot. It takes time to assess, understand the new/remaining effort, and potential ripple effects.
- Use second-order thinking: Look ahead at various outcomes for near-term decisions to inform the present. Avoid reactively responding to pointless requests by thinking through effects — and effects of those effects — from the start.
- Craft your communication with new delivery expectations carefully. Be concise but also cover key aspects like the cause(s) of the shift, impacts, trade-offs proposed/made, new assumptions, etc.
- Ensure/force realignment with all involved parties and document the sign-off on the new plan.
- Start working towards new delivery goals immediately.
It's a delicate art to reset plans and expectations. You need to be realistic (or even pessimistic when planning) but you don’t want to swing too far. You need to be intentional and factual but you don’t want to cause panic.
You want to shut down all new scope requests but you have to keep the overarching objectives in mind as these changes are often warranted and flexibility is required.
Managing emotions and anticipating reactions during plan (re)sets is a hard job. Be honest, use finesse, and stick to the facts in your communications.
It may sound easier to avoid these crucial discussions but a project will only be deemed a success if everyone is aligned upfront on what the end outcome will be and when.
Predictability without hard dates
Stay as far away from hard delivery dates as possible.
Of course this isn’t realistic in most settings such as a public company, a private company that values predictability, or a manager who is accustomed to having target dates. With or without these external team pressures, predictability is extremely valuable.
If you/the team doesn’t have an understanding of when something will arrive, progress, effectiveness, or success can’t be measured. The tough part is, dates freak people out.
The key is to stay as broad as possible when communicating ETAs and get more granular throughout the course of a project.
Here are some rules to follow depending on where your team is in a project lifecycle:
Discovery
- Set a target date for when the delivery plan will be established for review/sign-off, not a date for the full product to be delivered.
- A quarter goal is typically common at this phase. Note, a “goal” is not an informed target set by the team but rather the requested time frame.
Baseline plan
- Set a target quarter aligned with the goal quarter (this may be the original goal or it may shift during planning and initial discovery.)
- Try to stay at the quarter-level for long projects (e.g. over 2 quarters), but if that doesn’t fly, try early/mid/end of quarter. I’d be very apprehensive committing to anything more granular than target month before development has begun in earnest.
Execution
- Gradually increase granularity as the project progresses, risky areas are better understood, team velocity is more predictable, etc.
- Here’s a possible progression: target month > mid month > target week (once w/in 4-8 wks from launch) > target date (once w/in 4 wks from launch.)
Still need a HARD DATE?
If the above progression doesn’t fly and you must set an actual date, follow the above rules and pick the last date of the given time period.
So if it’s Q1 2024, set your date as 3/28/24 (since 3/29 is a Friday and 3/31 is a Sunday). If it’s mid March, go with 3/14 (since 3/15 is a Friday). If it’s the week of 3/18, go with 3/21 (since 3/22 is a Friday).
You’ve likely noticed, don’t pick a date that is on the weekend or Friday. I prefer Tuesdays so you have Monday for last minute prep and W-F for support/letting any dust settle before the weekend.
Setting targets is a bit of a game.
Dates hold weight and leaders all-too-often latch on to the first one they hear, so tread carefully. If you aren’t confident in your delivery message, either go back to planning mode & buy time, or communicate confidence levels loud and clear. E.g. "We're 60% confident that the timeframe is doable, pending further technical discovery of a & b."
This avoids others taking the date as an absolute and (hopefully) leaves room for the necessary adjustments as the project progresses and risk decreases.
How do you discuss delivery timeframes without freaking people out?
Predictability is essential to quality product delivery but most people run for the hills when you start bringing target dates up too early. Stay as broad as possible when communicating delivery timeframes and get more granular throughout the course of a project.
Here's a visual of a progression that works for me:
It’s a bit of a game of chess, but as long as you continually set expectations properly (alongside important caveats/assumptions and the team’s confidence level), you will set your team up for success, even when the plan inevitably shifts mid-flight.
When and how do you estimate + track your delivery ETA?
As a project leader, at any moment someone may ask you… “Are we on track for launch?” or “Is the project status green, yellow, or red?”
The only way to know how to answer these questions is to consistently track your delivery ETA. Here is my evolution of knowing where a project stands:
- In Discovery, I’ll tell folks when the target will be confirmed. E.g. “In 3 weeks, the team will have a better understanding of timing.”
If I have a sense of whether or not the requested delivery goal is in the ballpark, I’ll start setting expectations to avoid surprises down the line. E.g. “The goal of Q3 is unlikely given the current scope, so during planning we’ll work through what has the most flexibility — scope, resourcing, or timing.” (i.e. yellow or red)
- To reach a baseline plan, I collaborate with the team on high-level estimation.
This does NOT mean document every story and estimate each with points. That is a lot of waste when the plan will inevitably change.
Instead, estimate high-level categories (about epic-level size) with t-shirt sizes (or jump straight to days given the team’s preference). Don’t forget broader items like end-to-end testing, UAT, etc.
Now a target timeframe can be compiled.
If the sizing doesn’t land where desired, negotiations begin on scope, resources, or time. At the end of planning, all must be aligned on what to expect when.
- During development, I don’t look at story points or sprint burndowns. Instead, I maintain a weekly pulse by watching collective team throughput and if weekly goals are met (more in a future post on this).
I’ll informally track a suspected 1-3 week slip early in a project, specifically if there are planned mitigations and time is likely recoverable.
However, if a slip keeps increasing or is not decreasing over time, it’s time for a reset. The earlier the better to avoid surprises downstream. Other catalysts for resets (vs the rough tracking based on weekly output) include, but not limited to, resource shifts, new scope items, a large unknown unearthed, etc.
To do a plan reset I go back to the initial high-level estimation (step 2) and zero out items that are complete. Reconsider estimations for items not yet complete as the team will collectively know more further into the project. Recalculate the expected ETA and go back to negotiations as needed. E.g. “Can this scope item be cut to maintain our original target timeframe?”
Once alignment is reached (again), contributing factors to the reset are documented, and clear expectations are set, back monitoring weekly delivery pulses again (step 3). Then rinse and repeat depending on what obstacle the project throws next!
It may be your inclination to avoid these discussions but raising the alarm (in a calm, controlled manner) isn’t a bad thing. It often gets the team the support needed to get things back on track and green again.
Look at output not story points
During development, I don’t look at story points or sprint burndowns. Instead, I maintain a weekly pulse by watching collective team throughput and whether or not weekly goals are met. For example, ask yourself and your team:
- Did the team complete what they set out to for the week?
- What is demo-able now and what will be demo-able next?
- Are interim deliverables being met?
- What incremental work is complete towards an interim deliverable?
- Is the team ramping up as expected?
- Has there been new scope without removing scope?
- Have items roughly taken longer than expected, shorter, or about what you thought?
- Has there been a steep learning curve with slower throughput than planned?
All of these questions are rough indicators towards progress.
Working towards and looking at actual output is far more valuable than the perfect Jira implementation with charts that show points/time remaining (burndowns) or points deferred (because this inevitably happens… all the time).
Use your limited time instead to stay in touch with the latest changes pushed, make sure deliverables are being met, and the team has things to demo routinely. If not, it’s likely time to tune in and consider revisiting your high-level estimates and baseline plan, and possibly your approach for your specific team and environment.
Disclaimer: There are always exceptions. Some project types, junior to mid-level teams, newly formed teams, engineers who prefer story points usage, or differing environments call for story points and more detailed tracking, but you cannot forget the tangible outputs as well.
If you want to deliberately set and meet expectations, showing progress is where your and the team’s time is best spent.
Follow Kim on LinkedIn
Kim uses LinkedIn to share her thoughts on product delivery, prioritization techniques, and enterprise product development and design.
Follow and engage with her here.
