By. Ivsen Platcheck, Jan, 1st., 2023
Introduction and First Insights
Developing projects and planning is a human activity since the beginning. It doesn’t matter if there was a method, framework, or any kind of practice to achieve the final goal of developing a new product, innovation, a new service way or working method, a new procedure, or improving, updating, or enhancing something already existing.
As human societies evolved, due to the human brain improving and growing, knowledge began to be taught to others. All the processes started to be standardized, and workflows consolidated. Generation after generation, knowledge evolved, and all the working processes were adapted for the environment, personalities, and talents, and kept evolving as humankind evolved itself.
As an Electrical Engineer, I learned always to improve my methods, workflows, frameworks, and protocols to lead me to achieve the best results and reach all the objectives and goals for my work, with top quality and delivering what my clients actually needed.
I worked my entire professional life on projects related to electronics, telephony, energy, and computers, including infrastructure, computers, peripherals, and software, in a wide range of possibilities that reached my hands, or working needs have pushed me. I always accepted the challenges life had given me.
In fact, I was called E-T for moving through such areas said to be incompatible, and impossible for a single professional. Even though, I mostly succeed in most of the initiatives I worked on. I have been involved in projects since my teen ages, I have always liked to work with goals, targets, or objectives.
I learned and used some project management frameworks and methodologies. I went through the Project Management based on planning and controlling, somehow predicted by the PMI (Project Management Institute), as settled at the PMBOK [PMI01]. I always felt that this approach was too tied, and it didn’t give much space for learning and adapting, in an unpredictable world. I used to practice the idea of testing and adapting after each step, on my own, even before I had contact with agile thinking principles.
In the early 2000s, I got to read the first version of the Agile Manifesto [AMO01], and I started to study agile methodologies and principles. At the organization I was working then, it was not an option to start using frameworks like Extreme Programming [BA01], or practicing Lean thinking [PP01], and incremental development, among other Agile Thinking principles. Even though,
Despite my chiefs’ reluctance, I kept reading, learning, and somehow using some of the procedures and artifacts, like a daily meeting for discussing the current status, and a final meeting to discuss what we have done and how it was the working process.
In my readings, I learned about Kanban and Scrum frameworks. Those techniques called my full attention for the way it organizes the working process. The cycles, the meetings, and the incremental development process fulfilled my vision for a good process management path.
It didn’t matter if I was in charge of managing the project team or just a member, I always got some leading role and conducted the team to adopt some of those principles, meetings, procedures, and artifacts.
I made up my mind, and I went deep into studying Agile Management principles, going through Scrum, and Kanban, at first, then I went deeper on OKR, Design Thinking, and agile management itself.
Once I began to organize all I have learned, I realized that I am an Engineer, after all, and all those project management stuff leads to a possibility that, I know it is not new, and neither I am the original on this thought. I started to build in my mind, writing some articles too, and it seems to be something like a Project Engineering thing.
By Engineering it is understood that is a science dedicated to creating practical solutions to specific problems, innovating, create values that have a high potential for improving human life by planning solutions that are economically and technically viable, so you need to know the theme of that project in some depth, but always up to learn and adapt, change paths, in special on a fast-changing and unpredictable world like we actually live.
The approach I take for Project Engineering is using Agile Thinking, giving some flexibility to rigid Project Management Methodologies, allowing empiric work, antifragility practices, and empathy to the client, who is the actual target for the product we should deliver the value produced by the project cycle. I feel that my background in Electrical and Electronics Engineering shaped my flexible and adaptable way of working and facing the uncertain, and fast-changing world.
I start writing out my vision for the project development processes and cycles, using mostly agile methodologies and principles. I intend to describe, analyze, test, learn and adapt my Software Engineering approach. I know this is my first attempt to build some routine path for managing the project cycle process and I am always learning while using those techniques. I am also receiving insights, opinions, suggestions, and any other kind of help I can get from colleagues.
Every project comes from an idea, an initiative from one or a group of persons, in order to produce value, something that can make difference for a set of people, whether external or internal customers of an organization. This value is generated through solving a problem or through a benefit to the customer. [CR01]
In my own opinion, the first thing that the process needs is a facilitator, the one who will lead the cycle, like a servant leader (this concept will be really important throughout the whole process). This facilitator should take the lead for the whole project cycle teams to ensure that all the steps will be taken from the very start and bring together all the persons needed to achieve the final goal in each step.
I bring to use the milestone concept. Non-strict statements, but which allow having a perception of where we are, where we intend to go, or the possible paths ahead, according to what we already have done, analyzed, tested if the case, and learned from the previous steps. Those milestones can and should be reviewed often enough to avoid wrong paths and minimize reworking processes.
The first technique I use is what I call “textual user story”, in order to have the first glance of what the ideas bring about and the desire or necessity of who conceived those ideas. I will talk more further about this technique, but in short, as a slight description of the idea, its fundamentals, and the first possible start-points for the work itself.
Under the Agile thinking principles, this description should lack details, presenting the basic principles, and leave more deep definitions to be added while the process is on the way. But, in my opinion, this description should have, at least, the most important goal for the project delivering valuable products.
Besides, I advocate that the description could have some other features that can be part of, but which should not be made as a “must have” but be mentioned to help guide the team and the process.
Once some versions of the description are written, the facilitator should, with all the help from the stakeholders, extract the main features and list them using any tool suitable for the task, sort them, and extract the most important stories.
Once we have the first insight into the first features needed to deliver what the product the stakeholders expect, it is time to define the objectives, and how those objectives will be achieved. It means, what results will lead achieving the objectives.
The agile management theory talks about OKRs, or Objectives and Key-Results, and in a twisted way, it is what I use to start planning the next cycles and steps. My approach for OKRs is that I not only use them with numeric and objective results to achieve. I plan them with subjective results, too. When I describe the OKRs step and usage, I will present the theory, and how I actually use them.
Once the objectives for the next cycle are identified, the key results are the measure to assure to the objectives are accomplished. The next step is due defining the tasks that will ensure that the key results will be achieved. those tasks will give or use the resources in order to achieve the key results defined at the OKRs and reach the objectives. It is the facilitator’s task to discuss the possibilities with the team and the stakeholders.
I use Design Thinking [LLL01] to work the ideas, and the Use Case [Ca01] artifact theory to create and describe the tasks. At first, those tasks will create their stories, and give the directives for the work ahead. At this point, it is important to have another leading role, known as the responsible for the product, the person who will be entitled to shape the product, adapt, as all the team learns, and decide aspects about the value to be created.
In the sequence, the tasks defined should be estimated for any measure the team agrees to take, like time, points, size, or any other unit the team feels is more suitable for the work to come.
All the process for defining and estimating the tasks leads to other important steps, for refining the stories. Some stories may be too large and complex. They should be split into smaller stories, faster and more suitable to produce working increments for the product, which can be tested, analyzed, and adjusted, if necessary. There are steps named Grooming, and Inception [MM01], which will lead to small stories, that can be finished in one workday.
The responsible for the product should prioritize the stories, and then start the Scrum Framework [SJ01] in order to effectively develop the project using its principles, pillars, events, and theory. At the sprint cycles, I use Kanban [VY01] board to visually organize and control the workflow.
The process evolves on cycled, from the OKRs, delivering the increments, until the whole value is delivered to the stakeholders. Along the way, the learning takes the team to evolve and work better, adapt, and deliver the value that should be. It may not exactly fit the first specifications, but once the market changes, the people learn more, and corrections should be made.
This is the first approach to what I intend to show how I see Project Engineering could help organizing the processes. At the next articles, I will describe one by one, the techniques I advocate to make my idea for project engineering working process.
This is just the first insight, a macro-view, before writing about each step, each technique, and framework.
I encourage all colleagues to reply and give me insights. I use the same principles, executing, testing, analyzing, learning, and adapting for all my working processes. Some concepts, I may eventually add as appendixes.
References
ABC01 – “The Agile Manifesto”, The Agile Business Consortium.
AMO01 – “Agile Manifesto”, agilemanifesto.org
BA01 – BECK, Kent & ANDRES, Cintia, “Extreme Programming Explained”, 2nd Edition, Addison Wesley, USA, 2005.
Ca01 – COCKBURN, Alistair, “WRITING EFFECTIVE USE CASES”, Addison-Wesley, USA, 2001,
Cd01 – CAMPBELL, Derick, “Microsoft Solutions Framework v3 Overview”, Microsoft – ResearchGate, June 2003.
Ce01 – CATT, Evelyn A., “Lean Six Sigma & A3 Thinking Workbook”, TTAC Consulting, LLC, USA, 2015
Cm01 – COHN, Mike, “Desenvolvimento de Software com Scrum – Aplicando Métodos Ágeis com Sucesso”, 1st Edition, BOOKMAN, 2011.
Cm02 – COHN, Mike, “User Stories Applied for Agile Software Development”, Addison-Wesley, USA, 2004.
CR01 – CAMARGO, Robson & RIBAS, Thomaz, “Gestão Ágil de Projetos – as melhores soluções para suas necessidades”, Saraiva, Brasil, 2019.
GOJ01 – GRILO, Flávio Henrique Silva, OLIVEIRA, Helber Felippe and SOUZA JUNIOR, Paulo Antonio, “MATRIZ A3 – UMA ABORDAGEM A CERCA DAS DIFERENTES COMPLEXIDADES DOS PROBLEMAS”, Revista Latino-Americana de Inovação e Engenharia de Produção, vol. 4. num. 6, Brazil, 2016.
Hf01 – Hossain, F. M. A. (2014). A Critical Analysis of Empiricism. Open Journal of Philosophy, 4, 225-230. http://dx.doi.org/10.4236/ojpp.2014.43030
LLL01 – LEWRICK, Michael; LINK, Patrick, LEIFER; Larry; “The design thinking playbook: mindful digital transformation of teams, products, services, businesses and ecosystems”, John Willey & Sons, 2018, USA.
Lo01 – “Forms and Templates”, Lean Enterprise Institute, Inc, 2022, url: https://www.lean.org/events-training/forms-templates/.
Ml01 – MARTOS, Lucas Santana, “LEAN SIX SIGMA: O QUE É E QUAIS SÃO SUAS VANTAGENS?”, Engrenar Jr., April, 16th, 2021,
MM01 – “Curso Gestão Ágil 2.0”, Mind Master, 2022.
MSF01 – “MSF Team Model v. 3.1”, Microsoft, June 2002.
Mv01 – MASSARI, Vitor L., “Gerenciamento Ágil de Projetos”, 2nd edition – Kindle edition, Brasport, Rio de Janeiro, RJ, Brasil, 2018.
Pj01 – PATTON, Jeff, “User Story Mapping”, O_Reilly, 2014.
Pm01 – POPPENDIECK, Mary, “Principles of Lean Thinking”, Poppendieck.LLC, 2002.
PMI01 – “A guide to the project management body of knowledge (PMBOK guide)”, 6th Edition, Project Management Institute, 2017.
Pmo01 – PRABHAKAR, More, “THE LEGACY OF LOGICAL EMPIRICISM”, IJARIIE, Vol. 3, Issue 6, 2017.
PP01 – POPPENDIECK, Mary & POPPENDIECK, Tom, “Leading Lean Software Development: Results are Not the Point”, 1st Edition, Addison Wesley, USA, 2010.
SJ01 – SHWABER, Ken & SUTHERLAND, Jeff, “The Scrum Guide”, Scrum.Org, 2020, USA.
Sm01 – SIDIROPOULOS, Michael, “Rise of Empiricism”, ResearchGate, 2021.
Tn01 – TALEB, Nassim Nicholas, “Antifragile: things that gain from disorder”, Random House, USA, 2012.
TP01 – “Six Sigma process Improvement approach”, Tutorials Point, USA, 2015.
VY01 – VACANTI, Daniel & YERET, Yuval, “The Scrum Guide for Scrum Teams”, Scrum.Org, 2021, USA.
WJR01 – WOMACK, James P., JONES, Daniel T., and ROOS, Daniel, “The Machine That Changed the World: The Story Of Lean Production”, Rawson and Associates, USA, 1990.