5 Lessons We Learned from Working on Big Industrial Projects

With each project, we learn more and more about industrial IoT. As we have recently completed the Kyotopia, we have a bunch of afterthoughts and essential guidance we wrapped up in 5 lessons learned. So how to run a large industrial project and not fall over?

1.Never underestimate the power of good planning

To estimate the project scale and so-called bottlenecks, you need good planning. With large industrial projects scheduled for many months ahead, a lot of unknowns always come. The better the planning, the more it should allow us to avoid some unpleasant situations that we can not anticipate.

Such an approach to planning takes into account various disciplines, in many cases, it would be designing software, firmware, and hardware. Each of them has its demands. Like hardware, which is strongly dependent on the availability of parts and whether everything will arrive on time.

The crucial thing is to define dependencies - what results depend on what actions are performed. That is because all things happen in parallel, they rely on one another, and it is challenging to embrace everything in such a way that no one ever waits for anything.

So, it is crucial to approach planning in a thorough and detailed way. It can be done by drawing up a timeline for each person or team representing different competencies. Developers need their own timeline, engineers another one. The business also requires separate tracking.

To ensure everything goes smoothly, we regularly compare the timelines and status of milestones on SCRUM events, updating and adjusting the scope and deadlines. Simply put, flexibility is key. If you want to learn more about it, go to the article: Why Is Flexibility Such a Valuable Trait in Software Development?

2. Everything the team works on must meet the business scenario

It is essential that each member of the development team knows what the business goals are. Everybody should be aware of:

• the business context, so what we are building and why,
• how the product is to bring value to the business or people.

That is not something that belongs only to people dealing with strategy or finance. It has to be presented to the whole team on an ongoing basis.

The development team must receive updates on the implementation of business goals or changes related to business and strategy.

So, on the one hand, we need careful planning simply because large venture projects involve many risks, and on the other hand, we should bear in mind the business context and keep the team informed.

3. Prototyping, improvisation, and validation - create a lab!

To develop a small-scale beta solution for the engineering project, we must build a laboratory environment. Thanks to this, we visualize the product for the team.

It's important to remember that when we say we're building something, each team member has a slightly different understanding of the end solution until they see the visualization. It may be in the form of a diagram, illustration, or prototype.

When we were working on the RES hardware project, we built a large system of pumps, valves, and pipes. Unfortunately, we did not have a natural scale prototype, so we worked with... a garden hose and big water bottles as liquid reservoirs. We also bought some valves, but you don't always have to purchase stuff. Again, creativity is the key - everybody needs to see the prototype work. Only through this, the team learns what exactly is to build.

Each hypothesis needs real-life validation to become the solution in the target environment.

There is no other way. So, there are two effects of building a lab prototype:

• validation of our product concept,
• making the team aware of what the end solution should look like.

Understanding the business context and organizing the laboratory allows the team to understand the target product and why it is worth creating.

4. Keep looking for the best solution

Don't insist on the first working solution. Instead, take those few extra steps, an extra mile, to ensure it's the only best reasonable solution for your case. Then, if it can be bettered, don't be afraid to change it.

The more we manage to optimize, the better the solution. Advanced products will be scalable, which is a great benefit for everyone.

5. Project documentation updated on an ongoing basis

When the team scales and new people come in, it's easier to onboard them and make them feel comfortable with their tasks. Besides, with such a large project that takes months, even the decision-makers can forget what was established a year or so ago.

The documentation must be live and updated after each sprint

So with documentation, if it is well organized and cataloged, we can reach every decision made every week. In fact, good documentation is not only a wikipedia of the project but also a notebook where all meetings and decisions are written down and interlinked, so you can go back to any decision that was made at a given time by that specific person. And this comes in handy. For example, when looking for those responsible for a given decision or those with exceptional merits for the project.

Knowledge cannot be kept in a person's head but should be accessible to the entire team and well segregated. When scaling the team, making or backtracking decisions, keeping a good record is necessary.

Bonus lesson: team bonds are a guarantee of productivity

Finally, a crowning jewel. That is teambuilding. Don't forget that all scrum events, lunches, or meetings are crucial for the team to operate smoothly. Keeping strong ties in the team makes everyone care more.

Do you want to work in a well-coordinated team where we like each other? Then, go to the Careers page.