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
