Management Spectrum

Presented by :
Lunas, Venus
Montesa, Judy

What is Management Spectrum?

The management spectrum describes the
management of a software project or how to
make a project successful. It focuses on the
four Ps; people, product, process and project.
Here, the manager of the project has to
control all these Ps to have a smooth flow in
the project progress and to reach the goal.

Management Spectrum
The
The
The
The

People
product
Process
Project

The People
In a study published by the IEEE [CUR88], the
engineering vice presidents of three major
technology companies were asked the most
important contributor to a successful software
project. They answered in the following way:
VP 1: I guess if you had to pick one thing out that is most
important
in our environment, I'd say it's not the
tools that we use, it's
the people.

VP 2: The most important ingredient that was successful on this

project was having smart people . . . very little else matters in
my opinion. . . . The most important thing you do for a project is
selecting the staff . . . The success of the software
development organization is very, very much associated with
the ability to recruit good people.
VP 3: The only rule I have in management is to ensure I have good
peoplereal good peopleand that I grow good peopleand that
I provide an environment in which good people can produce.

In fact, the people factor is so important that the

Software Engineering Institute has developed a people
management capability maturity model (PM-CMM),
to enhance the readiness of software organizations
to undertake increasingly complex applications by
helping to attract, grow, motivate, deploy, and retain
the talent needed to improve their software
development capability

The Players
The software process (and every software project) is populated by
players who can be categorized into one of five constituencies:
1. Senior managers who define the business issues that often
have significant influence on the project.
2. Project (technical) managers who must plan, motivate,
organize, and
control the practitioners who do software work.

3.

Practitioners who deliver the technical skills that are necessary to

engineer a product or application.
4. Customers who specify the requirements for the software to be
engineered and other stakeholders who have a peripheral interest in
the outcome.
5. End-users who interact with the software once it is released for
production
use.

Team Leaders
In an excellent book of technical leadership, Jerry Weinberg
[WEI86] suggests a MOI model of leadership:
Motivation. The ability to encourage technical people to
produce to their
best ability.
Organization. The ability to mold existing processes (or
invent new ones)
that will enable the initial concept to
be translated into a final
product.
Ideas or innovation. The ability to encourage people to
create and feel
creative

Team Leaders
Another view of the characteristics that define an effective
project manager emphasizes four key traits:
Problem solving. An effective software project manager can diagnose the
technical and organizational issues.
Managerial identity. A good project manager must take charge of the project.
Achievement. To optimize the productivity of a project team, a manager must
reward initiative and accomplishment.
Influence and team building. An effective project manager must be able to
read people. The manager must remain under control in high-stress
situations.

The Software Team

The following options are available for applying human resources to
a project that will require people working for years:
1. Individuals are assigned to different functional tasks, relatively little
combined work occurs; coordination is the responsibility of a
software manager who may have six other projects to be
concerned with.
2. Individuals are assigned to different functional tasks so that
informal "teams" are established; coordination among teams is the
responsibility of a software manager.
3. individuals are organized into teams; each team is assigned one or
more functional tasks; coordination is controlled by both the team
and a software project manager.

3 generic team organizations:

1. Democratic decentralized (DD) : This software engineering

team has no permanent leader. Rather, "task coordinators are
appointed for short durations and then replaced by others who
may coordinate different tasks." Decisions on problems and
approach are made by group consensus.
2. Controlled decentralized (CD). This software engineering
team has a defined leader who coordinates specific tasks and
secondary leaders that have responsibility for subtasks.
Problem solving remains a group activity, but implementation of
solutions is partitioned among subgroups by the team leader.

3 generic teamorganizations:

3. Controlled Centralized (CC). Top-level problem

solving and internal
team coordination are managed by a team leader.
Communication
between the leader and team members is vertical.

Coordination and Communication Issues

There are many reasons that software projects get into
trouble. The scale of many development efforts is
large, leading to complexity, confusion, and significant
difficulties in coordinating team members. Uncertainty
is common, resulting in a continuing stream of changes
that ratchets the project team. Interoperability has
become a key characteristic of many systems. New
software must communicate with existing software.

To deal with them effectively, a software engineering team

must
establish effective methods for coordinating the people who
do the work. To accomplish this, mechanisms for formal and
informal communication among team members and
between multiple teams must be established.
Formal communication is accomplished through writing,
structured meetings, and other relatively noninteractive
and impersonal communication channels.
Informal communication is more personal. Members of a
software team share ideas on an ad hoc basis,
ask for help as problems arise, and interact with one
another on a daily basis.

Collection of project coordination techniques

are categorized in the following manner:

Formal, impersonal approaches include software engineering

documents and deliverables (including source code, technical
memos, project milestones, schedules, and project control tools
change requests and related documentation error tracking
reports, and repository data).
Formal, interpersonal procedures focus on quality assurance
activities
applied to software engineering work products. These include
status review meetings and design and code inspections.

 Informal, interpersonal procedures include group

meetings for information dissemination and problem solving.
Electronic communication encompasses electronic mail,
electronic bulletin boards, and by extension, video-based
conferencing systems.
Interpersonal networking includes informal discussions
with team members and those outside the project who may
have experience or insight that can assist team members.

The Product
Product is any software or project that has to be
developed. To develop successfully, product objectives and
scope should be established, alternative solutions should
be considered, and technical and management constraints
should be identified. Without this information, it is
impossible to define reasonable and accurate estimates of
the cost, an effective assessment of risk, a realistic
breakdown of project tasks or a manageable project
schedule that provides a meaningful indication of
progress.

Software Scope
The first software project management activity is the determination of
software scope. Scope is defined by answering the following questions:
Context. How does the software to be built fit into a larger system,
product, or
business context and what constraints are imposed as a result of the
context?
Information objectives. What customer-visible data objects are
produced as
output from the software?
What data objects are required for input?
Function and performance. What function does the software perform to
transform input data into output? Are any special performance
characteristics to be addressed?

Software Scope
Software project scope must be unambiguous and
understandable at the management and technical levels.
Scope is presented in quantitative data (e.g., number of
simultaneous users, size of mailing list, maximum
allowable response time) are stated explicitly.
constraints and/or limitations
(e.g., product cost restricts memory size) are noted

Problem Decomposition
Problem decomposition, sometimes called partitioning or
problem elaboration, is an activity that sits at the core of
software requirements analysis.
It is aproblemsolving strategy of breaking aproblemup
into a set of subproblems, solving each of the subproblems,
and then composing a solution to the originalproblem.

The Process
A software process provides the framework from
which a comprehensive plan for software
development can be established.
Generic Phases
Deffinition
Development
Support

The Process
Software Engineering Paradigms

Linear sequential model

Prototyping model
RAD model
Incremental model
Spiral model
WINWIN spiral model
Component-based development
model
Concurrent development model
Formal methods model
Fourth generation techniques model

Melding the product and the Process

The Project
The project includes all and everything of the total
development process and to avoid project failure the
manager has to take some steps, has to be concerned
about some common warnings etc.

10 signs that indicate an information system is in

jeopardy

Software people dont understand their customers needs.

The product scope is poorly defined.
Changes are managed poorly.
The chosen technology changes
Business needs change [or are ill-defined].
Deadlines are unrealistic.
Users are resistant.
Sponsorship is lost [or was never properly obtained].
The project team lacks people with appropriate skills.
Managers [and practitioners] avoid best practices and
lessons learned.

5 part commonsense approach to software projects:

Start on the right foot

Maintain momentum
Track progress
Make smart decisions
Conduct a postmortem analysis

THE W5HH PRINCIPLE

Barry Boehm states: you need an organizing principle that
scales down to provide simple [project] plans for simple
projects.
Why is the system being developed?
What will be done, by when?
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?

CRITICAL PRACTICES

Formal risk management

Empirical cost and schedule estimation
Metric-based project management
Earned value tracking
Defect tracking against quality targets
People-aware program management