AMR-One. 05 Project Management Plan

This is the fifth on the series of posts about the AMR-One Project. Today it is time to talk about what is a Project Management Plan, how to prepare it, and its application to the AMR-One project.

The Project Management Plan is defined as the document that describes how the project will be executed, monitored, controlled, and closed.

But... we already talked about it in my previous post The Project Management Plan. But the important thing is how you prepare it and why. For that, I used the AMR-One Project example and prepared the following video that I hope you like:

AMR-One. 04 Work Breakdown Structure (WBS)

This is the fourth on the series of posts about the AMR-One Project. Today I will talk about the Work Breakdown Structure tool as a way to get the tasks of a project.

The concept

Once we have somehow the scope, requirements, or definition of what we are going to do, we could prepare the Work Breakdown Structure (WBS).

The Project Management Institute (PMI) PMBOK defines the WBS as a “deliverable oriented hierarchical decomposition of the work to be executed by the project team.”

Basically is an iterative process that takes one large work product, and breaks it down into smaller, manageable work packages.

In a WBS such elements are the items that are estimated in terms of resource requirements, budget, and timing

WBS applied to AMR-One Project

In the case of AMR-One, I made a simplification of the process, aligning the Product Roadmap, the Requirements, and WBS.

So in the WBS I added all Initiatives from the Roadmap as L1, and the Features or Epics as L2. Also I added one column to define the version of the product where these Epics will apply.

WBS related to Roadmap and Requirements

I didn’t split it into more levels as in this way it is quite aligned with the requirements already defined.

Now from here, and having the architectural approach mentioned in the previous video, we could start identifying atomic tasks within each Epic. This is work to do with the technical team, identifying dependencies, resources, time, and cost estimation.

Epics decomposition in atomic activities

And that is all so far. 

In the next post, I will explain to you how to prepare a good Project Plan. It is not only to have a plan of tasks, time, and costs. It is much more than that!

See the following video for more details:

AMR-One. 03 Architecting the solution

This is the third on the series of posts about the AMR-One Project. Today I will talk about architecting the solution.

In the previous post I described the requirements, so we know now what are the functions that the system should accomplish. But before defining the tasks to accomplish these requirements, we need to have an idea of how are we going to build the solution. For that, some people tend to create more technical requirements, in the language of the developers. I prefer to spend some time working on a pre-design of the whole system, from the mechanical, electrical, and software sides, involving representative people from each of the disciplines. It is essentially an iterative process, but having a basic architecture already opens minds to understand the tasks needed to build the system. 

When we have this general pre-design of the system, we could go further on the class definition for SW, materials for mechanics, or technologies for hardware.

Let's see as an example how this architecture has been defined in the AMR-One project.

The AMR-One case

As we saw in the episode about the roadmap, there are at least two versions of the product, with different functionalities. But we will consider the mechanical, hardware, and software approach for both versions 1.x and 2.x.

The mechanical approach

The mechanical approach starts with an overall analysis of the kinematics of the needed system, then continue with some freehand sketches and then with some draft ideas using some computer tools, but not going in deep on the design.

The hardware architecture

The hardware and electrical architecture define the components (sensors and actuators) but what is more important, helps to define the processing systems and the functions assigned to each of them. (click on the image to see it bigger)

HW architecture

We define 4 processing systems: 

• Safety PLC (Flexisoft)
• Low-level controller (LLC)
• High-level controller (HLC)
• Cloud base system

Going a bit further on the functions assigned to them we have that:

• The Safety PLC is responsible for ensuring the safety measures are executed reliably. It uses several inputs (Safety Lidar and safety stop buttons) to determine when there is a dangerous situation and the system should stop. There is therefore a program inside this PLC to ensure this behavior.

• The Low-Level Controller (LLC) is responsible for the Low-Level functions, which are the following:
• Sensory reading
• Traction motors PIDs controls
• Velocities (linear and angular) conversion into inputs for the PIDs controls
• Magnetic guidance
• RFID tags reading and execution of actions
• Pinhook control
• Buzzer control for warnings
• Device HMI data
• ROS publisher to connect with HLC/Cloud Monitoring
• ROS publisher/subscriber to connect with HLC/ROS navigation (AMR-One v2.0)

• The High-Level Controller (HLC) is responsible mainly for:
• Communication with the LLC
• Communication to the cloud
• User interface (AMR-One v2.0)
• Localization, navigation, and mapping based on ROS (AMR-One v2.0)

• The cloud-based processing system is not described in the hardware architecture because it would not require additional hardware from us.

The software structures

As mentioned, there are four processing systems, each of them with programs inside. 

The structures are quite self-explanatory. Only to mention that the items with yellow background correspond to v2.0 of the project and the rest correspond to v1.0 (click on the images to see them bigger)

See the following video for more details:

Now we know how to approach the solution and we are prepared to work on building a Work Breakdown Structure to define the Epics and tasks of the project, but this will come in the next post.

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!