User Tools

Site Tools


Open Orbit User Guide

Getting started with Diagnostics


Open Orbit is a unique algorithm-based business process improvement tool. It mentors users through an optimised way of solving business improvement problems – proactively recommending the most relevant symptoms, causes, and remedies for the problem - to drastically reduce project duration and cost.

The algorithm guides human judgment to speed up the identification of the best solution. It’s like a GPS for users, helping them get to where they need to be as quickly and reliably as possible. Open Orbit stores the best route so it can be referred to by anyone in the organisation. Unlike any other tool on the market, it builds reusable corporate memory of what works and why, in a way that’s accessible by anyone, regardless of their familiarity with business process improvement. It also detects whether multiple users in the organisation have similar problems and connects them to drive collaboration. This user guide has been designed to help you get started with the diagnostics journey on Open Orbit. It is the first of the series of guides that includes how to use the platform to track and manage improvement projects, how to extend the functionality as a Super User, and how to manage user licences in your organisation as an Administrator.

Add a new Project:

How this is done

After sign up and account application, we can get started with adding a new project. In the blank space add your Project name, optionally enter a description (you may defer this step till later and leave the field blank for now if you wish) and click on Submit.

A new record will get created and will contain a button called “Project Details”.

Best Practice Tip: Project names should be brief and yet easy to understand for your colleagues. Use acronyms and jargon only if widely prevalent in your organisation. A longer description can always be added in the Description field. In some cases, your organisation may have issued guidelines on nomenclature, and if so we highly recommend you follow them. Everyone following those simple rules can make a significant impact on how easily people can find knowledge and lessons embedded in each other’s work.

Framing the problem:

Why we need to do this

Faster improvement has to start with a clearer definition of the problem. A process transformation problem has three elements to it:

  • Symptom-cause-remedy analysis
  • Happy path of hand-offs
  • Connections between the above two

We will now learn about each of these aspects, as well as how to perform the relevant steps in Open Orbit. The first step in defining a process improvement problem is “symptom-cause-remedy” analysis. Open Orbit is a GPS for process improvement. You feed in the map coordinates and it shows you an optimised path towards better processes.

The map coordinates are industry, process type and business objective. Together, they enable Open Orbit to recommend some metrics to measure (or symptoms to check for). After you have shortlisted some metrics from this list, the tool recommends causes to check for. And based on which of those causes you shortlist as potentially relevant to your business, it will recommend solutions (or remedies) to consider.

In the first iteration, all of this is just a working hypothesis. You haven’t actually validated the shortlist with people who perform the process. That will be the next step. The purpose of this first iteration is to build a working hypothesis that significantly speeds up the diagnosis compared with starting with a blank sheet. It will be refined over multiple iterations.

How this is done

Go to the Project Details page of the Diagnostic workbench. You will now need to set context in your project: The first map coordinate is the industry you are working in. Add new Industry Vertical: select from standardized lists of industries, which have been designed to optimize the generation of actionable insights in the quickest and most relevant way.

Best Practice Tip: While you can use add multiple industries, we recommend you stick to one unless it clearly doesn’t capture the context of your project.This enables more focus in the following steps.

We now turn to the second map coordinate - selecting a process type. You have an option to ‘ASK OO” to give a list of relevant processes appropriate under the selected Industry. Alternately, you may select from a comprehensive list of processes listed.

Best Practice Tip: While you can use add multiple processes, we recommend you stick to one unless it clearly doesn’t capture the context of your project. This enables more focus in the following steps.

This brings us to the third map coordinate – Business Objective. Why is there a problem worth solving at all? What is the high level objective here? Is it increased revenue? Or reduced cost? Or better customer experience? Timeliness perhaps? Defining this objective can be hard as many of these high-level goals overlap. Despite this, it is important to pause and think here, and make an informed choice as to which option you will go for. Spending this time now and making sure the project has the right focus will save a lot of time and money further down the track. The Primary or Secondary Objective can sometimes change at a later stage in the project based on further understanding of the problem.

Best Practice Tip: The Primary Objective should be chosen with care so as to drive the right focus for the project. The algorithm automatically takes care of the interdependencies. For example, a process cannot be efficient without being accurate (doing the wrong thing efficiently doesn’t count!) so selecting Efficiency implies that Accuracy is included. Similarly a process cannot deliver good customer experience without being accurate as well as timely. Again, the algorithm will consider such dependencies and you do not need to add the other factor as a secondary objective “just to be sure”. At the same time, there is no harm as such if you did do so, to emphasise the factor for people who read about your project. Also, it is easy to change this setting and re-run the recommendations algorithm at any time of the project without invalidating the work done to that point. All these lists above are standard drop down, standard lists allow for the algorithm to be leveraged better making for speedier analysis. You are benefiting from the wisdom of the crowd, so to speak, without compromising the confidentiality of your business data. These lists are continuously evolving based on how people use the technology, so you are being encouraged to categorise your problem based on how others in similar situations categorised it.

Reviewer's Tip: It is critical that the reviewer validates the context as these will play an important role in the recommendation output. Please pay special attention to the Objective / Big Y selected for the process.

Diagnostics – Metrics:

Why we need to do this

We now have the foundation in place to begin our Symptom Cause Remedy analysis. A visit to the physician starts with a purpose to resolve an illness. You are experiencing symptoms, which need to be then assessed by the physician. In our case, the symptoms are the business metrics, and how close or far they are from target values.

How this is done

The tool has a repository of metrics. Ask the tool for the relevant metrics for your hypothesis by clicking on “Ask OO”. This will show you a list of symptoms to check for. The list of metrics is arranged into groups in multiple layers. For example, measures of “correctness”, or “timeliness” etc. You can expand and collapse these groups as you browse through the suggestions. Use the “+” / “-“buttons to expand and collapse the structured set of question. These questions help you frame your thinking process and guide you through every possible option that might be relevant in the business problem that you are trying to solve. Use the “Add” button to select the metric and “info” button to read more about the topic:

Best Practice Tip:

  • Aim to have between 5 and 10 metrics. This is not a hard and fast rule, but too few metrics may result in a very narrow scope of analysis, and too many can risk spreading your efforts too thinly. .
  • The metrics are grouped into a 2 level hierarchy, and if you are selecting either, none or too many, from one category, that can also reduce the insightfulness of the analysis.
  • Some of the metrics within one sub-category can be seen as aliases, synonyms or proxies of each other – for example % On Time and % Provisioned On Time. In such cases, pick the term that is more familiar to you and your stakeholders, and avoid picking both, since it will not add to the root cause analysis.
  • Continous metrics, where data is available, are more insightful than discrete metrics. For example, Provisioning Time is a richer source of insights than % Provisioned on Time. While SLAs are often managed by using the latter, root cause analysis is better informed by the former. If you measure it, use it.
  • Each process has some commonly found vital signs, quite like the human body. They can tell you if it is worth digging further at all – if all 5 vital signs are “green” then there may not be a problem worth solving at all, and if there still is, then the targets behind the “green” assessment could be wrong!
  • The vital signs are in two groups: those impacting the customer – Accuracy, Touch Time and Wait Time; and in addition those impacting the business – Volume and Capacity. The most commonly found holistic analysis will have as many as possible of these 5 vital signs represented. In fact, if you are struggling to narrow down from a vast array of challenges with the process, and feel like you can’t decide where to begin, a first round analysis of these 5 metrics for the end to end process is a good start.

Reviewer's Tip: While metrics can be added/deleted at a later stage, as a reviewer please consider that all relevant metrics are selected - check for aliases and ensure that the list is not too long and at the same time covers all important aspects of the project. It is wise to select the metrics that are currently not measured but should be measured potentially. This should be captured in the Solution Check list. Also redirect users to the “info” button to read more about the metrics. the Wiki page on these topics are handy and help practitioner to clear his thinking and understanding about the particular topic.

Diagnostics – Causes:

Why we need to do this

Now that we have selected the symptoms, the next step is to quickly learn about the possible causes and explore remedies or solutions. You can always come back to the list of metrics and make additions or deletions as you learn more about the process. Coming back to our medical analogy, it is now time for the doctor to investigate the possible causes of your symptoms.

How this is done

Open Orbit shortlists some causes for you when you click the ‘Ask OO’ button. The tool can also help you to analyse causes more effectively by breaking them down into the following categories; Environment, Process, People, Measurement, Policies and Systems. You can expand and collapse these groups as you browse through the suggestions. Use the “+” / “-“buttons to expand and collapse. The lists can be sorted by either Cause type or Metric. Use the “Add” button to select the cause and “info” button to read more about the topic. Once selected, the cause will appear on the right hand side panel of the screen. You can also delete if need be from this list of Causes

Open Orbit’s algorithm uses a comprehensive database of root causes and it will make sure you haven’t missed anything. It will reduce the effort and time needed to identify causes thereby maximising your capacity to do more. These recommendations can help you come up with probing questions that you can ask during workshops and stakeholder meetings. You can also use your own judgement and knowledge of the specific business situation to filter the recommendations from the algorithm.

Best Practice Tip:

  • Aim to have between 5 and 15 causes. This is not a hard and fast rule, but too few causes may result in a very narrow scope of analysis, and too many can risk spreading your efforts too thinly. .

Reviewer's Tip: While causes can be added/deleted at a later stage, as a reviewer please consider that all relevant type of causes are selected, usually people tend to get inclined towards people / system related causes, therefore it is important that the causes are selected keeping the broad spectrum in mind. A good idea is to conduct a brain storming session with the project team and Subject matter experts using the AsK OO list, which will help users ensure that they shine the torch in each corner of the room. In case you have a customised cause, particular to the project, please get the Super User of your account to add it to the “Private List”. Also another point to make note here is that the causes are a deliberate high level expression and thus it gives the user flexibility to set context and record the particular issue in the comments in the Diagnostic Map.

Diagnostics – Solutions:

Why we need to do this

So far we shortlisted symptoms and then we selected possible causes. We are nearly at the end of our diagnostic cycle. It is now time for the physician to recommend treatment. A solution is initially set up as a hypothesis that must be validated before being taken up for implementation. Like Metrics and Causes, the list of Solutions in the project evolves during the life of the project.

How this is done

The tool will provide a list of remedies or solutions to solve for the problem at hand. The tool enables you to sort the solutions suggested based on the cause. It also categorises them by Environment, Process, People, Policies, Measurement and Systems. Just like we selected metrics and causes you can use “Ask OO” button to recommend possible solution against the selected causes. You can expand and collapse these groups as you browse through the suggestions. Use the “+” / “-“buttons to expand and collapse. The lists can be sorted by either Solution Type or Cause. Use the “Add” button to select the Solution and “info” button to read more about the topic. Once selected, the solution will appear on the right hand side panel of the screen

This full cycle of symptom, cause and remedy should be used continuously and iteratively throughout the project to provide probing questions for workshops and to capture insights as your understanding of the problem evolves.

Best Practice Tip:

  • Aim to have between 5 and 10 solutions. This is not a hard and fast rule, but too few solutions may result in a very narrow scope of analysis, and too many can risk spreading your efforts too thinly. .

Reviewer's Tip: Solutions typically will be the reverse of the cause and you need to elaborate particular actions for the recommended solution in the “Solution Check List” in Open Orbit. In case you have a customised solution, particular to the project, please get the Super User of your account to add it to the “Private List”. Also a detailed “How to” step is available in the Wiki - Info button of the Solution section, so it is worth a read to get some tangible actions. .

remember the Metric-Cause-Solution diagnostic cycle is a working hypothesis and the user is expected to come back to this section multiple times during the project lifecycle. Typically diagnose the problem in the define/measure phase and as the project matures, do keep evolving the hypothesis..

Process Model – Diagnostic Map:

Why we need to do this

We need to understand the logical flow of the process to get a clear view of the steps and process as a whole. We should describe the process using a structure called the happy path of hand offs. A Happy path is a set of steps performed on a transaction when everything goes right. A step is the largest possible set of activities before a hand-off is required to another person or team.

How this is done

Add a new Process. Name the process as per your requirement.

A new line item gets added.

Best Practice Tip:

  • Process names should be brief and yet easy to understand for your colleagues. Use acronyms and jargon only if widely prevelant in your organisation. A longer description can always be added in the Description field. In some cases, your organisation may have issued guidelines on nomenclature, and if so we highly recommend you follow them. Everyone following those simple rules can make a significant impact on how easily people can find knowledge and lessons embedded in each other’s work. .

Click on the Diagnostic Map button to start adding the process steps:

You will get redirected to a blank Diagnostic Map page. Click on the ‘+’ sign to add a step. Click on the ‘>’ to show / hide the left panel

Use the edit icon on the top left of the step to add comments or to modify the step entered.

The delete link allows you to delete that particular step. The left and right arrows can be used to shift steps around.

Best Practice Tip:

  • Step names should be brief and yet easy to understand for your colleagues. Use acronyms and jargon only if widely prevelant in your organisation. A longer description can always be added in the Comment field. In some cases, your organisation may have issued guidelines on nomenclature, and if so we highly recommend you follow them. Everyone following those simple rules can make a significant impact on how easily people can find knowledge and lessons embedded in each other’s work. .
  • A step is defined as the largest set of activities that does not involve a hand-off (say from one person to the next). A hand off suggests you should separate the subsequent activities into another step.
  • Aim to have between 5 and 8 steps. This is not a hard and fast rule, but less than 4 may point to a problem that is too simplistically framed, and needs some extension of scope (either upstream or downstream or both) to provide actionable insights. A common mistake is to miss analysing an upstream step of triage, queue allocation or a quick “pre-validation” even before work begins. Specifying that as an explicit step can help weed out subsequent wasteful activity.
  • Similarly more than 8 can become very complex to analyse and to articulate to your stakeholders, and you should consider breaking it down into multiple processes. .
  • Some times, you may want to split a step into two, even without a hand off. This can be useful if the systems used in the remaining activities is different, or if the dependencies and data requirements are different. Especially if you have too few steps, then it is quite alright to split them up and make the analysis more granular.
  • The steps when put together should form a “Happy Path”. This means they represent what happens when everything goes right with a particular transaction. All other paths and diversions should be modelled as exceptions or defects from the Happy Path.
  • Your process may contain a branch or a fork, resulting in parallel steps. If the branch or branches converge back into a common step at a later stage, you have three options: either model that entire group of branches as one step in an end to end process, and then model each branch as a Happy Path process in itself separately; or pick the most commonly occurring branch as the happy path and model the rest as exceptions; or pick the most preferred branch as the happy path and model the rest as exceptions.
  • If the branches never converge back, you again have three options – pick the most commonly occurring branch as the main branch; or pick the most preferred branch as the main branch; or it if is really very difficult to make this choice then you may well have a case of fundamentally different processes, where the first few preparatory steps happen to be common. Consider splitting up into separate processes, even if the first few steps are repeated across multiple processes.
  • A step can be classified as “Value Adding” or not, or partially so. Value should ideally be defined from the end customer’s perspective, as in “would they be concerned about why you are doing this and how well you are doing it”. At times, it is quite ok to consider an “internal customer” if the process is totally inside the enterprise and a strict application of the rule of value to an external customer results in everything becoming non-value-adding. Read about Lean
  • At times, it may be useful to split a “partially value adding” step into separate value-adding and wasteful steps, especially if the two aspects are not totally comingled AND you don’t already have too many steps.

Reviewer's Tip: This is the most important section of project on Open Orbit, so it is critical that users understand how to model it. It would be a good idea to spend some time with a new user to they understand the concept of happy path. Users also tend to get lost in trying to replicate the complex visio structure. The idea is to keep the happy path simple and diagnose the process in simple large chunks rather than complex visio steps, where the crux of the problems tends to get lost .

Process Model – Connections:

Why we need to do this

Once all steps are created, the next stage is to make “connections” from these steps to the metrics, causes and solutions shortlisted earlier with the help of the algorithm. This will enable the creation of the diagnostic map, as well as the Fishbone diagram. Also, we will be able to gather a visual representation of the bottlenecks and root causes at each step

How this is done

Let us connect the corresponding metrics, causes and solutions to the relevant step by a simple drag and drop method. Click on the Diagnostic Map button and expand the Metric-Cause-Solution to show the list selected earlier in the Diagnostics section.

Click on the highlighted area to expand and collapse the list.

Simply drag and drop from this list to the main panel to build connections with steps or to the panel below the main section to create connections with the whole process.

These connections can be edited to capture additional data like priorities, actual & target values and whether the causes are controllable or not. Click on the edit box in the tile highlighted below to add more data against the selected Metric / Cause or Solution.

Now this diagnostic map provides a complete picture of the process steps, and metrics, causes and solutions of interest, in just one snapshot.

Best Practice Tip:

  • Each step should typically have at least one metric, or at the very least be covered by the fact that you have connected a metric to the whole process. Each step need not always have a cause and a solution, but if it does have a cause, and it is rated as High Priority, then it should have a solution too! .
  • Sometimes the same step will have a large proportion of the metrics, causes and solutions all crowded into it. While this is not an indicator of something being wrong, you may want to consider if that step deserves to be analysed separately as its own Happy Path and be drilled down to the next level. .
  • Metrics, causes and solutions that are measured, validated and implemented at the entire process level should be connected to the entire process, and not repeated at each step. For example, customer satisfaction, end to end workflow implementation etc. .
  • However, metrics that are measured at step level, even if relevant to each step, should be connected separately to each step, for example Accuracy or Touch Time. Similarly causes that may well occur at each step, but need to be managed separately for each step, should be connected separately to each step. For example, Capacity. The same goes for Solutions. .
  • Most metric connections should be categorised as “input metric” which is the default setting. Some very selected metric connections, which are representative of the overall objective of the project, should be set to be an Output Metric. For example, in a Timeliness project, the end to end Cycle Time, or % On Time, can be an Output Metric, and everything else is an Input Metric. .
  • Causes should be categorised as Controllable or Not, considering the scope of the project. Just because the step is outside your immediate team does not make it not controllable, and vice versa. For example, input quality from the upstream party that provides you information, can be influenced and should be considered as controllable. But the pressure of market forces, say through impractical expectations of customers because of competition, may well be considered as non-controllable. .
  • Solutions should start life as Hypothesis, and then be taken through the life cycle of being validated, prioritised etc. as the project progresses..
  • All connections should ideally be rated on their priority. This is a subjective rating, informed by the analysis you are performing. For example, a large deviation from target would suggest a higher rating for a metric. Significant impact from a cause would suggest a higher rating. And the same goes for solutions. .
  • Use the comments fields in each of the connections (Metrics, Causes and Solutions) to tell the story behind that element. For metrics, document where you got the data from, who helped validate it etc. You can also add a URL to the file on your intranet shared drive where the source data is kept. This way, anyone with authority to access your project gets the full picture in one place minimising the need to seek clarifications. Use the Cause Comments to document evidence and who helped you validate it. Use Solution Comments to document who needs to or already has approved it. Avoid detailing the action plan for that solution in the Comments section, as this may duplicate what should ideally be covered in the Solution Actions section. .

Reviewer's Tip: It is critical that the reviewer verifies the logic of connections of Metrics / Causes and Solutions. For example metrics like Touch Time should ideally be measured at a step level, however overall out metric like Customer Satisfaction can be measured at a process level. This will completely depend on the project and the process being modelled. Same is applicable for the Causes and Solutions. Reviewer should also ensure that all connections have priorities selected, these can be changed at a stage if required and most importantly detailed comments are recorded for each connection. This is important as Causes and Solutions are deliberately high level and therefore critical that the project records their thinking on why the particular tile has been selected and connected.There should be a good balance between step-level and process-level connections. Connections and data against each of these connection will play an important role in the output artefacts like Fishbone / Performance Gap report etc..

Fishbone / Root Cause representation:

Why we need to do this

Based on these inputs the tool is able to also generate a Fishbone diagram - a visual mapping of the causes selected, categorised by type of cause. It is a very handy tool to represent the root causes analysis of the project. The more accurate your inputs, the more useful the generated fishbone will be.

How this is done

On the process model tab, click on the “Fishbone” button to generate the Fishbone analysis:

The DIAGNOSTIC MAP & Fishbone are visual representations to identify pain points and areas of improvement. These are available to print and can be taken to the stakeholders for discussions and decisions. You can always come back and modify the diagnostic map of your process.

Best Practice Tip: Ensure all selected causes are connected to the steps or process in the Diagnostic Map and prioritised (H/M/L) to show up correctly on the Fish Bone.

Reviewer's Tip: Please check for the coverage and penetration of causes types and that all branches are adequately populated.

Performance Gap Reports:

Why we need to do this

We now come to the third and final analysis tool – the performance gap report. So far, we have not had to provide any actual data on the metrics. For example, we may have said that “wait time” is important at Step 3, but we have not specified what the current value or baseline is, nor what we want it to be as a target. We can do this by editing the connection of that metric. Once you have captured some baseline and target data you can generate the Performance Gap Before report, which answers the simple question “where is my biggest problem”. It plots the gap between baseline and target, as a % of the target, and sorts in decreasing order.

How this is done

First we will need to complete the data entry. Go to Diagnostic Map, from the Process Model tab. Click on the edit button on the left top corner of the metric tile connected either to the step or the process.

Enter data and click on update. You can also enter data using the “data collection report” on the project menu. It provides a faster, grid-like data entry option that is useful once the visual layout has been created on the diagnostic map.

Use the Grid Edit or Edit button to enter data:

After you have completed the metric data entry you can generate the performance gap report. Click on Baseline Vs. Target Report from the left panel.

Select the process from the drop down and click on search:

The Baseline Vs. Target Report is generated as below. You can use the download option below to extract the data in excel, or edit to change priority

Similarly, you can generate the Achieved Vs. Target Report and Before Vs. After reports.

Reviewer's Tip: Its is recommended that data is entered for all metrics. In case target is not available use a recommended performance threshold. Also, there will be situations when metrics are not measured, have a plan to initiate tracking of these metrics wherever possible. A popular management mantra: “ If You Can't Measure It, You Can't Improve It”: Peter Drucker .

Project Tracking:

How this is done

All projects need tracking and Governance; therefore, we have designed some of this and built in the Open Orbit tool. This enables practitioners and project leads to track project diagnostics and project tracking related items all at one common space. It eliminates the need to maintain multiple trackers and audit logs. There are various features on project tracking that can be accessed in the Project Administration section of the tool. This section provides the ability to track project stages, status, dates, actions and notes. The section can be configured by your Super User to suit the requirements of your organisation. It can potentially simplify and replace other project tracking mechanisms like spreadsheets, registers and standardised status reports.

This sections contains the following:

Project Outline primarily contain all features related to overall outline of the project and it important for Project Charter elements.

Stage Tracking provides for tracking of stages of the project based on the methodology selected in the above section. The slippage and actual duration gets calculated automatically based on the input of planned and actual dates. They have a RAG status and this report can also be downloaded in excel.

Project Checklists depend on the stage and also on how your Super User has set up these standardised activities. Super user can upload templates against each of these prescribed tasks to be performed and the project owner can download and upload the completed templates. You would not require to maintain project artefacts and supporting templates in drives or presentations. The slippage and actual duration gets calculated automatically based on the input of planned and actual dates. They have a RAG status and this report can also be downloaded in excel.

Solution Checklists are free-format activities for you to create and track through to completion. It is important that this section is completed as it allows you to break down the selection high level solutions to smaller action items, thus making activities easier to complete and track. Create and monitor the action plan of Improvement. Learn from other action taken and rate your action for future reference. Track completion and progress and download to excel at anytime.

Click on Add New Item to create a new action.

Click See Action Taken to see action taken against the same solution as your project but other others within your organisation. This allows you to learn from others experience and collaborate and share best practises. This in turn will save time for the project lead as they will not need to reinvent the wheel. Click on Submit after entering all the relevant data. A new line item gets created. You can down load all of this in excel.

Best Practice Tip:

  • By the time your analysis is ready to be presented to others, you should have at least one, and often more than one, action against each solution that is prioritised and proposed for implementation. Name and describe the action such that it minimises the need for others to seek clarifications. Use acronyms and jargon only if it is widely prevalent in your organisation. If the owner of the action is not an Open Orbit user, keep ownership with yourself and manage the progress of that action with the actual owner. These actions will be made visible to others in your organisation who intend to implement similar solutions. So document them in a way that makes it easy for others to learn from your insights. They will be reciprocating the same benefit to you! .

Project Notes: Leave Project Notes for reviewers and peers. No need to track activities and discuss project related matter on emails.

Reviewer's Tip: Its is recommended that the Project Tracking section is complete as it may really help negate Non Value-Add tasks performed by project leads on governance and tracking. The tool simplifies project tracking and also inculcates collaboration by means of adding project notes or tagging and learning from solution actions. If this section is managed well you can easily generate improvement plan reports and project charters. Some of these reports can be customised to meet your organisations needs, we shall cover these in other modules. .

Presenting your Project through Open Orbit:

Best Practice Tip: Congratulations! You have completed a holistic analysis of a challenge your business is facing. You are now ready to present your findings and recommendations to your stakeholders. We recommend you follow this approach to maximise use of the tool and minimise the need to translate all this good work into a slide pack – this itself can save you hours of re-work and also keep all the analysis in a re-usable and standard structure.

  • Set some context for your audience using the Project Outline section, focusing on those fields that are useful for any given situation. Spend less or more time on this, depending on how familiar your audience is to why you are doing this project in the first place.
  • Explain the Diagnostic Map, outlining the happy path and selectively talking about various connections of metrics, causes and solutions. Explain the priority ratings. Expand and collapse each tile as you speak to it, and give some context by re-iterating the comments entered. Pause along the way, and check for understanding and agreement.
  • You need not expand and collapse every tile – use judgment to selectively bring out the most important points, especially points where you need your audience to make a decision. But also talk about things you are addressing anyway, without waiting for permission! If you are anyway proceeding with some of the solutions because there are well within your remit to decide, then bring that out too.
  • At the end, invite the audience to ask questions and expand more tiles while you answer them. The more you use the interactive expand / collapse feature, you will not only focus their attention but also indirectly convey the benefits of reviewing this on-line. Once people can see the benefit of the interactive display, they are less likely to insist on being sent a static slide pack. That will save you time and effort in future.
  • You can also refer to the summary section of the diagnostic map - where you should have the extract of the key message that you want to showcase. Also, any supporting attachments in the footer section can be referred to if required.
  • Thereafter use the Fishbone to demonstrate how your root cause analysis is holistic across all factors.
  • If you have data behind your metrics, use the Performance Gap report to show relative priority and justify your priority ratings.
  • Finally, show the Solution Actions section and walk them through the proposed action plan with owners and dates.
  • Do remember that the above is for first time review, once your audience is aware of the context, you need not repeat the whole thing again. Based on the stage you are in the project use your judgement to redirect the conversation to the correct artefact. For example, if you are through with the diagnostic and analysis, and are focussed on implementing the solution you should directly move to the action plan and use the filters to show the progress.


So far, we have seen how to set context – or provide map coordinates – to the GPS algorithm; then create a symptom-cause-remedy hypothesis; then build a happy path of hand-offs and then pull it all together into a diagnostic map. Open Orbit is a place to think, and you are allowed to change your mind! At any stage in the analysis, if you feel one of these choices should have been different, you can make the change without negating the work done till that point. The algorithm simply picks up the new data and starts adjusting its recommendations from there on.

The information entered on the diagnostic map can also be used to generate the Fishbone diagram and the Performance Gap report. These are the core diagnostic tools in Open Orbit, and will help you save significant time and effort in taking your project through to a point where improvement actions can be debated and agreed between stakeholders.

The tool contains many more features, to help with collaboration between users and to enable project tracking and reporting. These will be covered in separate training modules.

You can also view a short video that will help you navigate the tool better: Open Orbit Tutorial Video

We hope you found this module of Open Orbit training informative and useful. Algorithmic guidance for process optimisation is a unique and leading edge approach, and we wish you every success in using this technology and deriving business benefits from it. Open Orbit, where Clever Meets Simple!

You could leave a comment if you were logged in.
user_guide.txt · Last modified: 2019/07/18 13:17 by insolitus