One of the biggest challenges in this industry is making sure that everyone has a desire to succeed. Often there are multiple decision makers who are competing for the attention of those who are building and managing their products. This is something I understand well.

Through the years I have worked with a number of companies and worked under some very challenging constraints. Sometimes the thing that you need to succeed is just not available to you and you have to hope that the people in charge of that aspect keep the ball rolling.

Sometimes everyone working on the project does their part, all the I’s get dotted and all the T’s crossed, and the result is something that everyone loves. Other times, the portions of the project that are beyond your control go horribly wrong and there is nothing you can do but watch.

In the last 10 years I have experienced all of these situations. The best thing that I can do is take what I have learned from those experiences and apply them to the next project.

What Causes Failure?

In my time managing projects I think that the biggest cause of project failure is bad communication. Poor communication has many different heads. Sometimes it is the project manager. Despite a clients best efforts to communicate their needs to them, those desires don’t get translated into stories and tasks in a way that the project developers understand. As a result features get lost or misconstrued and the end product doesn’t have the congruency the client was asking for.

Many times the client doesn’t understand the development process and as a result, doesn’t clearly communicate the product specifications. This tends to result in a misunderstanding between the developers and the client that manifests itself with missed deadlines, scope changes, and blown budgets.

One of the most common causes of failure I have seen is the result of an under-defined product idea. Most of the time I am presented with an idea that the client thinks is complete and well thought out, but in reality only defines an end goal. This situation is often magnified on the software side of things because what someone sees is only the tip of the iceberg. They often imagine a product that is working, but never think about the path to get there. That path is almost always far more complex and multi-faceted than they ever imagined.

Let me share an example of a somewhat typical IoT project to illustrate this situation:

A company is looking to bring internet of things capabilities to their exiting product lines. This company already has a strong social media presence, a website with content and a web store, and a marketing team. They envision an app that talks to their new hardware, allows users to monitor and control it, order accessories, consumables, and replacement parts, make notes, store user content, integrate with social media, present all of the existing web content, and best of all is easy for their existing customers to use.

In their mind, the only part that is missing is the new hardware, and an app that “controls” it. In their mind, because they have a social media team, a web team, fulfillment team, and a marketing team, all of those aspects of the new product are already in place and the only piece of the puzzle left is to hire a new team to build the tech. It never occurred to them that they are asking for much more than a remote-control, but are asking to build a micro-platform for their products. While they their existing teams are working well together, they haven’t yet considered that adding a new team and platform might change the logistics of their entire company.

If these things aren’t communicated clearly, the end result is usually sub-par and built with the frustrations of everyone involved.

In a situation like this, what exactly needs to be communicated, and who does it need to be communicated too?

The Disruptive Nature of IoT

Yes, IoT is disruptive. Most companies think of that disruption in terms of shaking their competition. They expect that their monetary investment into new industry leading tech will leave their competition in the dust and increase their sales overnight. When most people have the idea of bringing IoT into their products they almost exclusively imagine the successes while realizing that they will need to hire a new team to carry it out. What they often forget is that IoT is so incredible because it ties nearly every aspect of their product together. It’s that internal disruption that is often forgotten.

Define Features and Roles for Each Team

When the end goal is to simplify the user experience for the customer that means that the hardware and software need to take on the work of each existing team.

Fulfillment will need to facilitate a way for the developers to access the the product libraries and make orders.

Marketing will have to incorporate app content into their campaigns.

The Web developers will need to work with the app developers to help them understand how to access the content databases. Sometime this means completely revamping the existing database structure. I’ve worked with companies who’ve insisted on integrating existing content that wasn’t ever designed to be consumed by anything but their website.

Discuss desired workflows in each department.

One way to alleviate the pain of these changes is to understand the current workflow and try to find or build systems to work within those constraints. If changes must be made, find ways in which you can incorporate those changes while improving the existing workflow.

For the marketing team, find a way to help them share content in a way that allows it to be consumed both on the web and in the app. This usually means coordinating with the web development team to come up with a deep linking protocol.

Discuss with fulfillment ways in which they would like the orders from the device or app categorized. What information would be useful to them and what information doesn’t matter. Assumptions about these things almost always cause issues later on.

When you make sure to involve and consider the needs and desires of each team it will help them take ownership of their portion. When that happens you are much more likely to meet deadlines and receive the necessary deliverables on time. Without it you are likely to left with missing features, partially implemented integration, and resistance to the changes that could make the product a success.

While not all smart devices are going to be disruptive, in a situation like I’ve presented here a great deal of effort needs to be taken to communicate to all of the teams involved that their processes will have to change to incorporate this new technology.