• Nenhum resultado encontrado

Development and Implementation of a Product Management Methodology in a Supply Chain Management Startup

N/A
N/A
Protected

Academic year: 2021

Share "Development and Implementation of a Product Management Methodology in a Supply Chain Management Startup"

Copied!
48
0
0

Texto

(1)

Development and Implementation of a Product Management

Methodology in a Supply Chain Management Startup

Joao Lourenço França Cabral Machado

Master Thesis

Supervisor at FEUP: Prof. João Claro

(2)

“Todo o mundo é composto de mudança, Tomando sempre novas qualidades.”

(3)

Resumo

A empresa na qual foi desenvolvido o projeto de dissertação é uma Startup na área da Gestão da Cadeia de Abastecimento, com dois anos de existência e com um crescimento acentuado no último ano, em grande parte devido ao fecho da segunda ronda de investimento. Este crescimento trouxe maior complexidade á empresa, traduzindo-se também num aumento significativo do número de colaboradores, projectos e de clientes.

O principal produto desenvolvido pela empresa é o Spoke, uma plataforma Software as a Service que tem como objectivo juntar todos os participantes no processo da gestão da cadeia de abastecimento num espaço virtual comum. Até então, este produto não estava a ser desenvolvido de uma forma muito estruturada e, apesar de a empresa basear-se em alguns principios Agile para o seu desenvolvimento, maioritariamente Scrum e Kanban, ainda não se guiava por uma metodologia definida. Com o aparecimento destes novos desafios para a empresa, tornou-se tornou-se absolutamente necessário começar a gerir e desenvolver o produto com uma metodologia definida que possa trazer um produto de melhor qualidade e mais estabilidade no processo.

O grande desafio enfrentado neste processo, prende-se com o facto de decidir como escolher uma metodologia que possa responder de forma eficaz e adaptar-se ás características da empresa, no que diz respeito a tamanho, cultura, objectivos estratégicos, entre outros.

A recolha de dados na empresa, desenvolvendo entrevistas informais e analisando documentação existente possibilitaram uma melhor percepção dos problemas mais críticos na empresa respeitantes a esta temática, que são identificados no decorrer deste documento e mais tarde, são desenvolvidas soluções para endereçar os problemas identificados.

Os resultados foram validados através de metódos qualitativos, através de entrevistas informais, depois da metodologia ser implementada.

(4)

Abstract

The company of the study is a startup company in the area of Supply Chain Management with two years of existence and that has been growing exponentially during the last year due to the closure of the second round of investment. This growth has brought more complexity to the company, a representative growth in the number of employees, projects and customers.

The main product developed by the company is Spoke, a Software as a Service platform that has the goal to bring all the participants in the supply chain management process to one common virtual place. Until now, this product was not being developed in a very structured way, the company was starting to follow some Agile principles, mainly based on Scrum and Kanban, but didn’t had a defined methodology. With this new challenges faced by the company, it turned to be absolutely necessary to start to manage and build the product with a defined methodology that could bring better quality product and more stability.

The main challenge faced in this process was how to create a methodology that could fit with the specific characteristics of the company, regarding size, culture, strategic goals, among others.

The collection of data, performing informal interviews and analysing documentation in the company allowed to understand the most critical problems in the company and a set of solutions were proposed to address the problems.

The results were after validated with performing interviews after the methodology was implemented and using qualitative methods.

(5)

Acknowledgments

I would like to thank to all of the ones who somehow had an impact in the development of this work.

I would like to thank in the first place my tutor, for all the availability, help and guidance provided during this project.

To Huub, for providing me the conditions and opportunity to develop this work in their premises, for the fantastic environment lived inside and all the people that work in the company.

I would like to specially thank Tiago Craveiro and Pedro Santos, two of the founders of the company, who followed my work in greater detail and had always shown total availability and concern about my work.

To my family, girlfriend and friends to support me and keep my motivation always up during this process.

To all the teachers from the master in Service Management Engineering and Management to provide all the inputs that were absolutely relevant for the completion of the thesis.

(6)
(7)

Table of Contents

1 Introduction ... 1

1.1 Presentation of the company ... 1

1.2 Problem Description ... 6

1.3 Structure of the report ... 6

2 Literature Review ... 7

2.1 Project Management ... 7

2.2 Agile methodologies Vs Traditional Software Development Methodologies ... 8

2.3 The Software Development in a Startup Context ... 10

2.4 Software as a Service ... 10

3 Problem Characterization ... 13

3.1 Initial project idea ... 13

3.2 Spoke ... 14

3.3 IT Team ... 17

3.4 Product Management and Development in Huub ... 19

4 Solutions ... 23

4.1 The teams and the roles... 23

4.2 The process ... 24

4.3 The Communication Channels ... 27

4.4 Templates ... 28

4.5 Kanban Board ... 30

4.6 Prototyping ... 31

5 Results ... 32

5.1 Process and Roles Results ... 32

5.2 Communication Channels Redefinition ... 32

5.3 Product Definition Templates ... 33

5.4 Kanban Board ... 33

5.5 Prototyping ... 33

6 Conclusion and future research ... 34

References ... 35

APPENDIX A: Balsamiq Prototype ... 37

(8)

List of Tables

Table 1- Architectural archetypes ... 12 Table 2- Problems ... 22

(9)

List of Figures

Figure 1- Huub Main Processes ... 2

Figure 2- Warehouse Flow ... 3

Figure 3- Business Model Canvas ... 4

Figure 4- Spoke Interactions ... 15

Figure 5- Spoke Login ... 16

Figure 6- Spoke Initial View ... 16

Figure 7- Spoke Architecture ... 18

Figure 8- Story Structure ... 19

Figure 9- Product Development Team ... 23

Figure 10- Product Management Team ... 23

Figure 11- Specification Process ... 25

Figure 12- Intercalation ... 27

Figure 13- Chapter Template ... 29

Figure 14- Story Template ... 28

Figure 15- Feature Template ... 29

(10)

List of abbreviations

AM-Account Manager IT- Information Technology MVP- Minimum Viable Product PM- Project Manager

(11)

1 Introduction

This report was written under the scope of the master degree in Service Engineering and Management from FEUP (Faculdade de Engenharia da Universidade do Porto) with the goal of conclusion of the degree and it will describe the dissertation project “Development and Implementation of Product Management Methodology in a Supply Chain Management Startup” performed from 6 of February until 23 of June of 2017 in the company Huub.

The recent phenomenon of digitalization of supply chain management opened space and opportunity for new actors in the market. Many start-ups are entering in this segment and with considerable success. The main factors can be considered the flexibility to the market changes and the fact that most of these companies have cloud-based software’s which allows them to have very competitive service prices and a facilitated scalability.

In order to be able to have a part of the market share of the logistics market and compete with the large supply chain management companies, these startups in logistics market tend to specialize in one specific activity of the supply chain or to specialize in a specific market in order to reduce the complexity that is attached to this area.

Huub wants to disrupt the supply chain management paradigm and doesn´t want to be just “one more” startup offering a technological product inside logistics, Huub wants to offer a technological product but beside this wants to manage and control the whole supply chain operations of the customers, releasing them from activities where they don’t add value and letting them focus on their real competitive advantages.

1.1 Presentation of the company

HUUB is a Portuguese startup of supply chain management and operates mainly in the fashion industry. The company started working two years ago, but the representative growth started only since one year, after they achieved the first investment round.

One of the most relevant growth metric of the company is the number of workers, one year ago the company had only 7 workers, having right now around 30.

Some other relevant numbers of the company:

Sales:

-13 clients;

-Clients from 6 different nationalities;

-Sales of 300 000 eur in 2016;

Logistics:

-Shipments made to more than 60 countries;

(12)

The company considerers itself as the network that connects the whole supply chain of the brands, providing an to-end view: from the production, to the delivery to the end-customer. To support visibility of this end view and, facilitate interaction, they built a web based collaborative platform called Spoke, where they aim to gather all the participants of the supply management: suppliers, brands, end customers and Huub.

The company manages two main flows and they highly depend on each other: the physical flow and the data flow.

The physical flow is represented in the following image by the main logistic operations that they perform:

Production follow up:

 Frequently contact the brand´s suppliers in order to have information about the production state and product delivery dates in order to plan product receptions;

Inbound Logistics:

 Product reception quantities control;  Product batch split to orders or to stock;  Warehouse products;

Outbound Logistics:

 Prepare products to shipment according to orders requirements; Shipping management:

 Select best carrier option according to brand shipment necessities and market possibilities;

 Monitor and control of transport incidences;

(13)

 Customs clearance; Returns:

 Monitor and control reverse transport of products;  Quality control on receptions.

Inside the Warehouse the product may follow normally two types of flows as represented in the Figure below:

The pick to orders- This is the most typical operation performed by the logistics warehouse.

Most of the fashion brands that work with Huub do their sells in the beginning of the season, without having stock yet. They provide the catalog to the shops and this last ones place their orders. After the brands give order to suppliers to produce based on the selling’s they have already accomplished. In the moment of the reception of the products from the supplier, the products are split and picked directly to the orders, this minimizes the operations and flows of the product and plus allows the company to give a faster response in peak times since the orders are already placed in the packs to be shipped since the reception. This is the typical process of a brand that works with wholesale channel.

The pick to stock- This process is more characteristic of Brands that work with retail

webshop channels. In this case Brands must have stock available in order to respond to customer orders quickly. It is also common in Brands that work with wholesale and want to keep a small stock quantity for possible orders during the season. After the reception the

(14)

products are kept in a stock area in the warehouse and are only move from this location when new orders are placed.

The data flow activities support all the physical flow operations, giving the brands and Huub visibility into the operations and they take a key role in support of the company projects, from data mining, to business development or even product development.

1.1.1 Business Model Canvas

In order to easily represent and describe the business model of the company a Business Model Canvas was created. This tool was chosen in order to represent the “AS-IS” strategy of the company in a simplified way, representing the main points in one page.

1.1.2 Organizational Structure

(15)

Huub has a quite flexible organizational structure consisting of different teams, but often adopts a matrix structure due to the considerable number of multidisciplinary projects that it develops.

The different teams are:

 Financial/Legal This area is responsible to accounting and financial operations, legal issues, and human resources administrative activities since the company does not yet have a human resources team.

Operations This area is in charge of all the WH processes, such as Inbound Logistics, including all the activities related to the reception and storage of products and Outbound Logistics, comprising all the activities related to the preparation of products for shipping.

 Account Management (AM) The team act as a point of contact between the brands and Huub. It is responsible for managing the operations from the perspective of the brands, and acts as a bridge between the brands and the Operation team. It manages all the onboarding processes, which include inserting all the relevant information for each season in the management system (brands customers, suppliers and orders), negotiaties and monitorizes transportation, performs the follow-up of production and manages all brand issues.

 Marketing and Sales This team is responsible for Huub´s external representation. Its members are the ambassadors of the company, developing and executing communication strategies, making image decisions, managing distribution channels, and targeting new potential customers.

 Buisness Inteligence/ Artificial Inteligence This team can be considered the “data managers” team. Its activities are mainly organized in projects, which can be very different in purpose, but always have in common the usage of data. It is developing projects such us: creating a chat bot can be considered the “data managers”. Their activities are mainly based on projects which can be very different in the purpose having only something in common: usage of data. They are developing projects such us: creation of a chat bot; implementing a simulator that optimizes and decides the best shipment box for a given set of products based on volume and weight, or developing a decision support system that decides wether a given shipment should be handled by an outsourced operation or managed internaly, among others.

Information Technology (IT) / Internet of Things This team is mainly responsible for the development and maintenance of Spoke , the software platform. This includes back-end activities, front-end activities and integration with other services.

(16)

1.2 Problem Description

Product management (PM) in technological areas is a subject with growing importance. Increasingly, pure technology based companies, or technology enabled companies, feature a product management team in their structures.

The product manager is responsible for developing a product vision and strategy. Since most startups work with only one product, this role has a huge influence in setting the direction for the company.

Companies commonly apply project management methodologies. This is justified by the fact that new product management is characterized by large uncertainty and complexity, the latter driven by closely interrelated activities, which project management frameworks help to mitigate with all the tools and controls they apply.

PM methodologies, include different techniques for different stages of the product lifecycle, starting with product definition and ending with product release.

As organizations are complex systems, very different from each other, that develop very specific environment and personalities, an important question comes up when developing and choosing a product management methodology: which methodology can fit best, the environment and the strategical goals of the company?

This was the main research question faced in the development of this work.

1.3 Structure of the report

This document will be organized in the following way:

The first chapter will consist of an introduction to the dissertation, describing at a high-level the company in which the work was carried out- its evolution, organizational context, business model, and portfolio of services offered. This information contextualizes the study in the company environment. It also presents briefly the problem area considered by this work and the research question that it addresses.

The second chapter presents the state of the art in the areas which were considered relevant for this work. It includes as well a brief explanation of the relations between those areas, expressing thus the importance of the set of concepts as a whole.

The third chapter will give space to the characterization of the problem, describing the department, the product, the current methodology and the problems raised.

The fourth chapter will describe the solutions developed to respond to the problems. In the fifth chapter it will be presented the results of the implementations.

(17)

2 Literature Review

This chapter presents the “state of the art” on the topics that were considered most relevant for this study.

It first describes the different types of project management methodologies, from the most traditional to the most recent, including a comparative analysis, and providing an overview of the processual part of product management. Then it describes the specific context of software development in startups, and the concepts of SaaS (Software as a Service) and SOA (Service Oriented Architecture), highlighting the importance of having the right software structure, and not only a methodology, to allow fast developments.

2.1 Project Management

The field of Project management became largely established in the end of the 80´s, with the application to mass production industries, service sector and public organizations (Boltanski and Chiapello 1999). There is no history of Project Management comparable to the historic work that has been produced for areas such as Marketing, Accounting or Strategic

Management. Very few historians have considered projects as a specific focus of their work (Scranton 2008).

Nevertheless, it is widely acknowledge that the basis of project management theory includes, as many of the management theories “an articulated collection of best practices” (Engwall 1998).

The growing importance of this field is unquestionable, as more and more universities, colleges and companies offer courses related to project management. In late 2014, a gradchools.com search for project management found 370 campus and online accredited graduate, certified and doctoral programs from all types of institutions. According to PMI (Project Management Institute) there are 51 million persons working in projects across the globe.(Schwalbe 2015)

The emergence of project management practices that later on evolved to become

methodologies, took place in a context in which companies were forced to develop very fast the ability to engage with an increasingly competitive dynamic and unpredictable market. Prince2, a project management methodology funded by Office of Government Commerce (OGC) of the UK, is one of the most diffused methodologies around the world, applied in more than 150 countries. It defines a project as “a temporary organisation that is created for the purpose of delivering one or more business products according to an agreed business case and considers the following two competitive imperatives as a key challenge to succeed in today’s innovation-driven economies:

 maintain the current business operations, addressing profitability, service quality, brand loyalty and productivity, among other concerns;

 and transforming business operations-deciding how business change can be introduced to best effect for the organization.

(18)

It considers projects as the means by which we introduce change, and, while many of the skills required are the same for both imperatives, there are some crucial differences between managing business as usual and managing projects. The main characteristics that differentiate projects are their change, temporary, cross-functional , unique and uncertain

nature.(Commerce 2009)

According to the PMBOK (Project Management Body of Knowledge), the most popular body of knowledge reference in the domain there are nine underlying key knowledge areas in project management: Integration, Scope, Time, Cost, Quality, Human Resources, Communications, Risk and Procurement.

There is however some criticism of the PMBOK within project management community because the guide does not identify the relative importance of each of the nine areas. (Zwikael 2009)

Most academics working in the field agree that differences in project management exist among industry types.(Cooke-Davies and Arzymanow 2003).One of the ways to measure success in project management is what is called in the literature the “golden/iron triangle” which is based on three indexes ( Time, Cost and Scope), and is mainly focused on the efficiency of the project management process (Atkinson 1999). However these metrics are considered to have some limitations and many authors suggest some other metrics to quantify the success of a project, e.g, related to customer satisfaction (Dvir, Lipovetsky et al. 2003). As Peter Drucker said once “Doing the right things is more important than doing things right”.

2.2 Agile methodologies Vs Traditional Software Development Methodologies

 Waterfall

The DoD (United States Department of Defence) back in the 70´s, created Ada, a standard department wide programming language, and at the same they developed a series of standards and procedures that the DoD considered that would encourage good software engineering.

These standards were characterized by a rigid, sequential, and large front design effort, a large testing effort at the end and a high degree of documentation. This approach was later named “Waterfall” (Council 1997).

The pillars of this traditional waterfall-based software development approach are the following:

 the systems are developed in a sequential process (at times even in a single pass);  requirements are determined up front, with the dual assumptions that they can all be

known up-front, and that they are and will remain unchanged;  analysis is done once, and precedes design;

(19)

 all coding is done once, and precedes testing and integration;  all testing is done once;

 formal review and approval is required to proceed from any one step to the next;  the customer is most involved in setting the requirements, is hardly present during

analysis design and coding, and re-emerges during test and acceptance;  extensive documentation required for every step.

 Agile

Jim Highsmith, in his writings about the context of the Agile Manifesto creation, said that the group was driven by “the need for an alternative to documentation-driven, heavyweight software development processes” – how the waterfall methodology was frequently characterized (Beck, Beedle et al. 2001).

On February of 2001 in a ski resort on the Wasatch mountains of Utah, 17 people met to talk, ski and relax, and what emerged from this meeting was the Agile Software Development Alliance, and the consequent signing of what is known as the Manifesto for Agile Software Development.

The Agile methodology movement is not anti-methodology, it embraces modelling, documentation and planning, but in a different and less “rigid” way, compared to traditional methodologies.

The manifesto proclaimed a set of values which are on the basis of any agile methodology:  individuals and interactions over processes and tools

 working software over comprehensive documentation  customer collaboration over contract negotiation  responding to change over following a plan

Additionally, a set of principles have also been created, including (Fowler and Highsmith 2001) :

 satisfy the customer through early and continuous delivery of software development;  welcome changing requirements, even late in development-agile processes harness

change for the customer´s competitive advantage;

 business people and developers work together daily throughout the project;

 the most efficient and effective method of conveying information with and within a development team is face-to-face conversation;

(20)

2.3 The Software Development in a Startup Context

The definition of “startup” is something that the literature does not yet have a wide consensus on. The concept was built and developed by entrepreneurs and there are no strict rules for which thresholds a company should meet to be considered a startup, regarding metrics such as number of employees, years of existence or turnover.

Steve Blank, one of Silicon Valley’s most well-known entrepreneurial educators defines a startup as: “a temporary organization designed to search for a repeatable and scalable business model.”

Eric Ries, a prominent entrepreneur and writer of the book “The Lean Startup” defines a startup as “a human institution designed to create a new product or service under conditions of extreme uncertainty.” The choice for these two authors’ definitions, beside their credibility in the entrepreneurship world, is related to the fact that these definitions encompass two key characteristics of: scalability and uncertainty;

Minimum Viable Product

For a startup it is of extreme importance to validate its value and growth hypothesis as soon as possible, because they usually work with few resources, therefore this validation process is often also an important tool to convince investors of the potential value of the product/company. In order to do that, the company has to come up with a version of its product that is complete enough to demonstrate the value it brings to the users: a minimum viable product (MVP).

On one hand this product should include only the essential set of features, but on the other hand should include development of capabilities to measure its traction on the market. (Moogk 2012)

The concept of building minimum viable products should not be confused by no means with the creation of a “bad” product. In the validation of the hypothesis the products, normally numerically indicators are used, such as: growth of adoption rates, growth of sales, meaning that even this simplified version of the product must have good acceptance and metrics will help to prove it.

2.4 Software as a Service

SaaS (Software as a Service) is a concept that was promoted by the software industry leaders (Microsoft, Oracle, Sun, among others), in the beginning of this century as the basis of the next computing paradigm (Greschler and Mangan 2002). Although this was an innovative concept at the time, and with a huge degree of uncertainty regarding its future relevance, the importance that was given by the above mentioned companies and their influence in the industry, could already be seen as a good indicator of its potential future impact, and that it would not be just another temporary “trend”.

(21)

Salesforce, the worldwide leader of CRM (Customer Relationship Management) platforms, founded in 1999, was a pioneer in the revolutionary idea of replacing traditional CRM systems by cloud-based solution. It is considered by many authors as the pioneer of SaaS and it describes SaaS as “a way of delivering centrally hosted applications over the Internet - as a service. SaaS applications are sometimes called web-based software, on-demand software, or hosted software. Regardless of the specific name, SaaS applications run on a SaaS provider’s servers. Instead of installing and maintaining software, a user simply access it via the Internet, free from complex software and hardware management. The provider manages access to the application, including security, availability, and performance. SaaS business applications are usually accessed by users using a thin client via a web browser.”(Salesforce Website).

2.4.1 The growing importance of SaaS

McKinsey developed a report in 2007 titled “Delivering Software as a Service” focused on describing and analyzing this concept that they described as “a new delivery method (…) shaking the software industry´s foundation”. In this report, McKinsey mentions an IDC report from 2007 that projected that by 2009 10% of the market for enterprise software would migrate to a pure SaaS model.

There are a few factors pointed in the study for this adoption rate growth, which highlight the fact that new software design and delivery models allow many more instances of an application to run at once in a common environment, so providers can share application costs effectively across hundreds of companies. Besides this, bandwidth costs continue to drop, making it affordable for companies to purchase the level of connectivity necessary for applications to perform effectively.

Another reason is the fact that consumers are unhappy with the cycle of buying a software license, paying for maintenance contract, and having to go through time consuming and expensive upgrades. Many consumers believed they would have an increased control over the service if they would pay a monthly fee, and switch to another vendor in case the first failed to perform.(Dubey and Wagle 2007)

A more recent report, from 2016 by Tech Pro Research called “Software as a Service-adoption rates, business benefits, and preferred providers”, based on an online inquiry, targeting 200 workers from IT and non IT areas, has showed that 49% of those inquired in their investigation are already using one or more SaaS solutions and 23% planned to implement one SaaS solution within one year.

When questioned specifically about the type of applications that are provided to the business by SaaS providers, email service is the preferred one with 64% of respondents using it in cloud-based, compared to 55% in 2013.Integration of web services into in-house applications grew substantially as well since 2013, from 15% to 26% in 2016.

When questioned about the most important factors to move to SaaS the respondents ranked the following as the most important: improved availability (61%), anytime/anywhere access (57%) and lower total cost of ownership (55%). (Meghann Agarwal 2017)

(22)

The evolutionary architecture concept is critical for a tech company to strive nowadays. Companies like Google, Amazon and Ebay had near-death experiences due to architectural problems. Jez Humble, the writer of books like “Continuous Delivery” and “The Devops Hand book” states that architecture of “any successful product or organization will necessary evolve over its life cycle.”

The biggest challenge is how to constantly migrate from the architecture the organization has to the architecture it needs.

The Strangler Application Pattern

Martin Fowler famous developer and writer of some famous books in the tech industry, wrote an article in 2004 in his blog, where he defined “the strangler application pattern”.

This is a technique built to progressively change architecture of systems. Basically is resumed by putting an existing functionality in an API and avoid making further changes to it. All the new functionalities are then implemented in the new desired architecture and making calls to the old system when necessary.

It is especially useful to decouple a monolithic application or tightly coupled services to one that is more loosely coupled.

Monoliths Vs Microservices

The major architectural archetypes, each of them representing a different evolutionary need for an organization are represented in the figure below together with the pros and cons:

(23)

3 Problem Characterization

3.1 Initial project idea

The exponential growth of the company during 2016 translated naturally into a larger complexity, at an operational and organizational level. The number of projects developed followed the company´s growth and multiplied at a very fast pace. This brought an imminent need for the company: to standardize project development, to adopt a common project language across the company, to facilitate communication and provide visibility into the projects, and to increase efficiency in the use of resources.

It was in this context that the first proposal for the development of this work was prepared: the “Development and implementation of a Project Management framework in the company”. The goals of this framework were to provide to the Board a holistic view of the projects, and at the same time to serve as guidance for each person responsible for developing an individual project.

The methodology that was adopted for the dissertation than was the following: in an initial apply an observation/participation method to operational tasks being performed by each of the teams, observing how people interact in their original environment, and holding some unformal interviews throughout the process. The goal was to develop a broader understanding of the company´s environment and of how the company worked operationally.

Almost at the same time, a review of the project management literature was performed in order to identify the different existing methodologies and which components of those methodologies could best fit the company. This review of the project management literature, carried out in parallel, was instrumental in developing a focused understanding of which questions to ask and what points to observe.

After one month into this process, some early conclusions were achieved, which later led to a change in the scope of the work:

A part of the company was managing projects as processes –The two should be

approached differently, and different methodologies exist for each. Projects tipically feature a much higher degree of uncertainty, and are often multidisciplinary, while processes are often repeated and often interdepartmental. Using the same tools for both therefore would not be effective.

To apply or create a project management framework for the whole company could take a long time, and many companies have different teams working with different methodologies- This process can take a long time and many companies never actually carry it

out, because it require a deep understanding of the different methodologies and a deep understanding of the sociocultural factors of the company, which are not always clear.

In order to manage projects efficiently and effectively, the project owners should have a certain level of experience in the activity and be familiar with methodologies-The

definition of the project management framework per se wouldn’t be enough, because more than standardizing processes and procedures and defining templates, people need to know how to work with them and in the case of Huub, most of the staff have never worked with

(24)

project methodologies before. It would be unrealistic to think that it would be possible to define the methodology and educate the staff of the whole company to work with it, within the timeline of this project. It is a process that usually requires intensive training.

3.1.1 Reformulation of project idea

After deciding that the initial project idea was too broad and its development would not be feasible within this timeline, a new opportunity for the project was identified, that could address many of the issues with the initial idea, and narrow the scope of the project to more feasible proportion.

The reformulation of the project idea can be related to concept of MVP, adopted by many startups. The company identified a need, but did not know very well how to address it- everything was still quite uncertain regarding the solution for this problem. The company then proposed the idea of the project to develop, which worked as a prototype. This prototype was enough to understand that the initial idea was not feasible due to limited resources (the timeline of the thesis), which is a very common scenario in startups, and forced the company to prioritize necessities.

After this prioritization, it was proposed to focus the work in the product section of the company, which in turn made the focus of the thesis much more objective.

3.2 Spoke

Spoke is the technological product created by Huub. It has a crucial part in the value proposition of the company. It is a cloud-based collaborative platform that gathers in a virtual place the multiple stakeholders involved in the supply chain management process: Huub, brands, suppliers and customers.

The development of Spoke is mainly guided according to Brands necessities. Although the system takes also a very important part in Huub operations management, being the ERP (Enterprise Resource Planning) of the company, and this naturally takes also part of the focus to an internal perspective, it’s always triggered and shaped by the Brands necessities, because Huub´s operations are the Brands operations.

To be able to have access to the software, the user just needs internet connection and a browser, following the typical structure of a SAAS. The software is also intended to have bidirectional interface, this means that each of the different type of users are able not only to access information but also to insert and change data.

(25)

Right now, the only users of the system are: Huub employees and Brands. However in less than one year the company targets to bring the other participants to the platform.

In the beginning of this project, Spoke main functionalities were:

 WMS (Warehouse Management System) - Providing support to all warehouse operations such as: picking products to orders, tracking inventory levels and stock locations, among others.

 OMS (Order Management System) - Allows users to manage all the aspects related to orders, including creating/changing receptions orders and sales orders, creating/changing customers information, creating/changing suppliers information and allocating products to different sales channels, among others.

In the end of this project due to the fast paced development of this type of companies, Spoke had already another functionality:

 SMS (Shipping Management System) - Offering support to shipping management activities such as providing rates for transports, buying transportation labels and tracking transportation, among others.

Spoke is the materialization of most of the company´s projects, converting them into an interface and transforming them into a usable service for the users. Its ultimate goal is to become a B2B platform, one in which brands can display catalogues and customers can place their orders in an automated way, and at same time to provide a complete functionality for brands production management, allowing them to place orders directly to suppliers, calculate product costs automatically and use a variety of tools that can facilitate production planning.

The main problematic of this thesis was to find the best way to manage and develop this product. Therefore, a brief presentation and description of the main interfaces and functionalities was intended to be relevant.

(26)

The first step to access Spoke is the log-in (Figure5), a procedure which will allow the system to differentiate the interface provided, depending on the type of user:

After logging in successfully, this is the initial view a Huub´s employee has of Spoke (Figure 6):

The boxes in yellow and blue colors are a dashboard with an overall view of the status of the PO´s (Purchase Orders) and the SO´s (Sales Orders). These two different types of

Figure 5- Spoke Login

(27)

orders represent the basis of what the company will work on, so having a perspective of their statuses is very useful.

In the left-hand side of the interface, each of the icons represents a different functionality with the system divided in the main following areas:

Clients- This area is reserved to manage all the brands administrative information (addresses,

contacts, associated customers and associated suppliers, among others). They are called “clients” because they are considered Huubs clients;

Customers- This area allows the management of all the administrative information of the

different customers, i.e, which represent brands customers.

Suppliers- This area allows the management of all the administrative information of brands

suppliers.

Products- In this area is possible to manage all the product information such as names,

categories, variants, product stock and locations in the warehouse.

Orders- This section allows the management of all the different types of orders, SOs and

POs.

Shipping- This part of the system allows the creation of transport forecasts, the fulfillment of

orders, purchase of transportation labels, and the following-up of shipments.

3.3 IT Team

The IT Team is composed by three elements: One lead full stack-developer which is the responsible for the It operations and one two full stack-developers.

Developing product is the main activity performed by the company, however it’s not the only one. Due to the lack of resources it is needed that the elements are versatile and perform different activities. In contrast with other organizations where in IT teams there are people assigned to only focus in product development, in Huub it is not possible regarding the limited size of the team. The main activities performed by them are:

 Product Development- is the activity that consumes more time to the team. The activities here are divided by front-end and back-end activities. Normally there is different people assigned for each of them.

 Helpdesk- building a management software is not enough by itself, it is needed to create a structure to be able to respond to possible issues related to operational activities. Here is included all the type of internal assistance such us: debugging, which is the process of finding defects in the system and in a fast software

development context this problems are even more frequent and operational assistance, involves all the support which is given regarding the problem raised from wrong usage of the system;

(28)

 Systems Administration- which includes all the activities related to system and servers configuration;

 Other Projects- There are other projects rather than developing the Spoke with a high degree of importance, the main difference is that this projects cover necessities that arise from different areas and normally they are less frequent or sometimes even unique. Examples of this projects: software architecture change projects; integration with a 3PL system, among others.

3.3.1 Huub Architecture

It’s of an extreme importance in every software project it´s architecture. Previously Huub had a monolithic system which was turning it scalability quite difficult. To overcome this, the company implemented a micro service architecture based:

Regarding the software architecture of the system, it is based in a micro-service structure, where Spoke “lives” in an independent module from each of the components. This architecture responds effectively with the needs of the company, which focus a large part of it software development in integrations with other applications.

(29)

3.4 Product Management and Development in Huub

With the growth in the company structure and clients, the necessities have grown proportionately and Spoke had to be able to respond to new challenges: Internally, became imperative to optimize existent processes, which in many cases involved an automation of them, allowing a structure able to escalate effectively. Externally, in a market that is particularly known to be very competitive, became extremely necessary to quickly increase the range of services provided to the clients, and with a better quality, to be coherent with the value proposition of the company.

This two groups of necessities meet the strategical balance that the company constantly focus on achieving: optimize the operational processes but innovating in parallel.

At the moment I started the project, the product section of the company was still under construction and, although the people involved in product development were already starting to follow some agile project management practices, mainly based in Scrum and Kanban methodology, there was a strong necessity of more structuration.

The product management and development was being held with very few planning and control, big part of requirements were being defined by the It team, the features where decided and implemented according to the necessities that would progressively arise from the different teams, but they were being constructed in a very isolated way, without a global vision of the system.

To define the product the company uses the storytelling technique, which in the case of the company divided in: stories, chapters and features. Stories are the definition of product in the most abstract level, they just need to get started with an abstract vision that normally should contemplate one necessity and one or more customers, which represent the ones to who is directed the necessity. Each story has more than one chapter, which is already a more granular definition of the product, here it is already asked to have an idea of the requirements, the flow and possible features that will integrate the chapter. Each chapter can be defined as one small project. The most granular part of one story is one feature, which is a component of the product, and should be defined in greater detail. Each chapter should feet in one sprint, which is a Scrum definition of a time-boxed period, normally between two and four weeks, on which a small increment of product is build. In the case of Huub the goal was to feet one chapter in one sprint, and the sprints had the duration of one month.

(30)

3.4.1 Methodology

The first step of the process of developing and implementing a new methodology was to do an analysis of the current state of product management and development, collecting information inside the company, through the performance of informal interviews, questioning the ones involved with about the current state of the product management and development and at the same time through the examination of documents and records to understand how the information in product management was being managed. This gave a perspective of what were the critical points to “focus on”.

The second step was to formulate hypothesis about the causes of problems identified. This was made based on the information collected in literature review about the topic, analysis made of the current state of product management and plus with some considerations taken during the observation of the different interactions in the company in it natural environment. The third step was to come up with possible solutions for the problems, adapting some existent techniques and methods to the reality of the company.

The fourth step was to validate the solutions. Due to a lack of past data regarding the projects indicators, was not possible to perform quantitative analysis comparing the previous methodology with the new one. Therefore the validation was performed through qualitative analysis, conducting informal interviews again with the ones involved on it and.

(31)

3.4.2 Problems

After conducting the interviews a table was constructed with the main problems identified, the outcome of each problem, a possible cause for the problem and who raised it. This helped to organize the research and focus on what was considered the most important problems. Problem Outcome Possible cause (formulation of hypothesis) Raised By 1- Planned dates to finish developments were often largely exceeded  Teams were often with low moral  Expectations of customers and stakeholders defrauded  Development Team was unexperienced planning workload of the feature  Pressure from the

board to build software fast could result in too optimistic planning  Poor planning  Development Team  Board 2- Product built

was not what idealized by product manager or stakeholders  Rebuilt of features was often, sometimes almost totally  This would lead

to more time spend building software  Documentation of requirements was weak  Gaps in communication between development team  Development Team 3- Frequent change of requirements by stakeholders during the sprint  Result in out-focus of the teams  Planned dates were exceeded  Lack of accountability from stakeholders requirements  Requirements were defined verbally  Development Team

(32)

4- Lack of visibility of the project information  Gaps of communication between the company  Documentation about the project was confusing and was spread in different repositories  Board 5- Control of the project was very low, product manager was only aware about project state in the end of the sprint  Decisions and directions over issues were often took by development team and their vision over the project was limited  Gaps in communication between teams  Head of Product 6- When product was dependent of third parties, the changes in direction were frequent.  Integrations with third party companies are very time consuming and when software supplier changes, is work that cannot be harnessed in future  No risk mitigation activities  Development Team Table 2- Problems

(33)

4 Solutions

This solutions were the result of a benchmarking analysis collecting ideas mainly from referenced blogs and articles and after with some adaptation to the reality of the company. Most of the tools and techniques advised in existent methodologies were thought to companies with larger structures and more experienced teams so the tools were adapted to the reality of the company.

During this chapter it will be explained in the first place the methodology proposed to manage and develop product, explaining the process of the methodology and the different roles. Secondly it will be explained some specific solutions, mainly procedures or tools that were developed to respond to the specific problems raised before.

4.1 The teams and the roles

The roles and the teams are illustrated in the figures bellow:

Figure 9- Product Management Team

(34)

The roles in product team:

Product Owner (PO)-Product owner role is performed by one of the founders of the

company, which is also the head of the product. It is responsible to all the strategic decisions regarding the product: defining the product roadmap, the features, and methodologies in product section.

Product Owner Assistant-This was the role I performed in the company while I was doing

the dissertation. My role was to act as a bridge between the stakeholders and the product development team. I had the freedom to take tactical decisions if any issue would arise, as long as that would not compromise the main goals of the product.

The roles in product development team:

Scrum Master (SM)-He is responsible to manage the Developers work regarding

coordination of tasks and assignment of them to people. In the case of Huub, due to it limited structured, the Scrum Master often performed Developer activities too.

Developers-They are responsible to design, build and test the software. One of the developers

was more focused in activities linked to the front-end and back-end of the application and the other was more focused in activities linked to integrations with third-party applications.

4.2 The process

The process of creating a product is divided by two sub-processes that are inter-connected: the specification and the development.

The specification process is conducted by the product owner and the product owner assistant and they intend to create a solution based on the necessities of the stakeholders, what the competitors are doing and the perspective of feasibility of the Scrum Master, matching the idea presented with the resources available.

The development process is from the responsibility of the development team, although the product management team I also responsible of some activities in the process like: performing the functional tests and conduct usability tests with the customers and release planning.

After the first two month of research in the topic, the first MVP of the methodology processes camed up:

(35)

The specification process was divided in four different meetings that would act as the milestones of the process. In the first meeting would be to elicit the requirements of the features that belong to the chapter. After the requirements were gathered, a digital prototype would be built and presented on the second meeting. The third meeting would be to present the second prototype, now with the feedback of the SM as well which would a more realistic view of the possible solution to implement. The third meeting would be to present the final version and in this one, only the Product team and the Scrum master would participate.

Figure 9- Specification Process

(36)

The development process would contain the activities identified in the above image which will be explained in further detail:

Sprint Planning: The sprint planning was a meeting before the beginning of the sprint, which

would serve to plan the Sprint execution as the name suggests. The features already specified in the sprint backlog would be broken down into activities and the order on which they would be developed would be here decided as well.

Sprint Execution: It is the time boxed period on which the development team, codes and

performs the technical tests of the features. It had the duration of three weeks. Initially the team was using periods of four weeks, but I suggested to change to a shorter iteration cycle (three weeks) because this would allow to have quicker feedback and to plan more precisely, which in my opinion could be important due to the inexperience of the team. I suggested as well in order to improve communication and control to implement the daily Scrum inside each Sprint, which is a meeting of around 15min between the Product team and the Development team where the following questions would be answered: What did you do yesterday? What will you do today? Are there any impediments in your way?

Product Tests- This activity is when the product team does the quality assurance of the

product specified. The guidelines to perform the tests and analyse the correct behaviour of the functionality will be the requirements previously defined. In a second phase, it would be performed usability tests with the customers when they belong to the company. Here the main focus would be to analyse the user experience and design of the functionality.

Release- The release would be an activity which would include the release planning, where

each feature will have a release planning date. There are features that can be run independently but there are another’s which are dependent on the completion of others, this will be decided in the release plan. In this phase would also been given some trainee to the customers, when they belong to the company, about the correct usage of the new functionality.

Sprint Review-The Sprint Review would be a meeting that would serve mainly to do a

review and retrospective of the previous Sprint and realise what went well and what should be improved during the Sprint.

The specification and the development processes were intended to have the same duration (three weeks) and to be interleaved activities. When the beginning of a certain chapter sprint would start, the specification team should be already at halfway in the specification of the next sprint. The following image helps to understand the process:

(37)

4.3 The Communication Channels

The communication Channels for product management and development in the company were not well defined, and when the participants in the process where questioned about the purpose of usage of each communication tool, the answer was not clear between them using it on a random basis which made information very spread and difficult to find sometimes. The company was using the following tools and ways to communicate:

Trello- is a collaborative tool for project management, which allows to write cards with

specifications and easily move them between boards in order to represent the progress;

Dropbox paper- is a collaborative document editing service from dropbox. It was being used

to specify product together with Trello, but was not clear which of them should be used exactly for what. In the end, the specification was often broken down between these two features.

Slack- is a corporate chat service that allows to create teams, share documents and chat in real

time,

Direct communication- many changes were discussed face-to-face, without any written

record. This often led to lack of accountability for changes and divergences on what was agreed on this changes.

After the analysis, it was decided that the reformulated communication channels would serve for the following purposed:

Trello- Would serve to control the progress of the Sprint. Here it would only serve to

document the specification of the features when they would be ready to be allocated to the sprint.

(38)

Dropbox- Dropbox would serve as the repository during the process of product specification:

should include all the updates, benchmark analysis, meeting records, etc.

Slack- Would be used to all the small clarifications that might appear;

Email- Would be used to all the changes that were made after the product was specified.

Every change should be sent by email with all the participants in copy. This would allow to make the changes registered and people responsible for their actions and would substitute the changes made face-to-face.

4.4 Templates

This section of the thesis will describe and present the templates developed for the company in order to improve communication and support work procedures.

4.4.1 Product Definition Template

The product definition template was very confused, and there was no clear standard template that was being followed in order to define the product. This was leading often to misunderstanding of scope. The product manager had a different vision from the other participants. For this reason was created a template in Dropbox paper tool with all the fields that should be fulfilled in order to define the different granularity definition of a product: Story, Chapter and Feature. The fields were also followed in some cases by an explanation in order to explain the differences between them. The different examples of the templates created may be seen bellow:

(39)

Figure 14- Chapter Template

(40)

4.5 Kanban Board

A physical Kanban Board was created in the company, with the purpose of giving visibility and transparency of the current state of the products developed to the whole company. It serve as a support for the Daily Scrum meeting as well, every day the board was quickly reviewed and updated if necessary.

The left column is used to describe the different Chapters the company is developing. Each row corresponds to the different progress states of one Chapter and the yellow post-its correspond to a feature from the Chapter.

This features will progressively be moved from the left to the right side according to the completion state. The column right after which is named “Spec UI/UX” is used to identify the features from the Chapter which under specification once they are already defined. They should only pass to the next column “Backlog”, when they are fully specified and ready to enter in the “Sprint”. After entering in the “Sprint” they pass to “Development” state and once they are assumed to be done from the Development team, they will go to “Testing” column. Here the Product Team will perform their tests and in case the feature positively passes in the tests it goes to the last column “Release” where it stands in standby until the Product Team assumes is the right time to do it. In case the feature doesn’t pass the tests it may go back to

(41)

the first column in case there was specification mistake, or it goes back to backlog in case it was a development mistake.

4.6 Prototyping

The prototyping of features wasn´t being done in the company which often lead to divergent idealization of interfaces and user experience details. The main reason why it was not being done was because of the will to release features quickly and, at same time, the lack of resources in the product team. However the frequent re-doing of features by the development team was the trigger to believe that spending more time specifying and start to prototype would be worthy in the end.

For this reason it was implemented the use of balsamiq, which is a prototyping tool, which is simple and fast to use. The prototyping was used in different phases of validation of the specification phase, not only to use when the product is already defined.

(42)

5 Results

The results from the solutions were not possible to quantify regarding the lack of past data. In this case the results were only qualitative and chosen way to evaluate the results was based on informal interviews.

5.1 Process and Roles

The result of the proposed process of specifying and developing product was in big part positive, however some limitations that needed future reformulation were observed. After questioning the involved in the process about the results in the process, it was consensual that there in general was positive, bringing advantages like:

 “It was much more clear the responsibilities of each role”; (SM)

 “The stablished weekly meetings to specific product allowed people to organize better their time and plan the effort required to participate in projects”; (Head of AM)

 “The daily scrum meeting between the Product Team and Development Team made communication better allowing the product team to be more present in some decisions when issues appeared”; (PO)

 “The product tests before release allowed the product to be released with much more quality and cause less stops in operation”; (Head of WH)

The disadvantages identified were:

 “The releases took a bit more time now”; (Board member)

 “Define standard milestones in advance for the specification meetings made the process too rigid. They should be defined at the moment according to specifications of each product”; (PO)

 “The will to intercalate the specification and development processes of each chapter, taking both the same time in practice was not feasible, because there were some products that required very few of research of specification and a lot of effort by the development and the contrary as well”; (PO)

5.2 Communication Channels Redefinition

The redefinition of communication channels brought advantages especially to the development team:

(43)

 “The usage of email for changes in features brought accountability of decisions, avoiding divergent opinions about what was decided and this much more stability in the process”- ( SM)

5.3 Product Definition Templates

The implementation of a standard templates to define the product had the goal to ensure all the relevant aspects of the scope were covered and to make understanding facilitated. When questioned about the advantages of this change, everyone agreed it brought only improvements:

 “The scope and goals of the product was not always clear and sometimes changed during the process because it was not written, this way helped to make it more clear”; (SM)

5.4 Kanban Board

The Kanban Board main goal was to bring visibility of the process to the whole company and according to the company Board and Heads of Departments which were the ones that complaint the most about it, it accomplished the goal:

 “It is much more clear now to understand the progress, the software was not so easy to access for someone who doesn’t use it on a daily basis “; (Member of Board)

 “It made meetings much more facilitated”; (PO)

5.5 Prototyping

The usage of prototyping although it made the specification taking a bit more time, was referred to increase the quality of the requirements but also to improve the understanding of the ideas in the meetings, making the meetings much more productive.

 “Starting to prototype had a huge impact in the better understanding of the requirements” ( SM);

 “The meetings were much more focused because the ideas were visible”- (Head of AM Team)

(44)

6 Conclusion and future research

The development of the work allowed to take some conclusions, and the first conclusion came out from the initial idea for the project that allowed to conclude that implementing the same methodology to a whole company, may limit their creativity and productivity. There are some principles which are commonly shared in all methodologies, but each team should personalize the methodology to it necessities, because the right methodology depends in many factors such as the focus of the teams, their size, specific environment, etc. So trying to adapt the same way of working to a whole company it is limitative in this type of companies where creativity is a key factor.

The second conclusion is that the change in a company should be progressive. It was tried to implement a methodology with a process that was too “rigid”, and the company was coming from a state of almost no methodology which was suitable with the needs of the company at that time. Following procedures and documenting information may improve quality of the product but take resources and each company should do the evaluation of what is more important according to the current goals.

For further research it would be interesting to start to have some measurement about the project key performance indicators. As the company was coming from a state where documentation was very week, this type of analysis was very difficult or impossible. But now there are some rules and standards that allow to do this with more precision, like: the fact that there is a fixed time for a project (three weeks), or that all the requirements and tests are documented. Would be interesting to analyse indicators such as the percentage of delay in the project completion or the number of changes per sprint. Another important point could be to analyse the features that have to be re-done, to attribute reasons like: bad specification; programming mistake, etc. This breakdown could help to analyse the performance of each the teams.

Imagem

Figure 1- Huub Main Processes
Figure 2- Warehouse Flow
Figure 3- Business Model Canvas
Table 1- Architectural archetypes
+7

Referências

Documentos relacionados

Resultados gerados pelos softwares, Ester 2.1, Stereonet9 e OpenStereo, com os dados da tabela 5 Utilizando os dados da Tabela 2, foi compara- da a plotagem concomitante de dados

A consagração da matriz principiológica das novas constituições; a institucionalização da natureza normativa dos princípios jurídicos; a estruturação de um rol de

Sob tal perspectiva, as teorias da eficiência estática (de Vilfredo Pareto) e dinâmica (de Nicholas Kaldor e John Richard Hicks) serão adotas para a verificação dos ganhos e das

This research elaborated guidelines for learning environments, associating multiple learning activities to performance criteria for built environment, comfort conditions, layout,

Os valores encontrados para a média da massa específica, em g/cm3, do Pinus oocarpa, nas posições relativas à altura comercial da árvore base, 25%, 50% e 75%, foram respectivamente

(2012), a prática de atividade física, desportiva ou outra, mantém e melhora a capacidade funcional, sendo também capaz de possibilitar uma maior inserção na