Project Management for Electronic and Computer Engineers (sample)

Project Management for Electronic and Computer Engineers

From specification to implementation

Pedro Fonseca 2020

Project Management for Electronic and Computer Engineers

1 Project management in Electronic and Computer Engineering

So you want to start your project? Welcome! In this text, we will talk about developing a project in Electronic and Computer Engineering, and related fields.

Project Management is a discipline that has emerged in the middle of the 20th century. It concerns the best practices to conduct a project in many fields of human activity. We will start by looking at what is a Project, in this general approach, and then we will focus on the particularities of Project in Electronic and Computer Engineering. What is so special about a project in Electronic Engineering that makes it different from other projects? As in any other field of Engineering, Electronic Engineering has its own characteristics. Electronics are present in most (if not all…) human activities today. In many instances, projects in Electronic and Computer Engineering (ECE) deal with developing products. This is different from what happens in Civil Engineering, that deals with building houses, bridges and dams, or Electrical Engineering, to design an electric power distribution network. While designing products, Electrical and Computer engineers are integrated in multidisciplinary teams, together with software and firmware developers (nearly all electronic devices today include a micro-controller or a microprocessor), mechanical engineers (electronic devices have to be installed inside an enclosure), designers (the product must be pleasant to use) and marketeers (the product must be appealing to the consumer). Designing a product means creating a device that must be adequate for mass-production in a factory, which is a challenge in itself. This environment includes development processes with production cycles of varying duration: from software development, where an error can be corrected in a matter of seconds, to hardware design, where correcting an error in a printed circuit can have significant costs in time and money to repair.

1.1 What is a Project?

Many organizations and authors have proposed different definitions of what a project is. In the following, we will look at some of these definitions. The fact that there are different ways to define a project shows that there is not a definite and unique definition. On the other hand, each definition focus on some particular aspects. Looking at these alternative approaches allows to identify some relevant aspects of what constitutes a project.

According to the Project Management Institute (PMI) (Project Management Institute, 2017):

A project is a temporary endeavour undertaken to create a unique product, service, or result.

This definition allows us to pay some attention to the main characteristics of a project:

• Projects create unique products, services or results. The outcome of each project is unique, it did not exist before the project was executed. Projects are run in order to create

Project Management for Electronic and Computer Engineers

new things: new products (e.g., the new mobile phone your company will be selling), new services (such as organizing a food collection service for your local charity) or results (organizing a sports event in your club). The fact that a project exists to create things that did not exist before means that there is always a certain level of uncertainty in the project results.

• Projects are temporary endeavours. Projects are time-bound: they have defined dates to start and finish. Any activity that goes indefinitely, such as assembling electronic devices in a factory, is not a project.

The International Organization for Standardization (ISO) publishes the ISO 10006 standard on “Quality management – Guidelines for quality management in projects” (ISO, 2017). In this standard, ISO defines a project as (emphasis added):

Project: unique process undertaken to achieve an objective

A project generally consists of a set of coordinated & controlled activities with start & finish dates, undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources

This definition adds a little more detail to what a project is. In particular, it helps to make clear that:

• Projects involve coordinated and controlled activities. The work to be carried out during the project consists on several, different activities. These activities must be coordinated. The project of building a house implies coordination among the several activities: painting can only start after finish plastering the walls, and, before plastering, plumbers and electricians must install the water and sewage conduits and the electrical wiring. These activities must also be controlled: when plumbing is installed, someone must check whether work is being executed on time and in the correct way. If delays occur, all subsequent activities will also be delayed. If work is unduly carried out, leaks in the plumbing may imply additional work to repair them, damaging the plaster and painting, which will have to be redone, at extra cost.

• Projects have start and finish dates. Projects are time-bound; we have seen this in the previous definition.

• Projects are undertaken to achieve an objective conforming to specific requirements. Projects are implemented with a purpose, an objective, that is known from the start. A collection of activities without a well defined purpose is not a project.

• Projects have constraints of time, cost and resources. The means available to undertake a project are not endless. Projects do not last forever; they have start and end dates. Projects cannot use an infinite amount of money; projects have budgets, an estimate of how much money will be required to accomplish them, which is limited. A project has a finite set of

Project Management for Electronic and Computer Engineers

resources that can be used in its activities, be it the number of people assigned to the project, machinery, offices,…

Projects do not involve necessarily activities related to engineering or technology. For a bank, opening a new branch is a project. It is time limited: it starts with the management decision to open the branch and it finishes with the branch inauguration. It is an endeavour that involves a set of activities (finding a location, buying the furniture, recruiting and training personnel, advertising the inauguration ceremony, …) to produce a result that did not existed before: a new office operating at a new location. A project does not have to be a professional activity: organizing a birthday party is also a project. It requires a set of coordinated activities (preparing the invitations, inviting people, finding a location, renting the location, designing the decoration, …) that have to be controlled (“Did the restaurant confirm the reservation?”), with a purpose, specific requirements (maybe a thematic party) and subject to constraints of time (maybe you are doing it on your free time), cost (you must consider how much each person will be willing to pay) and resources (everything will have to be transported in your car).

The outcomes of a project are deliverables. A deliverable is a result of the project, such as a document with relevant information or new knowledge, a piece of software to perform a given function, the blueprints of a road or sewer system, a component, a prototype, a full working system or having the restaurant room booked for you birthday party. Deliverables must be verifiable: there must be an explicit and objective test or procedure to decide whether the deliverable has been correctly produced. Deliverables can correspond to a product, a service or the capability to perform a service. Deliverables can be tangible, if they correspond to physical assets, such as a prototype, or intangible, when they do not correspond to a physical object.

It may be worth noticing that some deliverables may have tangible and intangible characteristics. For example, when the project requires acquiring knowledge about a given process, such as using a new sensor technology, the deliverable may be expressed as a report. Although this report, when printed, is a tangible asset, the relevant deliverable is not the paper where the report is written (tangible), but the information contained in the report (intangible). If the deliverable is checked only by the existence of the report and not considering the information it contains, a crucial point to the project success may be missed.

Of course, it may not always be easy to verify whether the report contains the relevant information, but focusing the test to verify the deliverable on the expected results may help. For example, by writing the verification test as:

“Does the report identify and specify a process to integrate the required sensor technology in a new development project, in a way that can be used by an engineer in the design room?”

instead of

Project Management for Electronic and Computer Engineers

“Did the team write the report on the integration of the required sensor technology in a new development project?”

may help to focus on the actual relevance of the deliverable (a design engineer, with sufficient knowledge, becomes capable of using the sensor based on this new technology), and not on the formal aspects (the project team wrote a report on how to use the new sensor technology).

Unfortunately, experience shows that, in many cases, the verification is done based on the formal aspects (“Did you write the report?”) and not on the relevant issues (“Does your report allows other people to use the technology you have studied?”). If this happens, project is, if not doomed to fail, very probably heading for difficult times...

1.2 Project Management

Projects do not happen by chance. Developing a project requires coordinating all the people involved so that the available time, money and resources are used in the best possible way and the project is concluded successfully, delivering the expected results on time and on budget. The Project Management Institute defines Project Management as (Project Management Institute, 2017):

Project Management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.

The definition by ISO in ISO 10006:2017 is similar (ISO, 2017):

planning, organizing, monitoring, controlling and reporting of all aspects of a project and the motivation of all those involved in it to achieve the project objectives

The first definition, by the PMI, emphasizes that managing a project requires a combination of competences and aptitudes:

• Knowledge: project managers are required to know how to conduct a project. Knowledge on the specific domain of the project, such as banking or electronic engineering, is also usually required. Although an experienced project manager can coordinate projects in many different areas, knowledge on the specific project domain allows for a better understanding of the issues involved in the project.

• Skills: besides knowing the required subjects, project managing requires abilities such as interpersonal communication: project managers are responsible for creating the conditions that motivate and engage all people in completing the project. Personal organization is also required.

Project Management for Electronic and Computer Engineers

• Tools: over the years, many tools for project management have been created. Project managers must know how to use and apply them in their projects. These tools can be physical or software-based; a search in Google for “Project management tools” shows hundreds of different project management tools.

• Techniques: conducting a project requires using specific approaches to handle the challenges posed by the project. These can include, for instance, brainstorming sessions to collect information to prepare the project, scheduling to estimate the project duration, risk analysis to control what may possibly go wrong in the project, and cost estimation, to name just a few.

The definition by ISO focuses on the different types of activities that must be performed in the course of a project:

• Planning: every project must start by defining a plan of the activities. Even if not all activities are planned before hand, the plan on how to plan them must be defined...

• Organizing: projects result from the joint effort of several people, in different activities, using different resources, sometimes in different locations. All this requires organization in order to work together.

• Monitoring: monitoring refers to the process of collecting data and information about the project performance. This is fundamental to know the actual project situation. Without monitoring, the project manager would be steering the project ship blind-folded.

• Controlling: when controlling the project, you are comparing the actual project progress and performance with the plan, and taking the necessary measures, such as allocating more resources to activities that are lagging behind schedule or rescheduling other activities.

• Reporting: in many cases, the project stakeholders are not the project team. The status of the project must be reported to all the relevant stakeholders. It is also important to have internal reporting, so that the whole team knows what is happening with the project.

Project management started to be an informal activity, done in a best effort way. But, as the people involved were getting more experience, a body of knowledge started to appear and project management emerged as a distinct profession, by the mid 20 th century. As a result, organizations like the Project Management Institute1 appeared, that aim at providing training and certification for the Project Management professionals, as well as defining standards and supporting academic research on Project Management.

The main activity of the Project Management Institute is the edition of the PMBOK Guide, A Guide to the Project Management Body of Knowledge (Project Management Institute, 2017), which is currently in its 6th edition. According to the PMI, the PMBOK Guide includes traditional and innovative practices that are emerging in the profession and it presents a general framework to organize projects of different nature. It is based on the ANSI Standard for Project Management. Following the trends of agile methodologies adoption, the PMI has issued a companion book, Agile

1 http://www.pmi.org

Project Management for Electronic and Computer Engineers

Practice Guide (Project Management Institute & Agile Alliance, 2017), that results from a collaboration between the Project Management Institute and the Agile Alliance. The principles in the PMBOK Guide will presented in more detail in chapter 3 .

1.3 Project Management for Electronic and Computer Engineering

Engineering Project Management is the application of Project Management to the development of Engineering projects. We will address the particular case of Projects in Electronic and Computer Engineering (ECE), which can be seen as a subset of Engineering Project Management (Figure 1).

What makes this kind of projects different? One reason is the fact that Electronics and Computers are pervasive in today’s world. Electronics and Information and Communication Technologies (ICT) are present in nearly all human activities, from farming to industrial production, to medicine and teaching, sales and banking (you name it…) This implies that the outcome of ECE projects are extremely varied. An Engineering firm in Electronics may be developing a water quality control in one project and a road marking device in the following month. In both projects, the core may be the same: electronic circuits, with amplifiers and micro-controllers, connected to sensors and actuators. But the functions to be performed are totally different. Electronic and Computer Engineers must develop Project Management processes that allows them to tackle projects of different nature.

In many cases, projects in ECE aim at developing products for mass-production. While designing products, Electrical and Computer engineers are integrated in multidisciplinary teams, together with software and firmware developers (nearly all electronic devices today include a micro-controller or a microprocessor), mechanical engineers (electronic devices have to be installed inside an enclosure), designers (the product must be pleasant to use) and marketeers (the product must be appealing to the consumer). Designing a product means creating a device that must be adequate for mass-production in a factory, which is a challenge in itself. This environment includes development processes with production cycles of varying duration: from software development, where an error can be corrected in a matter of seconds, to hardware design, where correcting an error in a printed circuit may imply repeating the production of the board, with significant costs in time and money.

Figure 1: Project Management in Electronic Engineering.

Project Management for Electronic and Computer Engineers

Any methodology for developing projects in ECE must be capable of accommodating these different rhythms.

Innovation is another characteristic of many ECE projects. Electrical and Computer Engineers are often called to design new circuits or to devise new ways of having a product interacting with the end user. These are innovation activities, that introduce new elements created in the course of a the project. Compare this with a project to build a new block of apartments. This is also a project, but the procedures and the methods applied are, for most cases, standard. No particular innovation is required, which means that the project activities can be, for the most part, defined in anticipation. In an innovation project, it can be very difficult to anticipate in detail what activities will be required, and what time will they take.

Another aspect that add uncertainty to ECE projects is requirement volatility. This is an expression that illustrates how easily the requirements of a project can change during its implementation. A project can change with a certain set of requirements and rapidly evolve to something completely different. This is pervasive in software related projects and it is the driving force behind the emergence of Agile methodologies, that we will address further on.

1.3.1 ECE project is part of a chain

An engineering project in ECE is, most often, part of a larger chain, that commences in the stage where the idea of a product or a service is conceived, and terminates with managing the project end of useful life. In the activities chain presented in Figure 2, the engineering project, which is the project we will focus on, corresponds to the development phase.

The first phase in this chain is the “Idea Conception and Capturing”, the moment where the project proposal originated. This can be an innovation process in a company that develops products, the sales department in an engineering services company that develops electronic systems for their customers, the marketing department the identifies the need for a new product, etc. This occurs when a hydroponic farmer finds that she needs a new electronic controller for her farming installation, or the City Mayor decides to equip street lighting with a system to detect people and automatically control the light level in the streets. In these examples, there is a need that can be fulfilled with an electronic device or system that does not exist yet and must be developed. Most often, the person or the people identifying the need do not know about electronics, but they know about the process to which electronics is going to be applied.

The next phase is the “Development” phase: in this stage, the idea is converted into something concrete and tangible (prototypes, engineering plans or both). This is the stage where Engineering

Idea Conception and Capturing Development Production Sales and Deployment

After sales services End-of-life management

Figure 2: ECE Project is part of a chain.

Project Management for Electronic and Computer Engineers

design occurs and where Electronic and Computer Engineers develop most of their work. This phase takes as input the idea for the electronic product or system to be developed and turns it into reality: an actual implementation of the concept, that can be produced and put to work. Often, the output of this phase is a working prototype of the system, than can be used to validate the design.

In the “Production” phase, the output of the Development phase is prepared to be used in “real-life” conditions. The product will now be manufactured; the engineering plans previously developed are used to define the production process. This may mean assembling the system in a robust way so that it can be installed in its final location, or it may imply industrialising the project outcome in order to be produced in large quantities. Among other things, industrialisation implies defining a process to produce the new product in a factory. The goods produced in the factory are the input of the “Sales and Deployment” phase, where the new product or service is sold to the final customers and installed, in order to be used. This can be trough shops, for mass products, or it can consist on installing a specific device at the customer premises. The customer for a company producing electronic equipment does not have to be necessarily the final customer or the end user. In many cases, the product is created by one company to be integrated in the product of some other company. In many cases, this is the first time the product will generate any revenue for its creators.

Selling a product or a service to the customer does not need to end the relationship between the seller and the buyer. Many companies use “After sales services” as a means to generate extra revenues during the time the client will use the product, by associating other services to the product or service. This includes all services that the company keeps providing their customers, after selling the base product. It can consist on maintenance and repair services, spare parts and extras, training or any other services that relate to the original product, such as an app store or a music store for smartphones.

Finally, the product should undergo a correct “End-of-life management”. In order to guarantee the sustainability of whole process, what happens to the product must be considered and thought of. Although the stages are open-ended, the concept of circular economy (Bastein et al., 2013; Gama et al., 2016) should always be present in the development of any product or service.

1.3.2 Interaction of Development phase with other stages

In Figure 2, all stages in the value chain are represented sequentially. Representing the Development phase as a separate step in a chain is an aid to understand its role in a process and it does not mean that Development phase is independent of the remaining phases. On the contrary: the Development phase is the stage where Engineers intervene to convert an idea into reality, in a process that is intimately related to all other stages.

In the interaction of “Development” with “Idea conception and capturing”, the idea that generated the whole process must be correctly captured and understood; the development team must do what the costumer asked for. This is critical for the success of the new product or service. If the product fails to comply with the user needs, it will not succeed.

Project Management for Electronic and Computer Engineers

Engineering firms often work as subcontractors, developing projects (such as new circuits or devices) for companies that do not have engineering expertise. For example, a maker of metal-working machinery may command a new controller for their machines to an Electronic design firm. Their expertise is on metal working, not on electronic and computing devices. So, the metal-working machinery maker expects the design firm to develop a component of their system that they do not know how to build, but they know how to use: their knowledge is on the process of working with metal parts and they have a very clear idea of what they need. If an Engineering company fails to understand what is required by their client, this company risks completing the project and hearing: “This is not what I want. I will not pay!”

Another important issue in conceiving a new product or service is to guarantee that concepts are translated into feasible devices. In other words, make sure that you can build a working product.

Every new design will have to be produced or manufactured. The product should be easy to manufacture: it should not rely on expensive components nor require complex assembling procedures. Care should be taken not to include components that may become obsolete in a short time. When a component in a PCB board is discontinued and the replacement has a different encapsulation, a new PCB will have to be designed and all boards that may exist in stock will have to be discarded. All of these imply losses for the product manufacturer.

The way the new product will be sold to the customer influences the engineering design process. If the product is to be sold in a pay-per-usage model, where the client only pays for the time the product is used or for the number of utilizations, the product design must consider the features required to support this model. This could be a hardware key or the connection to a license server. It may require also the possibility of ceasing to provide the service or the function to the client, if the renting for the product has expired. These are features that can be easily introduced at the design stage, but that may be very difficult (if not impossible) to implement as an afterthought, when the product is designed and the assembling or production has started.

Figure 3: Make sure that you can build what you have designed...

Project Management for Electronic and Computer Engineers

The product must be easy to manufacture.

Production costs must be considered (no expensive components, avoid complex assembling operations, ...)

Idea

Conception and Capturing Development

Production

The business model may consider upgrades to the product (e.g., by having features that are unlocked): these must be part of the design.

Sales and Deployment

After sales services

End-of-life management

Ideas must be correctly understood (“do what the customer asked for”) Concepts must be translated into feasible devices (guarantee that you can build a working product)

Product must implement the sales model. E.g., it may require a hardware key or a connection to a license host.

Product should not incorporate materials with toxic components that prevent parts from being recycled.

Similarly, the engineering design must consider also all the after-sales services that the product manufacturer may want to explore. Remote servicing is an obvious candidate, allowing the manufacturer to perform maintenance work on the system from the distance, as well as the possibility of remotely distributing new software versions or configurations, known as OTA (Over The Air) programming.

Tesla is probably the most famous example today of a company relying on OTA communication with their products to provide after-sale services. Soon after receiving a negative review from Consumer Reports as a result of a excessively long breaking distance in tests, Tesla provided a OTA fix to solve the issue (Mitchell, 2018). Not only Tesla is capable of downloading software updates to the cars they make, but they collect information on the vehicle’s behaviour in order to validate their next move. The software update for Model 3 that increases the available power by 5% was done overnight in March 2019, and the owners received a message in the LCD display announcing the power increase. But the company waited for more than one year to perform this update, in order to collect real-world data to guarantee that it was safe (Stumpf, 2019).

Other car manufacturers are now trying to follow Tesla’s strategy, but they are still lagging behind (at least, as of 2019). In 2014, both Tesla and GM were required to perform software updates for similar problems. But while GM owners had to take their cars to the nearest dealer, Tesla software update was performed with no user intervention (Bullis, 2014). In 2019, that situation has not changed yet: Jaguar and Audi electric vehicles,

Figure 4: Interaction of Design phase with the other Product Cycle phases.

Project Management for Electronic and Computer Engineers

competing with Tesla, still require their owners to recall their vehicles (Alvarez, 2019). This clearly shows the advantage of thinking about customer service since the very first inception of the product.

Finally, every product should be designed taking in consideration its sustainability and the impact on the environment. Products should be designed in order to be integrated in a circular economy (Gama et al., 2016; Meloni et al., 2018). For example, products should not contain materials with toxic components, that may prevent parts from being recycled. Products should be designed in a way that facilitates dismantling and separation of components and using materials than can easily be recycled.

Project Management for Electronic and Computer Engineers

2 General principles in Project Management

In this chapter, we will review some of the main concepts related to Project Management. These are present, in a way or another, in every proposal or framework for Project Management.

2.1 Project scope

The Project Scope is the base concept that needs to be defined to start and conduct a project. PMI defines project scope as:

Project scope is the work required to output a project’s deliverable.

This is a very broad concept, that encompasses all the work required to achieve the project’s objective. In practice, the project scope statement should capture, in general terms, the expected output of the project and detail the vision of the project. It should define what is to be done to conclude the project, not more, not less.

The project scope statement should also contain mention to the main conditions that influence the project: if developing a product, it should mention what type of users is the new product directed to. If the project is supposed to make use of a particular technology, that should be part of the project scope statement. If the project exploits a business opportunity, that should also be clear from the project scope statement. The project scope must include the list of applicable standards and regulations. The main activities and milestones of the project are also to be part of the project scope.

2.2 The triple constraint

Every project must be carried out under certain constraints. The three most important constraints are time, cost and scope:

• Time: projects have deadlines, they have a time to start and a time to finish.

• Cost: projects are assigned a budget, a limited amount of money to spend, and the expected results should be obtained within that budget;

• Scope: scope comprises what is expected to result from the project and all the work required to obtain it.

All these three constraints are related and they influence each other. Trying to speed up a project implies either spending more money (thus, increasing costs) or reducing the scope. Trying to reduce the cost of a project may be done by using

Figure 5: The Triple Constraint

Project Management for Electronic and Computer Engineers

cheaper processes, which are usually slower, or by reducing the project scope (doing less in the same amount of time). You can think of the project as an object (a ball) in a 3-dimensional space where the object is tied to the origin and each axis represents the performance on each constraint, as in Figure 5. It is not possible to improve over all constraints: trying to improve one of the constraints can only degrading the performance on one or both of the other two. An alternative way to express this triple constraint, used in some car repair shops, is the one in Figure 6.

Managing a proper balance between cost, time and scope is one of the key features in project management and one of the most delicate tasks for the project manager.

2.3 Work Breakdown Structure

We have seen before that a Project can be defined as set of mutually coordinated activities, with the aim of producing something (a product, a service or any other result) with well defined limits on time and cost. In order to handle the complexity of the project and manage all that must be completed to achieve the intended result, this work must be decomposed in smaller parts. The Work Breakdown Structure, or WBS, is the result of this decomposition.

The goal of the Work Breakdown Structure is to divide the project work in smaller, manageable parts. In short, it can be described in the following 3 steps:

1. Divide a complex work in simpler activities.

2. Be sure to identify all partial activities.

3. Each activity has a concrete, well-defined, verifiable outcome.

The first level is performed in several steps, corresponding to different levels of detail, depending on the project complexity. Very simple projects can be immediately decomposed in simple activities. But most project require WBS to be performed in several steps. First, activities are defined in broad terms, and each of these is the divided in simpler activities, until we reach a sufficient level of detail.

Figure 6: An alternative way to express the triple constraint

Project Management for Electronic and Computer Engineers

In the most detailed level, work is reduced to a set of tasks.

A task is concrete activity (what), performed by one or more people (who), with a defined duration (when) and a specific result, concrete and verifiable result (deliverable).

In its simplest terms, a project can be seen as a sequence of tasks, performed in a coordinated manner. It is the job of the Project Manager or the Project Management team to define these tasks so that: a) they correspond to the work required to complete the project, complying to the constraints of scope, time and cost; and b) they are coordinated, so that they can be completed in an orderly fashion, implementing the necessary control mechanisms. It is important to guarantee that each task generates a result that is:

• specific: the task exists to produce this result, which is necessary for the project;

• concrete: everyone knows what the task result is;

• verifiable: there is a process or method to assess if the task deliverable was correctly produced. The result of this process or method must be binary: Yes or No.

Project tasks:

2.4 Project documentation

We will talk often about what documents need to be produced in the course of a project. Documentation is not the purpose of project management; the most important issue in Project Management is to guarantee that expected results are attained on time and within budget. But it is not possible to work without documentation (either paper based or digital). The main reasons for that are:

• Projects often involve large teams, that must work in coordination. Without written documents, it is not possible to guarantee that all people in the project are aligned in the same direction. Documents are the means to communicate within the project team.

Figure 7: The simplest view of a project is as a set of coordinated tasks.

Project Management for Electronic and Computer Engineers

• Projects may take a long time. Memory is imperfect and prone to errors. Written documentation provides a permanent record for project decisions. Even if we are working alone, we cannot remember by heart all the decisions that have been taken. Project decisions and events must be recorded, for future memory.

• Projects involve different parties with contract responsibilities. In case of disagreement, if there are no written documents about the responsibilities of each party, it will be one person’s word against another’s, with possibly unresolvable conflicts, delaying the project and payments and possibly leading to a judicial decision. Remember that, in this situation, the party executing (developing) the project (i.e., you) is the one that has already invested and purchased the required goods and is waiting to be paid. Unless this party is in a good financial situation, payment delays can have serious implications.

Documentation has also the advantage of forcing project related concepts to be explicitly stated, highlighting possible points of disagreement and misunderstanding and forcing their resolution.

Project Management for Electronic and Computer Engineers

3 Overview of Project Management methodologies

In the following, we will revise some of the most common and popular approaches to Project Management and try to categorize them in the general panorama of existing solutions. These are represented in Table 1, organized in different groups. At the highest level, we find “paradigms”, representing general patterns of project organization, which include waterfall and agile methods. Models and Frameworks correspond to a more concrete approach, a realization of project methodologies with a prescribed set of procedures and rules. Finally, tools and methodologies correspond to the concrete application of procedures, visual aids and methods to the organization of project activities.

Concept Instances

Paradigms

• Waterfall

• Agile Models and Frameworks

• V-Model

• PMBOK

• Unified Process (UP)

• Scrum

Tools and Methodologies

• Gantt

• Precedence Diagrams

• PERT

• Kanban

Note that these are not exclusive; they represent sometimes different perspectives of the same problem. For instance, PMBOK is a framework for identifying and organizing the activities to be conducted in a project; Gantt and PERT are methodologies to represent the different activities, their mutual relationship and the execution calendar, and all of them can be used together in the same project. Each of them has a particular approach or focuses on some particular aspects related to managing a project. None of them solves all the problems in Project Management; in most cases, applying a mix of these methods is a good approach.

3.1 Paradigms

3.1.1 Waterfall

Waterfall project development is the grandfather of ECE project methodologies. It was formalized by Winston Royce in 1970 (Royce, 1970). Royce held the position of Director at Lockheed Software Technology Center in Austin, Texas, in the USA. During his career, he was involved in many pioneering large and complex software projects. His 1970 paper (Royce, 1970), “Managing

Table 1: Project Management paradigms, frameworks and tools.

Project Management for Electronic and Computer Engineers

the development of large software systems: concepts and techniques”, Royce presents his personal views about managing large software systems, where he looks at the development of these large software systems as a following series of steps (Figure 8):

• System Requirements

• Software Requirements

• Analysis

• Program Design

• Coding

• Testing

• Operations

System requirements

Software requirements

Analysis

Program Design

Coding Testing

Operations

Although Royce is, in many instances, associated to the Waterfall paradigm, it should be noticed that he was well aware of the problems of looking at project development as a series of sequential steps. The following quote from (Royce, 1970) clearly shows that he was not an apologist of Waterfall as the solution for large projects development:

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy

Figure 8: Royce's steps to develop a large software program; from (Royce, 1970)

Project Management for Electronic and Computer Engineers

the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

Royce did also introduce concepts like iterative development, prototyping, intensive use of testing and customer involvement in the design process, principles that would later be advocated by the Agile approach proponents.

One main principle in Waterfall is to complete program design before analysis and coding begins. This design is successively refined, starting by defining the system requirements and then the software requirements. Only then the analysis is done, preparing the program design, where the software major blocks and architecture are defined. Coding is done only with the software architecture defined.

Strict Waterfall development is referred to as “up-front specification” or “documentation driven”: the development work does not start before the job to be done is totally specified.

3.1.2 Agile

The evolution and the widespread utilization of software soon showed the limitations of a waterfall approach. Imposing requirements to be fully defined before the development work starts required a lot of work and the production of extensive and complex requirement documents. These documents were sometimes difficult to be used by the development team, due to their size and complexity. Furthermore, the specifications were laid out at an early stage of the project; often, the customer perception about the project objectives and, thus, of project requirements would change in the course of the project. Incorporating this new, updated vision of the project deliverables implied redoing the specification work, issuing new documents, duplicating costs and increasing the effort in the project. Particularly in the case of software projects, it seemed illogical to develop the project based on documentation that is fixed, immutable and previously defined, when one considers the flexibility in modifying a software program, if needed.

Aware of this, a group of developers met in 2001, at Snowbird ski resort in the Wasatch mountains of Utah, in the United States, in a place called The Lodge, and produced the Agile Software Development Manifesto (Beck et al., 2001), reflecting “the need for an alternative to documentation

Project Management for Electronic and Computer Engineers

driven, heavyweight software development processes convened”. The Agile Manifesto defines 4 values (Figure 9) and 12 principles (Figure 10), that should guide the development of software.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Principles behind the Agile Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals.

Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Figure 9: The 4 values of the Agile Manifesto.

Figure 10: The 12 Principles of the Agile Manifesto.

Project Management for Electronic and Computer Engineers

The Agile Manifesto, and the methodologies that follow the values and principles of Agile, are a proposal to deal with the increasing need for flexibility and a focus on the customer. Since the publication of the Agile Manifesto, many models and frameworks for project development have been proposed based on agile approaches, like XP, or eXtreme Programming (Don Wells, 2013; Ron Jeffries, 2011), Scrum (Schwaber, 1995; Schwaber & Sutherland, 2017), and others, some of which will be referred later on.

Although Agile was born for software projects, the values of the proposal soon made it interesting and relevant for other areas, in Engineering and elsewhere: the National Public Radio in the U.S. uses agile methods to create new programming. John Deer, the manufacturer of agricultural machines, employs agile to develop new products and Saab to produce new fighter jets, amongst others (Rigby et al., 2016)

3.1.3 Waterfall or Agile?

(TBD)

3.2 Models and Frameworks

Waterfall and Agile are paradigms to help thinking about how to organize a project and to conduct activities. They define a general model and, to some extent, a philosophy for developing projects. But, by themselves, they do not provide concrete or specific answers, that may help someone in the task of developing a project, as they define principles in a somewhat abstract level.

In the following, we will approach some Models and Frameworks. By Models and Frameworks, we mean conceptualizations of Project Development that can provide concrete solutions and processes for developing a project.

3.2.1 V-Model

V-Model (Weilkiens et al., 2016) is specially adapted for software development and it can be seen as an extension of the waterfall model. In this model, the development process is modelled in a Vshaped diagram, with the the specification and design phase on left-hand side (downwards, in a topdown approach) and the right-hand side corresponds to the verification and validation phase (upwards, bottom-up) (Figure 11). The idea behind V-Model is that, during specification and design, we dive each time into deeper detail, and we emerge from that detail during the development and integration phase. In the V-Model, the initial steps (Business Requirements, Software Requirements, …) start at a high level (user needs) and, as the process advances, get into lower levels of detail, in a top-down approach, until coding starts. Work in this leg of the ‘V’ is concerned about defining the system, in successive levels of details. At the bottom of the ‘V’, the elementary units of code are developed and, in the right leg of the ‘V’, they are progressively organized in each time more complex structures, in a bottom-up construction. As work progresses in the bottom-up path, the elements are tested against the corresponding specifications that were defined in the left-hand side.

Project Management for Electronic and Computer Engineers

The left side of the V shape corresponds to the specification and design steps, where we start with a high level view (System Requirements) and then move into further detail. Each step in the downward branch should generate one or more tests, to verify the correctness of the solution developed to fulfil that requirement. These can be high level tests (Acceptance tests), at the upper level, or Unit-Tests, at the more detailed level. During Development and Integration, each successive step should pass the tests that have be previously defined. Figure 12 presents an example of a V-Model with the different specification, design, verification and validation steps.

The V-Model emphasizes that, when developing a technology-based product or system, the design process starts in the User domain, that corresponds to the top of the V-Model. The first thing to do is to understand what the User needs or wants and, then, progressively, it gets into more technical details, moving away from the user and into the technology domain. The technology domain corresponds to the bottom of the V-Model diagram. During development and integration, the

Figure 12: Example of a V-Model process.

Figure 11: Principle of V-Model

Project Management for Electronic and Computer Engineers

movement is in the opposite sense: development starts with items that are mainly technical (devicedrivers, function blocks, hardware components and circuits) and they are successively integrated, moving away from the Technology domain and returning to the User domain (Figure 13).

3.2.2 PMBOK

PMBOK, or the Project Management Body of Knowledge, is probably the most utilized framework for Project Management. The PMBOK framework is proposed by PMI, the Project Management Institute (http://www.pmi.org). PMI is the publisher of A Guide to the Project Management Body of Knowledge (Project Management Institute, 2017), currently in its 6th edition, which is the standard reference for information on the PMBOK.

PMBOK is a process oriented approach, meaning that all activities are organized as processes. A good and synthetic definition of process is provided by Jacobson, Booch and Rumbaugh (Jacobson et al., 1999):

A process defines who is doing what, when, and how to reach a certain goal.

The PMBOK framework considers all activities (processes) in Project Management as organized in five Process Groups and ten Knowledge Areas. This defines a matrix, where all working processes are located (each process is part of a group and in one knowledge area).

The 5 process groups are:

Figure 13: V model and the interaction with User and Technology domain-

Project Management for Electronic and Computer Engineers

• Initiating

• Planning

• Executing

• Monitoring and Controlling

• Closing

The role of each process group is shown in Figure 14.

The group of Initiating processes corresponds to all the necessary work to start the project: establish what is to be done by defining the initial project scope, identify the main stakeholders (who will be involved in the project), and get the necessary funding, among others. One of the results of the Initiating processes is getting the authorization to start the project. The Initiating processes group helps establishing a vision to the project.

With a vision and an initial scope to the project, the Planning group of processes is responsible for defining and detailing the work to be performed. This includes creating the Work Breakdown Structure, defining start and finish dates to the different tasks and establishing costs, creating the necessary documentation. In summary, the Planning processes exist to guarantee that the different project activities are coordinated so that the project is capable of achieving the expected deliverables within the boundaries of time and cost, defining a baseline that is used to compare the actual results with the expected outcomes.

The Executing process group comprises all activities to complete the work defined, in order to attain the project goals. As depicted in Figure 14, the Planning and Executing process groups influence each other: the Planning processes define an activity schedule, to be carried out by the Executing processes. But the actual outcome of the Executing processes, with all possible deviations to the baseline (completing activities sooner and later than expected, with costs that can exceed or to be well below budget), may cause Planning to be revisited and adjusted, generating a new plan for the Executing processes.

Figure 14: Five process groups in PMBOK.

Project Management for Electronic and Computer Engineers

In the background, the Monitoring and Controlling processes are responsible for measuring and analysing the advancement and performance of the project. This means performing all activities necessary to know the current state of the project, in particular controlling scope, time and cost: verify that what is delivered corresponds to what was expected, that it is delivered on time and within budget.

Finally, the Closing processes group includes all activities related to terminating the project, guaranteeing that all project results are duly delivered and all necessary paperwork is completed. For instance, in a project for developing a new electronic circuit to control a machine, the Closing processes guarantee that the produced circuits and its documentation are effectively delivered to the machine manufacturer that will integrate the new controller. Conducting Lessons-Learned sessions, where the project team reflects on the successes and failures of the project in order to improve for future projects, is another example of an activity in the Closing processes. The Closing group of processes includes also all activities performed when the project is prematurely terminated. This can occur by several reasons, such as the funding for the project is exhausted, the need for the project no longer exists (the client is no longer interested, a new device was launched in the market that makes the project obsolete), required human or physical resources are no longer available or changes in the legal framework cause the project objectives to be unattainable or even illegal.

In the PMBOK model, work is organized in 10 knowledge areas, that reflect specific skills and functions related to Project Management:

• Integration

• Scope

• Schedule

• Cost

• Quality

• Resources

• Communications

• Risk

• Procurement

• Stakeholders

The purpose of each of these areas is clear from the definition, which is almost self-explanatory. Integration concerns all processes for overall project management and put everything together. The next three, Scope, Schedule and Cost, correspond to the processes that deal with complying with the triple constraint: the project should do what it is required to do (scope), at the right time (schedule) and within budget (cost). Quality area embarks the processes guaranteeing that the project outcomes comply with standards and regulations, as well as with customer's criteria. Resources is here in the sense of Human Resources and contains the processes to create and manage the project team, while

Project Management for Electronic and Computer Engineers

Communications integrates activities to manage all necessary exchange of information between the project stakeholders, either internally or externally. Risk management deals with the processes to identify, control and mitigate risks in the project. The Procurement area is concerned with identifying suppliers and acquiring all necessary goods and tools and, finally, Stakeholders management deals will the relationship with the project stakeholders: identify the stakeholders and engage them in the project.

The combination of the 5 process groups with the 10 knowledge areas defines a matrix, where all project processes are located (Figure 15). In this model, each Project Management project corresponds to one process group (Initiating, Planning, Executing, Monitoring and Controlling or Closing) and to one of the 10 knowledge areas.

The PMBOK framework defines, for each one of these processes, what are the inputs, the outputs and the applicable tools and methodologies, as well as a data flowchart describing the process, what documents it requires and how does it interact with other processes.

Project Management for Electronic and Computer Engineers

Let us see how this works with the example of process 5.2 Collect Requirements. This process belongs to the Planning group and is include in the Project Scope Management area (see Figure 15). Getting the client requirements right is a fundamental step for the success of the project.

Figure 15: Correspondence of processes to groups and knowledge areas (Project Management Institute, 2017).

Project Management for Electronic and Computer Engineers

Inputs

● Project charter

● Project management plan

● Scope management plan

● Requirements management plan

● Stakeholder engagement plan

● Project documents

● Assumption log

● Lessons learned register

● Stakeholder register

● Business documents

● Business case

● Agreements

● Enterprise environmental factors

● Organizational process asset

Techniques and Tools

● Expert judgement

● Data gathering

● Brainstorming

● Interviews

● Focus groups

● Questionnaires and surveys

● Benchmarking

● Data analysis

● Document analysis

● Decision making

● Voting

● Multicriteria decision analysis

● Data representation

● Affinity diagrams

● Mind mapping

● Interpersonal and team skills

● Nominal group technique

● Observation/conversation

● Facilitation

● Context diagram

● Prototypes

Outputs

● Requirements documentation

● Requirements Traceability

Matrix

Figure 16: Inputs, Tools and Outputs for the process 5.2 Collect Requirements in PMBOK

Figure 16 contains the schematic representation of inputs, outputs and applicable tools and methodologies for this process. This is one of the processes with the most extensive list of Inputs and Techniques and Tools. Following this process, collecting the requirements for a project requires a set of inputs, such as the project charter, the project management plan and others, as listed in the left hand box. The output of this process will be the Requirements documentation, which will have to be defined, and the Requirements Traceability Matrix, a tool that allows to match user requirements with technical features of the project output. PMBOK recommends an extensive set of Techniques and Tools to collect requirements in a project, such as use expert judgement (talk to people who have previous experience in managing similar projects), gather all possible data (by means of brainstorming sessions, surveys and questionnaires, interviews and others) and recur to decision making processes, like voting or multicriteria decision analysis when you have to make decisions. Note that prototyping is defined as a tool to collect user requirements.

The PMBOK Guide contains similar definitions for all the processes listed in Figure 15, providing a framework that covers the activities for managing most projects and that defines them as processes, specifyng what should result from each of them, their inputs and the tools and methods to convert from inputs to outputs.

Project Management for Electronic and Computer Engineers

a. Waterfall and Agile in PMBOK

The PMBOK framework has been traditionally associated to the Waterfall paradigm. In fact, the first editions of the PMBOK Guide (up to the 4th edition) did not consider Agile approaches to Project Management. The logic of up-front specification, or documentation driven, is, somewhat, still present in some PMBOK concepts. But this has been changing in recent editions. The fifth edition of the PMBOK Guide, issued in 2013, included references to Agile methodologies and the sixth edition, issued in 2017, includes a companion volume, the Agile Practice Guide (Project Management Institute & Agile Alliance, 2017) developed as a resource to use help using agile and hybrid agile practices, aligned with the PMBOK Guide.

3.2.3 Unified Process

The Unified Process, or UP, is an agile methodology for developing software projects, proposed by Jacobson, Booch and Rumbaugh (Jacobson et al., 1999). UP is part of an effort to define tools adequate for complex software projects development, which includes other tools like UML, the Universal Modelling Language (Booch et al., 1999)

UP framework considers project development in two dimensions: phases and disciplines Phases represent the time dimension and refer to the stages a project goes through. Disciplines describe the different project activities. Figure 17 presents a simple view of the UP life cycle. There are 4 phases: Inception, Elaboration, Construction and Transition, during which activities from the different disciplines are executed. In this example, 6 disciplines are considered: Business Modelling, Requirements, Analysis & Design, Implementation, Test and Development. The graph in each discipline is used to show the effort in each discipline during the project life cycle. For example, most of the work in the Analysis & Design discipline occurs in the Elaboration and Construction phases.

Figure 17: UP phases and activities.

Project Management for Electronic and Computer Engineers

a. Phases

Separating Phases from Disciplines allows for a more flexible management of project activities over time. Some authors like to think of UP Phases as the “Seasons” of a project (Ambler, 2005). During Elaboration and Construction phases, you will be doing activities from the same disciplines (Requirements, Analysis & Design, Implementation, …), but their relative intensity, the amount of work in each of these disciplines will be different. During the Elaboration phase, work will focus on activities related to Business Modelling, Requirements and Analysis & Design; in the Construction phase, work will be less on Business Modelling and Requirements, and more focused on Implementation. This is in contrast with a waterfall approach, where implementation would only start when the requirements were completed.

Phase

Objective

Inception Know what you are going to build. Elaboration Define how are you going to build it.

Construction Build it.

Transition Handle it to the customer.

The concept of phases in UP servers to organize project activities over time and reflects the need for some serialization of activities. By using phases, UP aims at introducing some sequence in the project activities, without imposing a strict organization, as Waterfall does. Table 2 summarizes the objectives in each phase of the UP framework. The purpose of Inception is to have a clear idea of the project objectives. During this phase, you will need to know how will your project deliverable be used and what problems is it supposed to solve, so that you can develop a vision for the project. You should also create an initial project calendar and have at least a preliminary understanding of the project risks and cost. During this phase, you should focus on the what to build, and not on the how

Then, in the Elaboration phase, you transform the project vision into elements that can be built. This is the phase where you start concerning about the how to build your project. This comprises defining the system architecture. Some outputs from Inception phase should be improved during Elaboration: the calendar should now be more detailed and accurate, and the same applies to the costs estimate. Besides identifying risks, you should now define measures for mitigating risks.

The Construction phase corresponds to the time where the team iteratively and incrementally develops a complete product that is ready to be presented to the user. Finally, the Transition phase includes the activities to handle the final result to the user or project client, as well as activities related to project closure: assess if project goals were fully attained and analyse the lessons learned, in order to improve in future projects.

Table 2: UP Phases

Project Management for Electronic and Computer Engineers

b. Disciplines

Disciplines are the logical groups of activities that take place over the lifetime of a project (Ambler, 2005). In some models, disciplines are called process workflows. They provide an organization to the activities that must be performed during a project, aligning them according to common characteristics. The disciplines in the example of Figure 17 are Business Modelling, Requirements, Analysis & Design, Implementation, Testing and Deployment. Without going into further detail, it is easy to understand which kind of activities each of the disciplines comprises.

c. Artifacts

An artifact is some document, report, or executable that is produced, manipulated, or consumed (Booch et al., 1999). Every discipline has a correlated set of artifacts. Each activity in any of the disciplines has a set associated artifacts, either as inputs, or as outputs.

d. Iterative and incremental development

Iterative and incremental development (C. Larman & Basili, 2003) are two practices largely used in agile approaches, such as UP.

Work perfomed in each phase in UP project is divided in a sequence of iterations. An iteration is a complete development cycle, resulting in a release of a working version or a subset of the final product. In iterative development, instead of trying to reach the final result in a single shot, the result is obtained iteratively: first, starting with crude approaches, and then refining the results, each time closer to the desired output.

The iterative approach has been used for long by painters and sculptors. Before painting the School of Athens fresco, in the Apostolic Palace in the Vatican, Rafaello created sketches for his artwork. These sketches allow to have an approximation of the final result, allowing the artist to take decisions based on the perception he gets from the sketch.

Project Management for Electronic and Computer Engineers

Iterations must comply with some conditions:

• Iterations must terminate with a working deliverable. An iteration must add value to the project. It must be something that the user or client can experiment, so that the developing team can get useful feedback.

Figure 18: Sketch for “The School of Athens” (original at Uffizi Gallery)

Figure 19: Final result for “The School of Athens”

Project Management for Electronic and Computer Engineers

• Iterations are time boxed. The iteration end date is fixed from the start and it should not change. If, by some reason, what should be the output of an iteration cannot be completed on time, the scope should be reduced (for instance, by removing the lower priority requests), instead of postponing the iteration end date (Craig Larman, 2004). This stems from how customers may react to a developer failing to comply with what has been agreed. A customer will, probably, accept better that the developer does not show all features working but keeps the previously agreed date, than postponing the demonstration date, trying to complete all features meanwhile.

• Scope does not change during iteration. Once the iteration has started, no changes in the scope of work can be introduced. If external stakeholders request for more features, they will have to wait for the next iteration. The only possible changes to the iteration scope are those introduced by the development team, either because they detected the need for unanticipated work, or because scope was reduced in order to keep iteration within the defined timebox.

Iterations are often aligned with the working week: they start on a Monday morning and they end on a Friday afternoon. This is a rule followed by practical reasons, but it is not mandatory. Most agile methods suggest iteration lengths from one to six weeks long; the most common values are two or three weeks.

Incremental development is a design principle closely related to iterative development. Alistair Cockburn (Cockburn, 2008), one of the subscribers of the Agile Manifesto, distinguishes them as describe in Table 3

Method

Incremental development a staging and scheduling strategy in which various parts of the system are developed at different times or rates and integrated as they are completed.

Iterative development a rework scheduling strategy in which time is set aside to revise and improve parts of the system.

to develop the entire system with a big-bang integration at the end.

to get everything right the first time

Table 3: Incremental and Iterative development (Cockburn, 2008)

Project Management for Electronic and Computer Engineers

Both approaches, iterative and incremental, should be used in the development of ECE projects. Incremental development is “add to”. It means to identify components in the project that can be separately built and added to what exists. It is intimately related to principles like modular programming. For example, in a project to develop a new RFID based access control system, you will most probably need to develop the device-drivers for the RFID reader and some interfacing electronics. If, at same stage, you focus on developing what you need to read the cards, completing that piece of work will add an useful increment to the project: you will have a system that is capable of reading RFID tags (although it does not yet open and close doors, but that will be left for a later stage).

Iterative development means “re-do”. That’s when you start with a more or less crude approximation of the desired result. In the access control system, you may start with LEDs going on and off to simulate locks that open and close. That’s not the final system, but it is an approximation that allows the development team to get some feedback from the end user in a early phase of the project. You will have to re-do some software, but it may be easier and faster to switch LEDs on and off than interfacing with an electronic lock to open and close.

e. UP variants

Since its initial proposal, some variants of the Unified Process have been proposed. These variants maintain the four phases (Inception, Elaboration, Construction and Transition) but diverge in the number and description of the disciplines, as well as in the level of formality associated to the method. The best-known variants of UP are Rational UP, OpenUP and Agile Unified Process.

Rational UP

Rational UP (Ambler, 2005; Kroll, 2003; Rational, 1998) was the original proposal of the Unified Process. The name stems from Rational Software, the company where Booch, Rumbaugh and Jacobson worked at the time they created UP, and that would later be acquired by IBM.

Figure 20: Eifflel Tower is an example of incremental development.

Project Management for Electronic and Computer Engineers

Rational UP considers a total of nine disciplines (Table 4), where the first six are “Engineering Disciplines”, or “Process Workflows”, and the last three are “Support Disciplines” or “Supporting Workflows”.

Table 4: Disciplines in Rational UP

Business modeling

Requirements

Analysis and design

Implementation

Test

Deployment

Configuration management

Project Management

Environment

Describes the structure and dynamics of the organization

Describes the use case— based method for eliciting requirements

Describes the multiple architectural views

Takes into account software development, unit test, and integration

Describes test cases, procedures, and defect-tracking metrics

Covers the deliverable system configuration

Controls changes to and maintains the integrity of a project's artifacts

Describes various strategies of working with an iterative process

Covers the necessary infrastructure required to develop a system

Agile Unified Process

The Agile Unified Process (Ambler, 2006) is a simplified version of RUP that was proposed by Scott Ambler. Work on the Agile Unified Process stopped in 2006, when the author decided to commit to work on the Disciplined Agile Delivery (DAD) framework (Ambler, 2013).

OpenUP

OpenUP (Balduino, 2007) is an open proposal for UP. OpenUP is simpler than RUP but maintaining its key features. It is a part of the Eclipse Process Framework, an open source framework developed within the Eclipse Foundation.

3.2.4 Scrum

Scrum was initially proposed as an approach for developing innovative products (Takeuchi & Nonaka, 1986). In rugby, scrum, or scrummage (Figure 21), is the means of restarting play after an interruption where players from both sides link themselves together in a group, with their heads down, and push against the other side. The ball is then thrown between them and each side tries to get it. Takeuchi and Nonaka took this image of scrum as a metaphor of how teams developing innovative products should work, by opposing to another sport’s metaphor, the relay race, representing a sequential approach to project development. In this relay race, the teams involved in the several steps of the product development process work independently. When their job is done, the team passes the relay baton to the next group. In this sequential approach, functions are

Project Management for Electronic and Computer Engineers

specialized and segmented, and each group is focused on its own speciality; the baton is relayed through the several groups. This sequential approach conflicts with the goals of flexibility and speed.

The alternative approach is to have all people, from different backgrounds and disciplines, interacting and working together, in the same way a rugby team tries to advance in a scrum to get possession of the ball.

It is interesting to note that many characteristics that would be later embraced in the Agile approaches were already present in Takeuchi and Nonaka’s work: multidisciplinary teams, iterative experimentation and self-organizing teams are explicitly mentioned.

The first references to the application of Scrum to software development are probably by Schwaber and Sutherland (Schwaber, 1995; Sutherland & Schwaber, 1995). Since then, Schwaber and Sutherland have been working together to keep “The Scrum Guide” (Schwaber & Sutherland, 2017). This is the main reference for anyone wanting to use Scrum for project development, it is freely available and it is kept updated in the Scrum Guide site (https://www.scrumguides.org/). (Kniberg, 2007) presents a practical approach to using Scrum in software development.

Although Scrum was initially proposed as a framework for software development, it can be applied to many other types of development processes.

a. What is Scrum?

The Scrum Guide defines Scrum as follows:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

The Guide also mentions that Scrum is:

Figure 21: Scrum is the means of restarting play in a rugby match.

Project Management for Electronic and Computer Engineers

• Lightweight

• Simple to understand

• Difficult to master

Scrum follows an iterative and incremental approach and it is based on three pillars:

• Transparency. Transparency means that all stakeholders involved in the project share a common understanding of the project elements. There should not be different interpretations of the same concept. A fundamental shared concept is the notion of done: all team members and all stakeholders should understand “Done” in the same way.

• Inspection. All outputs (artifacts) should be regularly inspected to verify that progress occurs as expected. Inspection should be as frequent as needed, to keep the project on track, but not so frequent that it interferes with the progress of work.

• Adaptation. When the need for changes occurs (for instance, when an inspection shows that the results are not as expected), they must be adopted without delay.

Iterations in Scrum are called sprints.

b. The Scrum framework

The Scrum framework comprises: Roles (what is the mission of people in the Scrum team), Events (what happens) and Artifacts (what is created).

Figure 22: 3 pillars of Scrum

Project Management for Electronic and Computer Engineers

The Events in the Scrum framework refer to what happens during the Scrum process, and they are:

• Sprint. The Sprint is a time-boxed iteration, lasting no more than a month, with the objective of meeting the Sprint Goal. The result of the sprint should be a usable and potentially distributable product Increment. When a Sprint terminates, the following Sprint starts immediately afterwards. During a Sprint, no changes that endanger the Sprint goal can be introduced, quality goals do not decrease and the scope may be clarified between the Project Owner and the Development Team.

• Sprint planning. The Sprint Planning serves primarily to define the Sprint Goal with the collaboration of the entire Scrum Team. The duration of the Sprint Planning is limited to 8 hours, for a one-month Sprint. The Scrum Master conducts Sprint Planning. During the Sprint Planning, the Scrum Team defines what to do (the Sprint Goal) and how will it be achieved. The “how” could include, for instance, defining specific features to implement, based on upper level specifications, such as user stories or others.

• Daily Scrum. The Daily Scrum is an event, time-boxed to 15-minutes, held every day of the Sprint. During Daily Scrum, the team reviews what happened in the last 24 hours and what is expected to happen in the next 24 hours, as well as impediments that may be harming the progress of work. The Daily Scrum is an event to exchange information and keep the team aligned and aware of project progress. If problems are raised, they should not be solved during the Daily Scrum, but afterwards, by the people involved.

• Sprint Review. At end of Sprint, Sprint Team and stakeholders collaborate in inspecting the Increment (the result of the Sprint) and adapt the Product Backlog, if needed. The Sprint Review is an informal meeting, and the purpose is to collect feedback from all stakeholders and improve collaboration. The duration of the Sprint Review is limited to 4 hours, in a onemonth sprint.

Figure 23: Elements of Scrum framework.

Project Management for Electronic and Computer Engineers

• Sprint Retrospective. The Sprint Retrospective is held at the end of the Sprint. During Sprint Retrospective, the Scrum Team reflects on how the Sprint was conducted and tries to identify improvements to be applied in future Sprints. Unlike the Sprint Review, where both the Scrum Team and external stakeholders are present, the Sprint Retrospective is a meeting for the Scrum Team only. The duration should not exceed 3 hours, for a one-month sprint.

The Team refers to the different roles and missions of people that develop work. The Scrum Team is comprised of a Product Owner, the Development Team and the Scrum Master. Scrum Teams are self-organizing and cross-functional; the work organization is defined within the Scrum Team and the team possesses all required competences to produce the desired outcome.

• Product Owner. The Product Owner is responsible for maximizing the product value and he is the representative of the external stakeholders in the Scrum Team. His or her task is to guarantee that the product developed by the Scrum Team corresponds to the needs that gave rise to the project.

• Development Team. The members of the Development Team are those that work to produce the Sprint outcome, the Increment. The Development Team is self-organizing: the team members have full authority to decide how to convert the Sprint Backlog (the list of features to implement during the Sprint) into an Increment.

• Scrum Master. The Scrum Master is responsible for guaranteeing the necessary conditions for the Scrum Team to do the work, and that the Scrum Team works following what is defined in the Scrum Guide. The Scrum Master is a servant-leader to the Scrum Team. The Artifacts refer to work or value that results from the Scrum Team work. They are defined to maximize transparency.

• Product Backlog. The Product Backlog is an ordered list of everything that is known to be needed in the product and it is managed by the Product Owner. Items in the Product Backlog may include the tests to verify that they are Done.

• Sprint Backlog. The Sprint Baklog consists on the items the Product Backlog that were selected for the Sprint, together with a plan for delivering the Increment and attaining the Sprint Goal. If new work comes up during the Sprint (the team may realize the need for a given development that is required for the Sprint Goal during the course of the Sprint, for example), the Development Team adds this work to the Sprint Backlog.

• Increment. The Increment is the sum of all Product Backlog items completed during the Sprint and it must correspond to the definition of “Done”.

A key point in Scrum is the definition of “Done”. When some Product Backlog item is marked as “Done”, this should have the same meaning for all people involved, either members of the Scrum Team or external stakeholders.

Putting Scrum to work

Project Management for Electronic and Computer Engineers

Now that we have presented the different components of Scrum, let us see how they all work together. The whole functioning of Scrum is described in Figure 24. The process starts by gathering all relevant inputs from stakeholders, which can include the customer that ordered the product development, end-users, marketeers, development teams, etc. These requirements will be expressed from a user perspective (what the product must or should do), using methodologies like User Stories. The list containing all these features is the Product Backlog and it is maintained and managed by the Product Owner. The Product Backlog is an ordered list, so every item should be tagged with some priority or importance, to assist the Scrum Team in the process of selecting the items for each Sprint.

The Sprint is now ready to commence. In the Sprint Planning Meeting, the Scrum Team selects which features will be developed in the following Sprint, defining the Sprint Goal and creating the Sprint Backlog. Creating the Sprint Backlog may require defining the features collected from the Product Backlog with a greater level of detail. For example, features in the Product Backlog may be expressed as User Stories. To estimate the effort required for each item in the Product Backlog, these User Stories have to be translated into actionable items, such as developing an interface or creating an API. With the Sprint Goal and Backlog defined, the Team starts the Sprint for the prescribed duration, which is commonly from 2 to 4 weeks. The estimates of time and complexity associated with each item in the Sprint Backlog should allow the Scrum Team to create a work package that corresponds to the Sprint duration: the work assigned to the Sprint, measured by summing the estimates associated to each item, should correspond to the Sprint duration. The Team should start the Sprint knowing that the planned work is doable in the duration of the Sprint (all

Figure 24: The Scrum process

Project Management for Electronic and Computer Engineers

items can be completed during the Sprint) and that they will not run out of work before the Sprint ends (the work is not too little for the Sprint duration).

During the Sprint, the Team gets together every day in the Daily Scrum Meeting to update on the current development status and signalling any difficulties or obstacles. During a Sprint, the Sprint Master should be “hovering” above the process, in order to quickly solve any problems or difficulties that may be impeding progress. At the end of the Sprint, there should be an Increment, some new version of the product that adds value to the project. Before closing the Sprint, the Scrum Team holds the Sprint Review meeting to collect feedback from all stakeholders and, possibly, to make adjustments on the Product Backlog if required. Finally, the Team makes the Sprint Retrospective, where the Sprint process is analysed, in order to identify possible points for improvement.

After the Sprint Retrospective, the Scrum Team prepares the next Sprint. It is common for Sprints to last for an integer number of weeks and to be aligned with calendar weeks, starting on a Monday and ending on a Friday. This is a common practice, but it is not mandatory.

3.3 Tools and Methodologies

In this section, we will address some common tools and methodologies in Project Management.

3.3.1 Gantt

The Gantt chart is a tool to visualize the activities that occur during the project and their schedule. It is a 2-dimensional graph, with time in the horizontal axis and the activities resulting from the work breakdown structure (WBS) in the vertical axis (Figure 25). Each activity in the project corresponds to a bar in the Gantt chart, the position of the bar in the horizontal axis corresponding to the activity schedule.

The Gantt chart can provide some additional information. In Figure 25, the bars in black inside the coloured bars indicate the amount of work completed in each task as a fraction of the total work

Figure 25: Gantt chart example

Project Management for Electronic and Computer Engineers

corresponding to that task. This provides a quick and visual indication if the project is on schedule: in a project running on schedule, all bars to the left of the current date should be covered in black. If the project is running late, there will be bars “in the past” (to the left of current date position) that are not covered in black, meaning that there is work not yet completed. On the contrary, a project running ahead of schedule will have activities covered in black to the right of current date.

3.3.2 Precedence Diagram Method

In the Precedence Diagram Method, the project tasks are represented as nodes in a graph and the edges, or links, represent the precedence relationships between the tasks. Precedence graphs are directed graphs, meaning that the edges between nodes have a direction associated with them. A precedence relationship exists between two tasks when the execution of one of them (the successor) depends on some condition on the the other (the predecessor).

The arrows in the graph denote the precedence relationship, going from the predecessor to the successor. In the diagram in Figure 26, task A precedes tasks B and D, meaning that the execution of both B and D depend on the execution of A: B and D can only start after A as finished. Task E depends on both C and D.

In a Precedence Diagram, the relationships between two activities can be one of the following: FS (Finish to Start), SS (Start to Start), FF (Finish to Finish) or SF (Start to Finish), as shown in Table 5. The FS precedence relationship is, by far, the most common. SS and FF may sometimes be used and SF is very rarely used.

Table 5: Precedence relationships.

Figure 26: A simple Precedence Diagram

Project Management for Electronic and Computer Engineers

The precedence relationships can be qualified with a lag or lead time interval. The lead time is the amount of time the successor can be advanced with respect to the predecessor, and the lag time, the amount of time it can be delayed. It is common to note lag times with a positive value and lead times with a negative value. Table 6 presents two examples of precedence relationships with lag and lead times.

Table 6: Lag and lead times in precedence relationships.

FS

lead time

SS with lag time PCB assembly

A company is moving to their new premises; transporting the boxes to the new site can start 2 days before finish putting all things in boxes.

When producing an electronic equipment, mounting the assembled PCB board in the plastic casing can start 2 days after starting assembling the components.

Precedence Diagrams are a convenient method for planning a project, by graphically presenting all required tasks or activities and the relationships. Knowing the duration of each task and the precedence relationship between them allows to estimate what the project duration will be.

a. Activity on Node and Activity on Arrow

The precedence graphs that we have just discussed are called Activity on Node (AON) diagrams: the nodes correspond to work that is performed and the passing of time occurs in the nodes. The links, or edges, correspond to the transition from one activity to another and no time interval is associated to links. Figure 27 presents a simple project for an electronic product by means of an Activity on Node diagram2

2 This is a simple project, for example purposes only! There is no intention of saying that any project to develop an electronic product should follow this structure.

Project Management for Electronic and Computer Engineers

HW design

PCB fabrication

PCB assembly

Specification

SW design Implemen. & tests

Final tests

The same project can be represented by a Activity on Arrow diagram (AOA), as in Figure 28. In this case, the nodes are associated to events or milestones. They correspond to moments on time during the project. The passing of time and the development of work occurs in the transitions: the arrows.

HW design

PCB fabrication

PCB assembly

Specif.

SW design Implem. & tests

Final tests

Both representations are equivalent and opting by one or the other is a question of personal taste. In this text, we will use AON graphs to represent precedence diagrams.

Most of software programs that create Gantt Charts merge the concepts of Gantt charts with Precedence Diagrams, by depicting the precedence relationship as arrows from predecessors to the successors. This makes the Gantt chart also an AON diagram, with the horizontal dimension of the node (the length of the bar) representing the time dimension.

b. Critical path method

The Critical Path Method, or CPM, is a procedure to compute the duration of a project, given the duration of the tasks and their precedence relationships.

In CPM, each node and the associated data is represented as in Figure 29. The meaning of the abbreviations in the four corners is presented in Table 7; these are values to be computed in CPM, as well as the value of the Float parameter.

Figure 27: A simple project represented by a AON diagram.

Figure 28: The same project represented by an AOA diagram.

Project Management for Electronic and Computer Engineers

Duration

Task name

Consider the project in Figure 30, a very crude approximation of what could be the precedence diagram of a project for launching a website. All precedence relationships are FS with no lag or lead. We will now apply the Critical Path Method to this project.

Forward calculation

The first step in CPM is called forward calculation: in this step, we will start by the first task and schedule all tasks in the project trying to start and finish them as early as possible. We will use a

Figure 29: Task representation for CPM.

Table 7: Values to be computed in CPM. Abbrev. Meaning

Figure 30: Example project for CPM.

Project Management for Electronic and Computer Engineers

simplified representation of the task, as in Figure 31. The following example uses the convention of starting the project on day 0. Following this convention, the end date for a task is the start date plus the duration. In this case, “Web site design” is the first task; its Early Start (ES) date is 0 and Early Finish (EF) is 0+14=14.

Although the convention of starting on day 0 may seem odd at beginning, it is used to simplify the algebra of computing start and finish dates. Using this convention, the finish date is simply the start date plus duration. The alternative would be to start the project on day 1. Using this convention, the finish date for a task is (start date + duration -1): a task starting on day 1 and with a duration of 10 days will end on day 10 (1+10-1).

Another advantage of day 0 start convention is that the start date of the successor in a FS precedence relationship is equal to the finish date of the predecessor. Otherwise, with the start on day 1 convention, the start date of the successor would be the finish date of the predecessor plus 1. Considering that tasks take an integer number of days, if one task terminates at the end of day n, the following task will start on the beginning of day n+1. The convention of starting on day 0 simplifies the computations.

Figure 32: Example project after forward calculation.

31: Simplified representation of a task.

Project Management for Electronic and Computer Engineers

After computing the start and finish dates in the forward calculation, the result is presented in Figure 32: ES and EF are computed for all the tasks and represent the earliest possible dates, given the tasks duration and precedence relationships. The rules for the computations are as follows:

• First task starts on day 0.

◦ For task 1: ES = 0.

• For each task, EF = ES + Duration.

◦ For task 1: EF = 0 + 14 = 14

• If a task B as one single predecessor A, the start date of B is the finish date of A: ESB = EFA

◦ For task 3: ES3 = EF1 = 14

• If a task B has many predecessors A1, A2, …, the start date of B is the latest finish date of its predecessors: ESB = maxi( EFA,i).

◦ For task 6: EF6 = max(EF2, EF3, EF5) = max(59, 16, 34) = 59

Backward calculation

The following step is the backward calculation. Now that the completion date for the project is known, we move backwards, from the end to the beginning, trying to schedule the tasks as late as possible. This will yield the Late Finish (LF) and Late Start (LS) dates. The rules are:

• The Late Finish date for the last task in the project is its Early Finish date: LFlast_task = EFlast_task

◦ For task 7: LF = EF = 76

• The Late Start date is the Late Finish date minus the Duration: LS = LF – Duration.

◦ For task 7: LS = LF – Duration = 76 -2 = 74

• The Late Finish date of a predecessor task is the earliest Late Start date of its successors: LF = min(EFsuccessors).

◦ For task 6: LF6 = LS7 = 74.

◦ For task 1: LF1 = min(LF2, LF3, LF4) = min(14, 57, 39) = 14.

Project Management for Electronic and Computer Engineers

Following these rules, the result of backward calculations is in Figure 33. It is possible to note that, for some tasks, the Early Start and Finish dates are different from the Late Start and Finish dates, whereas for some others (Tasks 1, 2, 6 and 7), the forward and backward calculations produce the same results. The fact that one gets the same results scheduling these tasks as soon as possible (forward calculation) or as late as possible (backward calculation) means that, if the project completion is to be respected (in the example, if the project is to finish by day 76), these tasks cannot move in the calendar. They constitute the project’s critical path (Figure 34): a delay in any of these tasks will have as consequence an identical delay in the project completion date. Contrast this, for instance, to the situation of task 3 in the example: this task may start any time between day 14 and 67, that the project will still be able to complete on day 76. The critical path is the path from beginning to end of the project with the longest duration.

Figure 33: Results after backward calculations.

Project Management for Electronic and Computer Engineers

The difference between Late Start and Early Start (or Late Finish and Early Finish) is the task’s float or slack. For all tasks in the critical path, the float is 0. For task 3 in the example above, the float is 59-16 = 43. This mean that the task may be delayed up to 43 days w.r.t. the initial calendar without affecting the project closing date.

Critical path and project management

The concept of the critical path is a fundamental concept for managing a project. Some aspects related to tasks, both in and out of the critical path, are:

• Tasks in the critical path can not be delayed and their execution must be kept on time. Every delay suffered by a task in the critical path will have, as a consequence, an equal delay in the project finishing date. As such, critical tasks should be closely monitored by the project manager, to guarantee that they do not take longer than scheduled. The only ways to reduce the impact of a delay in a critical task are to reduce the duration of the following tasks in the critical path or to reschedule the whole project, redefining the precedence diagram. Any of these two can be hard to achieve.

• Saving time in tasks outside the critical path will not contribute to finish the project earlier. The longest execution time lies on the critical path. Shortening the length of tasks outside the critical path will not modify the time to execute the critical path. It will only contribute to increase the tasks slack time, not to decrease the project duration time.

• Non-critical tasks can be a resource stock for critical tasks. If the project manager notices that a critical task is about to take longer than scheduled, a possible option to mitigate or eliminate the problem is to move resources (people, machinery, even money…) from non-critical tasks to that critical task, if this may contribute to finish the critical task sooner. A necessary caution is that the delay incurred in the non-critical task, as a result of

Figure 34: Critical path of the project.