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!

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?

Why demos are like demons for developers?

[5 minutes reading]

If your team of developers consider demos are a stressfull waste of time that delays development, then you may have an issue that this post could help to solve.

Some weeks ago, a robotics engineer working for a company in Singapore shared to me his concern with his boss, who was asking for a weekly demo to potential customers of an uncomplete prototype. This is quite a common situation and the reason why I decided to write this post.

It is clear that demos are key for a business success. Having customers and stakeholders involved in demos gives them not just a way to evaluate a product, but also a living experience. We are rational, but also emotional. Demos should also touch the rational and emotional inside of the audience. But why developers think demos are demons conspiring against development?

• Sometimes because demo preparation takes long, as reinventing the wheel every time.

• other times because it involve the same developers and the team do not see them as an opportunity to get good feedback for development and business.


• and many other, the product or prototype is not properly tested and mature for a demo, so the stress of developers for a highly probable demo failure is too high

But really there are really good things we could do about demos. Let me tell you some key actions I recommend to follow:

• Have clear requirements of what the demo should do. These requirements usually are a subset of the product requirements and will give clarity on what features will be part of the demo.

• Prepare a demo as much standard and automated as possible, so it could be executed with minimum amount of supporting people. This reduces cost of demo and transmit simplicity to the audience.

• Prepare a written Demo Plan, describing roles of people involved in the demo, what should they do, in what sequence, describing the preparation of the demo, the execution and the post-demo actions. 

• Keep always one unique interlocutor for each demo, who would give turns to others to clarify specific points of the demo if needed.

• Before doing a demo, ensure the features have been tested properly and a rehearsal of demo is done.

• Share with the development team clear reasons why demos are important and a good way to test, learn and correct features, as well as for the business.

• Rotate the responsibility of doing a demo between different people, so they could learn and dilute stress between each other. Consider also doing demos with sales or product management team instead of developers as main executors of the demo, may be with a developer as support in case of doubts. This shows simplicity to audience and usually sales and product management  people are more adequate for communication with customer than developers.
  If your company requires doing demos with developers, take care of the amount of demos a developer does. Usually, developers need to develop and could understand dedicating part of their time for demos, but too much time doing demos and low time developing may demotivate them.

• Give clear expectations to the audience. I saw many times failing demos of products, with the promise to be mature products when they were really prototypes in alfa version. Being sincere to the audience on what you are showing will ensure adequate expectations and prevent deception and stress if something wrong may happen. Anyone could understand a failure if they know is an alfa/beta version but not if they believe it is a finished product.

At the end demos are important and necessary for a company success. The way we prepare and do demos will directly influence the mood of the people involved in the demo and the experience of the potential customers.

7 tips to choose a Methodology for Software Development

There is quite a variety of Process Models and Methodologies that could be used for a project.  Although there are fans of each model and methodology,  the question to answer is which one fits best for our specific need. This is where I will try to help you in this post.

Sometimes a methodology is used in a company due to company standards (i.e. SixSigma is a standard for General Electric), or just because it has been used during some time, or because the project managers and sponsors do not know well the benefits to apply other methodologies, or just because they are frightened of the change. 

For Software Development we could use different Process Models, like 

• Linear Process Models, that follow a pattern of phases completed one after the other without repeating phases (Waterfall, V-model, Sawtooth model,..) and

• Iterative Process Models, that allow repeating stages of the process and are cyclical (Spiral model, Unified Process Model,...). These models may be used along with Agile Methodologies, like Lean, Kanban, Extreme Programming or Scrum to mention a few.

dilbert.com all rights reserved

I would like here to point out some tips and benefits of the mostly used Process Models and Methodologies, to get some idea on what is better for us:

1. Linear Process Models are not very adaptable to change. I used quite often these models, but usually for projects with very fixed and well defined requirements, that involved not only software development, but hardware integration. Although changes could happen in this model by applying Change Management practices, the model is not very well designed for those changes, so if these changes happen late in the project, they may add great delays and costs.
2. Iterative Process Models are more adequate for Software Development as they are focused on iterations, with releases deployment after each iteration, getting feedback from customer and improving/modifying the product in each iteration. Desirable this iterations are short (under one month), so adaptation to change is much easier than with Linear Models
3. Unified Process Model is one of the most interesting Iterative Process Models, that emphasizes gradual development. Something I like from this model is that it considers parallel work at the same time as cyclic iterations. Therefore for example it is possible to design the product architecture while developing tests at the same time. This is good and logic, as the Architecture may change when there are changes in the requirements and sometimes it is not necessary to have the full system architecture design ready before the coding phase starts. It is ok to have a general architecture definition at the beginning and go more into detailed architecture design for the features we are going to prepare during an iteration.
4. Extreme Programming Agile Methodology or XP is all about client satisfaction by encouraging customer feedback during all development, small and frequent releases, simple designs (adaptable to change), coding standards, continuous integration and testing, balance between work and personal life and something that, in specific phases of the project is really good, although costly, that is “pair programming”, meaning that programming is done in groups of two developers, using the same computer and developing the same piece of code. It is interesting because drastically reduces failures in the code design, but needs to ensure that there are no personality conflicts in each pair. Also we need to keep in mind that XP is designed for small development teams. With big groups may become a mess, specially in the integration part
5. Scrum is one of the most popular Agile Methodologies that is based on three pillars: Transparency, Inspection and Adaptation. From the Transparency pillar I really like the common agreement on standards and the “definition of Done” concept, that basically emphasizes clear common understanding on when a feature to develop is considered finished. This prevents misunderstandings and false expectations that later could add complaints and delays to the project. Also from the Inspection pillar I like the four events that happen in a Sprint (cycle in which a working release is produced). These events are: Sprint planning, daily Scrum, Sprint review and Sprint retrospective. They are a good way to progress in the project without spending much time in management or micromanagement.
6. Lean software development (LSD) is a translation of lean manufacturing principles and practices to the software development domain, to reduce risks and deliver high quality products quickly. It sounds good, isn’t it?. I like one of it’s main principles: “Eliminate waste”. It states that anything that doesn’t add value is considered waste, like unnecessary meetings, unclear requirements or product defects. Other important principle, “Building Quality in” promotes the use of the best practices available to avoid errors in development, may be by using the pair programming concept, well commented code and good documentation, Refactoring if needed and automated testings.
7. Kanban is used in Lean Software Development. This approach aims to manage work by balancing the demands with available capacity, and improving the handling of system level bottlenecks reaching the ideals of Just-in-time manufacturing. In Software Development this balance is made having multi-functional teams that could be placed in one or other phase depending on the demand. For example a developer could become tester during a specific period of time, depending on the “work in progress limits” established in each phase. Work items are visualized to give participants a view of progress and process, from start to finish usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.

In summary, choosing one Process Model and Methodology depends on the kind of products to develop, the size of the development team, the culture of the company and the relationship with the customer, between others.

Depending on the company I worked for and the kind of project, I used Six Sigma (not described in this post), Waterfall, or Scrum Agile methodologies, but usually I added some ingredients from other methodologies that I considered may add value and adaptation to the needs. Sometimes being too strict with the methodology may not be the best option, depending on each specific situation. Because of that, it is good to know several methodologies, even if you are just using only one of them.

Reference:

• Lean Software Development. Wikipedia. https://en.wikipedia.org/wiki/Lean_software_development
• Software Product Management. University of Alberta. Coursera. https://www.coursera.org/specializations/product-management
• Kanban. Wikipedia. https://en.wikipedia.org/wiki/Kanban_(development)#Software_development
• Software Development Methodologies. IT Knowledge Portal. http://www.itinfo.am/eng/software-development-methodologies/