Why is expectation management in IoT so important?

I remember sitting in a Mexican bar and reading all the inscriptions on the wall, one stuck with me:

If our food or services don’t meet your expectations, please lower your expectations!

I wanted to put this in a separate article as it is one of the easy key factors that can define the success of an IoT project.

Why is this important?

If you have done one then you probably can relate to this.

IoT projects are usually long projects, very long sometimes, with often a lot of uncertainties. Not really an integration projects but more similar to a product development project with lots of iterations.

On top of that there are dozens of new unknown tools and processes to evaluate, dozens of decisions that need to be made that all impact the bottom line.

And just like 9 woman that can not make a baby in 1 month.. even with the best will in the world, an IoT project will take time.

Projects of 2 to 3 years are no exception, it always costs more than budgeted and also, over a period of a few years, lots of things can change in the vision and strategy of companies.

But the gold at the end of the rainbow is what keeps people moving.

Still, this gold might seem far away..

And… I can promise you, someone will get impatient in that time and will challenge the core reason of the project if there is no “integration like” structure.

You’ll feel like your defending yourself and your team till the finish line, if you even get there.

Before you start with expectation management, you will need to know what you are up against.

As an analogy: Just like a watch IoT is made up out of different gears that all connect. Forget one component and the watch won’t work.

So… get some advise if you’re not familiar with IoT i-IoT, data driven organization, industry 4.0 and all of the buzzwords that mean anything and nothing.

Think a bit on how you will keep your project going in a storm with the ship going from left to right..

Expectation management is about bringing consistency in your messaging, tackling bias, and basically, making sure that everyone is, and stays on the same page.

“Let’s go for a walk” is not the same thing as “let’s go for a 30 km walk in the rain”. Still people might prefer the 30km walk if, at the end, the reward is big enough..

Companies like structured integration, IoT not so much, so let’s find a middle road.

Getting structure with targets you can keep is definitely one of the foundations of expectation management but near to impossible.

Unless if you cheat or look differently at targets.

Defining the different phases and targets of an IoT project on a timeline makes a solution transparent..

How can you cut your project in phases when it looks and feels like one big interweaved mess that goes back and forward like a ball in a pinball machine.

I gave up putting everything in a Gantt chart. I was spending more time in updating it than that is was useful.

But phases and targets need to be set if you want to keep credibility..

No traditional phased approach in IoT

So we have to move out of the box to get everything in a box…

The phases and targets we define in IoT for C level are not the same phases we would traditionally use.

The end of an IoT Phase is at C level not defined by completed tasks, but by the end of a “general period of focus” (so with predetermined end date).

It might sound counterintuitive in a development cycle but fix end-dates are an excellent tool to bring IoT, that looks and feels like an exotic product development, in a more business familiar structure.

This then will make expectation management a lot easier.

Let me give you an example:

Here I have split everything up in 6 IoT Phases

• Research – research probably goes on up to “roll out” but the bulk of the research, the foundation, is defined and done here. What is still open goes on a roadmap.
• Analysis – This is actually a continuation of the research phase but you put most focus on ballpark figures. This will give an indicative TCO and ROI. Probably you can also finish the general design, the process and business architecture but if not, then it goes on the roadmap.
• Test – Do a “proof of concept” or “pilot” – During this phase most critical elements are field tested. Getting rid of most of the unknowns. I want to stress that different components might float between phases. As an example: Some people already do a technical POC as part of the analysis or research but it will remain part of “this phase” reporting.
• Validation – Validate the different elements or the technology or the process. Validate with internal and external stakeholders. This feels like a milestone that can be done in a few days but remember you might need some time to look for different components.
• Build – Bringing different components together to create an MVP, what doesn’t fit is put again on a roadmap. You will probably have started development already before this phase but it will need to be completed.
• Roll out – Deploy your solutions even if there are still different iterations to be done. Just get a real bare minimum on the table and do as much of the backlog as possible.

Special to this model is that all Phase blocks have the same size – a 2 year project would have 6 blocks of 4 months

This way will allow you to get everything in a rigid structure for your internal stakeholders but will give you the freedom to work in parallel on the different challenges.

Please note that this is only for the C level – Individual tracks like hardware integration or development probably will follow traditional sprints.

Recommunicate the long-term goals at every occasion.

Just a tip that helps with expectation management:

“Get a clear vision and mission of the project”.

Don’t let anyone ever forget why you started this project überhaupt.

Why is it a strategic project? List the benefits, the risks, the uncertainties, use language your peers can identify themselves with.

Then use it as standard opening slide and a short version for internal communication in combination with the phases.

Make sure you put the goalpost far enough from day one.

Not only for the stakeholders but also for yourself. Get a realistic view, check with your peers that have done similar projects or initiate a project with an experienced IoT mentor.

It is tempting to set the timeline as short as possible but don’t, there are too many dependencies.

Get your stakeholders really involved.

Yes people ignore mails..

Better that an email is a 15 minute update call, much harder to ignore. Some of the stakeholders will need to take part in the next steps, make sure they don’t lose track of their responsibilities and that they stay positive during the project.

Once a month, if they are not involved, can be enough to ensure your colleagues have your back when the weather is rough.