Project Management

It is a specialized branch of management capable of differentiation from others based on a variety of factors which includes the organization structure, the process of planning and control, human relation

Characteristics of Project
Objectives Life cycle Definite time limit Uniqueness Team work Complexity Sub-contracting Risk & Uncertainity

Attributes of good Project manager

Planning & organizational skills Personal Mgmt skills Communication skills Change orientation Ability to solve problems in totality High energy levels Ambition for achievement Ability to take suggestion

Search for Business Idea Concepts of Project Project Identification Project Formulation Project Analysis & Risks

Project Planning
Project Design & Network Analysis Project Report

Project Appraisal
Location of Enterprise

Phases of a Project Mgmt

Project Identification
Performance of existing industries Availability of raw material Availability of skilled labor Import / export statistics Price trend Data from various sources Research laboratories Consumption abroad Plan outlays & govt. guidelines Analysis of economic and social trends Reviving sick units

Project Formulation
Pre Feasibility study Functional studies- mkt study , raw material , project location, plant size, equipment selection Feasibility study
Technical Economic Commercial financial

Detailed Project Analysis (DPR)

Detailed Project Analysis (DPR)

It is a report to formally communicate the project promoters decision of venturing a new project to financial institutions for their perusal and to government departments for getting their approvals
General info Background and experience of project promoters Details of proposed project Schedule of implementation Project cost Means of financing project Working capital requirements Marketing and selling arrangements Profitability and cash flow estimates Mode of repayment of term loan Govt approvals Collateral security

Feasibility Report
Market Analysis
Consumption trends in the past and present consumption level. Past and present supply position. Production possibilities and constraints. Imports and exports Structure of competition Cost structure Elasticity of demand Consumer behavior Distribution channels and marketing policies Administrative, technical and legal constraints

Technical Analysis
Preliminary tests and studies Availability of raw materials Selected scale of operation is optimal Production process chosen is suitable Machinery is appropriate Supplementary engineering work to be provided Proposed layout of site and bldg Work schedules to be realistically drawn Appropriate technology

Financial Analysis
Investment outlay and cost of project Means of financing Cost of capital Projected profitability Break even point Cash flows of the project Investment worthwhileness Projected financial position Level of risk

Social Profitability Analysis (Economic Analysis)

Economic cost and benefit of project Impact of project on distribution of income in society Impact of project on the level of savings and investment in the society Contribution towards self-sufficiency, employment and social order

Ecological Analysis
Environmental damage Restoration measures

Criteria for selecting a particular Project

Investment Size Location Technology Equipment Marketing

Importance of Project Identification

Economic Development Employment and Income generation Substantial Financial Outlays Basic Infrastructure and Environment

Establishing the Project

Initiating Planning Organizing Executing Directing and Controlling

Chapter 2: Project Initiation, Project Management & Requirements Determination

Objectives
Understand the importance of linking the information system to business needs. Be able to create a system request. Understand how to assess technical, economic, and organizational feasibility. Be able to perform a feasibility analysis. Understand how projects are selected in some organizations.

Successful Projects
Cost
At project completion, no more money has been spent than was originally allocated

Schedule
The project is delivered no later than the original delivery date

Performance
When delivered, the project has all features and functionality that were originally required of it

Why Should We Care?

Would you buy a car that only had a 28% chance of driving off the lot with no problems?

Recent Significant IT Failures

Company Year Outcome

Hudson Bay (Canada)

UK Inland Revenue

2005
2004/ 5

Inventory system problems lead to $33.3 million loss.

$3.45 billion tax-credit overpayment caused by software errors. Enterprise resource planning (ERP) system cancelled after $54.5 million spent. Purchasing system abandoned after deployment costing approximately $400 M ERP system problems contribute to $160 million loss. Customer relations management system upgrade problems lead to $100M loss

Avis Europe PLC (UK) 2004

Ford Motor Co.

2004

Hewlett-Packard Co. AT&T Wireless

2004 2004

PROJECT IDENTIFICATION

Project Identification and Initiation

Projects are driven by business needs
Identified by business people Identified by IT people (better yet) identified jointly by business and IT

The project sponsor believes in the system and wants to see it succeed
Normally this is a business person Should have the authority to move it forward

Business Value
Tangible Value
Can be quantified and measured easily Example: 2 percent reduction in operating costs

Intangible Value
Results from an intuitive belief that the system provides important, but hard-to-measure, benefits to the organization Example: improved customer service

Elements of a System Request

Project sponsor
Primary point of contact for the project

Business need
Reason prompting the project

Business requirements
Business capabilities the system will need to have

Business value
Benefits the organization can expect from the project

Special issues
Anything else that should be considered

FEASIBILITY ANALYSIS

Feasibility Analysis
Guides the organization in determining whether to proceed with a project Identifies the projects risks that must be addressed if the project is approved Mayor components:
Technical feasibility Economic feasibility Organizational feasibility

Technical Feasibility
Familiarity with application
Less familiarity generates more risk

Familiarity with technology

Less familiarity generates more risk

Project size
Large projects have more risk

Compatibility
Difficult integration increases the risk

Can we build it?

Economic Feasibility
Development costs Annual operating costs Annual benefits (cost savings and revenues) Intangible costs and benefits

Should we build it?

Cost-Benefit Analysis

Cost-Benefit Analysis

Break-Even Point

Organizational Feasibility
Stakeholders
Project champion(s) Senior management Users Others

Is the project strategically aligned with the business? If we build it, will they come?

PROJECT SELECTION

Project Selection
Project portfolio management
A process that optimizes project selection and sequencing in order to best support business goals Business goals are expressed in terms of
Quantitative economic measures Business strategy goals IT strategy goals

Once selected, projects enter the project management process

How Not to Select a Project

First in, first out Political clout of project inventor Squeaky wheel getting the grease Any other method that does not involve a deliberate course of action analysis
A recent analysis found that between 2% and 15% of projects taken on by IT departments are not strategic to the business.

Review
Project Initiation Feasibility Analysis Project Selection

Objectives
Become familiar with estimation. Be able to create a project workplan. Understand why project teams use timeboxing. Become familiar with how to staff a project. Understand how computer-aided software engineering, standards, and documentation improve the efficiency of a project. Understand how to reduce risk on a project.

Project Management
The discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives
Cost Schedule Performance

IDENTIFYING PROJECT SIZE

Cost Schedule Performance Tradeoffs

Cost
Project management involves balancing trade-offs among the three key project parameters

Project

Schedule

Performance

Estimating Project Timeframes

Function Point Approach

Estimate System Size
(function points and lines of code)

Estimate Effort Required

(person-months)

Estimate Time Required

(months)

CREATING AND MANAGING THE WORKPLAN

Developing Work Plans

A work plan, is a dynamic schedule that records and keeps track of all tasks to be accomplished over the course of the project Created after a project manager has a general idea of the projects size and rough schedule The work plan is usually the main item in a project management software application

Sample Task
Task name: Start date: Completion date: Person assigned to the task: Deliverable(s): Completion status: Priority: Resources needed: Estimated time: Actual time: Perform economic feasibility Jan 5, 2010 Jan 19, 2010 Mary Smith (project sponsor) Cost-benefit analysis Complete High Spreadsheet software 16 hours 14.5 hours

Identifying Tasks
Top-down approach
Identify highest level tasks Break them into increasingly smaller units

Methodology
Using standard list of tasks

Work Breakdown Structure

Gantt Chart

Pert Chart
Used to communicate task dependencies Allows easier visualization of tasks on a critical path

Scope Management
Scope creep happens when new requirements are added to the project after the original project scope was defined and frozen.

Timeboxing Steps
1. Set the date for system delivery 2. Prioritize the functionality that needs to be included in the system 3. Build the core of the system (the functionality ranked as most important) 4. Postpone functionality that cannot be provided within the time frame 5. Deliver the system with core functionality 6. Repeat steps 3 through 5 to add refinements and enhancements

STAFFING THE PROJECT

Staffing the Project

Determine average number of people needed
Divide total person-months of effort by the optimal schedule Adding more people will not reduce schedule

Create a staffing plan

Roles required for the project Reporting structure

Reporting Structures
Project Manager

Functional Lead

Technical Lead

Analyst

Analyst

Programmer

Programmer

Motivation
Use monetary rewards cautiously Use intrinsic rewards
Recognition Achievement The work itself Responsibility Advancement Chance to learn new skills

Motivational Donts
Assign unrealistic deadlines Ignore good efforts Create a low-quality product Give everyone on the project a raise Make an important decision without the teams input Maintain poor working conditions

Conflict Avoidance Strategies

Clearly define roles and project plans Make sure the team understands how the project is important to the organization Develop detailed operating procedures and communicate these to the team members Develop a project charter Develop schedule commitments ahead of time Forecast other priorities and their possible impact on project

COORDINATING PROJECT ACTIVITIES

CASE Tools
Computer-Aided Software Engineering (CASE) tools automate some or all of the development process Not a silver bullet, but advantages include:
Reduced maintenance costs Improve software quality Enforce discipline Some project teams even use CASE to assess the magnitude of changes to the project

Standards
Types of Standards Documentation standards Coding standards Example The date and project name should appear as a header on all documentation. All modules of code should include a header that lists the programmer, last date of update, and a short description of the purpose of the code. Report to project update meeting on Fridays at 3:30 PM. All changes to a requirements document must be approved by the project manager. Name of program to be created Description of the programs purpose

Procedural standards

Specification requirement standards

User interface design standards

The tab order of the screen will move from top left to bottom right. Accelerator keys will be provided for all updatable fields.

Documentation
Good documentation happens up front
Documentation that occurs only at the tail end of a project/phase is not very useful

Project binder(s) are best practices containing

All internal communications (e.g. minutes from status meetings) Written standards Letters to and from the business users Deliverables from each task

Managing Risk

Summary
Project Management Identifying Project Size Creating And Managing the Workplan Staffing the Project Coordinating Project Activities

Chapter 4: Requirements Determination

Objectives
Understand how to create a requirements definition. Become familiar with requirements analysis techniques. Understand when to use each requirements analysis technique. Understand how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation. Understand when to use each requirementsgathering technique.

The SDLC and Requirements

The SDLC transforms the existing (as is) system into the proposed (to be) system Requirements determination step is the single most critical step of the entire SDLC
Studies show that more than half of all system failures are due to problems with requirements

REQUIREMENTS DETERMINATION

Defining a Requirement
A statement of what the system must do or what characteristic it must have During analysis, requirements are written from the perspective of the businessperson Two kinds of requirements:
Functional Nonfunctional

Nonfunctional Requirements
Requirement type Operational Example The system should be able to fit in a pocket or purse The system should be able to integrate with the existing inventory system. Any interaction between the user and the system should not exceed 2 seconds. The system should receive updated inventory information every 15 minutes. Only direct managers can see personnel records of staff Customers can see their order history only during business hours. The system should be able to distinguish between United States and European currency The system shall comply with insurance industry standards.

Performance

Security

Cultural & Political

Requirements Definition Report

Correct Unambiguous Complete Consistent Verifiable Modifiable Traceable Ranked for importance

A Bad Requirement
Initial Specification: Software will not be loaded from unknown sources onto the system without first having the software tested and approved. Critique: Ambiguous if the software is tested and approved, can it be loaded from unknown sources? (not) Testable it is stated as a negative requirement making it difficult to verify. (not) Traceable a unique identifier is missing.

Re-specification: 3.4.5.2 Software shall be loaded onto the operational system only after it has been tested and approved.

Determining Requirements
Requirements are best determined by systems analysts and business people together Techniques available to the systems analyst:
Interviews Questionnaires Observation Joint application development (JAD) Document analysis

REQUIREMENTS ANALYSIS STRATEGIES

Requirements Analysis Strategies

The basic process of analysis is divided into:
1. Understanding the as-is system 2. Identifying improvements 3. Developing requirements for the to-be system

There are 3 requirements analysis strategies

1. Business process automation 2. Business process improvement

Business Process Automation

BPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the work Low risk, but low payoff Planners in BPA projects invest significant time in understanding the as-is system using:
Problem analysis Root cause analysis

Problem Analysis
Users and managers identify problems with the as-is system and describe how to solve them in the to-be system Tends to solve problems rather than capitalize on opportunities Improvements tend to be small and incremental

Root Cause Analysis

Users are not asked for solutions, but for:
A list of (prioritized) problems All possible root causes for those problems

Analysts investigate each root cause to find:

Solutions for the highest priority problems Root causes that are common to multiple problems

Root Cause Analysis Example

Business Process Improvement

BPI makes moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing Common activities:
Duration analysis Activity-based costing Informal benchmarking

Business Process Reengineering

BPR changes the fundamental way in which the organization operates Spends little time understanding the as-is, because their goal is to focus on new ideas and new ways of doing business Popular activities:
Outcome analysis Technology analysis Activity elimination

Selecting the Appropriate Strategies

Business Process Automation Potential benefit Project cost Breadth of analysis Risk Lowmoderate Low Narrow Lowmoderate Business Process Improvement Moderate Lowmoderate Narrow-moderate Lowmoderate Business Process Reengineering High High Very broad Very high

REQUIREMENTS-GATHERING TECHNIQUES

Five Basic Steps of Interviews

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

Slide 85

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

Slide 86

Interviewing Strategies
Top-down
High-level: Very general How can order processing be improved?

How can we reduce the Medium-level: number of times that customers Moderately specific return ordered items? Low-level: Very specific How can we reduce the number of errors in order processing (e.g., shipping the wrong products)?

Bottom-up

Post-Interview

Joint Application Development

Allows the project team, users, and management to work together to identify requirements for the system Often the most useful method for collecting information from users Key roles:
Facilitator Scribe

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 ground rules Facilitator activities Keep session on track Help with technical terms and jargon Record group input Help resolve issues Post-session follow-up

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 used to obtain information from individuals Often used for large numbers of people from whom information and opinions are needed Common technique with systems intended for use outside the organization Response rates vary, but typically are significantly less than 50%

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 Questionnaire Design

Begin with non-threatening and interesting questions Group items into logically coherent sections No important items at the very end Do not crowd a page with too many items Avoid abbreviations Avoid biased or suggestive items or terms Number questions to avoid confusion Pretest to identify confusing questions Provide anonymity to respondents

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

Other Techniques
Throw-away prototyping Role playing CRC cards with use cases Mind/concept mapping

Selecting Appropriate Techniques

Interview Type of information Depth of info Breadth of info Info integration User involvement As-is, improves, to-be High Low Low Medium JAD As-is, improves, to-be High Medium High High Question Documen -naires t Analysis As-is, improves Medium High Low Low As-is Observati on As-is

Low High Low Low

Low Low Low Low

Cost

Medium

Lowmedium

Low

Low

Lowmedium

THE SYSTEM PROPOSAL

The System Proposal

The result of the planning and analysis phases Typically includes:
Executive summary System request Work plan Feasibility analysis Requirements definition Evolving system models

Summary
Requirements determination Requirements analysis strategies Requirements-gathering techniques The system proposal