Chapter 7: Project Management for a Machine Learning Project
Peter Dabrowski Wintershall Dea, Hamburg, Germany
Abstract
We will briefly revisit classical project management approaches in the oil and gas sector before giving a brief introduction of agile and scrum. It will be made clear how these approaches differ and why scrum might be the better choice when applied to machine learning and data science projects.The scrum framework with its most relevant components will be explained briefly using a real world example, while stressing the importance of management and change culture while executing these machine learning projects. At last, we will show what is important when scaling your ideas from simple pilot to a product that will be adopted in your entire organization.
Keywords
machine learning
project management
oil and gas industry
scrum
agile
change management
digitalization
Now that we have a better understanding of machine learning in the context of oil and gas, we can explore how to best execute these types of projects. A valid question to ask at this point might be: Is the management of projects with a machine learning component so different that it warrants its own in-depth discussion? The simple answer is “yes,” due to the complex and unique nature of machine learning projects, especially when applied to the oil and gas industry.
To further answer this question, it is helpful to view machine learning in the context of digitalization. Regardless of chosen technology, cloud computing, smart sensors, augmented reality, or big data analytics, the driver behind digitalization will in many cases be a change in the business model to allow for higher efficiencies and new value adding opportunities. This is not to say the exploration and production (E&P) business has not been innovative in the past. The introduction of horizontal drilling, multilateral wells, deep water drilling and other new technologies pushed the envelope of what is technically feasible in E&P.
Now, with the application of digitalization, we are leaving the arena of our core business. As we work to marry the traditional rough-neck technologies with digitalization, what is home turf to Amazon, Google, and Microsoft, we might as well learn from their experiences.
You will notice that this digitalization approach is somewhat different. Buzzwords, such as Scrum and Agile, will be demystified and translated into our business processes. In the end, you will find that these new processes are yet another set of tools in your toolbox.
7.1. Classical project management in oil & gas-a (short) primer
Projects in the oil and gas industry are some of the most complex and capital intensive in the world. Major projects, like installation of an offshore production rig, can cost upwards of US$ 500 million and make up a significant percentage of a company’s expenditures and risk exposure. Therefore, focusing on how to best manage processes, dependencies and uncertainties is imperative.
Traditionally, large projects in engineering design are run sequentially. This sequential approach is phased with milestones and clear deliverables, which are required before the next stage begins. These stages can vary, depending on needs and specifications, but typically all variations contain at least these five basic blocks (Fig. 7.1):
Figure 7.1 Example workflow of the Waterfall method.
With the workflow cascading toward completion, this approach is often referred to as the Waterfall method. This terminology was applied retroactively with the realization that projects could be run differently (e.g., Agile).
The Waterfall method is one of the oldest management approaches. It is used across many different industries and has clear advantages, including:
- • Clear structure-With a simple framework, the focus is on a limited number of well-defined steps. The basic structure makes it easy to manage, allowing for regular reviews with specific deliverable checks at each phase.
- • Focus-The team’s attention is usually on one phase of the project at a time. It remains there until the phase is complete.
- • Early well-defined end goal-Determining the desired result early in the process is a typical Waterfall feature. Even though the entire process is divided into smaller steps, the focus on the end goal remains the highest priority. With this focus comes the effort to eliminate all risk that deviates from this goal.
Although the Waterfall method is one of the most widely used and respected methodologies, it has come under some criticism as of late. Depending on the size, type, complexity, and amount of uncertainties in your project, it might not be the right fit. Disadvantages of the Waterfall method include:
- • Difficult change management-The structure that gives it clarity and simplicity also leads to rigidity. As the scope is defined at the very beginning of the process under very rigorous assumptions, unexpected modifications will not be easy to implement and often come with expensive cost implications.
- • Excludes client or end user feedback-Waterfall is a methodology that focuses on optimization of internal processes. If your project is in an industry that heavily relies on customer feedback, this methodology will not be a good fit, as it does not provision these kinds of feedback loops.
- • Late testing-Verification and testing of the product comes toward the end of a project in the Waterfall framework. This can be risky for projects and have implications on requirements, design, or implementation. Toward a project’s end, large modifications and revisions would often result in cost and schedule overruns.
Given its pros and cons and its overall rigid framework, the Waterfall method seems an undesirable management approach for machine learning projects. However, with so many management approaches from which to choose (e.g., Lean, Agile, Kanban, Scrum, Six Sigma, PRINCE2, etc.), how do we know which is best for machine learning projects?
One way to begin to answer this question is to categorize projects based on their complexity. Ralph Douglas Stacey developed the Stacey Matrix to visualize the factors that contribute to a project’s complexity in order to select the most suitable approach based on project characteristics (Fig. 7.2).
Figure 7.2 Stacey Matrix with zones of complexity.
On the y-axis, it measures how close or far members of your team are from agreement on the requirements and objectives of the project. Your team members might have different views on the goals of the project and the needed management style to get there. Your company’s governance will influence the level of agreement as well.
Your project’s level of certainty depends on the team’s understanding of the cause and effect relationships of the underlying technology. A project is close-to-certain if you can draw on plenty of experience, and you have gone through the planned processes multiple times. Uncertain projects are typically challenged by delivering something that is new and innovative. Under these circumstances experience, will be of little help.
Based on these dimensions, we can identify five different areas:
- 1. Close to agreement/close to certainty-In this zone, we gain information from the past. Based on experience, it is easy to make predictions and outline detailed plans and schedules. Progress is measured and controlled using these detailed plans. Typically, we manage these types of projects using the Waterfall approach.
- 2. Far from agreement/close to certainty-These projects usually have high certainty around what type of objectives and requirements can be delivered, but less agreement about which objectives are of greatest value. In situations where various stakeholders have different views on added value, the project manager typically has difficulties developing a business case because of the underlying conflicts of interest. Under these circumstances, negotiation skills are particularly important and decision-making is often more political than technical. In these instances, the favored management approach is Waterfall or Agile.
- 3. Close to agreement/far from certainty-Projects with near consensus on the desired goals, but high uncertainty around the underlying technologies to achieve those goals fall into this category. The cause and effect linkages are unclear, and assumptions are often being made about the best way forward. The driver is a shared vision by stakeholders that everyone heads toward without specific, agreed upon plans. Typically, Agile is the approach chosen for these types of projects.
- 4. The zone of complexity-The low level of agreement and certainty make projects in this zone complex management problems. Traditional management approaches will have difficulties adapting, as they often trigger poor decision-making unless there is sufficient room for high levels of creativity, innovation, and freedom from past constraints to create new solutions. With adaptability and agility being the key, Scrum and Agile are useful approaches here.
- 5. Far from agreement/far from certainty-With little certainty and little agreement, we find the area of chaos. The boundary to the complex zone is often referred to as the “Edge of Chaos.” Traditional methods of planning, visioning, and negotiating often do not work in this area and result in avoidance. Strategies applied to address these situations are called Kanban or Design Thinking.
Simplifying these different projects down to the degree of available knowledge and characteristics and the responsibilities of a leader highlights the inherent differences.
In Table 7.1, we see how important it is to choose the right process for each project. Although these categories are highly dependent on environment and the team’s capabilities (a project that is complicated for an expert can be complex for a beginner), most oil and gas projects are typically categorized as complicated. They are characterized by best practices and focus on efficiency. Execution works fantastically well with top-down management and clean lines of authority for command and control. In these circumstances, the Waterfall method is the best management option.
Table 7.1
| Environment | Characteristics | Leader's job |
|---|---|---|
Chaotic (little is known) | High turbulence No clear cause-effect True ambiguity | Action to re-establish order Prioritize and select work Work pragmatically rather than to perfection, act, sense, respond |
Complex (more is unknown than known) | Emerging patterns Cause-effect clear in hindsight Many competing ideas | Create bounded environment for action Increase level of communication Servant leadership Generate ideas, probe, sense, respond |
Complicated (more is known than unknown) | Experts domain Discoverable cause-effect Processes, standards, manuals | Utilize experts for insights Use metrics to gain control Sense, analyze, respond |
Simple (everything is known) | Repeating patterns Clear cause-effect Processes, standards, manuals | Use best practices Establish patterns and optimize Command and control, sense, categorize, respond |
What about machine learning projects? Application of machine learning and artificial intelligence to modern day problems is an innovative process. When compared with other industries, machine learning in the oil and gas industry has only recently found its application. Only governments lag farther behind oil and gas even further when comparing industry adoption of digitalization technologies [Source: World Economic Forum].
Machine learning is most effective when applied to complex problems. As outlined earlier, these are projects with many variables and emerging, interdependent interactions. With the interplay between these variables and dependencies being too complicated to predict, upfront planning is useless
As previously stated, Scrum is the most often used management approach to tackle complex projects. Soon, we will dive into the details of applying Scrum to projects, but before doing so, let us highlight the pitfall for managers, if this premise is not well understood.
The danger comes in the form of established processes and habits. As mentioned, the majority of E&P projects are being managed through the Waterfall method. However, a leader tasked with managing a complex machine learning project and using only familiar tools from simple or complicated projects is a recipe for conflict, failure, and misunderstanding.
From Table 7.2, we can see how the characteristics of a complex project, with uncertainty in the process and creative approaches, entails too many competing ideas that rely on the respective skills and competencies of the leader.
Table 7.2
|
Source: Adapted from Scrum.org/PSM.
For a complex project, a good approach is to rely less on experienced professionals in the specific technical field, but rather, collect various theories and ideas and observe the effect of choices by using an Agile approach. (You can, of course, heavily rely on team members with experience with Agile projects). The project team must identify, understand, and mitigate risk as new results emerge. This often happens at a rapid pace, requiring a good leader to be an integral team player by enabling the rest of the team and driving cooperation and open communication. This type of leadership is referred to as “servant leadership.” In order to arrive at productive solutions for complex projects, teams must approach a problem holistically through probing, sensing and responding, as opposed to trying to control the situation by insisting on a plan of action (Fig. 7.1).
The potential mismatch between organizational requirements of a successfully managed, complex project and what a typical Waterfall environment provides as outlined in Fig. 7.2 is why we need a different project management approach to machine learning projects. In the next section, we explore the specifics of Agile and Scrum and learn how these approaches are best applied to the world of oil and gas.
7.2. Agile-the mindset
Agile, Sprint, Scrum, Product Owner, and Retrospective-welcome to the world of digitalization buzzwords. A world that from the perspective of traditional project management might come across as disorganized-a passing fad, not to be taken seriously. However, by the end of this chapter, you will be able to put meaning to the buzz and understand where and how this approach is best applied.
The term Scrum was introduced 1986 by two Japanese business scholars. They published the article “New New Product Development Game” (that is not a typo) in the Harvard Business Review, describing a new approach to commercial product development that would increase speed and flexibility. Scrum has its roots in manufacturing (e.g., Japanese automotive, photocopier, and printer industries) and made its way into the software development industry to establish a new process, as an alternative to the dominant Waterfall method.
In 1995, Jeff Sutherland and Ken Schwaber, two US American software developers, formalized the method in a paper they presented at the OOPSLA conference in Austin, Texas. Their collaboration resulted in the creation of the Scrum Alliance in 2002-a group of pioneers in Agile-thinking who came together to evaluate similarities in Agile methods. The result of the group’s work was the Agile Manifesto, outlining the 12 principles of Agile software development.
In 2009, Ken Schwaber left the Alliance and became the founder of Scrum.org, which oversees the Professional Scrum Certification and publishes an open-source document called The Scrum Guide. The Scrum Guide is today’s standard reference guide for Scrum project management.
So, what exactly is Agile and Scrum then? Agile is a general term that describes approaches to product development, focusing on incremental delivery and team collaboration with continual planning and learning. It is a set of principles and values with people, collaboration and interaction at its core and it can also be applied in other fields, such as organizations and training. While Agile provides the mindset, it is Scrum that outlines the concrete framework. It is one of various frameworks under the Agile umbrella, and the one that we will concentrate on for the purpose of managing machine learning projects.
7.3. Scrum-the framework
If you are a fan of the sport of rugby, you certainly have heard of the term Scrum before. This word choice is no coincidence. In rugby, a Scrum (short for scrummage) refers to restarting a play and involves players being densely packed with their heads down, attempting to gain possession of the ball and progress down the field.
The terminology is purposefully chosen by Takeuchi and Nonaka (1986), who already in their original paper pointed towards the analogy: “The traditional sequential or ‘relay race’ approach to product development [...] may conflict with the goals of maximum speed and flexibility. Instead, a holistic or ‘rugby’ approach - where a team tries to go the distance as a unit, passing the ball back and forth - may better serve today’s competitive requirements” (Fig. 7.3).
Figure 7.3 A Scrum during a rugby match (© Luis Escobedo).
Also, Schwaber recognized the similarities between the sport and the management process. The context is the playing field (project environment) and the primary cycle is to move the ball forward (sprint) according to agreed rugby rules (project controls). Further, the game does not end until the environment dictates it (business need, competition, functionality, or timetable). Interestingly, he also acknowledged that rugby evolved from breaking traditional soccer rules, alluding to how Agile is new relative to traditional Waterfall framework.
Fast-forwarding to the present and using The Scrum Guide as reference, we note the following definition: “Scum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
Scrum is a lightweight framework for enabling business agility. Rather than being a process or technique for building products, it provides the framework within which you can employ various processes and techniques. This framework is based on empirical process control theory, acknowledging that the problem cannot be fully defined or understood up-front. Instead, it focuses on the team’s ability to quickly deliver value.
Scrum is best understood by investigating its elements. In the following section we will look at the 3-3-3-5-5 framework, which describes the following:
|
• 3 pillars of Scrum theory | what is Scrum based on? |
|
• 3 roles | who is involved with which responsibilities? |
|
• 3 Artifacts | what is being delivered? |
|
• 5 Events | what happens when? |
|
• 5 values of Scrum | which beliefs motivate actions? |
Let us start with the foundation. Scrum is based on three pillars of process control in which certain assumptions are met:
- 1. Transparency-Important aspects of the process are visible to the entire team, and there is a common understanding of language, including the definition of “done.” Everyone knows everything.
- 2. Inspection-Progress and deliverables (artifacts) are often inspected toward their goal to detect undesirable variances. Check your work as you do it.
- 3. Adaptation-If inspection shows that aspects of the process deviate outside acceptable limits resulting in an unacceptable product, the process must be adjusted as soon as possible to minimize further deviation. It is OK to change tactical direction (Fig. 7.4).
Figure 7.4 Three pillars of Scrum.
Inspection and adaptation are applied systematically throughout the process, as will be evident as we dissect all elements of the scrum framework.
7.3.1. Roles of scrum
There are three, and only three, roles within the Scrum team: the product owner, the development team, and the Scrum master. Ideally, they should be co-located to foster communication and transparency.
The product owner represents the product’s stakeholder and voice of the customer. He is responsible to optimize towards adding most value to the product and manages the product backlog. He does not have the responsibilities of a typical manager (i.e., he is not managing a team or a project).
The development team typically has three to nine members and focuses on delivering increments of added value to a product during a specific amount of time (a sprint). Although members of the team are often referred to as developers, they can often be from various cross-functional backgrounds, such as designer, architect, or analyst.
Most importantly though, especially relative to setups in E&P, is the fact that the team is self-organized. This means that while all work comes through the product owner, all responsibility to deliver its work falls solely on the team itself-no one tells the development team how to do their work. The product owner and the Scrum master are not part of the development team.
The Scrum master facilitates the Scrum methodology. He promotes Scrum by making sure everyone understands its practices, rules, and values. By removing possible impediments to the ability of the team to deliver the product goals, the Scrum master acts as the servant-leader of the Scrum team. Table 7.3 summarizes the Scrum master’s most important services toward stakeholders.
Table 7.3
| Stakeholder | Services of scrum master |
|---|---|
| Product Owner |
• Ensures goals, scope and product domain are understood by everyone • Helps arranging and prioritizing the product backlog |
| Development Team |
• Removes impediments • Coaches team in self-organization • Facilitates scrum events |
| Organization |
• Help employees and stakeholder understand and enact scrum |
The Scrum master’s role differs from that of a project manager because the Scrum master does not have any people management responsibilities. Since the responsibility of managing the development team lies within the team itself, the Scrum master’s involvement in the direction setting process is limited. In fact, Scrum does not recognize the role of a project manager.
7.3.2. Events
Scrum has a set of well-defined events to minimize the need for other unnecessary meetings. All events are time-boxed, that is, they have a specified maximum duration. As you will see, all these events (except the sprint itself) provide opportunities to inspect and adapt the ongoing process of development and add to transparency (Fig. 7.5).
Figure 7.5 Development cycles are done in sprints.
In Scrum, everything revolves around the sprint. It is typically between two to four weeks long (never more) with the goal to produce an increment of useable, potentially shippable product by the end. At the beginning of each sprint (during the sprint planning) the team agrees on the scope and defines the goals of the sprint by moving items from the product backlog into the sprint backlog. During the sprint, no changes are made that endanger the sprint goal, although the scope may be clarified and re-negotiated between the product owner and the development team as new insights arise.
Every sprint ends with the sprint review and sprint retrospective. As soon as one sprint ends, the next begins immediately (Fig. 7.6).
Figure 7.6 Scrum framework.
The sprint planning meeting marks the beginning of a sprint. A sprint planning, capped at 8 hours, focuses on answering two main questions: (1) Which product increment can be delivered in this upcoming sprint (sprint goal)? and (2) How can this chosen work be done?
In practice, the first half of the meeting involves the entire Scrum team (Scrum master, product owner and development team) suggesting product backlog items practical for the upcoming sprint. Ultimately, the development team selects the specific items for the sprint, as they are best equipped to judge what is achievable.
In the second half of the meeting, the development team breaks down the chosen product backlog items into concrete work tasks, resulting in the sprint backlog. To refine the sprint backlog, the development team might negotiate the selected items with the product owner to agree on the highest priority tasks. In the end, the development team explains to the Scrum master and the product owner how it intends to complete the work.
The daily Scrum is a meeting that is held every day of the Sprint and is time-boxed to 15 minutes. Everyone is welcome, but it is the development team members that contribute. It should always happen at the same time and location and start promptly, even if some team members are not present. The goal of the meeting is for the whole team to answer three questions:
- 1. What did I do yesterday that contributed to the team reaching the sprint goal?
- 2. What will I do today that will contribute to the team reaching the sprint goal?
- 3. Do I see any impediment that could prevent me or the team from reaching the sprint goal?
It is the Scrum master’s responsibility to keep the development team focused and to note potential any impediments. The daily Scrum is not to be used for detailed discussions, problem solving or general status updates. Once the meeting is over, individual members can meet to resolve any open issues in breakout sessions.
The sprint review and the sprint retrospective are held at the end of each sprint. They provide the opportunity to assess progress towards the goal and the team and collaboration, respectively. For the purpose of reviewing the sprint progress, the team does the following:
- 1. Reviews and presents the completed work (e.g., in the form of a demo),
- 2. Address which items were not “done” (completed),
- 3. Collaborates on what to work on next, and
- 4. Reviews of timeline, budget, and required capabilities.
Output from the meeting is a revised product backlog and dialog to inform the next sprint planning.
The sprint retrospective is an opportunity for the team to reflect and improve. Three questions facilitate this process, including:
- 1. What went well in the last sprint with regards to people, relationships, processes, and tools?
- 2. What did not go so well?
- 3. What can be improved to ensure better productivity and collaboration in the next sprint?
The entire team participates in the sprint review and sprint retrospective, which for four-week sprints, are time-boxed to two hours and 90 minutes, respectively (and scales proportionally for shorter sprints). For both meetings, the Scrum master is responsible for ensuring all participants to stick to the rules and time limits are honored.
Should it become apparent that a sprint goal is obsolete (due to company strategy, market conditions, technology changes, etc.) during the sprint itself, the product owner may cancel the sprint. However, due to the short duration of most sprints, cancellation is rare.
7.3.3. Artifacts
Another component contributing to transparency in Scrum is the artifact. Artifacts provide information on the product, forming a common understanding and allowing for progress on inspection and adaptation. Typical Scrum artifacts include the product backlog, sprint backlog and product increment.
A product backlog is an ordered list of all that is initially known about the product. In addition to foundational knowledge and understandings, it includes a breakdown of work to be done. Business requirements, market conditions or technology can cause modifications to the backlog, making it an ever-evolving artifact. The listed items can be features, bug fixes or other non-functional requirements. The entire team has access to the product backlog, but the product owner is solely responsible for it. Only the product owner can make changes and set priorities for individual items. Typically, the product owner will gather input and feedback and will be lobbied by various stakeholders; however, it is ultimately his decision on what will be built (and not that of a manager in the organization).
The sprint backlog is a set of product backlog items selected for the current sprint. It serves as a forecast of what functionality will be delivered by the end of the sprint and is being modified throughout the sprint to represent progress. Backlog items can be broken up into smaller tasks, which, rather than being assigned, team members will tackle based on priorities and individual skill sets. When the team finalizes the sprint, they analyze and reprioritize the remaining product backlog to have it prepared for the next sprint.
The team’s definition of “done” results in a product increment, which is a list of all product backlog items that were completed during the sprint. When combined and integrated into all previous increments, the product increment embodies a potentially shippable product that is functional and usable. It is up to the product owner to release it or not (Fig. 7.7).
Figure 7.7 All elements of Scrum during a Sprint.
7.3.4. Values
From the earlier figure, one can tell how all the different elements of Scrum enable a feedback-driven, empirical approach. The three pillars of Scrum-transparency, inspection, and adaptation-require trust and openness. To enable this trust and openness, Scrum relies on following five values:
- • Commitment-Individual team members personally commit to achieving the goals of the scrum team.
- • Focus-Team members focus exclusively on the work defined in the sprint backlog; no other tasks should be done.
- • Courage-Team members have the courage to address conflict and problems openly to resolve challenges and do the right thing.
- • Respect-Team members respect each other as individuals who are capable of working with good intent.
- • Openness-Team members and stakeholders are open and transparent about their work and the challenges they need to overcome obstacles.
These values are essential to successfully using the Scrum method.
7.3.5. How it works
By now you have a rough understanding of Scrum. But if we break it down, what does it mean to execute a project in an Agile way, using the Scrum framework? Let us translate the buzzwords into practice.
Short iteration cycles provided by time-boxed sprints afford high transparency and visibility. With this visibility, and the mandate to self-manage, it is quite easy to maintain adaptability to business and customer needs as well as steer your product in the right direction. Early product releases at the end of these short iterations help generate value relatively early in time, reducing risk, and unwanted cost overruns.
Returning to our comparison of the Scrum framework to traditional project management techniques, Fig. 7.8 illustrates how the differences transpire between the two approaches. Predicting all features of a project with large uncertainty is much more challenging at the beginning of the project, often resulting in surprises at project end when the customers are presented with results when deadlines loom. Agile development allows for better adaptability, lower risk early on and earlier creation of business value.
Figure 7.8 Value proposition of Agile development compared to traditional development.
The process of creating a car is one commonly used example to illustrate how Agile is applied in the real world and how it differs from big bang deliveries (i.e., build it until it’s 100% done, and then deliver it).
Let us assume we have a customer who has ordered a car. Delivery of the first iteration of the product is often misunderstood as delivering an unfinished product. In the case of our example, it would mean the delivery of a tire at iteration (1) (Fig. 7.9). Naturally, the customer will not be happy-after all he has ordered a car, not a tire!
Figure 7.9 Building a car-not using proper Agile development.
The customer’s reaction is not going to be much different at iterations (2) and (3), when the product is still a partial car at best. Although the product is getting closer to its final state, it is not until the final iteration (4) that we have a satisfied customer. And in this example, he is happy because it is what he ordered. A lot of time passes before the customer gets to see any of the product, resulting in the product being based on a lot of assumptions and design flaws.
Now, let us contrast this with the Agile approach. Although the customer ordered a car, we start by focusing on the underlying need he wants to see fulfilled. In this case, conversation with your customer might show that “getting from A to B quickly” is the underlying need, and a car is one of many ways to do that. (Keep in mind that the car is just a metaphor for any kind of customized product development.)
After the first sprint, the team would deliver the most minimalistic thing to get feedback from the customer, for example, a skateboard. We could call this an MVP (Minimum Viable Product). Naturally, the customer will likely be unhappy about the result, as it is nowhere near the car, but the goal at this stage is not to make the customer happy, but to get early feedback, learn and make adaptations for product development down the road.
The next iteration could have a different color (or other changes based on early feedback) and a way of steering, to make it safer to drive around with. The third iteration could be a bicycle, which the customer might start using, resulting in even more valuable. Based on this learning, the 4th sprint might be a motorbike as a deliverable. And at this stage, it may be that the customer is much happier with this product than he thought he would be with the car he originally ordered (Fig. 7.10).
Figure 7.10 Building a car-using proper Agile development.
Or, in the final iteration, he sticks to his original idea and gets the car delivered at last, but it’s better tailored to the feedback from previous iterations, perhaps resulting in a convertible rather than a coupe. In the end the customer is overjoyed-he got a car and a better one than he originally envisioned!
With the underlying question being “what is the cheapest and fastest way we can start learning?” it is possible to reduce risk early and provide the customer with business value that meets or exceeds his exact needs.
7.4. Project execution-from pilot to product
With our newfound understanding of Scrum and Agile, we can now identify opportunities to apply this approach within the context of an E&P company. Bringing this approach to a business world defined by Waterfall management will be a challenge that is best tackled with the introduction of pilot projects.
A pilot project, by nature of its test-setup, gets the mandate of experimentation. It is usually run in parallel to day-to-day operational business and focuses on the validation of a technology or process. In our case, this is the application of our machine learning algorithm. Let us use an example to examine a possible pilot setup and see how the different roles and stakeholders would interact. We will end the chapter outlining how you can introduce Scrum as a possible management framework within your company.
7.4.1. Pilot setup
ABC Oil Ltd., a small oil and gas company, is interested in exploring machine learning in the context of a virtual flow meter. Under normal circumstances, ABC Oil conducts well tests to inspect flow rates periodically, at best. In the interim, production engineers rely on extrapolating from previous test results, which leads to uncertainty and inaccuracies in data estimates.
By incorporating machine learning, advanced analytics, and all available production data (e.g., pressures, temperatures, fiscal flow meters, well-test data) ABC Oil sees an opportunity in using virtual flow meters to calculate real-time rates for all wells. This innovation would allow for informed decision-making based on live data.
ABC Oil has identified SmartML Ltd. as a potential partner for developing and testing this virtual flow meter technology. SmartML has experience working with companies in the petroleum industry, but its main expertise lies in the application of artificial intelligence and machine learning. ABC Oil and SmartML agree to cooperate and perform a pilot investigating the effectiveness of applying machine learning to all available production data to create a virtual flow meter.
Both companies are aware of the uncertainties, accept them, and agree to run this project in using the Scrum framework, including filling roles of product owner, Scrum master and development team.
7.4.2. Product owner
A technical representative from ABC Oil Ltd serves as the product owner. As an ABC employee, she possesses the best understanding of the requirements of the product (a virtual flow meter) and thereby, she is responsible for setting priorities for the backlog items and making sure the team understands the product goal.
However, given that this pilot project is occurring concurrently with existing ABC Oil operations, both companies see benefit in identifying a proxy product owner who serves as the go-between for the product owner and the development team. The proxy product owner is part of SmartML and thus, is more available to dedicate time to the project than the product owner, who is also managing ABC Oil’s day-to-day operations. The product owner and the proxy product owner require a relationship based on trust and open communication.
7.4.3. Development team
In the pilot, SmartMl’s developers and designers make up the core of the development team. Generally, the composition of the team depends on the size and capabilities of the E&P company. The larger the oil-company, the more capabilities internal capacity it can provide, while smaller companies may only possess the capacity to supply the product owner.
In the case of ABC Oil, the more inter-dependencies that exist between software solutions and the existing infrastructure, of ABC Oil the more important it is to involve ABC IT and OT engineers and data architects on the development team. Connecting relevant data sources and maintaining cyber security, while simultaneously allowing an external partner access to data, can be challenging and requires prioritization and teamwork.
Depending on the skill set available at ABC Oil, it may or may not involve its own staff during the development phase, but certainly will involve staff in the testing and validation process when the team finishes the first iterations of the solution. To this end, there is a notable benefit to having the team co-located. The larger and more complex the project, the more important co-location becomes in terms of facilitating interactions and improving transparency and clarity-especially at the beginning of a project when trust is being established. Remember, that the team is self-organized, so, neither the product owner, her proxy, nor the Scrum master, act as managers or superiors in this setup.
7.4.4. Scrum master
The Scrum master focuses on facilitation, meaning this role can be filled by ABC Oil, SmartML or an external organization. With ABC Oil providing core business expertise and SmartML providing machine learning respectively expertise, an external Scrum master with Scrum and Agile framework expertise would be a valuable asset to the pilot project.
How development teams conduct meetings is dependent on the degree of co-location. With an external development team, most meetings will be virtual, including the 15-minute daily Scrum meeting. In case of virtual meetings, artifacts such as product backlog, sprint backlog and product increment can be adapted by using virtual collaboration tools.
The length of the sprint review, sprint retrospective and sprint planning correlate with the length of the sprint. With back-to-back scheduling, an in-person meeting, where feasible, is ideal. The kind of communication, interaction, and feedback intended for these meetings are invaluable and will work significantly better in a traditional workshop environment. Typically, these meetings take place every two to four weeks, making in-person meetings achievable, even if team members are not co-located.
7.4.5. Stakeholders
Now, we will shift gears from our ABC Oil Ltd. example to a more general examination of Scrum applied to oil and gas operators. Outside the core team, you will have many stakeholders to collaborate with and the way you manage these stakeholders will be particularly important if your project competes with daily operations.
IT/OT and data management might be your most important collaborators. Machine learning projects are heavily reliant on data and your team needs access to this data. Enabling data availability with consideration of cyber security, compliance, access rights, data exchange protocols and consumption will often be your most time-consuming task. Onboarding and integrating data security staff onto your team will save you future headaches and delays.
Further, getting management buy-in is necessary to execute these projects; however, it makes sense to differentiate between management levels. Generally, top management understands the added value of digitalization projects and provides support, whereas middle management often calls for more massaging. A large part of these machine learning projects comes down to change management, especially when deploying a Scrum approach (where management does not have a designated role). Thus, it is imperative that middle management is aware, involved and has ownership that has been communicated top down.
Further, it is important that your customers are fully aware of their role as customers. In a setting where a project is initiated from corporate headquarters into other operational organizations, the product owner might be someone who is not part of the actual operation’s team. In fact, more often than not, this is the case.
As much as your project will be competing your customers’ daily tasks and duties, their involvement will be required. Customer feedback will be critical to ensure user-friendliness and ultimately, user-acceptance. Your product could be the best from the perspective of the development team, but if your end customer is not using it, the product has failed. Your customer needs to be aware of his role, know how important his feedback is, and recognize that the development team and product owner are ultimately working to satisfy his needs.
7.5. Management of change and culture
New processes require change and change management, which can bring with it resistance. Consequently, your attention to the various stakeholders and your company’s change culture will be crucial.
As previously mentioned, it is common for pilot projects to run in the form of rogue projects, that is, in parallel to your core business activities. This approach has several advantages, including:
- • Setting context to test an assumption-The context of a pilot project gives you more liberties to experiment and test the underlying technology you want to implement to solve a certain problem. It is usually easier to get approval for smaller projects.
- • Implementing quickly, managing risk, and failing fast-A quick test implementation will allow you to better manage risk and minimize cost. In case of failure, you will have failed fast and gracefully, rather than blowing up. Experimenting on a smaller scale educates you about what works and what does not without the level of risk of a larger project.
- • Discovering dependencies-You will learn more about how your project interacts with various stakeholders as well as other devices, technologies, or data sources. Some of these stakeholders might not have been in your original scope. You will also learn more about the accuracy of your planned resource allocation.
- • Fine-tuning the business case-The learnings from the pilot will allow you to better estimate your business case should you want to scale and implement your project on a larger scale after successfully completing the pilot.
- • Getting feedback from the users, your customers-Next to understanding whether the technology itself works, your most important insights will be whether your idea will be accepted by the users.
- • Refining your solution and spur new ideas-Based on the user feedback, you will be able to fine-tune your product, so it matches your customer’s needs. This might result in new ideas and concepts. Further, smaller endeavors allow you to change direction quickly, if needed.
- • Preparing for rollout-Experiential feedback and learning will be the best possible preparation for a later rollout and scaling of your product. A small-scale rollout is the perfect testing ground and makes a later, larger release less risky and stressful.
With pilots like these, you are actively engaging your colleagues as testers. For many, this kind of involvement will be a new experience, resulting in various levels of enthusiasm. Some will embrace this level of engagement and participation in the development of something novel, while others will not. In the context of Scrum, its requirements of inspection and adaptation, such an approach might be viewed as disorganized and chaotic. If you are used to Waterfall project management, shifting to Scrum-like methods may not be so intuitive. You will need to invest significant time into setting the stage by explaining the approach and coaching your colleagues on the importance of their roles.
Since you are not directly contributing to the core business, the pilot could also be perceived as a useless distraction. With potential headwinds like these, it is important to get the right mandate from the start. The more novel the approach, the more important endorsement from higher management levels, such as CTO or CEO, will be. Management can be supportive by not only stressing the relevance to the organization for technical reasons, but also in the context of new ways of working and collaborating, including motivating the team to be brave and giving them the room and permission to fail. A basic understanding among top management of how Scrum and Agile works will give you yet another advantage.
Whatever the outcome of your pilot, you should not be afraid to share the results. With success or failure, there will be stories to tell. Be transparent, open, and honest. Use success stories that highlight your colleagues and customers and have them reflect, not only on the technical aspect, but on the way the team collaborated. Successful pilot projects can generate momentum that can be used to drive and multiply a solution into the organization.
7.6. Scaling-from pilot to product
With the completion of your pilot, hopefully you have a successful MVP. Assuming the product concept has been validated, you now have a better understanding of the technology and the risks and cost involved. Based on the positive feedback from your colleagues who serve as customers, you know you have a great product. With the product being operationally ready, it is now time to scale.
A great idea and productive pilot are only half of a successful product. Even more important is making sure you can scale your solution. Up until this point, the pilot has been a local, validation experiment-it is only after you scaled the solution to more assets that you can multiply and reap the full potential and benefits of the business case for the entire organization. Let us have a look at some important aspects of this process.
7.6.1. Take advantage of a platform
No matter which business units or assets you will scale your product to next, you will always need data and usually lots of it. Company wide, standardized data architecture will give your scaling efforts significant leverage. If your product only needs to learn to connect to one type of data source (e.g., a standardized data layer) your connectivity issues become close to plug-and-play, reducing scaling complexity significantly.
In the beginning of your scaling process you might find that the effort of getting relevant data connected to your data-layer is a task greater than connecting your application. Once your product is up and running, it becomes a lot easier to replicate, whereas hooking up different data-sources to your data layer can be tedious.
Considering data provision as part of your scaling requirements and as part of a global digitalization effort will give you additional leverage. Data availability will not only be relevant for your product, but hopefully, to future endeavors. These products will serve as business cases that will justify the data layer itself, since data provision alone does not create additional business value. Typically, data is moved from local data historians to global cloud solutions, facilitating access from anywhere in the world.
7.6.2. Establish a team and involve the assets
In the pilot phase, your team members might have been an ad-hoc ensemble of colleagues that were sourced to execute the project. As you move from pilot to product, your engagement will consequently be more long-term, including the creation of a self-sufficient, committed core team that can grow as needed.
Remember to Involve the asset from the start. Involving the user at the beginning of each roll-out assures you meet requirements and that you understand expectations. Your products will fail if you do not create co-ownership.
7.6.3. Keep developing
Be prepared to keep developing your product. Your users will find bugs and request new features. The product will evolve with implementation and use, and unforeseen issues will need to be addressed. Staying open-minded with an eye toward improvement, will help you meet these challenges.
As your product grows, you will need to ensure you scale its support. In the pilot phase, most issues will be handled by the development team. As the number of users increases, your capacity to support your solution will need to grow. Depending on the setup, this growth may be managed within your IT department or in conjunction with an external partner.
7.6.4. Involve UX expertise
While the pilot focuses on the technical feasibility of your product, you will have more time to fine-tune the user experience (UX) and design when you conceptualize the final product. In the end, your solution must not only work properly, but the user experience must be positive and sustainable. Again, the user’s input will be critical to create an intuitive interface while maintaining high functionality. Finally, the design of the tool can also be aligned with the corporate design language of your company.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.