On Software Project Management, Part 3

I have an exam tomorrow about risk management, so I thought I might as well post my notes about it. (So this post will be “raw” without much thought for grammar and punctuation.) These are my notes on this Lecture – Lesson 02, courtesy of Professor Rolly Torio.

First, a recap:

Software Project Management – concerned with making sure that software is delivered within schedule, within budget, and within the requirements specified by the organization.

Necessary because:
Software dev is constantly facing budget and schedule changes
Product is intangible , flexible
Most are one-off projects
Not standardized, recognized with same status as other engineering disciplines (although software does share the many similarities with other complex systems)

PM’s deal most with planning, scheduling, and estimating.

Management Activities include:
Proposal writing
Project planning and scheduling
Project monitoring and review
Report writing and presentation
Personnel selection and evaluation

On Project Staffing
Main problems include: lack of budget to hire great people, or lack of great people.
Can be remedied by training.

Project Planning
Most time consuming
Iteratitive, should be regular updated as more info comes in
Focuses on schedule and budget

Types of Project Plans (QVCSM)
Config Management
Staff Development

The Project Plan includes
1. resources available
2. work breakdown
3. schedule

Project Plan Structure
Project Organization
Risk analysis
Hardware and software requirements
Work breakdown
Project Schedule
Monitoring and reporting mechanisms

Milestones: end points(most visible with waterfall)
Delivarables: project results

Steps in Requirements Engineering + their corresponding deliverables (FRPDR)
Feasibility Study -> Feasibility Report
Requirements Analysis -> User Requirements
Prototype Dev – > Evaluation Report
Design -> Architectural Design
Requirements Specification ->System Requirements

Tips on Project Schedule
1. Use tools to eliminate time wasted for waiting for processes that do not need to be waited on. Some tasks can be done concurrently. Minimize dependencies to avoid delays.
2. Split project into tasks (1-2 weeks length) that you can easily estimate for time and resources needed.
3. Estimating is hard, but improves with experience.
4. Productivity is not based on how many people are on your team. In fact, adding someone new will make a project later (mongolian horde).
5. Always have a contingency plan.
6. Involves graphs: activities, durations, and staff

Activity Path vs. Bar Charts
Activity paths show dependencies and the critical path.
Bar charts show time against a calendar.

Risk Management
-consists of identifying risks and plans to minimize/avoid/deal with their effects.

“A risk is a probablity that some adverse circumstance will occur.”
Risks affect the schedule, resources, quality, performance, and the business making/buying the software.

Types of Software Risks

The Risk Management Process (IAPM)

Risk Identification: project, product, or business?
Ex. Technology, people, organizational, requirements, and estimation risks

Risk Analysis: assess likelihood and their effects
Probability: very low, low, medium, etc.
Effects: catastrophic, tolerable, insignificant, etc.

Risk Planning: create plans to avoid/minimize
1. Avoidance strategies: how to avoid altogether
2. Minimization strategies: reduce impact
3. Contingency plans: how to move forward/deal with the risk

Risk Monitoring: should be done throughout the project
Regularly  check if probability and/or effects are changing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s