AMR-One. 02 Product Requirements

Today I will talk about "Product requirements”, from a conceptual point of view, and how they have been handled under the AMR-One Project, where an autonomous mobile robot for the industry is developed.

The concept

Requirements Engineering is one of the processes of Systems Engineering, that is focused on defining, documenting, and maintaining requirements. 

In the Waterfall Model, requirements engineering is presented as the first phase of the development process while Agile Methodologies, like Scrum, assume that requirements engineering continues through the lifetime of a system.

Basically, a requirement is a singular documented need that a particular design, product, or process must be able to perform. 

Once all stakeholders are aligned, the requirements serve as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

The steps

The steps to follow with the requirements are in summary:

1. Eliciting and expressing requirements (getting the Requirements from the client)
2. Prioritizing requirements, for example in the form of:
• Must be done
• Should be done
• Could be done
3. Analyzing requirements to ensure they are complete, clear, and consistent
4. Analyzing also requirements from the technical point of view to ensure they are feasible in terms of time, cost and execution.

Types of requirements

When defining requirements it is good practice to cover several types of requirements, like:

• Business requirements (Define why the product is needed)
• Business rules (budget, policies or regulations, brand uniformity requirements,…)
• User Requirements (what tasks the users can do with the product)
• Functional Requirements (describe what the product should do)
• Non-functional Requirements (describe how well a product must perform)
• External interfaces 
• Physical settings
• Development constraint

In the following video, you could see this more in detail and how requirements are applied to the AMR-One Project, where an autonomous mobile robot for the industry is developed:

AMR-One. 01 Product Strategy and Roadmap

This is the first on a set of posts about the project AMR-One. 

AMR-One Project's scope is the development of an autonomous mobile robot for the industry. The set of posts covers not only the technical part but also project management and strategic concepts.

In this post we will mention the strategic part of the product, talking about the Product Strategy and Product Roadmap.

A Product Strategy is a high-level plan that defines your product goals throughout its life cycle and how it will support the organization’s goals. The product strategy will also answer who the product will serve and how it will benefit them.

These plans are then brought to life on the roadmap.

A Product Roadmap is a plan of action for how a product or solution will evolve over time. Product owners use roadmaps to outline future product functionality and when new features will be released.

To build a roadmap, product owners should consider market trajectories, customer value propositions, strategic goals, and effort constraints. Once these factors are understood, the product owner can work with their team to start prioritizing initiatives and epics on the roadmap.

The roadmap should be updated as often as necessary so that it can remain an accurate source of truth.

Having that roadmap we should go ahead with the Product Lifecycle Management, which is the process of managing the entire lifecycle of a product from its inception through the engineering, design, and manufacture, as well as the service and disposal of manufactured products.

See my previous post: 5 tips on ... Product Strategy & Product Roadmap

See the following video on how these concepts are applied to the AMR-One project:

AMR-One. 00 Introduction to the AMR-One Project

This post is the introduction to the AMR-One project series, a set of posts and videos on how to plan, manage and execute a technical project as well as on how to technically develop an autonomous robot.

The AMR-One project objective is to develop a prototype of an autonomous mobile robot for the industry, as a personal project, with some basic characteristics:

• Rotational base with damped traction system
• Safety system
• Pinhook system to hook trolleys from the bottom and carry them.
• Two navigation modes:
• Magnetic band guidance with RFID tags control
• SLAM based navigation using ROS
• Cloud monitoring (over AWS)

High, this is Alejandro Alonso and I will be here, through this interesting trip, where we will explore the details of this fascinating project!

During the following posts I will cover:

• The product strategy, roadmap, and product requirements (basic to have good focus and scope definition).
• The project management aspects, including
• The project management plan (rules on how to manage the project)
• Work breakdown structure (tool to identify the tasks)
• Planning from an agile perspective, including the Gantt and dependency graph as well as backlog and sprints plan
• Risk management, 
• Cost and time control
• Change management control, to approach correctly any change in the project
• The technical design, covers:
• The architecture of the system, both hardware, and software
• Electrical design
• Mechanical design
• Software design
• The manufacturing process, using modular structures and a few 3D printed parts

See the following introductory video.

I hope you enjoy this trip with me. Let’s make robots!

Cloud Monitoring for robots as IOT using AWS

AWS is a great Cloud Computing platform for many applications. Here I describe how I integrated ROS based mobile robots with IoT (IoTcore), Elasticsearch (Opensearch), and Kibana (OpenSearch Dashboards) to get Cloud Monitoring.

This video explains that under a personal project named "AMR-One" that covers the design and development of AMR-based solutions.

Link to the video: https://youtu.be/k_uQZ-rj-6M 

Related posts:

• Cloud Computing for our exponential world
• Is Amazon AWS Robomaker worth it?
• Is ROS ready for industry?
• ROS, for more than proofs of concept

The Project Management Plan

[3 minutes reading]

The Project Management Plan is defined as the document that describes how the project will be executed, monitored, controlled, and closed. In my previous post I explained the early steps before preparing it. 

I would say that one of the most important keys to preparing a good Project Management Plan is to understand why this document is needed and how it could really help the success of the project. 

This document, as mentioned at the top of this post, describes the rules for the execution of the project. We need to understand that in a project there might be many people involved and many phases to execute. It is key to have a common point of understanding of the rules for the management of the project, so anyone could read them when needed. Rules could change of course, but always under some kind of control.

Source: PM illustrated

The Project Management Plan could include the following important sections and components:

• Scope management plan. Establishes how the scope will be defined, developed, monitored, controlled, and validated.
• Scope baseline. The scope baseline provides the project and product definition.
• Requirements management plan. Establishes how the requirements will be analyzed, documented, and managed.
• Project life cycle description. The project life cycle determines the series of phases that a project passes through from its inception to the end of the project.
• Development approach. The development approach defines whether waterfall, iterative, adaptive, agile or a hybrid development approach will be used.
• Schedule management plan. Establishes the criteria and the activities for developing, monitoring, and controlling the schedule.
• Schedule baseline. The schedule baseline is used to assess the impact of the changes in the project schedule.
• Cost management plan. Establishes how the costs will be planned, structured, and controlled.
• Cost baseline. The cost baseline is used to assess the impact of the changes to the project cost.
• Quality management plan. Establishes how an organization's quality policies, methodologies, and standards will be implemented in the project.
• Resource management plan. Provides guidance on how project resources should be categorized, allocated, managed, and released.
• Communications management plan. Establishes how, when, and by whom information about the project will be administered and disseminated.
• Risk management plan. Establishes how the risk management activities will be structured and performed. 
• Procurement management plan. Establishes how the project team will acquire goods and services from outside of the performing organization.
• Stakeholder engagement plan. Establishes how stakeholders will be engaged in project decisions and execution, according to their needs, interests, and impact.
• Change management plan. Describes how the change requests throughout the project will be formally authorized and incorporated.

Not all these sections are mandatory. Of course, tailoring practice depends on the kind of project and complexity, company culture, and other factors. But in general, I consider it good practice to have all of these sections included as they cover most of the key important aspects of a project. 

---

Bibliography:

• PMBOK
• Before starting a Project

Before starting a Project

[3 minutes reading]

So you have a nice corporate Products Roadmap (see my previous post 5 tips on ... Product Strategy & Product Roadmap) that includes the products that will help your business succeed. Now let’s start with its execution, step by step.  

These steps are defined in the phases that compose the project life cycle (not the product life cycle). In this case, I will consider how PMBOK groups these phases. 

There are some initial steps that are quite common in all kinds of projects, even if they use Linear Process models or Iterative Process models (see my previous post 7 tips to choose a Methodology for Software Development): 

Source: Project Management Body of Knowledge (PMBOK) seventh edition

Pre-Project Work

This phase is where we should evaluate in some detail the real business need of the project and the estimation of the costs through the preparation of the Business Case document. It might be a very detailed study or just something simple and quick depending on the project, but is something key to work on. It is not uncommon to find companies that jump from the corporate Products Roadmap (if they even have one) to the project execution, and this directs them to big holes of investment in projects with no clear ROI.  

A Needs Assessment often precedes the Business Case. The Needs Assessment involves understanding business goals and objectives, issues, and opportunities and recommending proposals to address them. 

The project Benefits Management Plan is the document that describes how and when the benefits of the project will be delivered and describe the mechanisms that should be in place to measure those benefits.

Starting the Project

So we have this Business Case that gives us some understanding of where we are investing the money from the company. Well, the next step is to prepare a Project Charter. This is a formal summarized document that includes the following information:

• Project purpose;
• Measurable project objectives and related success criteria;
• High-level requirements;
• High-level project description, boundaries, and key deliverables;
• Overall project risk;
• Summary milestone schedule;
• Preapproved financial resources;
• Key stakeholder list;
• Assigned project manager, responsibility, and authority level; and
• Name and authority of the sponsor or other person(s) authorizing the project charter. 

This document is approved by the Project Sponsor and when it is signed, gives the Project Manager full authority to start the project. 

Many people see this document as “another boring document that the bureaucracy of the company demands” but this is not at all that. It is a key document to understand the whole key elements of the project from the management standpoint. Without it, management might take decisions without enough global vision of the project.

Once the Project Charter is approved I recommend going ahead with a kickoff meeting. It is the first meeting with the customer or sponsor and the project team, to give a vision of the project. Many companies do not pay enough attention to this meeting, but it is crucial for the success of the project as we will involve the team in the project from the beginning. This will help identify risks and help in the planning process.

Organizing and preparing

Here is where the Project Management Plan is prepared. The project management plan is defined as the document that describes how the project will be executed, monitored, controlled, and closed. It includes all the rules of the game of running a specific project, including the methodology we would like to follow.

This part is so important that I will dedicate my next post to this subject, so I see you then!

---

Bibliography:

• PMBOK
• 7 tips to choose a Methodology for Software Development

5 tips on ... Product Strategy & Product Roadmap

[5 minutes reading]

Product Strategy defines what your product should achieve and how that supports the organization, and is brought to life through the product roadmap.

A Product Roadmap is a high-level summary that shows the vision and direction of your product offering over time. It is a key strategic document as well as a plan for executing the product strategy.

Clearly, both are key for a product-focused company, and many books, posts, videos, courses talk about it. Here I will just share with you a few key tips that I learned from my professional experience in the software and automation business. I wish these tips will help you to get a successful business.

Tip 1. Product strategy and roadmap should support market needs. It is sooooo common, especially for small companies, to focus on what they want to do and not what the market wants to use and pay for! This is a very common mistake and might put at risk the survival of the company. Recommendation: Base your decisions on market analysis, conversations with customers, demo prototypes, proofs of concept, or even sales experts' gut feelings, but consider the customer needs, not your desires.

Tip 2. Your customer is your mate. Many companies just see customers as the people or companies that pay for their products, but customers should be seen as colleagues, mates to ensure we build a win-win relationship with them. Otherwise, customers will come and go, because they will see you in the same way, as the supplier of something they just need at that moment. Recommendation: Work with the customers in the definition of your roadmap, not just getting their inputs, but involving them in an evolving adventure to have products that will help them as well as you. 

Tip 3. A roadmap might be flexible, but not too much. A Roadmap is a guide for the whole company. It might be used by the sales department to advance future products to the customers, or by the development team to plan resources, or by the finance department to prepare treasury plans. Some companies tend to adapt the roadmap depending on the commercial opportunities and customers. Roadmaps should have some flexibility to adapt to changing circumstances, but too many changes produce confusion in the organization. Recommendation: Define a Roadmap. September is an adequate moment, so resources could be allocated for the new year, although any time of the year is good if you do not have one. Once you have that roadmap, evaluate the risks and impact of any change you might want to do before applying it. 

Tip 4. Pay attention to the cost of building a product. Many companies consider that a product costs what it is needed to make it in terms of time and resources, but it is not. There are many other costs related to a product that should be considered from the beginning, like integration testing phases, standardization and industrialization, proofs-of-concept (POC) with customers, documentation, rules compliance (like CE, etc), demos, internal training, and something that many times is not considered: Maintenance. Because there might be bugs, improvements, design mistakes that will need time and resources, especially in a new product launch. Recommendation: Plan considering all the phases of a product life cycle, not only on the few first ones. 

Tip 5. Give a good product or you will lose the good customer. Quality, quality, quality. This should be a must in any product and many times is not so. The rush to have a product in the market means many times reductions in the validation and industrialization phases. Recommendation: I know it is a trade-off not always easy to solve. The key is to take a strategic decision, planning in advance the time and resources to ensure the product is good enough for the market. Be agile in the execution and reduce functionalities if needed, but not reliability.

As you could understand, product strategy and product roadmap are very serious strategic decisions. Good practices will not always ensure success, but bad practices will definitely make the company fail. So let’s pay full attention to do it well.

I recommend reading this post: What is the key to get a successful product?