Project Management

Planning Phase
Focus :
Why build this system? How to structure the project?
System request with feasibility study Project Plan Identify opportunity Analyse feasibility Develop work plan Staff project Control and direct project

Primary Outputs Steps

Analysis Phase
Focus: Primary output Steps
Who, What and Where and when for this system
System proposal Develop analysis strategy Determine business requirement Create use cases Model processes Model data

Design Phase
Focus: Primary output:
How will this system work?
System Specification Design Physical system Design architecture Design Interface Design Databases and files

Steps

Implementation Phase
Focus: Primary output:
Delivery and support of completed System
Installed System Construct System Install System Maintain System Post Implementation

Steps

Project Identification and Initiation

A project is identified when someone in the organization identifies a business need to build a system. A need may surface when an organization identifies unique and competitive ways of using IT. Emerging technologies. Both IT people and business people should work together to find way for technology to support business needs. The project sponsor is someone who recognizes the strong business need for a system.

Project Sponsor This individual will work throughout the SDLC to

make sure that the project is moving in the right direction from the perspective of the business. Serves as the primary point of contact for the system. Size and scope of the project is determined by the kind of sponsor that is needed.

The project sponsor also should have an idea of the business value to be gained from the system, in both tangible and intangible ways. Tangible value can be quantified and measured easily (reduction in operating costs). An intangible value is based on the belief that the system is important; however, benefits are hard to measure.

System Request
The document that describes the business reasons for building a system and the value that system is expected to provide. The project sponsor usually completes this form as part of a formal system selection process within the organization.

Elements of system request

Project Sponsor Project need Business requirement Business value Special issues and constraints

Too much paper Part 1

Sponsor: Business Need:
Document Manager.
Increase efficiency in storing, updating, and retrieving information on employee injury claims. Automated system which allows for electronic submission of reports via a secure web site. Reduce response time for employee inquiries, increase effectiveness of storing, updating, and retrieving employee injury claims.

Business Requirements: Business Value: Special Issues:

Must have someone who understands how to create and maintain a secure web site. Must have resources to migrate paper files to data storage. Must work within Govt guidelines to ensure that medical documents are treated according to regulations.

The completed system request is submitted to the approval committee for consideration. The committee reviews the system request and makes an initial determination, based on the information provided, of whether to investigate the proposed project or not. If so, the next step is to conduct a feasibility analysis.

Feasibility Analysis

Feasibility analysis guides the organization in determining whether to proceed with a project. Feasibility analysis also identifies the important risks associated with the project that must be addressed if the project is approved.

As with the system request, each organization has its own process and format for the feasibility analysis. Most include techniques to assess three areas:
Technical feasibility Economic feasibility Organizational feasibility

The results of these techniques are combined into a feasibility study deliverable that is given to the approval committee at the end of the project initiation.

Too much paper Part 2

Issues arising from digital signatures and electronic documents typically focus on establishing validity for signatures and originators. As these issues can be overcome using certificates and encryption, they dont necessarily affect the project feasibility. However, they do need to be addressed. Show the clerks how their jobs might be easier to accomplish by presenting them with a projection of how the new system will allow them to reduce the response time to customers and to allow for more efficient updating of the files.

Consider the Amazon.com Web site. The management of the company decided to extend their Web-based system to include products other than books. (e.g., wine, specialty gifts). How would you have assessed the feasibility of the venture when the idea first came up? How "risky" would you have considered the project that implemented this idea? Why?

Technical Feasibility
Not a concern since the base system we use for selling books is easily adaptable to other products.

Economic Feasibility
Would need to carefully analyze sales projections for the various proposed product lines. Should be able to determine costs associated with this fairly accurately

Organizational Feasibility
They are the pioneers in web-based retail; broadening their product line beyond books makes good strategic sense.

Gartner Quadrant for Portfolio Management Software Solutions in the IT-Sector The Gartner Group is a large US-based consulting organization whose focus is primarily the IT-field. The Gartner Group periodically reviews the Project Portfolio Management software solutions which are available on the market and ranks these in its acclaimed Magic Quadrant for IT Project and Portfolio Management.

Project Classification

Project Selection
Option 1: Costs: expenses for writing ad hoc reporting programs, expenses for maintaining ad hoc reporting programs, expenses associated with maintaining staff with CICS expertise Benefits: employees already understand the new system, shorter short-term costs, no employees would be replaced by automated system Risks: Continued low performance of premiums to claim payment ratios, possible loss of data integrity, no processes available for auditing performance, possible law suits associated with low premium to claim payment ratio

 Option 2: Costs: expenses for writing a dynamic retrieval program, expenses for maintaining a dynamic retrieval program, expenses associated with training staff with new functionality Benefits: data would be more accurate, users would be able to view required data, less costly than developing a new system Risks: difficult to develop processes for auditing performance, difficult for the program to provide a relationship among the data, more costly than Option 1

 Option 3: Costs: expenses for software, expenses for outside consultants, expenses associated with employees taking time away from work to learn new program Benefits: auditable processes, reliability of data, relational capability among data stores Risks: Possible compromise of proprietary information through consultants, costlier than other two options, time taken for development and implementation

Project Methodology Options

Waterfall Development Parallel Development V-model (variation of the Waterfall Development Prototype Rapid Application Development (RAD) Iterative Development Agile Development

Waterfall Development

Waterfall Strengths
Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

Waterfall Deficiencies
All requirements must be known upfront Deliverables created for each phase are considered frozen inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)

When to use the Waterfall Model

Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.

Parallel Development

V-model

V-Shaped Strengths
Emphasize planning for verification and validation of the product in early stages of product development Each deliverable must be testable Project management can track progress by milestones Easy to use

V-Shaped Weaknesses
Does not easily handle concurrent events Does not handle iterations or phases Does not easily handle dynamic changes in requirements Does not contain risk analysis activities

When to use the V-Shaped Model

Excellent choice for systems requiring high reliability hospital patient control applications All requirements are known up-front When it can be modified to handle changing requirements beyond analysis phase Solution and technology are known

System Prototyping

Prototyping Model
Developers build a prototype during the requirements phase Prototype is evaluated by end users Users give corrective feedback Developers further refine the prototype When the user is satisfied, the prototype code is brought up to the standards needed for a final product.

Prototyping Strengths
Customers can see the system requirements as they are being gathered Developers learn from customers A more accurate end product Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality

Prototyping Weaknesses
Tendency to abandon structured program development for code-and-fix development Bad reputation for quick-and-dirty methods Overall maintainability may be overlooked The customer may want the prototype delivered. Process may continue forever (scope creep)

When to use Prototyping

Requirements are unstable or have to be clarified As the requirements clarification stage of a waterfall model Develop user interfaces Short-lived demonstrations New, original development With the analysis and design portions of objectoriented development.

Example of Throwaway Prototyping

Iterative Development

Iterative Model Strengths

Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses divide and conquer breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced

Iterative Model Weaknesses

Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower

When to use the Iterative Model

Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology

Agile SDLCs
Speed up or bypass one or more life cycle phases Usually less formal and reduced scope Used for time-critical applications Used in organizations that employ disciplined methods

Some Agile Methods

Adaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Clear Dynamic Software Development Method (DSDM) Rapid Application Development (RAD) Scrum Extreme Programming (XP) Rational Unify Process (RUP)

Extreme Programming - XP
For small-to-medium-sized teams developing software with vague or rapidly changing requirements Coding is the key activity throughout a software project Communication among teammates is done with code Life cycle and behavior of complex objects defined in test cases again in code

Example of Extreme Programming

Rapid Application Model (RAD)

Requirements planning phase (a workshop utilizing structured discussion of business problems) User description phase automated tools capture information from users Construction phase productivity tools, such as code generators, screen generators, etc. inside a time-box. (Do until done) Cutover phase -- installation of the system, user acceptance testing and user training

RAD Strengths
Reduced cycle time and improved productivity with fewer people means lower costs Time-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code (WYSIWYG). Uses modeling concepts to capture information about business, data, and processes.

RAD Weaknesses
Accelerated development process must give quick responses to the user Risk of never achieving closure Hard to use with legacy systems Requires a system that can be modularized Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

When to use RAD

Reasonably well-known requirements User involved throughout the life cycle Project can be time-boxed Functionality delivered in increments High performance not required Low technical risks System can be modularized

Criteria for Selecting a Methodology

Important Factors to Consider

Clarity of User Requirements Familiarity with Technology System Complexity System Reliability Short Time Schedules Schedule Visibility

yt-Selecting a Methodology
Throwaway prototyping would be a good choice for this scenario for a number of reasons. First, this is a brand new idea, so there may be some ambiguity or confusion as to the functionality of the system. Second, there are technical issues associated with integrating existing hardware and software due to the diversity at different locations around the world. Third, the time frame to delivery is one year. The time frame would allow for an in-depth analysis to gather information and develop ideas for the system before the design phase. Once the initial requirements were documented, a series of design prototypes can be created, distributed and tested to determine whether issues dealing with functionality or technical problems have been addressed. Once the issues have been resolved, the project can move into design and implementation.

SESSION 4 Requirements Analysis

Learning Objectives
Become familiar with analysis phase of SDLC Understand how to create a requirements definition Become familiar with requirement analysis techniques Understand when to use and gather requirement using various requirement analysis technique Understand when to use each requirement gathering techniques

Introduction

The As-Is system is the current system and may or may not be computerized The To-Be system is the new system that is based on updated requirements The System Proposal is the key deliverable from the Analysis Phase

Introduction
The goal of the analysis phase is to truly understand the requirements of the new system and develop a system that addresses them -- or decide a new system isnt needed. The System Proposal is presented to the approval committee via a system walk-through. Systems analysis incorporates initial systems design. Requirements determination is the single most critical step of the entire SDLC.

What is a Requirement?
A statement of what the system must do A statement of characteristics the system must have Focus is on business user needs during analysis phase Requirements will change over time as project moves from analysis to design to implementation

Requirement Types
Functional Requirements
A process the system has to perform Information the system must contain

Nonfunctional Requirements
Behavioral properties the system must have
Operational Performance Security Cultural and political

Functional vs. non-functional requirements

Functional: describes an interaction between the system and its environment Examples:
System shall communicate with external system X. What conditions must be met for a message to be sent

Non-functional: describes a restriction or constraint that limits our choices for constructing a solution Examples:
Paychecks distributed no more than 4 hours after initial data are read. System limits access to senior managers.

Your Turn: Identifying requirements

Functional business requirements: 2, 4, 6, 8. Nonfunctional business requirements: 1, 3, 5, 7, 9, 10.

Review the Amazon.com Web site. Develop the requirements definition for the site. Create a list of functional business requirements that the system meets. What different kinds of nonfunctional business requirements does the system meet? Provide examples of each kind.

Examples of Functional Requirements include: Search - enable user to find item(s) based on variety of item characteristics Browse - enable user to look through items Shop - enable user to select and purchase items Comment - enable user to submit his/her comments on items and read other users' comments on items Personalize - enable site to remember user's preferences based on previous use of the site and orders placed Registries - enable user to participate in registry (e.g., wedding, baby); enable users to search registries Wish Lists - enable user to create and maintain a wish list of desired items; enable users to search a person's wish list for gift ideas.

Examples of Non-functional Requirements include:

Operational - the system should work on any web browser Performance - the system should be available 24/7/365. Security - the system enables registered customers to review their own accounts Cultural - the system exists in versions tailored to global users, e.g., French, Japanese, German, etc.

Documenting Requirements Requirements definition report

Text document listing requirements in outline form Priorities may be included

Key purpose is to define the project scope: what is and is not to be included.

Determining Requirements

Participation by business users is essential Three techniques help users discover their needs for the new system:
Business Process Automation (BPA) Business Process Improvement (BPI) Business Process Reengineering (BPR)

Basic Process of Analysis (Determining Requirements)

Understand the As-Is system Identify improvement opportunities Develop the To-Be system concept Techniques vary in amount of change
BPA small change BPI moderate change BPR significant change

Additional information gathering techniques are needed as well

Business Process Automation

Goal:

Efficiency for users

Identifying Improvements in As-Is Systems

Problem Analysis
Ask users to identify problems and solutions Improvements tend to be small and incremental Rarely finds improvements with significant business value Challenge assumptions about why problem exists Trace symptoms to their causes to discover the real problem

Root Cause Analysis

Root Cause Analysis Example

Business Process Improvement

Goal:
Efficiency and effectiveness for users

Duration Analysis
Calculate time needed for each process step Calculate time needed for overall process Compare the two a large difference indicates a badly fragmented process Potential solutions:
Process integration change the process to use fewer people, each with broader responsibilities Parallelization change the process so that individual step are performed simultaneously

Activity-Based Costing

Calculate cost of each process step Consider both direct and indirect costs Identify most costly steps and focus improvement efforts on them

Benchmarking

Studying how other organizations perform the same business process Informal benchmarking
Common for customerfacing processes Interact with other business processes as if you are a customer

Your Turn: IBM Credit

Conducting a duration analysis would illustrate problem areas in this process, and a process integration analysis would certainly help in reducing the number of steps required to complete the process. One of the major problems in this scenario is that too many departments are involved. reducing the number of departments, or the number of steps required, which would decrease the time involved, would be right on track.

Business Process Reengineering (BPR)

Goal: Radical redesign of business processes

Outcome Analysis

Consider desirable outcomes from customers perspective Consider what the organization could enable the customer to do

Technology Analysis

Analysts list important and interesting technologies Managers list important and interesting technologies The group identifies how each might be applied to the business and how the business might benefit

Activity Elimination

Identify what would happen if each organizational activity were eliminated Use force-fit to test all possibilities

Comparing Analysis Techniques Potential business value Project cost Breadth of analysis Risk

Project Characteristics

Requirements Gathering Techniques

Learning Objectives
Understand when to use and gather requirement using various requirement analysis technique Understand when to use each requirement gathering techniques

Mini Case 1
Problem analysis and benchmarking would be feasible strategies to employ in this situation. This is a problem with a rather narrow scopethe As-Is system needs to be improved, but there is no broadening of the information that needs to be integrated into this system. Problem analysis would permit the analyst to identify potential solutions that the users can identify, then identify the problems those solutions are addressing, and investigate the root causes of the problems. Analysts could also employ informal benchmarking, and investigate systems used by other similar organizations for ideas for this systems requirements.

Practical tips for requirement gathering techniques

Recognize the important side effects of the requirement gathering process Carefully determine who is included in the requirement gathering process Respect the time constraint that you are asking the participants to make.

Requirement Gathering Techniques

Interviews Questionnaire JAD Document Analysis Observation

Interviews -- Five Basic Steps

Selecting interviewees Designing interview questions Preparing for the interview Conducting the interview Post-interview follow-up

Selecting Interviewees
Based on information needed Often good to get different perspectives
Managers Users Ideally, all key stakeholders

Types of Questions
Types of Questions Closed-Ended Questions * Examples How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide?

Open-Ended Questions

* * *

What do you think about the current system? What are some of the problems you face on a daily basis? How do you decide what types of marketing campaign to run? Why? Can you give me an example? Can you explain that in a bit more detail?

Probing Questions

* * *

Designing Interview Questions

Unstructured interview
Broad, roughly defined information

Structured interview
More specific information

Questioning Strategies

Interview Preparation Steps

Prepare general interview plan List of question Anticipated answers and follow-ups Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee Schedule Inform reason for interview Inform areas of discussion

Conducting the Interview

Appear professional and unbiased Record all information Check on organizational policy regarding tape recording Be sure you understand all issues and terms Separate facts from opinions Give interviewee time to ask questions Be sure to thank the interviewee End on time

Conducting the Interview Practical Tips

Dont worry, be happy Pay attention Summarize key points Be concise Be honest Watch body language

Post-Interview Follow-Up
Prepare interview notes Prepare interview report Look for gaps and new questions

Interview Report
INTERVIEW REPORT

Interview notes approved by: ____________

Person interviewed ______________ Interviewer _______________ Date _______________ Primary Purpose: Summary of Interview: Open Items: Detailed Notes:

JAD Key Ideas

Allows project managers, users, and developers to work together May reduce scope creep by 50% Avoids requirements being too specific or too vague

Joint Application Design (JAD) Important Roles

Facilitator
sets the meeting agenda and guides the discussion

Scribe
assist the facilitator by recording notes, making copies, etc.

Project team, users, and management

Joint Application Design (JAD) Setting

U-Shaped seating Away from distractions Whiteboard/flip chart Prototyping tools e-JAD

JAD Meeting Room

JPEG Figure 5-5 Goes Here

The JAD Session

Tend to last 5 to 10 days over a three week period Prepare questions as with interviews Formal agenda and groundrules Facilitator activities Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up

Post JAD Follow-up

Postsession report is prepared and circulated among session attendees The report should be completed approximately a week to two after the JAD session

Managing Problems in JAD Sessions

Reducing domination Encouraging non-contributors Side discussions Agenda merry-go-round Violent agreement Unresolved conflict True conflict Use humor

Questionnaires
A set of written questions, often sent to a large number of people May be paper-based or electronic Select participants using samples of the population Design the questions for clarity and ease of analysis Administer the questionnaire and take steps to get a good response rate Questionnaire follow-up report

Questionnaire Steps
Selecting participants Using samples of the population Designing the questionnaire Careful question selection Administering the questionnaire Working to get good response rate Questionnaire follow-up Send results to participants

Good Questionaire Design

Begin with nonthreatening and interesting

questions. Group items into logically coherent sections. Do not put important items at the very end of the questionnaire. Do not crowd a page with too many items. Avoid abbreviations. Avoid biased or suggestive items or terms. Number questions to avoid confusion. Pretest the questionnaire to identify confusing questions. Provide anonymity to respondents.

Document Analysis
Study of existing material describing the current system Forms, reports, policy manuals, organization charts describe the formal system Look for the informal system in user additions to forms/report and unused form/report elements User changes to existing forms/reports or nonuse of existing forms/reports suggest the system needs modification

Document Analysis
Provides clues about existing as-is system Typical documents Forms Reports Policy manuals Look for user additions to forms Look for unused form elements

Observation
Watch processes being performed Users/managers often dont accurately recall everything they do Checks validity of information gathered other ways Be aware that behaviors change when people are watched Be unobtrusive Identify peak and lull periods

Observation
Users/managers often dont remember everything they do Checks validity of information gathered other ways Behaviors change when people are watched Careful not to ignore periodic activities Weekly Monthly Annual

Selecting the Appropriate Techniques