GMP Session 3&4

Project Management

Planning Phase Focus :

Why build this system? How to structure the project?

Primary Outputs System request with feasibility studyProject Plan

StepsIdentify opportunity Analyse feasibility Develop work plan Staff project Control and direct project

Analysis Phase

Focus: Who, What and Where and when for this system

Primary outputSystem proposal

Steps Develop analysis strategy Determine business requirementCreate use cases Model processes Model data

Design Phase

Focus: How will this system work?

Primary output: System Specification

Steps Design Physical system Design architecture Design Interface Design Databases and files

Implementation Phase

Focus: Delivery and support of completed System

Primary output: Installed System

StepsConstruct System Install System Maintain System Post Implementation

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.

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.

Project Sponsor

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.

System Request

Elements of system request

Project SponsorProject need Business requirement Business value Special issues and constraints

Too much paper Part 1Sponsor:

Document Manager.

Business Need: Increase efficiency in storing, updating, and retrieving information on

employee injury claims.

Business Requirements: Automated system which allows for electronic submission of reports via

a secure web site.

Business Value: Reduce response time for employee inquiries, increase effectiveness of

storing, updating, and retrieving employee injury claims.

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 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.

Feasibility Analysis

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 feasibilityEconomic feasibilityOrganizational 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 don’t 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 useProvides structure to inexperienced staffMilestones are well understoodSets requirements stabilityGood for management control (plan, staff, track)Works well when quality is more important than cost or schedule

Waterfall Deficiencies

All requirements must be known upfrontDeliverables created for each phase are considered frozen – inhibits flexibilityCan give a false impression of progressDoes not reflect problem-solving nature of software development – iterations of phasesIntegration is one big bang at the endLittle opportunity for customer to preview the system (until it may be too late)

When to use the Waterfall Model

Requirements are very well knownProduct definition is stableTechnology is understoodNew version of an existing productPorting 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 developmentEach deliverable must be testableProject management can track progress by milestonesEasy to use

V-Shaped Weaknesses

Does not easily handle concurrent eventsDoes not handle iterations or phasesDoes not easily handle dynamic changes in requirementsDoes not contain risk analysis activities

When to use the V-Shaped Model

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

System Prototyping

Prototyping ModelDevelopers build a prototype during the requirements phasePrototype is evaluated by end usersUsers give corrective feedback Developers further refine the prototypeWhen the user is satisfied, the prototype code is brought up to the standards needed for a final product.

Prototyping StrengthsCustomers can “see” the system requirements as they are being gatheredDevelopers learn from customers A more accurate end productUnexpected requirements accommodatedAllows for flexible design and developmentSteady, visible signs of progress producedInteraction with the prototype stimulates awareness of additional needed functionality

Prototyping Weaknesses

Tendency to abandon structured program development for “code-and-fix” developmentBad reputation for “quick-and-dirty” methodsOverall maintainability may be overlookedThe 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 modelDevelop user interfacesShort-lived demonstrations New, original developmentWith the analysis and design portions of object-oriented development.

Example of Throwaway Prototyping

Iterative Development

Iterative Model Strengths

Develop high-risk or major functions firstEach release delivers an operational product Customer can respond to each buildUses “divide and conquer” breakdown of tasksLowers initial delivery cost Initial product delivery is fasterCustomers get important functionality earlyRisk of changing requirements is reduced

Iterative Model Weaknesses

Requires good planning and designRequires early definition of a complete and fully functional system to allow for the definition of incrementsWell-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 timeA need to get basic functionality to the market earlyOn projects which have lengthy development schedulesOn a project with new technology

Agile SDLC’s

Speed up or bypass one or more life cycle phases Usually less formal and reduced scopeUsed for time-critical applicationsUsed in organizations that employ disciplined methods

Some Agile MethodsAdaptive 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 projectCommunication among teammates is done with codeLife 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 usersConstruction 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 StrengthsReduced cycle time and improved productivity with fewer people means lower costsTime-box approach mitigates cost and schedule riskCustomer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needsFocus moves from documentation to code (WYSIWYG).Uses modeling concepts to capture information about business, data, and processes.

RAD WeaknessesAccelerated development process must give quick responses to the userRisk of never achieving closure Hard to use with legacy systemsRequires a system that can be modularizedDevelopers and customers must be committed to rapid-fire activities in an abbreviated time frame.

When to use RAD

Reasonably well-known requirementsUser involved throughout the life cycleProject can be time-boxed Functionality delivered in incrementsHigh performance not requiredLow technical risks System can be modularized

Criteria for Selecting a Methodology

Important Factors to Consider

Clarity of User RequirementsFamiliarity with TechnologySystem ComplexitySystem ReliabilityShort Time SchedulesSchedule 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

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

Learning Objectives

Introduction

The As-Is system is the current system and may or may not be computerizedThe To-Be system is the new system that is based on updated requirementsThe 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 isn’t 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.

A statement of what the system must do A statement of characteristics the system must haveFocus is on business user needs during analysis phaseRequirements will change over time as project moves from analysis to design to implementation

What is a Requirement?

Functional RequirementsA process the system has to performInformation the system must contain

Nonfunctional RequirementsBehavioral properties the system must have

OperationalPerformanceSecurityCultural and political

Requirement Types

Functional vs. non-functional requirements

Functional: describes an interaction between the system and its environmentExamples:

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 solutionExamples:

Paychecks distributed no more than 4 hours after initial data are read.System limits access to senior managers.

fig_03_01

fig_03_02

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 characteristicsBrowse - enable user to look through itemsShop - enable user to select and purchase itemsComment - enable user to submit his/her comments on items and read other users' comments on itemsPersonalize - enable site to remember user's preferences based on previous use of the site and orders placedRegistries - enable user to participate in registry (e.g., wedding, baby); enable users to search registriesWish 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 browserPerformance - the system should be available 24/7/365.Security - the system enables registered customers to review their own accountsCultural - the system exists in versions tailored to global users, e.g., French, Japanese, German, etc.

Requirements definition reportText document listing requirements in outline formPriorities may be included

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

Documenting Requirements

fig_03_03

Determining Requirements

Participation by business users is essentialThree 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” systemIdentify improvement opportunitiesDevelop the “To-Be” system conceptTechniques vary in amount of change

BPA – small changeBPI – moderate changeBPR – significant change

Additional information gathering techniques are needed as well

Business Process Automation

Goal:

Efficiency for users

Identifying Improvements in As-Is Systems

Problem AnalysisAsk users to identify problems and solutionsImprovements tend to be small and incrementalRarely finds improvements with significant business value

Root Cause AnalysisChallenge assumptions about why problem existsTrace symptoms to their causes to discover the “real” problem

Root Cause Analysis Example

Business Process Improvement

Goal:

Efficiency and

effectivenessfor users

Duration Analysis

Calculate time needed for each process stepCalculate time needed for overall processCompare the two – a large difference indicates a badly fragmented processPotential solutions:

Process integration – change the process to use fewer people, each with broader responsibilitiesParallelization – change the process so that individual step are performed simultaneously

Activity-Based Costing

Calculate cost of each process stepConsider both direct and indirect costsIdentify most costly steps and focus improvement efforts on them

Benchmarking

Studying how other organizations perform the same business processInformal benchmarkingCommon for customer-

facing processesInteract with other

business’ processes as if you are a customer

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.

Your Turn: IBM Credit

Business Process Reengineering (BPR)

Goal:

Radical redesign of business

processes

Outcome Analysis

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

Technology Analysis

Analysts list important and interesting technologiesManagers list important and interesting technologiesThe 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 eliminatedUse “force-fit” to test all possibilities

Comparing Analysis Techniques

Potential business valueProject costBreadth of analysisRisk

Project Characteristics

Requirements Gathering Techniques

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

Learning Objectives

Problem analysis and benchmarking would be feasible strategies to employ in this situation. This is a problem with a rather narrow scope…the 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 system’s requirements.

Mini Case 1

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

Practical tips for requirement gathering techniques

Interviews QuestionnaireJADDocument Analysis Observation

Requirement Gathering Techniques

Interviews -- Five Basic Steps

Selecting intervieweesDesigning interview questionsPreparing for the interviewConducting the interviewPost-interview follow-up

Selecting Interviewees

Based on information neededOften good to get different perspectives

ManagersUsersIdeally, all key stakeholders

Types of Questions

Types of Questions Examples

Closed-Ended Questions * 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?

Probing Questions * Why?* Can you give me an example?* Can you explain that in a bit

more detail?

Designing Interview Questions

Unstructured interviewBroad, roughly defined information

Structured interviewMore specific information

Questioning Strategies

Interview Preparation Steps

Prepare general interview planList of questionAnticipated answers and follow-ups

Confirm areas of knowledgeSet priorities in case of time shortagePrepare the interviewee

ScheduleInform reason for interviewInform areas of discussion

Conducting the Interview

Appear professional and unbiasedRecord all informationCheck on organizational policy regarding tape recordingBe sure you understand all issues and termsSeparate facts from opinionsGive interviewee time to ask questionsBe sure to thank the intervieweeEnd on time

Conducting the InterviewPractical Tips

Don’t worry, be happyPay attentionSummarize key pointsBe concise Be honestWatch body language

Post-Interview Follow-Up

Prepare interview notesPrepare interview reportLook 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 togetherMay reduce scope creep by 50%Avoids requirements being too specific or too vague

Joint Application Design (JAD) Important Roles

Facilitatorsets the meeting agenda and guides the discussion

Scribeassist the facilitator by recording notes, making copies, etc.

Project team, users, and management

Joint Application Design (JAD) Setting

U-Shaped seatingAway from distractionsWhiteboard/flip chartPrototyping toolse-JAD

JAD Meeting Room

JPEG Figure 5-5 Goes Here

The JAD Session

Tend to last 5 to 10 days over a three week periodPrepare questions as with interviewsFormal agenda and groundrulesFacilitator activities

Keep session on trackHelp with technical terms and jargonRecord group inputHelp resolve issues

Post-session follow-up

Post JAD Follow-up

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

Managing Problems in JAD Sessions

Reducing dominationEncouraging non-contributorsSide discussionsAgenda merry-go-roundViolent agreementUnresolved conflictTrue conflictUse humor

Questionnaires

A set of written questions, often sent to a large number of peopleMay be paper-based or electronicSelect participants using samples of the populationDesign the questions for clarity and ease of analysisAdminister the questionnaire and take steps to get a good response rateQuestionnaire follow-up report

Questionnaire Steps

Selecting participantsUsing samples of the population

Designing the questionnaireCareful question selection

Administering the questionnaireWorking to get good response rate

Questionnaire follow-upSend 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 systemForms, reports, policy manuals, organization charts describe the formal systemLook for the informal system in user additions to forms/report and unused form/report elementsUser changes to existing forms/reports or non-use of existing forms/reports suggest the system needs modification

Document Analysis

Provides clues about existing “as-is” systemTypical documents

FormsReportsPolicy manuals

Look for user additions to formsLook for unused form elements

Observation

Watch processes being performedUsers/managers often don’t accurately recall everything they doChecks validity of information gathered other waysBe aware that behaviors change when people are watchedBe unobtrusiveIdentify peak and lull periods

Observation

Users/managers often don’t remember everything they doChecks validity of information gathered other waysBehaviors change when people are watchedCareful not to ignore periodic activities

Weekly … Monthly … Annual

Selecting the Appropriate Techniques