PROJECT MANAGEMENT

Lecture Notes 2
 PROJECT MANAGEMENT
• Software Project Managements is an
umbrella activity within Software Engineering

• Project Management involves the Planning,

Monitoring and Control of People, Process
and Events that occur as Software evolves
from preliminary concept to an operational
implementation.
•
Project Management begins before any
technical activity and continues throughout
the Definition, Development and Support of
Computer Software.
 PROJECT MANAGEMENT
• WHO DOES IT ? Project Managers
.Project Managers Plan, Monitor and Control the work of Team of
Software Engineers.

• WHY IS IT IMPORTANT ?

Building a Computer Software is a complex undertaking, particularly if it

involves many people working over a relatively long time. That’s why
Software Projects need to be Managed.

• WHAT IS THE WORK PRODUCT ? ‘’A PROJECT PLAN’’

Project Plan defines the Process and Tasks to be conducted, the People
who will do the work and the mechanism to assessing Risks, Controlling
Change and Evaluating Quality.

Project Plan is produced as Management activities commences

 THE MANAGEMENT SPECTRUM
Effective Project Management focuses on 4 P’s

People, Product , Process, Project

• A Manager who forgets that Software Engineering is an intensely

Human endeavour will never have success in Project Management.

Manager who fails to encourage comprehensive Stakeholders

communication early in the evolution of a Project Risk building an
elegant solution for the wrong problem

• The Manager who pays little attention to the Process runs the risk of
inserting competent technical Methods and Tools into a vacuum.

• The Manager who embarks without a solid Project Plan jeopardize

the success of the Product.
 THE 4’Ps OF PROJECT MANAGEMENT
1. THE PEOPLE
• The People Factor is so important that Software Engineering
institution has developed a People Management Capability Maturity
Model. (PM-CMM).

• PM-CMM Defines the following key practice areas for Software

People:-

- Recruiting
- Selection
- Performance Management
- Training
- Compensation
- career Development
- Organization and work Design
- Team Culture Development

• Organizations that achieve high level of Maturity in People

Management area have a higher likelihood of implementing effective
Software Engineering Practices.
 THE 4’Ps OF PROJECT MANAGEMENT
THE PRODUCT (Software Application )

• Before a Product can be Planned:-

- Product Objectives and Scope should be Planned

- Alternative solutions should be considered

- Technical and Management Constraints should be identified.

• Without the PRODUCT Plan it is not possible to define:-

a) Reasonable and accurate Estimates of Cost and

Effective Risk Management
b) Realistic breakdown of Project tasks (WBS)

c) Project Schedule that provides a meaningful indication of

progress.
 THE 4’Ps OF PROJECT MANAGEMENT
THE PROCESS

• Software Process provides the Framework from which a

comprehensive Plan for Software Development can be established.

• A small number of Framework activities are applicable to all

Software Projects regardless of Project size or complexity.

• A number of Different Task set however, such as :-

- Tasks
- Milestones
- Work Product (Deliverables)
- Quality Assurance points
enables the Framework activities to be adapted to the
characteristics of the Software Project and the requirements of the
Project team.
 THE 4’Ps OF PROJECT MANAGEMENT
THE PROJECT

• Software Project Development is conducted in a Planned and

Controlled way since it is only known way to manage complexity.
And yet we still struggle.

• In 1998 industry data indicated that 26% of Project failed outright

and 46% experienced Cost and Schedule overruns.
Although Project success rate for Projects has improved, yet Project
failure rate remains higher than it should be!

WHY PROJECTS FAIL

- An unrealistic Deadlines is established
- Changing Customer Requirements
- An honest underestimate of effort
- Predictable and/ or unpredictable risks
- Miscommunication among project staff
- Failure in Project Management practice
 THE 4’Ps OF PROJECT MANAGEMENT
THE PROJECT

• AVOIDING PROJECT FAILURE

- Project Managers and Software Engineers must:-

- Heed a set of common warning signs
- Understand the Critical Success Factor (CFS) that
lead to good Project Management
- Develop a common sense approach for
Planning, Monitoring and controlling a Project.
 THE 4’Ps OF PROJECT MANAGEMENT
THE PEOPLE AS PROJECT PLAYERS (STAKEHOLDERS)

• The Software Process is populated by People as Players or

otherwise called as Stakeholders. Who can be categories into one of
the Five constituencies:-

- Senior Mangers
- Project Managers
- Software Engineers (Practitioners)
- Customers or Clients
- End-users

• Since the Software Process is populated by People. The Project

Teem must be organized in a way to maximize each person’s skills
and ability. The Organization of the Project Team is the Job of
Project Team Leader may be called Project Manager.

• Companies that organizes and Manages their people wisely .

Prosper in the long run!!!
 THE 4’Ps OF PROJECT MANAGEMENT
TEAM LEADERS

• Project Management is a people-intensive

activity, and for this reason, competent
Software Practitioners often make poor
Team Leaders since they do not have the
right mix of people skills

• Many Practitioners unfortunately just fall

into a Project Manager role and become
accidentally Project Mangers.
 TEAM LEADERSHIP
TECHNICAL LEADERSHIP

• Jerry Weinberg suggests a Technical Leadership Model

(MOI). Based on Motivation, Organization and Ideas
(Innovation)
•
Weinberg also suggests that successful Project Leader
applies a Problem Solving Management Style.

PROBLEM SOLVING MANAGEMENT STYLE

• Concentrate on understanding the Problem to be

solved;

• Managing the flow of ideas and at the same time letting

everyone on the Project team (by word or action) that
quality counts and that it will not be compromised.
 TEAM LEADERSHIP
CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANAGER

• PROBLEM SOLVING
• MANAGERIAL IDENTITY
• ACHIEVEMENT
• INFLUENCE AND TEAM BUILDING

PROBLEM SOLVING

• An effective Project Manager can diagnosis Technical and organizational

issues that are most relevant;

• Systemically structure a solution or properly motivate other Software

Practitioners to develop the solution;

• Apply lessons learned from past Projects to new solutions and remain
flexible enough to change directions if initial attempt s are fruitless.
 TEAM LEADERSHIP
CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANMAGER

MANAGERIAL IDENTITY

• A good Project Manager take full charge of the Project;

• Have the Confidence to assume Project Control (when necessary);
• Gives assurance to allow good Technical people to follow their instincts.

ACHIEVEMENTS

• To optimize Productivity of a Project Team:-

- Manager must Reward initiative and accomplishments;

- Demonstrate through his/her own actions that ‘’Controlled Risk taking’’
will not be punished
 TEAM LEADERSHIP
CHARACTERISCTIC OF AN EFFECTIVE PROJECT MANMAGER

INFLUENCE AND TEAM BUILDING

• An effective Project Manager must be able to ’‘Read People’’, be able to

understand verbal and non-verbal symbols and react to the needs of the
people sending these signals

• Must remain in control in high stress situation.

.
 THE SOFTWARE TEAM
The Best Project Team Structure depends on:

• The Management style of the organization;

• The number of people, who will populate the team, and their
skill levels
• The overall problem difficulties.

MANTEI describes Seven Project Factors that should be considered

when Planning the structure of Software Engineering Teams.

1. The difficulty of the ‘Problem” to be solved

2. The ‘’Size’’ of the resultant programs in terms of Line Code (LOC) or
Function Points (FP)
3. The “Time” that the Team will stay together (Team Lifetime)
4. The degree to which the problem can be modularised.
5. The required Quality and Reliability of the System to be built
6. The rigidity of the Delivery Date
7. The degree of Sociability (Communication) required for the Project.
 THE SOFTWARE PROJECT TEAM TYPES
The word “Team” is fairly loosely used in Business world , calling any group of
people assigned to work together. But many of these groups just do not seem like
Teams. They do not have a common definition of success or ant identifiable “Team
Spirit”. What is missing is the phenomenon that is called “Jell”

HIGH PERFORMANCE TEAM

To achieve a high performance Project Team:-

• Team members must have trust in one another;

• The distribution of skills must be appropriate to the problem;
• Mavericks may have to be excluded from the team, if team cohesiveness is to be
maintained.

JELLED TEAM

• A Jelled Team is a group of people so strongly knit together that the whole is
greater than the sum of the parts…

– Once a team begins to jell, the probability of success goes way up. The team
can become unstoppable. A juggernaut for success… Team members do not
need to be managed in traditional way, and do not need to be motivated. They
have got momentum.

• Jelled Teams are significantly more productive and more motivated than average.
They share a common Goals, a common Culture, and in many cases a ‘’Sense of
eliteness’’ that make them unique.
 THE SOFTWARE PROJECT TEAM
For one reason or another not all Project Teams Jell. Many teams suffer
from what is called “Team Toxicity”.

FIVE FACTORS THAT FOSTERS A POTENTIALLY TOXIC TEAM ENVIRONMENT

1. A Frenzied work atmosphere

2. High frustration that causes friction among team members
3. A ‘’fragmented or poorly coordinated’’ Software Process
4. An unclear definition of roles on the Software team
5. Continuous and repeated exposure to failure.
 THE SOFTWARE TEAM
TEAM ANTITOXINS

• To avoid A Frenzied work environment, the Project Manager should be certain that
the Team has access to all Information required to do the job:

- The major Goals and objectives once defined should not be

changed unless absolutely necessary.

- Bad news should not be kept secret but rather delivered to

the team as early as possible.

• Software People often feel Frustration when there is a lack of Authority to control
their situation.

• Frustration (and Stress) can be avoided if Software team is given as much

Responsibilities for Decision Making as possible.

• An inappropriately chosen Process (e.g. unnecessary or burden some work

task or poorly chosen Work Product) can be avoided in two ways:

a) By understanding the Product to be built and the People doing the work.

b) By allowing the Project Team to select the Process Model

 THE SOFTWARE TEAM
TEAM ANTITOXINS (continued)

• Software Project Manager should clearly refine Roles and

Responsibilities of Team members before the Project begins.

- The Team itself should establish its own accountability and

define a series of corrective approaches when a member of
the team fails to perform.

• Every Software team experiences small failure. The key to avoid an

atmosphere of failure is to establish team-based techniques for
Feedback and Problem solving

Failure of a team must be viewed as a failure by the Team itself.

This leads to a Team-oriented approach to corrective action rather
than the finger pointing and mistrust that grows on Toxic Team.
 THE SOFTWARE TEAM
AGILE TEAMS
Agile Software Engineering combines a philosophy and a set of Development
Guidelines.

• The Philosophy encourages customer satisfaction with and early Incremental

delivery of Software by Small and highly motivated Project Teams.

• The Small, highly motivated Project team also called Agile Team , adopts
many characteristics of successful Project Teams and avoids many of the
toxins that create problems.

• Agile Team are Self-organized. A Self- Organizing team does not necessarily
maintain a single team structure but instead uses elements of random, open and
synchronous paradigms.

• Agile Team members competency coupled with Group Collaboration are

considered to be the Critical Success Factor for the team
 THE SOFTWARE TEAM
AGILE TEAMS (Continued)

Agile Process models give the Agile Teams autonomy to make Project
Management and Technical decisions required to get the job done.

– Planning is kept to a minimum

– Team is allowed to select its own approach (within the constraints of

business requirements and the organizational standards)

• As the Project proceeds, the Agile Team self organizes to focus individual
competency in a way that is most beneficial to the project at a given
point in time.

• To accomplish this:

– An Agile Team might conduct brief Daily Team meetings to coordinate and
synchronize the work that must be accomplished for the day.

• Based on information obtained from the daily meetings, the team adapts its
approach in a way that accomplishes an incremental of work.
• As each day passes, Continual Self-organizing and collaboration move the
team towards a completed Software Increment.
 HUMAN TRAITS OF SOFTWARE TEAM
A Software Team often struggles with the differing ‘’HUMAN TRAITS’’ of its
Team members :-

• Some Team members are extroverts; others are introverted

• Some people gather information intuitively, distilling broad concepts from

disparate facts. Others process information linearly, collecting and
organizing minute details from the data provided.

• Some members are comfortable making decisions only when a logical,

orderly argument is presented. Others are intuitive, willing to make a
decision based on ‘’Feel’’.

• Some want a detailed Project Schedule populated by organized tasks that

enable them to achieve closure for some elements of a Project. Others prefer
a more spontaneous environment in which open issues are okay.

• Some work hard to get things done well before the milestone date, thereby
avoiding stress as data approaches, while others are energized by the rush
to meet a last minute deadline.

It is important t o note that recognizing Human Traits is the first step

towards a building a creative Project Teams that Jell.
 SOFTWARE PRODUCT
A Software Project Manager is confronted with a dilemma at the very
beginning of a Software Engineering Project for the following reasons:

• Quantitaitive Project Estimates and an Organized Plan are required

but the Information (solid information) is not available as yet.

• Project Requirements may be fluid, changing regularly as the project

proceeds.

Yet a plan is needed “immediately”. !

A detailed analysis will provide all the solid information for Quantitaitive
Estimates and Project Plan . But Analysis often takes weeks or months to
complete

The ‘’Scope’’ of the Product must be established and bounded at the very
beginning of the Project.
 SOFTWARE SCOPE
The first activity of Software Manager is to determine the Scope of Software.

Software Scope is defined in collaboration with the User Management by

asking the following Questions on the following areas:-

- Software Context,
- Information Objectives
- Function and Performance of Software

• Software Context – How does the Software to be built fit into a larger System, Products
or Business Context, and what Constraints are imposed as a result
of the Context?
• Information Objectives – What Customer – visible Data Objectives are produced as Output
from the Software? What data objectives are required for Input?
• Function and Performance – What Functions does the Software Perform to transform
Characteristics to be addressed?

Software Poject Scope must be Unambigious and understandable at the Management

and Technical level’’.

A Statement of Software Scope must be bounded. (i.e. Quantitative data must be stated explicitly)

Constraint and / or Limitations are noted and mitigating factors (e.g. desired algorithms
are well understood and available in C++) are described .
 SOFTWARE SCOPE
PROBLEM DECOMPOSITION

During the Project Scoping no attempt is made to Decompose the Problem.

Rather decomposition is applied in two major areas :-

–The Functionality that must be delivered

–The Process that will be used to deliver it

Human beings tend to apply a Divide –and- conquer strategy when they
are confronted with a complex problem. A Complex Problem is partitioned
into smaller problems that are more manageable.

We apply the ‘’Divide and Conquer strategy’’ to partition a Product into

Smaller pieces so that can be managed better, as Project Planning begins.

Software Functions described in the Scope, are evaluated and refined to provide more
detail prior to the beginning of Estimation. Since both Cost and Schedules are
Functionally oriented, some degree of Decomposition is often useful.

As the Statements of Scope evolves, a first level of Partitioning naturally occurs.

 SELECTING PROCESS MODEL

The Project Manager must decide which Process Model is most

appropriate for :

– The Characteristics of Product itself

– The Customers and thePpeople who will do the work (users)
– The Project Environment in which the Software works

• After Selection of a Process Model , the Software Team then defines

a Preliminary Project Plan based on the set of ‘’Common Process
Framework’’ (CPF) Activities.

• Once the Preliminary Project Plan is established, Process

Decomposition begins.

A Complete Project Plan, reflecting the Work Tasks required to populate

the Framework Activities can be created .
MELDING THE PRODUCT AND PROCESS
• Project Planning begins with the melding of Product and the Process.

• Each Product Function to be engineered by the Software Team must

pass through the ‘’Set of Framework Activities’’ that has been defined
for a Software organization.
Assuming that an Organization has adapted the following ‘’Set of Common
Process Framework Activities’’.
• Communication
• Planning
• Modeling
• Construction
• Deployment

• Set of the Common Process Framework Activates are listed in the top row of
a matrix and the Software Engineering Work Tasks entered in the following
rows.

• The team members who work on the Product Function will apply each of the
Framework activities to it.
 MELDING THE PRODUCT AND PROCESS
• The job of the Project Manager is to Estimate Resource requirements Start
Dates and End Dates for the tasks associated with each cell, and work
Products to be produced as a consequence of each task.

COMMUNICATION

CONSTRUCTION
DEPLOYMENT
MODELING
PLANNING
COMMON PROCESS
FRAMEWORK ACTIVITIES

SOFTWARE ENGINEERING TASKS

Product Functions
Text Input
Editing and Formating
Automatic Copy Edit
…………………………...
………………………..
………………………….
File Management
Document Production
MELDING THE PRODUCT AND PROCESS
• The Process Framework is invariant and serves as the basis for all Software
work performed by Software organization.

• The Actual Software Engineering Tasks (i.e. Work Task) do actually vary.

• Work Tasks must be adapted to the specific needs of the Project.

• Process decomposition commences when the project manager asks,

’’How do we accomplish this Framework Activity’’?

For example: A small relatively simple Project might require the following ‘’Work
Tasks’’ for the ‘’Communication Activity’’:

1. Develop list of clarification issues

2. Meet with Customer to address clarification issues
3. Jointly develop a statement of Scope
4. Review the Scope with all concerned
5. Modify the Statement of Scope as required
 THE PROJECT
In order to manage a Successful Software Project, we must understand
What can go wrong so that the problem can be avoided,

John Reel defines 10 Signs that indicate an Information Systems Project

is in Jeopardy:-

1. Software People don’t understand their Customers’

needs
2. The Product Scope is poorly defined
3. Changes are managed poorly
4. The chosen Technology changed
5. Business needs change or ill defined
6. Project Deadlines are unrealistic
7. Users are resistant
8. Sponsorship is lost (or never obtained)
9. The Project Team lacks People with appropriate skills
10. Managers / Practitioners avoid best practice and Lessons
learned.
 AVOIDING PROBLEMS SIGNED BY JEOPARDY
Jaded Industrial Professionals often refer (half facetiously) to the
90 – 90 Rule when discussing particularly difficult Software
Projects.

The seeds that lead to the 90 – 90 rule are contained in the 10 Project
Jeopardy Signs.

90 – 90 RULE

– The first 90 % of a System absorbs 90 % of the Allocated Effort and Time.

– The last 10 % takes the other 90 % of the Allocared Effort and Time.

John Reel Suggests a Five-part Common-sense approach to avoid Project

Problems:-

1. Start with right foot

2. Maintain Momentum
3. Track Progress
4. Make Smart Decision
5. Conduct a Post-mortems Analysis
 AVOIDING PROBLEMS SIGNED BY JEOPARDY
1. START WITH RIGHT FOOT

• This is accomplished by working hard to understand the problem that

is to be solved and then setting realistic objectives and expectations
for everyone who will be invloved in the Project.
• This is achieved by building the ‘’Right Team’’ and giving the Team the
autonomy, authority and technology needed for job
2. MAINTAIN MOMENTUM :

Many Project get off a good start and then slowly disintegrate. To maintain
momentum:-
 The Project Team should emphasize quality in every task it performs.
 The Project Manager must provide initiatives to keep ‘’Staff turnover’’ to an
absolute minimum.
 Senior Management should do everything posssible to ‘’Stay out of the
Project Team’s way’’.
• (Management should reduce bureaucracy to a minimum, Eleminate
exraneaos meetings and eliminate dogmatic adherence to Project rules.
The Project team should be self-organizing and autonomous.
 AVOIDING PROBLEMS SIGNED BY JEOPARDY
3. TRACK PROGRESS

• Progress is tracked as Work products (i.e Specification, Source code, Test

results etc) are produced and approved (using Formal technical reviews),
as part of a Quality Assurance activity.

• Additionally, Software Process and Project Measures can be collected and

used to ‘’Assess Progress Against Averages’’ developed for the Software
Development Organizations.

4. MAKE SMART DECISION

In essence, the decisions of Project Manager and the Software Team should be
‘’keep ıt sımple”. Whenever possible decide to:-

• Use , commercial ‘Off- the -shelf Software’’ or Existing Software components.

• Avoid Custom Interface when standard approaches are available.
• Identify and then avoid obvious risks,
• Allocate more time than you think is needed to complex or risky tasks.
 AVOIDING PROBLEMS SIGNED BY JEOPARDY
5. CONDUCT A POSTMORTEN ANALYSIS

• Establish a Consistent mechanism for extracting lessons learned for

each Project.
• Evaluate Planned and Actual Schedules
• Collect and Analyze Software Project Metrics
• Record findings in written form
 THE W5HH PRINCIPLE
BOEHM suggest an organizing Principle that scale down to
provide simple Project Plans for simple Projects.

Boehm suggests an Approach that addresses the following areas:

• Project Objectives
• Milestones and Schedules
• Responsibilities
• Management and Technical approaches
• Required Resources
 THE W5HH PRINCIPLE
W5HH (WWWWWHH) Principle is based on a series of questions that
leads to a definition of key Project Characteristics and the resulting
Project Plan.

• Why is the System being Developed?

• What will be done?
• When will it be done?
• Who is responsible for a function?
• Where are they organizationally located?
• How will the job be done technically and Managerially?
• How much of each resource is needed?
 THE W5HH PRINCIPLE
Why is the System being Developed?
The answer to this question enables all parties to asses the validity of business reasons for the
Software work. (To justify the expenditure of People, Time, and Money for the Business purpose)

What will be done?

The answer establishes the task set that will be required for the project

When will it be done?

The answer helps the Project Team to establish a Project Schedule by identifying when Project Tasks
are to be conducted and when Milestones are to be reached.

Who is responsible for a function?

The answer helps to define the roles and responsibilities of each member within the Project team.

Where are they organizationally located?

Not all roles and responsibilities reside within the Project team itself. Users, Customers and other
stakeholders may have responsibilities as well.

How will the job be done technically and Managerially?

Once Product Scope is established a Management and Technical strategy for Project must
be defined.

How much of each resource is needed?

The answer is derived by developing estimates based on answers of the above questions
 CRITICAL PRACTICES
A team of Software Engineering experts has developed a list of ‘’Critical
Software Practices for Performance-based Management;

These practices are consistently used by , and considered critical by , highly

successful Software Projects and Organizations whose ‘bottom line’
performance is consistently much better than industry averages.

Critical Practices include the followings

 Metric-based Project Management

 Empirical Costs and Schedule Estimation
 Earned Value Tracking
 Formal Risk Management
 Defect Tracking Against Quality Targets
 People Aware Management

The Critical Practices is also known as QUICK LOOK QUESTIONS.

 SUMMARY
• The Project Management activity encompasses Measurements
and Metrics, Estimation and Scheduling, Risk Analysis,
Tracking, and Project Control .

• The pivot element in all Software Projects is ‘’PEOPLE’’.

• Software Engineers can be organized in a number of different

Team structures that ranges from Traditional control hierarchies
to ‘’Open Paradigm’’ Project Teams.

• A variety of coordination and communication techniques can be

applied to support the work of the Project Team. In general,
Formal reviews and Informal person-to-person communication
have the most value for Software Practitioners.

• Each of the Project Management Activity is considered in the

chapters that follow.