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. 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!