Étiquette : Energy Sector

Catégories
Digitalization Energy Sector Project management

How root cause analysis can help your solution implementation

root cause analysis

Root Cause Analysis, Project Management, Energy, Transition

Written by  

Root Cause Analysis, Project Management, Energy, Transition

How root cause analysis can help your solution implementation

What is Root Cause Analysis?

Root cause analysis (RCA) is a problem-solving technique used to identify the underlying potential causes of

an issue or problem. The purpose of RCA is to determine why a problem occurred in the first place, rather than simply addressing its symptoms. The objective is to find long term solutions.

Why is it key?

If a problem has occurred once, it can occur again. If the root cause is identified and addressed, the problem is unlikely to happen again. Root cause analysis can prevent future problems, minimize the severity of the issues and can be seen as a tool or habit to continuously improve.

Root Cause Analysis, Project Management, Energy, Transition

How to apply it?

The RCA process typically involves the following steps:

A. Identify and describe the problem or issue.

B. Gather data and evidence about the problem.

C. Analyze data to determine root and approximate causes

  • Decompose the problem into basic events and conditions, describing what happened. Asking “WHY” helps to dig toward the root cause and its conditions. However, to use when the team environment is positive and supportive; alternatively, the communication may tend to be unilateral, instead of a collaborative and useful exercise.
  • Create a time line and workflow, summarizing events and steps as a causal factor tree
  • Check logic and facts while eliminating items that are not causes nor contributing factors.    

D. Develop and implement solutions to address the root causes of the problem.

E. Monitor the effectiveness of the solutions.

Some questions to ask during the analysis phases

  • Clarifying origins of the problems.

What happened?

What caused it?

Where and when was the cause?

Where and when was its effect?

What was the magnitude of effect?

  • Defining the cause and its effect, challenge the assumptions and look for evidence and alternative perspectives:

What are all the potential causes we can think of?

How do we know this is a cause?

What else could have caused this issue?

What can we do to prove or disprove our assumptions?

  • Get some others’ perspectives.
  • Examine consequences and implications.

What are the consequences of the causes?

What are their severities?

What are the factors of the severity of the effect?

  • Go to solutions and focus on the way forward

How can we solve problems?

How can we prevent the effect happened again or to be more severe?

What can we do differently now that we know the root cause?

How will this help us in the future?

Why it can be difficult to apply?

  • A systematic approach is not used – Consider applying the workflow from data collection to solution monitoring.
  • Not enough time is dedicated for data gathering, analysis or retrospective – Think of the long term benefit to apply this analysis.
  • The problem is not clearly defined – Dedicate enough time to the 1st step of identifying and articulating the issue to resolve.
  • Skills, knowledge, or experience to understand the root cause are not available. This is required at all steps of the workflow to identify the problem, to collect data and facts, to perform the analysis, to provide solutions and to monitor new outcomes.  
  • Solutions are based on guesses or assumptions – Before implementing solutions, make sure to focus on facts.
  • Solutions are not permanent, nor monitored – Focus on solution implementation for long term with monitoring aspect to test and evaluate effectiveness of the solutions.

How to make successful analysis?

  • Use and practice standardized approach regularly.
  • Adopt fact-based decision making: Eliminate opinions or guesses.
  • Build a mind map or a diagram to show relationships, causes, effects, conditions view and timeline.
  • Test to confirm if the root cause has been found.
  • Implement permanent corrective solutions.
  • Monitor regularly if the solution is practical, feasible, and cost-effective, robust and sustainable.

RCA and Digital Solution Development

RCA is an important tool for identifying the underlying causes of problems and issues that can arise during

a digital solutions development project. By understanding the root causes of problems, teams can develop more effective solutions that address the underlying issues. RCA can be used at various stages of a project of development for digital solutions, including during planning, development, and testing phases. For example, if a team encounters issues with delays in development, poor quality output, or lack of stakeholder engagement, RCA can help identify the root causes of these issues. The analysis is done in collaboration with all stakeholders, and gathering data from multiple sources, reviewing key performance indicators, getting feedback from stakeholders, conducting interviews with team members and users.

Once the root causes have been identified, teams can design, develop and test effective solutions that address the issues. This may involve changes to project planning or development processes, additional training for team members, or adjustments to project requirements or timelines.

By applying RCA to project management for digital solutions development, teams can improve their ability to deliver successful projects that meet stakeholder expectations, and ensure that any problems or issues that arise are identified and effectively resolved. Teams move from acting in a reactive mode into a proactive mode with the benefit on solutions quality and users’ appreciation.

References

Introduction to Root Cause Analysis https://aaq.auburn.edu/node/9990/take

Mental Models https://fs.blog/proximate-vs-root-causes/

Photo from Unsplash Milad Fakurian

Contact

Would you like to contact me, don’t hesitate to do so at the following email address:

GMichaud@GM-Consult.it

Catégories
Digitalization Energy Sector Project management

How to apply “first things first” when developing and delivering digital solutions

gm consulting 80 20 pareto first things first
GM Consulting 80-20 Pareto First Things First

First Things First, Pareto Principle, Project Management, Energy, Transition

Writen by  

First Things First, Pareto Principle, Project Management, Energy, Transition

How to apply “first things first” when developing and delivering digital solutions

Pareto Principle – 80/20 Rule

The 80/20 rule, also known as the Pareto principle, indicates that about 80% of the consequences come from 20% of causes. The Pareto principle is a great model to keep in mind when prioritizing tasks and developing strategic plans. In the case of software or digital solution development, here are some examples of difficult scenarios that teams can face:

+ 80% of the development effort covers only 20% of the requirements needed by the business, leading to

delayed delivery and tension between users and development teams.

+ 80% of test cases cover only 20% of the features to test, leading to incomplete validation and inferior

quality of new features.

+ the majority of users use only 20% of the validated features upon roll out.

To maintain the pessimist point of view, these negative situations are not mutually exclusive. So, the key question to consider: how do we help teams to be more strategic in cases where the minimum development effort would cover the majority of the requirements, in alignment with business needs?

Requirement prioritization as a regular practice for the entire team

One way to put “first things first” is to focus on requirements, including requirement gathering, understanding, validation and their prioritization. Teams can’t design, develop and test all required features at

once. Requirements need to be gathered, documented and understood. In addition, they need to be prioritized regularly. This prioritization should be a fundamental and regular exercise where all stakeholders contribute in close cooperation. Customers/users and the wider development team (i.e., designers, developers, testers) collectively determine the potential value of a requirement, the cost to implement, and at what level of risk.

Users and development teams need to exchange information on requirement importance and cost/complexity in development and validation. It is difficult to adequately prioritize when evaluating only the business considerations, or only the development considerations. Furthermore, sometimes reevaluation needs to take place concurrently, based on the trade-offs between development cost estimates and business inputs. Users can and should be able to reevaluate feature importance, based on cost estimates and on the technical impact on the future architecture of the solution, if the feature or component is not implemented early in the project. Finally, users’ input during feature validation should be considered regularly. So, how do we do this?

First Things First, Pareto Principle, Project Management, Energy, Transition

Requirement prioritization considering the business case, the development costs and the risk

Alignment between business considerations and overall solution design and evolution is essential to optimum development and needs to be completed on a regular basis, as suggested by Wieger (1999). Such a review should consider the potential value of the developments to the business, alongside the costs incurred and risk assumed in development. The merit in this method is that it considers all requirements together, from both business and technical points of view. It enables teams to identify the features and components to prioritize, based on relevance to business and feasibility in development. This prioritization of requirements needs to include all available requirements, all relative development costs and all risks, according to the following priority level:

Note that business relevance could be estimated considering the relative benefit and relative penalty.

Limitations and challenges

Of course, this analysis may be tedious if the backlog includes hundreds of requirements. Some tough decisions may be needed to reduce the scope of requirements and to stagger the delivery plan into phases as a function of business needs and development capacity. Additionally, it can be difficult to understand how intermediate versions of a solution can and should be used in the interim, until delivery of the complete solution. However, the decision should consider the resource capacity alongside user expectations, to maintain the development team’s focus; delivering relevant solutions on time, within budget and meeting business expectations.

To tackle a complex system, a breakdown by element or component is required. The team’s focus is to develop according to priority. However, some resources should still be dedicated to clarifying and reviewing the integration of all components. In doing so, all stakeholders get a clear understanding of the complete solution under development. Dedicated communication and clarification of information should be encouraged throughout the process to ensure that any perceived complexity is acknowledged and teams are aligned on the overall development vision.

Teams should also review existing third-party components or available libraries which could remove the need for further development by building upon existing components. This approach requires a level of flexibility and certain capabilities within the team, such that the study and analysis of components

outside a given organization is possible. This role is rare, but so useful.

Using development satisfaction level to monitor progress and alignment

For any solution, it is fundamental to monitor user satisfaction level by ensuring feedback from the user validation phase is incorporated into lessons learnt and/or new requirements. Of course, any new requirement should be considered in conjunction with the existing requirements and/or those already added to the wish list. Without this information loop, the global development team risks working based on assumptions rather than gathered data, and drifting away from agreed business targets and user preferences. In this case, development satisfaction can be based on business relevance (common to the priority level), user satisfaction, or the actual cost of the development and validation phases:

In order to build in a considered and continuous manner that remains pertinent to the business, regular deployment is key. This enables teams to learn alongside users, take decisions based on priority and satisfaction level, and closely monitor relevance and progress during the entire development cycle.

Cooperation between teams is essential to continuous and regular delivery of solutions which address business objectives. Utilizing the feedback loop method when considering added requirements, where regular reviews and reprioritization is core practice, enables development and user teams to continually learn,

evolve and adapt solutions.

Would you like to contact me, don’t hesitate to do so at the following email address:

GMichaud@GM-Consult.it

Acknowledgements:

Wiegers, K., 1999, First Things First, https://www.processimpact.com/articles/prioritizing.pdf

Photo from Austin Distel – Unsplash

Catégories
Digitalization Energy Sector Project management

Using the feedback loop approach within the cause-and-effect model in the context of digital solution development

feedback loop

Feedback Loop, Cause and Effect, Project Management, Energy, Transition

Writen by  

Feedback Loop, Cause and Effect, Project Management, Energy, Transition

Exploring new opportunities with our team can lead to better and more innovative solutions for our users

The cause-and-effect model is based on the notion that every input or “cause” creates an output or “effect”. This model is fundamental and represents two elements:

  1. the first, on the cause side, relates to our responsibility for our actions. For each action taken, we should consider its effect and consequence;
  2. the second, on the effect side, relates to freedom of choice and actions. For each unsatisfactory outcome or situation, if we identify the cause, we can adjust the condition in order to create a new or better outcome.

Accordingly, responsibility for our actions and freedom of choice and actions are fundamental aspects of the cause-and-effect model. Good! But how can we effectively adopt and implement this model in our projects?

The feedback loop: a practical tool to support the cause-and-effect model

The feedback loop, which is based on a ‘listening, trying, understanding and adjusting’ approach, is particularly effective in adapting the cause-and-effect model into continuous improvement. It is also a practical way to explore root causes for breakages, underperforming features, and to iterate to fine-tune or optimize situations. The process allows teams to try, fail, learn, and then try again in a different manner. By connecting the output of an action with its input, teams can drive a culture of continuous learning and improvement.

Feedback Loop, Cause and Effect, Project Management, Energy, Transition

What’s the feedback loop in the context of digital solution development?

When applied to project management in general, employing a feedback loop approach allows teams to monitor the progress of a project and to refine plans, adjust timing, costs, or quality-level estimates in response to given indicators. In the case of digital solution development and delivery, the feedback loop is implemented at multiple levels: including how requirements are captured and understood, the roll out and validation of the design phase, the development and implementation of internal testing, and finally user validation. Multiple teams play a role in this process, including users, designers, developers, and testing and validation teams.

Feedback Loop, Cause and Effect, Project Management, Energy, Transition

The pitfalls in digital solution development when teams don’t employ a feedback loop

Digital solution development requires the inputs of multiple teams, functionalities, codes, and technologies to realize the end-product. By its very nature, it presents multiple occasions for things to go wrong or perform sub-optimally. Here are just some examples where the use or not of a feedback loop is concerned:

  1. No feedback loop within at least one phase of the solution development. Without a feedback loop there’s no iteration during the understand and requirement-gathering phase, the design phase, product development, testing or validation. Product teams who base their decisions on internal understanding of requirements without considering the end users risk a final solution that does not respond to the needs and expectations of this group.
  2. Disconnect between user validation and user requirement. Consumer teams responsible for validation of the solution are not always those who defined the initial requirements. Product development can be a long process and changes to team structure where stakeholders move in and out during the development phase often happen and can threaten the overall efficiency of development and validation.
  3. Solution requirement definition does not include criteria for product validation. The team has defined the ‘what’ of the solution, but not how to test and validate that product. Requirement gathering is lengthy and difficult, requiring knowledge and domain-specific understanding. However, it is also key to complete requirement phase with specifications on the validation side. Without any specification, testing teams won’t have a clear framework against which to evaluate the final solution.
  4. Lack of connection between teams through the entire solution development cycle. Teams can be dispersed in various places around the globe, with different work hours and culture, and competing objectives which can distract focus from the common objective. This situation occurs when communication between team leaders is irregular or opaque, and when individual team interests are put ahead of global cooperation and broader objectives.

Solutions to consider to foster a productive feedback loop

  1. Each Team Lead takes ownership of monitoring internal work and reporting coherent updates of their team’s activity in order to foster internal feedback and take appropriate actions.
  2. Global teams take responsibility for closing the gap between requirement definition and solution validation phases. When the project is drawn out and/or key stakeholders are replaced, iterating around requirement definition and validation criteria is highly recommended.
  3. Empower technical and domain experts and key stakeholders to participate in refinement of requirements with an eye on the defined validation criteria. As the solution is developed, it is essential to check, refine, and adjust the requirements and validation criteria to ensure ongoing development and validation remains in alignment with users’ needs, and accounts for evolutions of needs and expectations over time.
  4. Empower team leads to exchange feedback aligned with the common objective while respecting the differing needs and cultures of the various teams involved in the digital solution development. Sharing feedback fosters a cooperative spirit in the pursuit of a common goal, and ensuring learning, progress and growth within the global team will enable better collaboration. Regular touchpoints which center around the global objectives will ensure effective communication, understanding of respective interests and challenges, leading to improved performance.

As leaders, we need to establish and maintain the feedback loop to monitor and resolve misunderstandings, to iterate around users’ evolving needs, and to communicate team effort and progress. More specifically, our role is to assemble the technical and domain experts needed to realize the software solution, and leverage their knowledge such that the global team can take relevant decisions aligned with users’ needs and technical development capabilities. Above all, leaders should foster the collaborative spirit that makes the various development phases a worthwhile journey for all team members, building team pride which delivers better, more valuable solutions for end users.

Relevant opportunities for the feedback loop approach during digital development projects

Continuous improvement via the feedback loop approach is a valuable tool in your arsenal, both as a leader and for your team. Many processes are amenable to the deployment of a feedback loop approach:

  1. Sharing the same backlog view with key performance indicators that capture data and enable teams to act on lessons learnt,
  2. Regular requirement-gathering phases, either for definition or refinement, validation criteria definition or refinement, with lived and reviewed documentation for requirements and validation criteria,
  3. Internal meetings such as planning discussions, daily standups, retrospectives and debrief sessions, and progress updates,
  4. Global meetings with sprint planning, refinement sessions and demos with requirement iteration, development updates, validation phases and lessons learnt,
  5. The feedback loop should focus on spreading and amplifying technical and domain expert input, in order to provide the best solutions for our users.

Would you need more info on the application of feedback loop for your projects, please contact me at GMichaud@GM-Consult.it.