I thought I better discuss setting realistic expectations in todays post. Because it’s a term I have been using a lot recently.
Personally, I think it’s an important thing for us all to do. Because I think sometimes we have a responsibility to state these things to others.
For example, as I mentioned in a previous post I’m currently a Product Owner for a large number of SQL Server instances. You can read that post in detail here.
Part of doing that role means that I have had to set a lot of realistic expectations with stakeholders. For example, realistic times that they can expect things to be delivered.
To justify this, I usually have to explain the other priorities in the business, current roadmaps and existing items in the backlog.
Doing this can also bring other benefits as well. Because it helps to gain trust and understanding with your stakeholders. Which consequently helps you to manage priorities for your backlog items, if you are using scrum.
In addition, setting realistic expectations avoids anybody being disappointed. Especially when they go to deploy something you have shown them, and it takes a long time to deploy.
In fact, not only can they end up disappointed, they might also question what you have told them. However, if you’re honest and you tell them how long it takes up front they have a lot more respect for you.
For instance, I’ve started setting realistic expectations more when it comes to discussing various items. For example, how long it takes to deploy Azure SQL Database Managed Instances.
Which is something I have noticed that Microsoft now warns you about if you deploy a Managed Instance in the portal.
You can see this for yourself if you read their guide on how to deploy a Managed Instance. Which you can read in detail here.
I hope this post convinces some of you to set more realistic expectations. I think it’s something everybody appreciates and can provide many benefits.
If you’ve found setting realistic expectations useful as well feel free to share your experience with a comment.