project design using omi

Improving Project Design and Planning using Iterative Techniques and OMI

Patrick Gorman, Senior Systems Engineer, The Boeing CompanyBased on, “Techniques for Building Excellent Operator Machine Interfaces (OMI)”

Aerospace and Electronic Systems Magazine, IEEE  (Volume:24 ,  Issue: 10 )

Speaker

• Patrick Gorman, Boeing Senior Systems Engineer– Assisted in designing the Operator Machine Interface (OMI) on

the US Navy P-8A and other complex programs• Designed to facilitate diverse experts teaming to carry out complex

actions in a stressed, chaotic environment

– Managed the FAA Collaborative Decision Making program• Used for efficient communications between airlines and controlling

organizations (i.e., the FAA)

– Traveled throughout the world (> 30 nations)– Designed and taught university and training courses

patgorman123@excite.com; patrick.e.gorman@boeing.com

Purpose and Assumptions

• Provides another perspective on project management practice– Portions may be used with “agile” or other software

development methods– Provides a set to tools and ideas that may be of assistance

in any given project

• Audience is familiar with general project management practices

What is OMI and Why is it Important?

• Check Wikipedia “user interface” for a good definition and

discussion

– Good OMI design makes software use faster, simpler and more intuitive, reducing customer frustration, errors, training and overhead costs

• FAA- Potentially catastrophic consequences for incorrect or late interpretation of information

• DoD- Lives hang on accurate interpretation and manipulation of information

Large IT Project Success Rates are Poor

• For example, in banking, 7% of large IT project and 66% of small

projects succeeded in 2013 (Standish group). – Large IT projects are inherently difficult.– Key variables include communication and “iterative

development”- keeping the customer involved and actively participating throughout development to better identify/refine specifications.

6

Causal Factors of Failure (Six Sigma technique)

• Find and fix the largest

causes and solve most

potential problems– Pareto Chart

• Largest causes of project

failure are planning and

communications… and

OMI design process can

help with both

Others Recordkeeping Technical Support Planning Communications Defect

Percent

Reasons for Project Failures

How Can We Improve OMI?

• “Kill three birds with one stone”- better define the

project while beginning OMI development and

iteration sooner in the project.– Identifies requirements early that might otherwise be

overlooked (improves planning and decreases costs)– Improves relationships with and understanding of the

customer– Building excellent OMI is necessarily an iterative

process- beginning earlier allows more and less expensive iteration.

Planning- First Iterations

• Identify and prioritize major and as many minor requirements as

possible within constraints imposed by project funding, time and

scope.

• OMI design iteration helps customer and builder visualize the

end result, often allowing identification of previously unnoticed

requirements and constraints and refines design.

• Tell stories and take notes.

Using “Expert Users”

• Helps define project results from a user point of view- provides a valid view of success and failure

• Reminds developers (and executives) that people must use the product within certain limitations they may not be aware of- in extreme cases, the end result may meet specifications- but still be a failure for the customer

• Often experts have difficulty defining how they do what they do; our job is to assist them in discovering and translating their “How” into software requirements

From Simple to Complex

• Using progressively more detailed and expensive tools only as

needed– Tell stories and take notes– Use Powerpoint or equivalent to build a mock up– Use a simple tool that provides illustrative responses-

“Hypercard” – like– Run simulations based on scenarios from storytelling-

simulate capability. – Start building well understood parts; simulations become

more comprehensive – Balance change “usefulness” against impact – cost, risk, etc.

• Agree on measures of “usefulness” - Likert scale or other

Multiple Viewpoints

• Use several experts if possible to provide differing viewpoints– Listen carefully, and take notes! Respect their time

• Defining what “failure” or “wrong” looks like provides another

valid view of the project

• Often easiest to illustrate using an OMI mockup to describe

usage (or lack of it)

• Remember that users provide key inputs – They do not establish requirements.

Communication

Building Trust

OK

Consider precautions

Communications -Contractual vs. Technical

Beware Misunderstandings • Technical/professional jargon• Differing perspectives

OMI can be used to illustrate “done” to avoid misunderstandings

This?

Or this?

QSI Graphical Operator Interface

This?

Or this?

Establish a Baseline

• What “done” looks like, and how it functions

• What is of key importance

• What is “nice to have”- but not critical

Design the Logic

• Establish requirements

• Understand the general “shape” of required software

• Anticipate change, and design for it

• Once functionality is well understood, choose tools

and methodology

Iteration• Two parts of the software development

puzzle- user requirements (known by the customer user group) and difficulty of implementation (known by the builder).

– Usually need both for a good solution.

– As each gains a better understanding of the other groups’ constraints, decision making becomes better and more efficient

• “nice to have” vs. “must have” (on customer side), and • “easy to do” vs. “find a usable workaround” (on the developer

side)

Define the Details

• Specific scope

• Approximate SLOCs

• Identify “difficult” and “easy” code

• Define WBS and work packages

• Understand there are always “unknowns”

• Estimate costs

• Identify Risk

Project Process

• Encourage customer / builder interaction

• Allow swift revision of requirements for recognized deficiencies/ elimination of superfluous requirements

– Each must have schedule and resource impacts, and agreement of builder/ customer

– Don’t surprise the customer

• This helps:– Create more effective iteration– More effective use of “discoveries” (good and not so good)– Better/faster understanding of detail

Organizational Constraints• Large project = separate OMI team

– Communicate UP • with customer/ stakeholders to determine function, look, feel• OMI demonstrates capabilities, issues and priorities

– Communicate WITHIN • with programmers to describe / define function• OMI allows clearer communication of requirements and

constraints– Communicate ACROSS

• with organization to determine priorities, cost, schedule impacts, risk, etc.

• OMI assists in quick understanding of project

Take good notes, make them public, and act on them.

Required Changes

• Scope creep is always a concern.

– Control the “monster” by communicating; never discussing added scope without also discussing constraints (time, resources, risk)

Conclusion

• OMI- user interface design- must be a part of most software

projects, and can often be used to improve design, planning and

communications

– up to sponsors and customers – down to builders and users– across to peers and stakeholders

Saving the project time, money, frustration and risk.

Thank You for Listening

What questions do you have?

Take time to breathe, enjoy what you do, and celebrate

accomplishments

patgorman123@excite.com; patrick.e.gorman@boeing.com

Based on, “Techniques for Building Excellent Operator Machine Interfaces (OMI)”

Aerospace and Electronic Systems Magazine, IEEE  (Volume:24 ,  Issue: 10 )