project design using OMI
-
Upload
patrick-gorman -
Category
Documents
-
view
95 -
download
3
Transcript of 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
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
[email protected]; [email protected]
Based on, “Techniques for Building Excellent Operator Machine Interfaces (OMI)”
Aerospace and Electronic Systems Magazine, IEEE (Volume:24 , Issue: 10 )