10 c-draft-earthsoft-project management-detailed-experience based

Earthsoft Foundation of Guidance
Edge-Aggressive-Reliable-Trust-Honesty-Soft-Obedient-Fun-Transparent

Making earth little softer

About us
Earthsoft Foundation of Guidance (EFG) has uploaded following
presentations at http://myefg.in/downloads.aspx
Also https://dl.dropbox.com/u/83265908/Links-events.xls has links
Be mentor using your education, knowledge & experience to
contribute for a social cause & do conduct free training seeking
help of existing platforms. Kindly share with your friends
•Motivation for higher study, Planning for study, Education
guidance, Career guidance, Career available after SSC & HSC
•Personality development – 3 files
•How to prepare resume, Tips to attend interview successfully
•Religion related –To understand basic religion, Do &Don‟t tips
•Health related - Be vegetarian, Be healthy
•Corporate - Project management, Assertiveness, Ownership
•Finance - To avoid speculation in stock market
•Social - Women empowerment, Choosing life partner


Index
• Project • Communication
• Project Management • Closure
• Project Manager • Quality
• Scope • Client
• Estimation • Procurement
• Process • Reporting
• Plan • Feedback
• Schedule • Common Issues
• Team • Common Traps
• Integration • Tips
• Budget & Cost
• Risk

What is a Project?
• A temporary and one-time endeavor undertaken
to create a unique product or service, which
brings beneficial change or added value
It implies
• Specific requirements
• Specific timeframe
• Specific budget
• Working across organizational boundaries
• Delivering what client wants


Project Management
• Project Management is the application of skills,
experience, knowledge, tools and techniques to
meet the needs and expectations of
stakeholders for a project
• The purpose of project management is
prediction and prevention, NOT recognition and
reaction!


Not about
Project management is not about
• Organization & its culture
• Saying…I am the boss!
• Decision making
• Changing people‟s behavior
• Educating clients
• Proving other is wrong!


Observations
• No major project is ever installed on time,
within budget, or with the same staff that
started it.
• Projects progress quickly until 90% complete,
remaining completion consumes huge resources
• When things appear to be going better, PM may
likely overlook something
• PM mostly does not understand role clearly
• PM - Supervisor of many, but manager of none
• No system is ever completely debugged
• Clients pretend not understanding commercials
• Everyone thinks project can be executed better

Project Failure

Efforts over-run Schedule prolonged

Requirements not Deliverables not
met used

Budget over spent Loss making

Why Projects Fail
• Weak business case
• Lack of senior management commitment,
Failure to align project with organizational
objectives
• Absence of user/client involvement
• Lack of executive sponsorship
• New or unfamiliar technology
• Poor scope management - Lack of defined,
clear, and concise requirements, poor
requirements gathering


Why Projects Fail
• Scope creep
• Wrong estimation
• Unrealistic plan and schedule
• Unrealistic expectations
• Lack of project management, Inadequate project
planning
• Lack of resources & their planning
• Inability to move beyond individual and
personality conflicts
• Ineffective communication
• Political environment


Undesirable
• Too many changes, weak requirement gathering
• Too often resources are not available when
needed (even when promised).
• Scope creep
• Usually original due dates are not met
• Too many change request
• Extended or too tight schedule
• Discontinuity of the resources
• Different priorities between projects
• Budget over-runs and/or its non-availability
• Too many defects & requirements gap
• Less cooperation from client/users

Successful Project
• Successful project management is delivering a
quality solution meeting the customer‟s
requirements within efforts, time, scope &
budget making profit for the organisation.

Requirements Completed within
satisfied/exceeded effort & time frame

Completed within Accepted by the
allocated budget customer


Why Projects Succeed!
• Strong project management
• Domain knowledge
• Good project charter
• Good decision making structure
• Effective communication
• Effective risk management
• Continuous reviews of output & deliverables by
every senior level
• Detailed requirements & its traceability
• Empowered project manager
• Project sponsorship at executive level
• Availability of funding & motivation for profits

Why Projects Succeed!
• Sound project management processes
• Project aligned to organization‟s business goals
• Senior management commitment
• Right estimation, Realistic schedule
• Effective change management
• The right mix of team players
• Team members are working toward common
goals, high motivation
• Good stakeholder relationships
• Skilled and appropriate team members with
defined roles and responsibilities


Stakeholders
Individuals
and
Organizations

Interests Actively
Affected by Involved in
Project Project

Relationship

Employees

Management


Commitment to customers
Minimum
defects per
mm efforts

Support & Timely
comfort levels Commitment delivery
to Customers

Periodic
Minimum
Reporting
total cost
No surprises


Project Technique
• A set of techniques used for
• Planning
• Organising
• Scheduling
• Controlling
• Measuring
• Work activities
• To reach a desired result
• Within estimated efforts
• On-time
• Within budget and
• According to specification

Phases and Life Cycle
• Divide Project into Phases
• Conceptual Design
• Detailed Design
• Coding and Testing (Build)
• Training and Documentation
• Deployment
• Better Management Control for all parameters
• Review Deliverables and Performance
• Effective communication, tracking & reporting


Triple Constraint

Time

Quality

Cost Scope


Focus
Organizing and managing resources so the
project is completed within defined scope, time
and cost constraints achieving excellent quality

Manage these or they will manage you!

Triple Constraint
• Increased Scope = increased time + increased
cost + increased efforts

• Tight Time = increased costs + reduced scope +
increased efforts

• Tight Budget = increased time + reduced scope

• For the reduced duration, effort increases
exponentially (multiple times exponent (square)
of ratio of normal to reduced duration)


Characteristics of Project
• Objectives
• Life span
• Life cycle
• Uniqueness
• Successive principle
• Potential to change


Management
Professional and conscientious project
management is critical to a success!

Remember
Remember


Right factors

Facilities/
Infrastructure

Management
Processes & Plan
Execute
implementation Project Measure
Execution Control

Team – Skill,
experience, Communication
& Motivation


Project Management
SMC or
Scope FP or LOC

Mitigation Man-
& owner Risk & Issues Effort & Cost month
Plan
Track
Control
Measure
Defect per Milestones
mm Quality Schedule & Dates

Infra, People
Technology
Team

Project Management
Plan Track Control Measure
Efforts
Schedule
Quality
Cost
Risks
Resources


Project Management
Client Sign-off
End to End Management from client
testing

Integration & Proposal
deployment Management
All aspect &
If -then

Templates
Remain alert!
& Audits

Process Communication
Management Management Escalation
Metrics
Impact & Change control
Agreement Management

Key steps

Estimation

Measurement Planning &
& Matrices Project Scheduling
Execution Cycle

Integration & Costing &
Deployment Budgeting


Activities in sequence
Scope Activity
Planning Sequencing
Activity Schedule
Definition Development
Scope Estimating
Definition Effort, Duration Cost
Resource Budgeting
Planning
Cost Plan
Estimating Development

Activities in sequence
Quality Communications
Planning Planning

Risk Risk Response
Identification Quantification Development

Organizational Staff
Planning Acquisition

Procurement Solicitation
Planning Planning

Management activities
• Initialising
• Proposal writing
• Project planning and scheduling
• Project monitoring and reviews
• Controlling
• Costing & profitability
• Team building-Personnel selection, evaluation
• Report writing and presentations
• Efficient risk management
• Seeking support by seniors
• Measurement & Efficient PMO management
• Closure

Project Charter
• Project Goal & Objective
• Sponsor
• Stakeholders
• Timeline
• Resources required, role & responsibilities
• Deliverables
• Decision making structure
• Assumptions
• Risks
• Business process changes
• Project manager & Project team
• Budget
• Signatures

Project Charter
• What must be done?
• What are the required resources?
• What are the constraints?
• What are the short and long term implications?
• Why do it?
• When must it be done?
• Where must it be done?
• Who does what?
• Who is behind the project?
• Who is funding the project?
• Who is performing the work of the project?


Stages
• Project Management is divided as -
• Project charter development
• RFP Development and Process
• Project kick-off
• Planning & Design
• Project team creation
• Planning (WBS, schedule)
• Budget
• Implementation / construction
• Going live, Project closure, handing over to
operations management


Limitations
PM works efficiently when there is buy-in
however It does not work when
• Client / Users do not cooperate
• Business understanding gap with client
• buy-in is lacking or there is no support for the
methods or decisions by executives
• decisions made are not supported
• „end arounds‟ are tolerated
• influential players operate outside the project
• charters, schedules and other work products of
the team are not supported


Project Manager
• You used to be good friends with your co-
workers
• Project manager gets sandwiched, pressure
between co-workers and stakeholders
• The skills that brought you to this role are no
longer as vital; now new skills are needed
• You used to be & need to be really the best &
smart at your work
• Have effective, transparent & trustworthy
communication
• Be assertive


Leadership Skills
• Vision and Strategy
• Establishing Direction
• Aligning People
• Motivating and Inspiring
• Communicating
• Negotiating
• Influencing people & organizations
• Overcoming Barriers to Change
• Delivering quality solution
• Assertiveness


Key Strength
• Be the eye of the hurricane


PM makes things happen!

A good, solid professional project manager!

Different hats


Project manager
• A good project manager needs to be a juggler
• At times
• a magician
• a teacher
• a policeman
• a parent
• A Project Manager has to manage the triple
constraints!
• An under-qualified project manager can destroy
a contract, business relationship and client!


Various roles


Empowerment
• Have a spine
• Take a stand
• Act to achieve
• Be assertive


Control
• Stop on first instance
• Stop nuisance
• Stop non-sense
• Stop breaking guidelines


Lead
• Ensure strong, committed management support
• Connect the business goals to the project
• Assign an experienced project manager
• Establish clearly defined directions
• Be proactive
• Set clear performance expectations
• Ask for technical assistance
• Do not start roll-out until pilot is complete!


Project Manager’s Role

Lead

Communicate
Define Plan Monitor Complete

Communicate

Re-Plan


Project Manager’s Role
• Leadership
• Organising
• Managing
• Communication
• Finance
• Technical savvy
• Team building
• Praising
• Feedback (Punishing) (?)
• Politicking


Know your PM
Energy Energise
Ambition, Dreams, Team Player, Stability,
Commitment, Flexibility Delegation, Motivation
Self Motivation, Interpersonal skills,
Consistency, Initiative, Communication, Team
Build Organization Building, Managing Conflict
Execution Edge
Successful closure, Aptitude, Technology,
Reliability, Planning, Skills, Guiding, Ability,
Scheduling, Controlling, Expert, Management
Tracking, Problems Solving
Financial & Accounting

Know your PM
Energy Energise
Deep willingness to excel Respect in a team
Fun & Pressure Making a difference
Need & availability, Travel Recognition
Connecting with people
Edge Execution
To gain knowledge, Closing the threads,
expertise, Algorithmic & Controlling, Cost & Profits
Logical Sharpness Contribute, Problem solving
Etiquettes Ethics
Organised, Disciplined Value, Principle, Character
Well planned, Organising Believes, Trustworthy

Scope Management
Initiation
Processes

Scope Definition
Scope Planning
Scope Verification
Scope Change Control
Product / Project Description
Technologies

Project Charter
Tools &

Scope Statement
Microsoft Project
Formal Acceptance
Scope Management Plan

Scope Management
• Primarily it is the definition and control of what
IS and IS NOT included in the project.


Scope management
• Gradual, progressive increase in the project‟s
scope that is not noticed immediately
• Occurs when additional requirements result in
scope change causing cost & schedule overruns
• Take a judgment on clarity of requirements
being received from users
• Raise as many doubts & ask as many questions
during requirement gathering to users
• Document using question-answer format
• Make responsibility clear


Discuss & document
• Is it a must?
• Can customer/user do the job without project?
• Does it contribute to the viability of the system?
• Does it add value as a feature/function to the
system?
• Is it worth the additional cost?
• Take initiative
• Focus entire project
• Decide unit screen/ feature/ function
• Offer simple alternatives & decide
• Document entire discussions
• Get sign-off on daily basis

Develop Project Scope
• Scope Statement - agreement of what is & is not
Includes
• Primary objectives (products/deliverables)
• Major deliverable milestones
• Assumptions
• Constraints
• Interfaces
• Inputs to be received
• Output to be shared
• Completion criteria
• Baseline documents
• Maintain question-answer format file

Scope


Change Control Management
Define how scope changes will be executed
Scope Schedule Technical Specs Cost

Collaboration & agreement by the project sponsor
is must for all changes prior to implementation,
for above parameters!

Change Procedures/Requests
• Assess using baseline document
• Establish process early , from day one for
managing change requests
• Original scoping should be thorough as possible
• Any subsequent changes must be thoroughly
vetted, a form should be completed and
members and executives must sign off
• Change request has impact on efforts, schedule,
cost & probably quality so needs to be
communicated and sign-off from client is must
• It is critical at which phase, CR is received, cost
is multifold at later phase for the same request

Change Management
• Access management of changes with respective
to the primary objectives and major deliverables
milestones
The plan should include agreements of:
• Change acceptance/expectations
• How changes will be evaluated
• How change will be managed


Estimation numbers
Description Alt 1 Alt 2
LoC per FP (historical data) 53 40
No of FP per month 10 8
No. of days per month 20 20
No. of FP per day (data) 0.5 0.4
Loc per day (without 27 16
blank & comments)- Java
LOC per hour 3.3 2.0
Screen based estimation
Days Loc
1 Simple screen 9 239
1 Medium screen 18 477
1 Complex screen 27 716

Estimation
# Description # Description
1 Executive Summary 8 Assumptions
2 Cost Estimation 9 Risks & Mitigation
3 Phase breakup 10 Deliverables
4 Estimation 11 Pending list
5 Schedule 12 Out of scope
6 Team Structure 13 Prerequisites
7 Approach 14 Terms & Conditions
• Av. base or resource wise Rate per manmonth
• Type of project (Fixed, T & M, Hybrid)
• Project execution methodology

Execution Models
• Waterfall
• SDLC – V, Customised, Incremental Model
• Rapid application development
• Extreme programming - XP
• Agile and Feature driven design
• Dynamic systems development model


SDLC Phases

Requirement
Analysis

Users
High & Low
Testing &
Project level design
Deployment
Execution Cycle

Integration &
Development &
Application
Unit Testing
Testing


V Model
RFP document Acceptance Tests

Business Requirement Application Test cases

High Level Design Integration Test cases

Low Level Design Unit Test cases

Coding &
White box testing

Output
# Phase Output
1 Requirement Proto type, Functional document
Analysis Application Overview and diagram
Breakdown of application in Modules,
Sub Modules, Screen layout &
Screens functionalities, common
validations & rules, business rules
Screen transition diagram
ER design/ External files
External communication
Software/Hardware requirement
Deployment Diagram
Out of scope

Output
# Phase Output
2 High Design document
Level Class listing, Class diagram, Sequence
Design diagram, Common design rules
Detailed Screen specifications
Physical Database design; E-R
Database design, Integration Test
cases, Test data
Low level Program specifications, Unit test cases
design Screen specifications (Field level
validation) & business rules, Unit Test
case, Test data


Output
# Phase Output
3 Build Code
Test results of Unit testing
4 Testing Integration Test results
Application Test results
Bug posting & Tracking till closure
5 UAT & Test results
Deployment System Manual & User‟s Manuals
Training
6 Going Live Program document
Monitor the progress, feedback,
defects, H/w, S/w, Users,etc

Phase wise effort distribution
# Phase % Type Type Type
efforts 1 2 3

T&
1 Requirement Analysis 10-15

M
2 High & Low level Design 15-20

T&M
Fixed
Fixed
3 Build 35-45
4 Testing 15-20
5 UAT & Deployment 5-10

Duration = k * SQRT((efforts in mm)), k=0.8 - 1.2
Save as much efforts right from the beginning


HL Schedule

Duration = k * SQRT((efforts in mm)), k=0.8 - 1.2
Average no of resources = efforts/duration

Requirement Analysis

Gather &
Document

Estimation Think
Review Discuss &
Conclude Requirement Brainstorm
Analysis

Feasibility
Flow Diagram
Screen Design Conserve
Documents


Milestones


High & Low level Design
Technology &
Framework
decision
Technical
Validations & Architect,
reviews High & Low level Framework
design development

Interfaces Design Document
(Use cases, Class Dia, DB
Design design, Sequence Dia,
Test cases Common Design, Screen
specifications)


Development
Guidelines
(Do it FIRST
time RIGHT),
check list
Interfaces Look & Feel,
Integration Traceability,
Testing Development Coding & review

Unit test cases,
test data, Strong Code
testing, test reviews
result


Testing
Absolute
matching
environments
Reviewed test
Plan at least
cases, IT &
2-3 round of
AT, daily
testing Testing measurement

Detect maximum Test data, right
defects & Track tool,
till closure, Test Performance,
results Load, regression


UAT & Deployment
Absolute
matching
environments
UAT & closure
Staging &
Document-
Live server
System & UAT & management
Users Manuals Deployment

Configuration of
System manual,
servers
Users manual,
Installation of
Training
software


Types of plan
• Project Plan
• Monitoring and reporting mechanisms
• Quality Plan
• Validation / Testing Plan
• Configuration management plan
• Deployment Plan
• Maintenance Plan
• Risk analysis & mitigation plan
• Hardware and software Resource plan
• Budget & costing plan
• Staff development Plan
• Communication Plan

Plan
• Identify all stakeholders for each plan
• Develop the project plan before starting the
project
• Establish communications protocols
• Define requirements in detail
• Establish a speedy conflict resolution process
• Make contingency plans
• Plan a reasonable roll-out schedule
• Get it reviewed critically
• Get is accepted by all stake holders
• Project documentation to determine - How
the project will be managed

Project planning
• Probably the most time-consuming however
critical project management activity.
• Continuous activity from initial concept through
to system delivery.
• Plans must be regularly revised as new
information becomes available, almost daily
• Additional plan may be developed to support the
main software project plan
• Always determine the critical path


Coding “plan”
• Establish the project constraints
• Make initial assessments of the project parameters
• Define project milestones and deliverables
• while project has not been completed or cancelled loop
• Draw up project schedule
• Initiate activities according to schedule
• Wait ( for a while )
• Review project progress
• Revise estimates of project parameters
• Update the project schedule
• Re-negotiate project constraints and deliverables
• if ( problems arise ) then
• Initiate technical review and possible revision
• end if
• end loop

Scheduling
Activity Definition (Microsoft Project)
Processes

Activity Sequencing (Microsoft Project)
Activity Duration Estimating
Schedule Development
Schedule Control
Activity List
Technologies

Network Diagram
Tools &

Project Schedule
Schedule Management Plan
Identifying Critical Path


Scheduling

• Where are we now?
• Where we plan to be?
• How can we get there?

Scheduling
The project schedule sets out as Module wise
• Split project into modules & tasks
• All activities for each module to be captured
• Estimate time and resources required to
complete each task
• Include all possible activities, smallest to big
• The resources available / needed to the project
• A schedule - start & end time & total duration
• All dependencies to be identified, check to keep
waiting time as minimum
• It is essential to complete the project on time so
complete each task in time

Scheduling
• To review & analyse if any task is delayed,
support to get it completed without delay
• Incorporate appropriate buffer
• Understand critical path & track it closely
• Organize tasks concurrently to make optimal
use of workforce
• Identify all dependencies
• Minimize task dependencies to avoid delays
caused by one task waiting for another to
complete
• Depends on project managers intuition and
experience

Scheduling
• Estimate likely efforts & duration for activity

• For each activity
• Determine skills and resources
• Determine start and finish dates for tasks
• Assign the resources
May Jun Jul Aug Sep Oct Nov


Scheduling Tools
• Microsoft Project
• Excel
Most important
• Monitoring the tasks
• Gantt views of project
• One page views for executives
• Rollout and more complex views for work teams
• Critical Paths
• Inputs from multiple teams that roll up to project
manager
• Dependencies
• Resources assigned to tasks

Scheduling


Scheduling process


Scheduling problems
• Estimating the difficulty of problems
• Productivity is not proportional to the number of
people working on a task.
• Adding people to a late project makes it costlier
& complex because of communication
overheads
• The unexpected always happens. Always allow
contingency in planning


Team


Team
A good team delivers successfully!


Human Resource Management
Organizational Planning
Processes

Profile defination
Staff Acquisition
Team Development

Role Assignment Matrix (Microsoft Word)
Technologies

Staffing Management Plan
Tools &

Organizational Chart
Project Team Directory


Project staffing
• Try to get
• Right resources, is the key & can make
• Phase wise right number of resource
• Define appropriately profile of the resources
needed
• Intimate minimum 4-6 weeks prior to the need
• Share the resource chart with resource
management group
• Check the availability
• Analyse what if not available situation
• Raise alert & possible impact and risk due to
non availability of the resource

Project staffing
May not be possible to appoint the ideal people to
work on a project
• Project budget may not allow for the use of
highly-paid staff
• Try to determine profitability from start
• Staff with the appropriate experience may not be
available
• An organisation may wish to develop employee
skills on a project
• Managers have to work within these constraints
especially when there are shortages of trained
staff

Resource chart


Staff allocation
4/7 1 1/7 18/7 2 5/7 1/8 8/8 15/8 2 2/8 2 9/8 5/9 1 2/9 19/9

Fr ed T4

T8 T 11

T 12

Jane T1

T3

T9
Anne T2

T6 T 10

Jim T7

Mary T5


Organize and acquire staff
• Identifying, documenting, and assigning project
roles and responsibilities as they relate to the
work defined, acquiring the staff
• Staff acquisition - negotiations, position
announcement, procurement, or assignment.


Team Development
Select the right players
• Complementary skillsets
• Blend of technical and business
• Align with WBS
Stages of Team Development
• Forming
• Storming
• Norming
• Performing


Consultants


Consultants
• Objective, skilled consultants can provide a
team foundation
• Consultants can address dicey organizational
issues
• For large projects, this approach is vital.
• May want to hire contractors from outsourcing
partner or
• May want to outsource partial or complete
project to outsourcing partner


Destructive team members


Destructive team members
• Understand the profile & strategise to deal!
Tank
End Arounder Grenade

Traitor Think
Profiles

Sniper May Be

Yes Sir No Sir


Decision Making Structure
Define Layers
• Executive
• Project Manager
• Project Team
• Sub Teams
Documentation
• Roles & Levels of responsibilities to be defined,
conveyed, understood and agreed clearly for
each member


Decision Making
• Avoid consensus abuse
• Consensus may be desired, but is not required
• Lack of consensus does not mean no decision
• Projects force decisions by leaders
• Clarify who makes what decisions
• Establish structure for rapid decision making
• Communicate decisions
• Log/track decisions for future reference
• It is important that team members agree to
support the decisions even if not in agreement
• Agree to disagree
• Get buy-in from sponsor and administrators

Integration Management
Project Plan Development
Processes

Project Plan Execution
Overall Change Control
Boundary conditions
Inputs to be received
Output to be delivered
Technologies

Project Plan
Lessons Learned
Tools &


Budget & Cost Management
Resource Planning
Processes

Cost Estimating
Cost Budgeting
Cost Control

Resource Requirements
Technologies

Cost Estimate
Tools &

Cost Baseline or Spending Plan
(Microsoft Excel Documents)
Cost Management Plan
Indirect Cost structure

Controlling the Budget


Prior Approval
• Do not assign the resources unless funds are
committed & documented
• Not obtaining prior approval is the biggest
blunder PM would ever make
• Always fix the responsibility if someone wants to
start project without approval

Disapproved


Budget/Cost Management
• To spend only against budget
• Monitor project spending weekly
• When a variance occurs, determine the cause
• Seek approval depending on slab of variance
• Change the execution of the project, reduce
scope if needed
• Prevent unapproved changes to the project
• Save as much efforts from the beginning


Cost Management
• Effort is the important element of the total cost
• Ensure the project is completed within the
approved efforts and budget.
It includes
•Resources
• People
• Equipment
• Materials
•Quantities
•Budget


Budgeting & Spending
• Prepare budget, review & get it approved
• Include various direct & indirect cost items
• Resources – Actual
• Training, Management
• Hardware & Software
• Logistics
• Conveyance
• Infrastructure
• Outsourcing
• Revisit the budgets periodically
• Check the balance budget and pending project
activities in % & absolute terms

Think Fast & Ahead

Risk… POTENTIAL negative impact to project


Risk Management
Risk Identification
Processes

Risk Quantification
Risk Response Development
Risk Response Control

Risk register
Technologies

Risk Management Plan
Tools &

Checklists
Contingency Plans
Reserves
Contractual Terms

Risk management
# Risk Date Description Probability Impact Exposure Mitigation Owner Closure
/ Issue % plan date

• It‟s a skill & intuitive mindset to envisage the risk
• Efficient project manager smells the risk & act
fast to mitigate / transfer / close the risk
• Tracking the risks till closure is key task of PM
• Risk either to be mitigated or transferred in
agreement


Risk management
• A risk is a probability that some adverse
circumstance /problem will occur impacting
negatively
• Project risks impact
• Schedule or resources
• Quality or performance of the software
• Issue – Live problem
• To identify the risks and plan to minimise their
impact on a project
• Risk update and tracking
• Business risks affect the organisation
developing or procuring the software

Sources of the risks
• Poor estimates or unsupported estimates
• Requirements risks
• Estimation risks
• Impossible timeframes
• Unrealistic schedule
• Changes in requirements
• Design errors and omissions
• Political scenarios
• Technology risks
• Organisational risks
• Client side non-cooperation
• Non-availability of budgets

Sources of the risks
Resource risks
• Roles and responsibilities misunderstood
• Insufficiently skilled staff, People risks
• Not adequate
• Not skilled
• Not experienced
• Not motivated


Risk management process
Risk identification
• Identify project, product and business risks;
Risk analysis
• Assess the likelihood, probability, impact,
exposure and consequences of these risks;
Risk planning
• Draw up plans to avoid or minimise the effects
of the risk;
Risk monitoring
• Monitor the risks throughout the project
• Good to use issue tracking system


Risk management process


Risk analysis
• Assess probability and seriousness of each risk.
• Probability may be very low, low, moderate, high
or very high.
• Risk effects might be catastrophic, serious,
tolerable or insignificant
• The best practice is to keep risk register and
choose as applicable


Risk planning
• Identify risks with probability, impact & exposure
• Planning for risk mitigation or contingency
• Develop a strategy to manage each risk
• Avoidance strategies
• The probability that the risk will arise is reduced;
• Minimisation strategies
• The impact of the risk on the project to be
reduced
• If the risk arises, it becomes an issue, prepare a
contingency plan to deal with that risk
• Assign a owner to mitigate the risk

Risk monitoring
• Assess each identified risks regularly to decide
whether or not it is becoming less or more
probable
• Also assess whether the effects of the risk have
changed.
• Each key risk should be discussed at
management progress meetings.


Communications Skills
• Writing
• Listening
• Speaking
• Presenting
• Updates & reporting
• Meeting Management
• Media Relations


Communications Management:
Communications Planning
Processes

Information Distribution
Performance Reporting
Administrative Closure
Decision making structure
Project Records
Technologies

Performance Reports
Tools &

Change Requests
Project Archives
Formal Acceptance
Lessons Learned

Communication Management
• This process is necessary to ensure timely and
appropriate generation, collection,
dissemination, and storage of project
information
• Communicate objectives frequently
• Recognize different perspectives
• Check assumptions frequently
• Manage expectations
• Share success and broadcast achievements
• Invite feedback


Communication Plan
• Define stakeholders
• Define hierarchy
• Develop communication plan
To Identify
• Talents for communication
• Need to communicate
• Means of communication
• Frequency of communication


Communication
• Communication is everything we do in business
• It is essential to know and follow good practices
of communication to be successful
• Prepare minutes of meeting, action items &
owner, track action items till closure
• Good communication builds stronger
relationships & become more effective
• Poor communication
• results huge losses to business & individual
• cause the stress to individual or to the team
• create misunderstanding
• expresses inconsistent message or feeling
• Suggest to plan, training & practice skill

Communication Needs
The plan to determine:
• Team structure
• Role & responsibilities and Names
• Who needs what information
• When will they need it
• How will it be given to them
• By whom
And determine how to:
• Store, update, and disseminate information
• Close, file and archive information
• Update the communication plan


Closure
To conduct a meeting with all stake holders
To share following information estimated & actual
• Efforts
• Schedule
• Defect Matrices
• Profitability
• Client happiness Index Remember
Detailing
• Key learning
• Best performance
• What next?


Project completion

Figure 1-3


CMM 5

5 - Optimizing
Continuously
4 - Managed Improving
Predictable
3 - Defined
Standard, Consistent
2 - Repeatable
Disciplined Process
1 - Initial
Ad-hoc Process


CMM 5
Level 3 – Defined
-- peer reviews, intergroup coordination
-- software product engineering
-- integrated software management
-- training program
-- organization process definition & focus
Level 2 – Repeatable
-- software configuration management
-- software quality assurance
-- software project planning, tracking and
oversight
-- requirements management
Level 1 – Initial

CMM 5
Level 5 – Optimizing
-- process change management
-- technology change management
-- defect prevention
Level 4 – Managed
-- software quality management
-- quantitative process management


Quality Management
Quality Planning
Processes

Quality Assurance
Quality Control

Quality Management Plan
Technologies

Issue tracking system
Tools &

Risk tracking register


What is Quality
• Functionality related gap between expectations
of client and actual delivery
• Defects are injected during Requirement, High &
Low level Design and coding phase
• Continuous reviews help to prevent defect
injection
• Rigorous testing during Unit level, Integration
and application level testing detect the defects.
• Both of above processes remove the defects

RA R Design R Coding R UT IT AT


Make a statement
To aim your organisation to be the best in the
industry in terms “Defects Delivered Ratio” and
thus be able to achieve the organization objective
of being an extraordinarily reliable company
using..
• The best of the tools & technologies
• Incorporating processes
• Measurements & feedback
• Continuous Improvements


Reviews & testing
• Removing defects by reviewing & testing
• From each deliverable
• At each phase
Defects in system

Various Phases of SDLC
Get on Track at the end of each phase

Quality measurement
No. of defects 1
effort in manmonths 3
Loc per hr 10
Lines of code 4800
no. of defects 1
% of defects to LoC 1*100/4800=2.1%
Achieved quality 97.9167%
• 1 defect detected by customer for 3 man months
of efforts is said to be fairly good quality
• Count each type of defect (minor, normal, major,
critical or blocker) ; Minor defect is worst!

Quality Management
Quality Management is the process that insure
the project will meet the needs
• Conformance to requirements - Crosby
• Fitness for use - Juran
• The totality of characteristics of an entity that
bear on its ability to satisfy stated and implied
need - ISO 8402:1994


Quality Management
How will quality assurance and control be
conducted?

• Identify Quality Standards
• Quality Assurance
• Quality Control
• Quality Matrices
• Improve
Sometimes performed by a 3rd Party

Issue Management
• Issues are restraints to accomplishing the
deliverables of the project.
• Typically identified throughout the project and
logged and tracked through resolution.

Issues impact cost, time, quality, most
important is reputation and branding!

Types of issue – Minor, Normal, Major,
Critical, Blocker
Minor issue is dangerous!


Client
• Client is God!
• It‟s a source of profit for management & salary
for employees
• Good to keep balance educating to client
• Never forget you are hired to serve client
• Client always have choices so maintain those
values & attributes for which you were chosen
• Seek support & help as needed
• Get client on your side of table so be a team


Procurement Management
Procurement Planning
Processes

Solicitation Planning
Solicitation
Source Selection
Contract Administration
Contract Close-out
Technologies

Procurement Management Plan
Tools &

Procurement Documents & Framework
Proposals
Contract
Formal Acceptance and Closure

Procurement management
Procurement planning determines:
• Selection of partner
• Budget, Cost and negotiations
• Whether, what, and how much
• How and when
• How to manage solicitations, selection, contract
administration, and closeout
Procurement documents:
• RFP - Request for Proposal
• SOW - Statement of Work
• Evaluation Criteria
• Reward & penalty

Manage the Contractor
To develop a framework of outsourcing
To enforce the terms of the contract and meet the
requirements of the RFP


Manage the Contractor
• Trust but question
• Support contractor to build & grow
• Their bottom line is the bottom line
• Your bottom line is a working system
• Nothing is ever free
• Do not crush contractor over pricing


Reporting
• Establish reporting requirements upfront
• Include only the good, be diplomatic for the bad,
and the ugly
• Be brief but accurate
• Management really does want to know!
• Use the standard formats across organisation


Meeting Management
• Develop guidelines/ rules early
• Assign facilitator
• Assign reporter and reporting structure
• Start and end times, frequency of meetings
• Daily stand up meeting, max 2 minute for each
• Did you finish task as planned
• If not, what support is needed
• When would you complete the task
• Publish minutes of meeting & track action items
• Frequency of meetings, Focus of meetings
• Information sharing?
• Agenda building

Guidelines for meeting
• Start/end times are real
• Agree to debate issues, not people
• Civility required
• Confidentiality?
• Reporting out
• What is going to be reported
• What isn‟t
• Agree to bring all issues to the table
• Avoid discussion related to absentee


Feedback
• Praise in public
• Feedback/ Punish in private
• Build performance reviews into the contract
• Be clear and specific
• Be timely
• Follow up!


Multi tasking
• Bad multi-tasking inflates lead times!
• Try to limit multi tasking only for rare expertise &
capable resouce


People Problems
• 2/3 of project problems are people related
• Many operational leaders demonstrate a “just
do-it” mentality.
• There will always be conflict over goals and
scope, resources and between departments
• Lack of understanding basic project
management methods
• Some people will never get along
• Set the framework to resolve the conflict
• Onsite coordinator behaves like a client & does
not support development team
• Push for unwanted tasks by OSC

Navigating the Politics
• Know the environment
• What are the overarching issues of your
organization?
• What are the pressing issues of the hour?
• What will be the pressing issues of tomorrow?
• How do you help others satisfy their needs?
• What is the stake of others in your project?
• Identify a mentor
• The best is to keep away from politics than
trying to navigate!
• Never underestimate those who play the game!

CRT - Current Reality Tree

Budget over- Due dates are
runs not met

Early completions are
not transferred.

Estimates turn into
commitments


CRT - Current Reality Tree
There are too fights over priorities
many changes between projects

Budget Due dates Non availability
over-runs are not met of resources

Early completions are Bad multi-
not transferred tasking

Estimates turn into
commitments

Potholes
• Giving the contractor or any team member too
much control, responsibility, or authority
• Not managing scope creep
• Balancing client happiness & profitability
• Balancing – Client, Management & Employees
• Conflict not resolved till conclusion


Common Traps

Courtesy
Karl E. Wiegers
www.processimpact.com
Process Impact

Not clear Requirements
• Stakeholders discuss “requirements” with
no adjectives in front.
• Project sponsor presents a high-level
concept as “the requirements”.
• User interface screens are viewed as
“the requirements”.
• User provides “requirements,” but
developers still don‟t know what to build.
• Requirements focus just on functionality.


Not clear Requirements
• Adopt templates for three levels of requirements
• Business requirements (Vision & Scope)
• User requirements (Use Case Document)
• Functional requirements (Software
Requirements Specification)
• Distinguish functional from nonfunctional
requirements
• Quality attributes, constraints, external interface
requirements, business rules
• Classify customer input into the different
categories.
• Distinguish solution ideas from requirements

Inadequate Involvement
• Some user classes are overlooked.
• Some user classes don‟t have a voice.
• User surrogates attempt to speak for users.
• User managers
• Marketing
• Developers
• PM & Client have to make many requirements
decisions


Inadequate Involvement
• Identify various user classes.
• Identify product champions as user
representatives
• Convene focus groups
• Identify decision-makers
• Have users evaluate prototypes
• Have user representatives review the SRS
• Encourage participative management
• Try to involve all stake holders
• While decision making
• While reporting

Ambiguous Requirements
• Readers interpret a requirement in several
different ways.
• Requirements are missing information the
developer needs.
• Requirements are not verifiable.
• Developer has to ask many questions.
• Developer has to guess a lot.


Ambiguous Requirements
• Formally inspect requirement documents.
• Write conceptual test cases against
requirements.
• Model requirements to find knowledge gaps.
• Use prototypes to make requirements more
tangible.
• Define terms in a glossary.
• Avoid ambiguous words:
• Minimize, maximize, optimize, rapid, user-
friendly, simple, intuitive, robust, state-of-the-art,
improved, efficient, flexible, several, and/or, etc.,
include, support

Unprioritized Requirements
• All requirements are critical!
• Different stakeholders interpret “high”
priority differently.
• After prioritization, 95% are still high.
• Developers don‟t want to admit they can‟t do it
all
• It‟s not clear which requirements to defer during
the “rapid descoping phase.”
• All requirements in the same budget


Unprioritized Requirements
• Align functional requirements with business
requirements.
• Align functional requirements with high-priority
use cases.
• frequency of use
• favored user classes
• core business processes
• demanded for regulatory compliance
• Define priority categories unambiguously.
• Allocate requirements or features to releases.
• Analytically prioritize discretionary requirements
• Involve those approve the budgets

Analysis Paralysis
• Requirements development seems to go on
forever.
• New versions of the SRS are continually
released.
• Requirements are never baselined.
• Design and coding can‟t start until the SRS is
perfect
• Third party interface is not clear


Analysis Paralysis
• Remember: Product is software, not an SRS
• Select an appropriate development life cycle.
• Staged release or evolutionary prototyping
• Decide when requirements are good enough.
• Acceptable risk of proceeding with construction
• Reviewed by analyst, developers, testers, &
customers, conduct knowledge transfer & sign-
off sessions
• Model just the complex or uncertain parts of the
system
• Seek complete details of interface design


Scope Creep
• New requirements are continually added.
• Schedule doesn‟t change
• No more resources provided
• Product scope is never clearly defined.
• Requirement changes sneak in through the
back door.
• Proposed requirements come, and go, and
come back.
• Scope issues are debated during SRS reviews.
• Sign-off is just a game.


Scope Creep
• Determine root causes of the scope creep
• Document the product‟s vision and scope
• Define system boundaries and interfaces.
• Follow the change control process for all
changes.
• Improve requirements elicitation methods
• Involve seniors from client IT and users division
& share the data periodically
• Make a big bang sign-off event
• Follow a meaningful baselining process
• Renegotiate commitments when requirements
change, particularly schedule and budget

Inadequate Change Process
• No change process is defined.
• Some people bypass the change process.
• Implement rejected changes
• Work is done on proposed changes before
they‟re approved
• New functionality becomes evident during
testing
• Unclear change request status
• Changes aren‟t communicated to all those
affected
• It‟s not clear who makes change decisions
• Money is denied for the change request

Inadequate Change Process
• Define a practical change control process
• Set up a Change Control Board
• Diverse group including participation of client
• Makes binding change decisions
• Clear sign-off for each change request
• Use a tool to collect, track, and communicate
changes
• Problem or issue tracking tools work well
• A tool is not a process!
• Establish and enforce change control policies.
• Compare priorities against remaining
requirements.

Inadequate Version Control
• Accepted changes aren‟t incorporated into SRS
• You can‟t distinguish different SRS versions.
• Different versions have the same date
• Identical documents have different dates
• People work from different SRS versions.
• Implement canceled features
• Test against the wrong requirements
• Change history and earlier document versions
are lost
• Configuration server breakdown


Inadequate Version Control
• Assign a member as a owner for version control
• Implement right configuration tool from start
• Adopt a versioning scheme for all project assets
• Merge changes into the requirement document
• Record history of every requirement change
• Restrict read/write access as appropriate
• Make current versions available read-only to all
including client except the authors
• Communicate revisions to all who are affected
• Set build release process (latest compiled code)
• Always test on latest build
• Always take backup at end of day

Success Tips
Risk management reviews &
Right Project
Management
support from seniors
management

Project Success
Right Team (Quality & Timely
delivery)

Right
Processes

Reviews
• Every deliverable must be reviewed by senior
• Sharing experience & education from senior
management till project managers levels
• Define Goal, Objectives, Mission for each group
• Vibrant & visible enablers
QMG

RMG PMO TMG
• QMG – Quality Management Group
• TMG – Technology Management Group
• RMG – Resource Management Group
• SEPG – Software Engineering Process SEPG
• PMO – Project Management Office

Ask for
• Have you planned entire project?
• Do you have appropriate duration?
• Would you have enough appropriate resources?
• Do we track our assignments? & follow up till
timely closure?
• Are tasks completed as scheduled?
• What is tracking methodology?
• Do you have daily stand up update meetings?
• Are assignments piling up? Why?
• “First time right” Is it happening?
• Single window system – task given & collected?
Or huge overloading?

Ask for
• Anyone getting overloaded? Is this acceptable?
• Multi tasking? Need of a day? Is it sustainable?
Do you have choice not to assign multi-tasking?
• Tracking & Closing threads? And tasks?
• When do we decide to close a day?
• Do we update the status before leaving?
• Are risks being mitigated?
• Are you maintaining measurement matrices?
• Are we achieving Key result Area (KRA)?
• Ownership? Does each of team member own?
• Is quality being achieved?
• Are we heading towards tough situation?

Vision

 Minimum Defects
 Timely Delivery
 Minimum TCC

EXECUTION

MARKETING

ORGANISATION

References
• Experience of author having worked at Vertex, now NTTData
• Wiegers, Karl E. Creating a Software Engineering Culture
Gause, Donald C., and Gerald M. Weinberg. Exploring
Requirements: Quality Before Design. NY: Dorset House
Publishing, 1989.
• Gottesdiener, Ellen. Requirements by Collaboration: Workshops
for Defining Needs. Boston: Addison-Wesley, 2002.
• IEEE Std. 830-1998, "Recommended Practice for Software
Requirements Specifications." Los Alamitos, Ca.: IEEE
Computer Society Press, 1998.
• Leffingwell, Dean, and Don Widrig. Managing Software
Requirements. Reading, Mass.: Addison Wesley Longman,2000
• Robertson, Suzanne, and James Robertson. Mastering the
Requirements Process. Harlow, England: Addison-Wesley, 1999
• Sommerville, Ian, and Pete Sawyer. Requirements Engineering:
A Good Practice Guide. New York: John Wiley & Sons, 1997.

For More Information
• Wiegers, Karl E. Software Requirements. Redmond,
Wash.: Microsoft Press, 1999.
• Search Group, Incorporated
• www.search.org
• National Center for State Courts
• www.ncsc.dni.us
• Project Management Institute
• www.pmi.org
• International Standards Organization
• www.iso.org
• Software Engineering Institute
• www.sei.cmu.edu
• Center for Technology in Government
• www.ctg.albany.edu

Project Management Resources
• Project Management Institute – home of the Project
Management Body of Knowledge (PMBOK)
• http://www.pmi.org/Pages/default.aspx
• NYS Project Management Guidebook Release 2
http://www.oft.state.ny.us/pmmp/guidebook2/index.htm
• FNS Handbook 901, Chapter 5
http://www.fns.usda.gov/apd/Handbook_901/V_1-
2/Chapter_5.pdf
• ESI Horizons www.esi-horizons.com
• Project Management Institute. www.pmi.org
• On Becoming a Technical Leader. by Gerald Weinberg
• On Becoming a Leader. by Warren Bennis
• Getting Past No. by William Ury
• Decision Traps. by Edward Russo

Thank You


10 c-draft-earthsoft-project management-detailed-experience based

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 10 c-draft-earthsoft-project management-detailed-experience based

Similaire à 10 c-draft-earthsoft-project management-detailed-experience based (20)

Plus de EarthSoft Foundation of Guidance - EFG

Plus de EarthSoft Foundation of Guidance - EFG (20)

Dernier

Dernier (20)

10 c-draft-earthsoft-project management-detailed-experience based

Notes de l'éditeur