2009 Software Business Analyst: Seven Best Practices

Transcription

1 2009 Software Business Analyst: Seven Best Practices Barbara Merwin Patterson Group Monday April 20,

2 Seven Best Practices for Software Business Analysts Quality as Job 1 Understand Your Business Projects and Processes Managing Risk UAT as a Victory Lap Building a Winning Team Implement Excellence 2 2

3 Practice #1 Quality as Job 1 Quality Control Quality Assurance Quality Management Cost of Quality 3 3

4 Quality Control: Process to Find Defects Applied to products already created (after the fact) Performed first by producers Responsibility of line management to ensure it is performed Provides data for improvement Examples of Quality Control Activities Walkthroughs, Reviews, Inspections, Audits Testing: Unit, Systems, Integration, Regression, UAT 4 4

5 Quality Assurance: Process to Prevent Defects Performed prior to product creation Improves processes and procedures Enhances staff skill sets Supports the collection of measurement information Learns through analysis of Quality Control Data Typical Quality Control Activities Process development and support, Process management Standards, policies, and procedures Measurement and analysis Training and facilitation 5 5

6 Quality Management and a Quality Environment Quality Management Manage by Process Manage with Facts Manage Toward Results Focus on the Customer Continuous Improvement 6 6

7 QAI s Model For Managing Quality In A Changing World Customer Goals Manage Toward Results Strategic Measures Enables The specified results should be quantitative. Manage With Facts Manage By Process Tactical Measures 7 7

8 QAI s Model For Managing Quality In A Changing World Management must define the results they hope to achieve. Customer Goals Manage Toward Results Enables The specified results should be quantitative. Management must ensure that there are appropriate processes in place to enable the workers to meet the desired results. Manage By Process Manage With Facts 8 8

9 QAI s Model For Managing Quality In A Changing World Customer Continuous Improvement Goals Decompose Manage Toward Results Enables Manage By Process Strategic Measures Manage With Facts Tactical Measures 9 9

10 Plan Do Check Act: The Process Improvement Cycle Plan Do Check Act 10 10

11 Cost of Quality Cost of Quality Components Product costs Prevention costs Appraisal costs Failure costs 11 11

12 Investing in Prevention Cost of Quality Investment Prevention Appraisal Failure Product 12 12

13 Cost of Quality (COQ) Workshop Review each of the items on this software project cost report and label it P (Cost of Prevention,) A (Cost of Appraisal,) F (Cost of Failure) or X (Cost of Production.) Sum up the costs for each element (P, A, F, X) and then calculate the Cost of Quality (P + A + F) and the percentage of the entire project cost it represents. Project Costs Train team to use an automated test tool $ 7,000 Create requirements docs& external design docs 28,000 Review design 4,000 Develop acceptance test plan 10,000 Produce internal design and code 72,000 Perform code Inspection 12,000 Test Software 33,000 Modify code, correct problems found in testing 28,000 Add new requirements, modify design, code 13,000 Add help desk support 16,000 Write user manual 4,000 TOTAL Project Cost $227,000 COST OF PRODUCTION: COST OF QUALITY: Cost of Failure: Cost of Appraisal: Cost of Prevention: TOTAL COQ: 13 13

14 Practice # 2 Understand the Business Understand the Language of Business Understand the Business Process Create Business Requirements Identify Quality Requirements Manage Requirements 14 14

15 Business for BA s The language of business, as a whole, is finance Each industry has a unique vocabulary Each organization has a specific dialect Technology has a separate vocabulary To communicate successfully, the BA must speak and understand all four 15 15

16 Business Fundamentals: Understanding Vision, Mission, Goals, Objectives, Strategies and Tactics VISION MISSION GOALS GOALS GOALS OBJ OBJ OBJ OBJ OBJ OBJ SK

17 SK Business Fundamentals: Understanding Vision, Mission, Goals, Objectives, Strategies and Tactics GOAL OBJECTIVE Strategy OBJECTIVE OBJECTIVE Strategy Strategy Strategy Strategy Strategy T a c t i c T a c t i c T a c t i c T a c t i c T a c t i c T a c t i c T a c t i c T a c t i c T a c t i c T a c t i c T a c t i c T a c t i c

18 Business Fundamentals: Developing the Organizational Vocabulary Finance is the language of business Assets Capital Cash flow Liabilities Revenue 18 18

19 Return on Investment (ROI) The appreciation received based on the investment made. This amount is generally expressed as a percent of the base capital. A time factor must be defined for the number to be meaningful (a 10% return on investment over a 2 year period). Other formats which may be used in an organization to express this are: Return on Assets (ROA); Return on Equity (ROE) or Internal Rate of Return (IRR). The name of the format defines the basis used

20 Business Fundamentals: Organizational Funding Organization Types and their funding sources For Profit Not-For-Profit Governmental Funding Cycles 20 20

21 Business Processes Are designed to accomplish the specific purposes of an organization Are often comprised of both automated and manual sub-processes 21 21

22 Finding the story Identifying trigger events Naming major processes Creating Time Lines Customer experience analysis Process Identification 22 22

23 Process Identification Finding the story Identifying trigger events Naming major processes Creating Time Lines Customer visible Customer transparent TIME 23 23

24 Initial Process Time Line Process1 0 hour days 10 days Process N Process A 24 hours 5 days Process B 24 24

25 Build a Common Language Improve communication Reduce errors due to misinterpretation Reduce conflict Enhance the relationship 25 25

26 Defining the Business or Functional Requirements Define what they system must do and be. Requirements cannot be done by either the customer or by IT alone; they must be done together. The Business Partner has the primary responsibility for the development of good business requirements. Are an attribute of a product, measured on a binary scale. (e.g., Invoice Amount = Quality Times Price) Any step that can improve the quality of requirements will pay for itself many times over

27 The customer has primary responsibility to define good business requirements. A Good Business Requirement Must Be: Complete Important Modifiable Correct Unambiguous Realistic Consistent Testable Traceable 27 27

28 Technical or Quality Requirements Define how the finished system must perform. Are an attribute of a process measured on graded or numeric scales. (e.g., Invoice to be produced within 8 hours of receipt of order) Are the cause of more failures than lack of complete or correct functional requirements. Are often missed in the requirements gathering process

29 Quality or Technical Requirements Must always specify The Minimum Level of Acceptable Performance. This is the level, below which the proposed system or enhancement has no utility for the intended customer

30 Manage Requirements Known base Managed access Authorized modifications Controlled results 30 30

31 Creating a Change Request Process Identify the reason or cause Document the requested change Estimate the resources Designate approvals Document results 31 31

32 Practice # 3 Projects and Processes Understanding Business Problem and Projects Process Workbench Earned Value Using PBC 32 32

33 A Problem is A gap between where we are and where we want to be. A Business Problem is based on a business need. All IT projects should be based on an established business need

34 A Project is: a temporary endeavor undertaken to create a unique product or service PMBOK, A Guide to the Project Management Body of knowledge 34 34

35 A Project Shopping List An established business need An owner or champion A scope statement and charter A plan for accomplishing the solution Methods for accomplishing the solution Resources for accomplishing the solution Criteria for measuring progress Criteria for measuring success 35 35

36 A Process is A series of interrelated activities designed to produce a specific result

37 SEI Capability Maturity Model OPTIMIZING MANAGED DEFINED REPEATABLE INITIAL 37 37

38 The Concept of a Process Workbench System of Management Controls Rework OK? (No) Input Procedure To DO Work Procedure To CHECK Work OK? (Yes) Deliverable 38 38

39 Business Analysts Input Workbench System of Management Controls Rework OK? (No) Business Input Need Procedure Build System Requirements To DO Work Procedure Requirements To CHECK Correct? Work OK? (Yes) Deliverable IT Requirement 39 39

40 A Word About Processes A Good Process is better than a Bad Process A Bad Process is better than No Process How Good Are Your Processes? 40 40

41 Earned Value This approach compares information about the amount of work planned to what has actually been completed. This is used to determine if cost, schedule and work accomplished are progressing as planned. The comparisons are often expressed in equations such as: BCWP-ACWP = CV (Budgeted Cost of Work Performed minus the Actual Cost of Work Performed equals the Cost Variance ) 41 41

42 Example 1 ACWP Example 2 ACWP Example 1 BCWS Example 2 BCWS CPI Times SPI "=" CSI Example Example

43 Managing a Project as a Process Most problems related to customer satisfaction are communication problems. Most communications problems can be reduced by creating Performance Based Contract

44 Performance Criteria: Establish Performance Criteria Ease of Use Expandability Maintainability Cost/Benefit Reliability Availability/ Response Time Integrity Security 44 44

45 Performance Criteria: Identify Performance Standards Performance Criteria (Desired Outcomes) The ABC system will be easy to learn, easy to use, and will improve staff productivity. The system will be compatible with known and projected releases for all key hardware and software components for the first 15 months of operation. Measurement Standard 1. Users of the existing system will be able to perform a basic customer account query, set up a new order, update an order status, and print the confirming documents after 4 hours of training on the new system. 2. Total time to create a new customer record, place an initial basic order (5 items and $100 or less) and create the confirming documents will be 3 min, as opposed to the current 8 min. 1. Point upgrades of supporting software products, including operating systems, can be accomplished with a straight re-install, requiring 2 hours or less. 2. The product can be installed on new releases of the target hardware platform with a straight install, requiring 2 hours or less, for the first 15 months post implementation

46 Performance Criteria: Monitor Performance Performance Criteria (Desired Outcomes) The ABC system will be easy to learn, easy to use, and will improve staff productivity. Measurement Standard 1. Users of the current system will be able to perform a basic customer account query, set up a new order, update an order status, and print the confirming documents after 4 hours of training. 2. Total time to create a new customer record, place an initial basic order (5 items and $100 or less) and create the confirming documents will be 3 minutes, as opposed to the current 8 minutes. Monitoring (Quality Control Plan) 1. Post training examination of all students. 95% should successful complete the transactions. 2. Random sampling of actual performance in the workplace, beginning two weeks post training. 90% of target transactions should equal to or less than the time standard

47 Performance Criteria: Performance Criteria (Desired Outcomes) The ABC system will be easy to learn, easy to use, and will improve staff productivity. Measurement Standard 1. Users of the current system will be able to perform a basic customer account query, set up a new order, update an order status, and print the confirming documents after 4 hours of training. 2. Total time to create a new customer record, place an initial basic order (5 items and $100 or less) and create the confirming documents will be 3 minutes, as opposed to the current 8 minutes. Monitoring (Quality Control Plan) 1. Post training examination of all students. 90% should successful complete the transactions. 2. Random sampling of actual performance in the workplace, beginning two weeks post training and continuing for 6 weeks. 90% of target transactions should be completed within the time standard. Incentives Incentives Payment in full for this portion of the contract if standard is achieved. 5% (of the portion of the contract monies associated with the delivery) + or - for each 2% variation from standard, positive or negative

48 Performance Criteria: Performance Criteria (Desired Outcomes) The finished product will include all requirements included in the attached requirements document. Measurement Standard 1. Functionality may be delivered in up to four (4) releases. The first release will occur within 270 days of the contract % of identified KEY Functionality must be included in this first release. 3. Subsequent releases must be completed within an additional 365 days (1 year). Monitoring (Quality Control Plan) % inspection of releases to be cross checked against the full requirements list (attached) % inspection of releases to be cross checked against KEY Functionality list (attached) % inspection of releases to be cross checked against the full requirements list (attached) Incentives Incentives Full payment for 100% compliance. +/- 5% of contract for each 14 days difference from schedule. - 2% for each 1% of KEY functionality not included in initial release. -1% for each requirement not delivered within the specified time for the completed project 48 48

49 Performance Criteria: Evaluation and Metrics Vendor and Customer each evaluate performance: the numbers should be very close Additional metrics can help keep projects on track Collect as much of the same data used for internal projects as possible 49 49

50 Benchmark Identify a process for improvement Seek out others with a similar process Obtain data about how their process performs Compare that performance with existing process performance 50 50

51 Practice #4 Managing Risk Identify potential risk events Assess frequency and severity Major in majors Develop contingencies and triggers 51 51

52 Risk Appetite The extent to which a specific organization is willing to accept risk; the potential size or impact of risks an organization is comfortable with

53 Software Risk Issues Project Managers do not have development backgrounds. No two projects are exactly alike. Projects are humanly intensive. Project history is not well documented. Development is still organizationally immature. It is intangible and delicate

54 Risk Assessment Risk Probability = of * Occurrence Impact of Loss Quality Standards Reduce Frequency Reduce Scope QC Control Opportunity Minimize Impact 54 54

55 Create a Risk Assessment Matrix What kinds of risks exist How severe are those risks How likely are they to occur 55 55

56 Sample Risk Matrix Risk Description Severity Likelihood Ranking One or more test team members will High Medium 6 resign before completion The accounting department will not Medium Medium 4 be available on time The testing environment will fail to mirror production High Low

57 Majoring in Majors: Using Risk Categories Define changes by risk ranking (categories) Create processes by categories Major in majors Plan and agree to risk mitigation strategies Develop appropriate contingency plans 57 57

58 Contingencies and Triggers: Risk Response Planning for Risks: Risk planning includes defining and documenting Risk Triggers Risk Trigger Responses Risk planning includes risk mitigation or avoidance by changing the Outcome Probability Impact 58 58

59 Contingencies and Triggers: Risk Response Are we willing to assume the consequences of this risk? Can this risk be avoided entirely? How can the likelihood this risk will occur be lessened? How can we minimize the impact of this risk if it does occur? Is the cost of mitigation or avoidance likely to exceed the impact of the risk, should it occur? 59 59

60 Contingency Planning Timely and regular communication of all risk control and risk management plan data should be made including: Description of the impending risk. Anticipated effects on project staff, users, and stakeholders. Anticipated effects on project schedule. Anticipated effects on project budget. Anticipated effects on work products or deliverables. Desired outcome of contingency activities. Communication strategy as risk becomes more likely. What activities will be executed to minimize risk s effects. Who is responsible for the activities. When will the activities occur (what is the trigger event). How to evaluate and track the effect of the contingency activities. When the contingency activities will cease (by a certain date or when a specific desired effect has occurred)

61 Practice #5 Acceptance Testing as a Victory Lap Capture and Manage Defect Data Involve BAs early Inspect Requirements Create realistic test plans 61 61

62 Defect Source and Cost* REQ DES C/T MAIN 10 0 Caused * James Martin 62 62

63 Defect Source and Cost* REQ DES C/T MAIN 10 0 Caused Found * James Martin 63 63

64 Defect Source and Cost* REQ DES C/T MAIN 20 0 Caused Cost * James Martin 64 64

65 Defect Tracking Source and root cause of defect Phase and means of identification Magnitude Defect counts and density Process improvement and managing to expect defect densities 65 65

66 Using Defect Data Common Cause and Special Cause Common Cause Addressed Within the Process Are generally easier to identify Often simple to address More complex issues surface as easier ones are resolved Special Cause Addressed Outside the Process May be easy or difficult to identify May be outside the ability of the organization to address 66 66

67 Using Defect Data Illustration of an Out-of-Control Process μ + 3 σ μ μ 3σ SPECIAL CAUSE 67 67

68 Cause-Effect Diagram, Fishbone Diagram, Ishakawa Diagram, Root Cause Analysis Diagram People Processes Machines Environment Materials Data Cause Categories Threat Description Page

69 Hear yea! Hear yea!! Effective Acceptance Testing begins in Requirements!!!!! 69 69

70 Inspecting Requirements and Test Cases Roles Trained moderator Author representing the writing group Reader 2-4 others: experienced developers, BA s, testers, and members of the involved Business Unit(s) Resources Standards defining Entry Criteria and Exit Criteria Procedures defining how work is done Management support for processes 70 70

71 Inspecting Requirements Prepare for the meeting Conduct the meeting(s) Read document one item at a time Re-state each item Identify defects (wrong, missing, extra) Refer defects for correction Fix the defects 71 71

72 Develop a Realistic Test Plan If you don t know where you are going, any road will get you there

73 The Acceptance Test Pan A subset of the overall Test Plan, which is a subset of the Project Plan What will be tested, by whom and how When will testing start and how will it be conducted When will testing finish and how is that determined When and how will results be reported 73 73

74 Develop Acceptance Criteria in Advance All tests run successfully to conclusion and are 100% accurate or Nothing is falling below the Minimum Acceptable Level or Time runs out? 74 74

75 Planning Measures to Measure the Plan What gets measured gets done! If Prevention and Appraisal Activities are not measured and reported, they will not be performed Measures for Success: % Use Cases Developed In Requirements Budgeted to Actual Time Spent in Requirements by Business and IT (assumes a reasonable budget) Budgeted to Actual Time Spent on Requirements Validation % of Defects found in Requirements, Design, Code, Test, Production % of Defects escaping to later phases of Development 75 75

76 Practice #6 Building a Winning Team Partnership Model Team Building Facilitation Negotiation 76 76

77 Partnership Model Business community as Users Business community as Customers Business community as Partners 77 77

78 Team Building Norming Storming Performing Forming Tuckman Team Model 78 78

79 Teams for Business Analysts Team Member Team Leader Team Coach Team Founder 79 79

80 Facilitation Benefits Provides a form of group interview. Increases business partner involvement. Builds consensus by surfacing inter-functional and inter-group issues early. Forms team identity - group stakeholders. Allows IT staff to work on resolving conflict without becoming part of the conflict itself

81 Facilitation Skills Ensure a fair and productive session Manage the pace and flow Draw in all participants draw out information Build consensus Reconcile conflicts 81 81

82 Negotiations for Success Communicate clearly Respect the other side(s) Recognize and define the problem Seek answers from a variety of sources Collaborate on a solution Be Reliable Preserve the relationship 82 82

83 Practice #7 Implement Excellence Pre-Implementation Planning Post Implementation Assessments 83 83

84 Implementation Planning: Pre- Implementation Pre-Implementation Planning Business impact of the implementation Geographic distribution of the implementation sites Time of year Size of the project Competitive strategy Regulatory requirements 84 84

85 Pre-Implementation Planning Implementation Scope and Strategies Big Bang Theory Pilots Incremental Roll Out Individual Installation 85 85

86 Pre-Implementation Planning Implementation Scope and Strategies Big Bang Theory Pilots Incremental Roll Out Individual Installation 86 86

87 Pre-Implementation Planning Schedule and Budget 87 87

88 Pre-Implementation Planning Training Assessment Train the Trainer Using Power Users Help Desk Operations 88 88

89 Pre-Implementation Planning Training Assessment Train the Trainer Using Power Users Help Desk Operations 89 89

90 Pre-Implementation Planning Training Assessment Train the Trainer Using Power Users Help Desk Operations 90 90

91 Pre-Implementation Planning Hardware and Software Deployment Pre-Implementation inventory Hardware ordering and Installation Software deployment 91 91

92 Pre-Implementation Planning Hardware and Software Deployment Pre-Implementation inventory Hardware ordering and Installation Software deployment 92 92

93 Pre-Implementation Planning: Implementation Decision Critical Success Factors pecific easurable results ssignable ealistic Ime oriented 93 93

94 Pre-Implementation Planning: Authorization Who approves the actual start of Implementation? 94 94

95 Post Implementation Assessments Project Plan Project Execution Process Capability 95 95

96 Post Implementation Assessments Project Plan Project Execution Process Capability 96 96

97 Post Implementation Assessments Project Plan Project Execution Process Capability 97 97

98 Post Implementation Assessments Project Plan Project Execution Process Capability 98 98

99 Seven Best Practices for Software Business Analysts Quality as Job 1 Understand Your Business Projects and Processes Managing Risk UAT as a Victory Lap Building a Winning Team Implement Excellence 99 99

100 Building A Business Analyst s Plan Of Action Rate each idea using the following factors: Strategic goal: Does the improvement objective support a strategic goal? Management issue: Does the improvement objective support a management issue? Attainability: Is the improvement objective attainable within a one to three month time frame? Effectiveness: Will the improvement result in a high level of effectiveness?

101 Building A Business Analyst s Plan Of Action Identify your 1-3 highest weighted improvement ideas. Enter and describe each of these objectives on a Tactical Work Plan form. The objectives should be documented to specifically describe what needs to be accomplished and how accomplishing it will support a strategic goal, or a management issue/concern

102 Building A Business Analyst s Plan Of Action Often plans are prepared without identifying and analyzing the barriers and obstacles that can contribute to failure. Complete the Barrier/Obstacles Worksheet to ensure that appropriate attention is given to planning for addressing and overcoming them

103 1. Identify stakeholder (by individual or function). 2. Describe their current level of support or resistance: Make it happen Help it happen Let it happen Stop it from happening Building A Business Analyst s Plan Of Action 3. Identify the reasons for their current stake. 4. Identify where they need to be to contribute to your success. 5. Identify how to address stakeholders to move them to desired stake. 6. Identify whether they re a resource or a target

104 Building A Business Analyst s Plan Of Action The tactical work plan is a step-by-step implementation approach. It should include: Tasks that identify WHAT needs to be done; these tasks should include pre-selling and should address obstacles, barriers, and stakeholders. Resources necessary to accomplish task, including manpower and materials. Timeframes required to accomplish tasks

105 Building A Business Analyst s Plan Of Action Demonstrated short-term success equates to measuring the results of an implemented strategy. Define expected results. Identify measurable benefits you wish to achieve. Each quality improvement objective may have several expected results. All must be documented. Describe how you plan to measure success. Define who will be responsible for measuring. State when the result should be realized

106

107

108

109