Chapter 2 – Analysing the Business Case Flashcards
What is a business case
• Business case refers to: - Reasons - Justifications ~ For a proposal • Should be: - Comprehensive - Easy to understand • Should: - Describe the project clearly - Provide the justification to proceed - Estimate the project’s financial impact • Systems development - Starts with : ~ Systems requests - Followed by: ~ Preliminary study ~ Feasibility study
Reasons for Systems Projects
• Systems request
- Asking for a new system
• Stronger control (security)
- Encryption
~ Encoding messages or information that only authorized parties can access it
- Biometric devices
• Improved service, better performance, reduced cost
Factors that affect systems project
• Internal Factors (inside the company) - Strategic plan - Top managers - User requests - IT department - Existing systems & data - Company Finances • External Factors (outside the company) - Government - Technology - Suppliers - Economy - Competitors - Customer
Project Management
If project approved, it can be: • Planned • Scheduled • Monitored • Controlled • Reported upon
Evaluations of Systems Requests (*)
• Systems request evaluated by:
- Most large companies use a system review committee to evaluate systems requests
- Many smaller companies rely on one person to evaluate system requests instead of a committee
- Goal:
~ Evaluate the requests
~ Set priorities
• Systems Requests Forms - Properly designed form streamlines: ~ Request process ~ Ensures consistency - Requires an immediate response (depending on the situation)
Overview of Feasibility (*)
• Operational Feasibility (Will it be easy to use and learn?)
- A proposed system will be used effectively after it has been developed - Will the system require training for users?
• Technical Feasibility (Maintenance/Support team/Does company have tech resources?) refers to: - Technical resources needed to: ~ Develop ~ Purchase ~ Install ~ Operate the system
• Economic Feasibility (Will benefits exceed costs? $)
- Total cost of ownership (TCO)
- Tangible benefits (if they use money)
~ Can be measured in dollars
~ Example: New scheduling system that reduces overtime
- Intangible benefits (if they don’t use money)
~ Cannot be measured in dollars
~ Example: User-friendly system that improves employee job satisfaction
~ Something good but cannot use $ to measure
• Schedule Feasibility (Can it be done in time?)
- Time factors
Evaluating Feasibility
• First step: - Identify - Weed out systems requests that are not feasible • If request is feasible: - May not be necessary • Feasibility analysis: - Ongoing task that must be performed ~ Throughout the systems development process
Setting priorities
Factors that affect priorities • Will the system: - Reduce costs? (Where? When? How? How much?) - Increase revenue for the company? - Result in: ~ More information? ~ Produce better results? ~ Measurable? - Serve: ~ Customer better? ~ Organization better? - Can be implemented in a reasonable time period? ~ How long will the result last? - Available resources? ~ Financial ~ Human ~ Technical - If possible, the analyst should: - Evaluate a proposed project based on tangible costs & benefits that represent actual/approximate dollar values
Discretionary projects
• Management has a choice in implement them
• Example:
- Creating a new report for a user
Nondiscretionary projects
• No choice exists
• Example:
- Adding a report required by law
Preliminary Investigation Overview (6 steps)
• Preliminary Investigation:
- Study the systems request and recommend a specific action
- Step 1: Understand the Problem or Opportunity
- Step 2: Define the Project Scope and Constraints
- Step 3: Perform Fact-Finding (get information)
- Step 4: Analyze Project Usability, Cost, Benefit and Schedule Data
- Step 5: Evaluate Feasibility
- Step 6: Present Results and Recommendations to Management
Step 1: Understand the Problem or Opportunity
• Investigation of causes & effects techniques:
- Fishbone diagram - Ishikawa diagram - Pareto chart
Step 2: Define the Project Scope and Constraints
• Project scope (do not be too general)
- Define:
~ Specific boundaries
~ Extent of the project
- Example:
~ Payroll is not being produced accurately – Too general
• Project creep (If the scope is not properly defined):
- Project could expand gradually without specific authorization
~ Unnecessary expenditure of time and resources
• Constraint (restrictions)
- Requirement/condition that the system must achieve
• Present vs future
- Now or later
• Internal vs external
- Inside or outside
• Mandatory versus external
- Must or want
Step 3: Perform Fact-Finding (get information)
• Analyze Organization Charts - Understand how the department functions - Identify individuals you might want to interview • Conduct interviews - Determine the people to interview (1) - Establish objectives (2) - Develop interview questions (3) - Prepare for the interview (4) - Conduct the interview (5) - Document the interview (6) - Evaluate the interview (7) • Review documentation - Look at any available documents (information) ~ To understand a certain system • Observe operations • Conduct a user survey
Step 4: Analyze Project Usability, Cost, Benefit and Schedule Data
• Before evaluating feasibility • What? How? Who? - Cost? - Conduct interview? - Information? - Sources? - Survey? - Time? - People?
