the art of problem solving --> ensure you right the right business requirements in the right way
TRANSCRIPT
The Art of Problem Solving
Business Banking Client
February, 2013
PUBLIC
Agenda
• Context• Problem Solving According to Dilbert!• What’s the benefit of improving your problem solving
process?• The Problem Solving Framework
– Identify the problem– Develop Alternatives– Select the best alternatives– Implement– Evaluate the Solution
• Top 10 Tips for Developing Business Requirements
PUBLIC
Requirements in Context of Problem Solving
• You can only have discussions around requirements in the context of a good problem solving process
• Quality requirements gathering is an outcome of this process
• It is easier to get teams focused on having discussions around requirements when it is done within the problem solving framework
PUBLIC
Problem Solving According to Dilbert
PUBLIC
What’s the benefit of improving your problem solving process?
Improved Profitability
• Increased sales
• Reduced costs
• Reduced business risk
• Reduced cost of customer acquisition
• Increased customer retention and Satisfaction
• Improved work processes
• Opportunities to innovate
Improved Capability
• Increase staff resourcefulness
• More effective problem solving
• Improve decision making
• Increased capacity to leverage learning
• Build more effective team collaboration
• Enhance different types of thinking (creative, strategic)
PUBLIC
What happens if you don’t solve the right problem?
• "Houston, we've got a problem." These famous words, spoken by astronaut Jim Lovell from space in April 1970, launched a famous public demonstration of solution-finding.
• "Failure is not an option," Gene Kranz, lead flight director for Mission Control, announced to the ground crew in Houston as Apollo 13 approached the critical earth-to-moon decision loop.
• “It's so much easier to suggest solutions when you don't know too much about the problem.”― Malcolm S. Forbes
• “a problem well put is half solved.”― John Dewey
•“We always hope for the easy fix: the one simple change that will erase a problem in a stroke. But few things in life work this way. Instead, success requires making a hundred small steps go right - one after the other, no slipups, no goofs, everyone pitching in.”― Atul Gawande, Better: A Surgeon's Notes on Performance
PUBLIC
The Problem Solving Framework
Requirements definition is important
Requirements definition is criticalPUBLIC
Identifying the Problem • “If I were given one hour to save the
planet, I would spend 59 minutes defining the problem and one minute resolving it,” Albert Einstein said.
• You may know there is a problem, but do you know what the root cause is?
– Can you put your finger on the actual problem?
– Are there a number of issues that are just symptoms of a bigger cause?
• “Keep it simple”– Simply put, if you have a problem somewhere and it is causing a big
impact, measure it!
– How many times does it happen and what generic factors are causing this?
• Identify the Root Causes– The objective here is to wade through the symptoms, and identify the root
causes to the problem.
• State the problem as requirements that need to be solved for:
– Identify the current measure(s) which show that the problem is real
– Identify the goal measure(s) to show the benefit of the problem being addressed and the value of meeting it
– Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly
– Define the business "whats" that must be delivered to meet the goal measure(s
PUBLIC
Develop Alternatives
• USE BRAINSTORMING TO COMBINE AND EXTEND IDEAS, NOT JUST HARVEST THEM
• DO INDIVIDUAL BRAINSTORMING BEFORE AND AFTER GROUP SESSIONS
• BRAINSTORMING SESSIONS ARE WORTHLESS UNLESS IDEAS LEAD TO ACTION
• BRAINSTORMING SESSIONS ARE WORTHLESS UNLESS IDEAS LEAD TO ACTION
PUBLIC
Select the Best Alternative
• Team Agreement on the best alternative(s) to solve the root cause problem(s)
• There is value in the debate
• Avoiding “group think”
• Above the line commitment
PUBLIC
Implement
• Build your implementation roadmap• Consider short, medium and longer term actions• Ensure you plan out all of your activities• Ensure that your implementation requirements are
fully elicited:– Identify the people who will help specify requirements
and understand their organizational bias– Define the technical environment (e.g., computing
architecture, operating system, telecommunications needs) into which the system or product will be placed
– Identify "domain constraints" (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built
– Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings)
– Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the rationale for each requirement that is recorded
– Identify ambiguous requirements as candidates for prototyping
– Create usage scenarios or use cases to help customers/users better identify key requirement
PUBLIC
Best Practice Requirement Example
Bad Requirement
• The system shall be completely reliable”
• “The system shall be maintainable”
• “Order rejections shall be less than 99%”
• “The system shall be fast”
• “The system should use artificial intelligence”
• “The system should be totally modular”
Good Requirement
• “The response time for the system to present the checkout page upon an order button click on a product detail page shall be less than 500ms”
• “95% of all transactions on the public-facing webstore portal shall be processed in less than 4s”
• “MTBF for the domain controller server shall be 5000 hours of continuous operation”
• “The system shall present the closest 5 stores to the user on the map page, provided that 5 stores are within the user-defined search radius”
PUBLIC
Measure Success
• Did the actions we take move the yardstick?
PUBLIC
TOP 10 TIP FOR DEVELOPING BUSINESS REQUIREMENTS© 2011, TechWRITE, Inc.
PUBLIC
1. Make requirements verifiable and measurable
• One important purpose of a business requirements document is to measure results, but unverifiable requirements can’t be measured.
• Take for example, a requirement that says, “the system must be easy to use.” What exactly does that mean? A generalized statement such as this must be made specific so that it can be tested throughout the development process.
PUBLIC
2. Do not include the solution design
The requirements focus on what needs to be done, not how to do it. (The “how to do it” will be covered in other design documents.)
PUBLIC
3. Format requirements as separate paragraphs
It’s important to do this so that each requirement can be linked to details in subsequent design documents. Specifically, each requirement should express a single concept, such as:
• Quality measurements will be gathered monthly through online surveys.
• The quality information gathered will be maintained in a database.
• The database will have a reporting/query tool available for ad hoc queries and reports.
PUBLIC
4. Use details wisely
There are the two common mistakes with details:
• One mistake is including more details than are relevant to the reader. Ask yourself, does the reader really need to know this detail? If not, take it out.
• The other mistake is not including enough important details. To avoid missing critical details, take a wide view of the field or domain of the business process – review industry studies, reference architectures, industry and vendor white papers, and of course Google.
PUBLIC
5. Use uncomplicated sentences and chunk information so it’s easy to
understand.• Simple sentences are more understandable. In
addition, they lend themselves to more precise evaluation when the project is completed.
• To accomplish this, break out details into bulleted chunks so they’re easier to grasp.
• Take a look at the following example that shows how a complicated sentence can be restructured.
PUBLIC
Uncomplicated Sentences Example
PUBLIC
Original: Assessments of functional quality must be derived through an
online survey of multiple business line managers, senior
executives, sales and marketing managers, production
managers, and customers and then maintained in a database
and available as monthly reports or through ad hoc queries.
Revised: Functional quality assessments will be gathered monthly
through an online survey of the following participants:
Multiple line of business managers
Senior executives
Sales and marketing managers
Production managers
Customers
This information will be entered into a database and will be
distributed through:
Monthly reports
Ad hoc queries
6. Avoid unnecessary words.
• If the words do not add meaning to a sentence, leave them out. For example:
PUBLIC
Original: There must be the three following results from this
process:
Revised: The three results must be:
7. Use simple words rather than “complicated” words
PUBLIC
Difficult Simple
facilitates helps
substantiate prove
presently now
exemplifies shows
usage use
represents is
utilize use
8. Avoid using “it” and “this” without a clear antecedent
• Using the antecedent in place of “it” or “this” helps in two ways.
• The repeated antecedent adds clarity to the sentence.
• If the sentence is “lifted” from the text, for traceability purposes the meaning will remain understandable. For example:
PUBLIC
Original: Add course location aids for all course locations. To
facilitate this, add or update class libraries for all
software development environments. This will allow
students to get directions to course locations at the
office as well on mobile devices.
Revised: Add course location aids for all course locations. To
provide this location functionality, add or update
class libraries for all software development
environments. The course location aids will allow
students to get directions to course locations at the
office as well as on mobile devices.
9. Use terminology consistently
• Avoid using different terms for the same thing. For example:
PUBLIC
Original: Click the Resources tab. After you click this button,
a list of resources displays.
Revised: Click the Resources tab. After you click this tab, a
list of resources displays.
10. Review the document and then spell check and proofread
• Read through the entire document to be sure the document makes sense and flows logically. Don’t forget to spell check. And then, proofread the document, checking for missing words and incorrect numbering or cross-references. Then check that the table of contents refers to the correct page numbers. In a final pass, read the document aloud slowly to catch anything you might have missed previously. (For more information on proofreading, see TechWRITE’sblog entitled, The lost art of proofreading.)
PUBLIC