developed by reneta barneva, suny fredonia project management concepts

Developed by Reneta Barneva, SUNY Fredonia

Project Management Concepts


The Management Spectrum

Effective software management focuses on 4 P’s:

people

product

process

project

The order is not arbitrary.


The Management Spectrum:People

This factor is so important that Software Engineering Institute developed a people management capability maturity model (PM-CMM). To help the organizations to:

attract,

grow,

motivate,

deploy,

and retain

the talent needed to improve their software development capability.


The Management Spectrum:People

People management capability maturity model (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.


The Management Spectrum:Product

Before a project can be planned,

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 not possible to define

reasonable estimates of the cost,

an effective assessment of risk,

a realistic breakdown of project tasks.


The Management Spectrum:Process

Process defines the framework for a set of key process areas that must be establish for effective delivery of SE technology.

Key process areas include:

technical methods

work products (model, documents, data, reports, forms, etc.)

milestones

changes to be done.


The Management Spectrum:Project

Planned and controlled software projects are the only way to manage complexity.

In 1998:

26% of the software projects failed outright

46% experienced cost and schedule overruns

In order to avoid this program manager must:

avoid a set of common warning signs

understand the critical success factors

develop a commonsense approach for planning.


The People

In a study published by IEEE the vice presidents of three major technology companies answer that the most important contributor to a successful project are the people.


The People Related to Software Project

1. Senior managers who define the business issues and have significant influence on the project

2. Project managers who must plan, motivate, organize, and control the practitioners

3. Practitioners who deliver the technical skills that are necessary to engineer a product

4. Customers who specify the requirements for the software to be engineered

5. End-users who interact with the software once it is released


The People: Team Leaders

How to select the leader:

motivation

organization

ideas of innovation


The People: The Software Team

Mantei suggests three generic team organizations:

Democratic decentralized (DD):

Has no permanent leader.

Task coordinators are appointed for short periods of time.

Decisions are made by group consensus.

Communications among members are horizontal.




Controlled decentralized (CD):

Has a defined leader who controls the project and secondary leaders responsible for subtasks.

Problem solving remains a group activity, but implementation of solutions is partitioned among subgroups by the team leader

Communication among subgroups and individuals are horizontal. Vertical communication along the control hierarchy also occurs.




Controlled centralized (CC):

Has a defined leader who controls the project.

Communication between the leader and team members are vertical.



Centralized structure completes tasks faster. It is better for simple problems.

Decentralized teams generate more and better solutions than individuals. Better for difficult problems.

DD team structures result in high morale and job satisfaction. Good for teams that stay together long time.



Typical centralized team:

senior engineer

technical staff (2-5 people) - conduct analysis and development activities

backup engineer - supports and can replace the senior engineer

specialists (database designer, communications expert, etc.)

support staff - technical writers, clerical staff

software librarian - maintains the documentation, helps data collection, catalog reusable components


The People: Coordination and Communication Issues

There are many reasons the software project to get into trouble:

The project is very complex -> difficulties in coordinating team members

Uncertainty is common

Interoperability - new software must communicate with existing software


The People: Coordination and Communication Issues

Project coordination techniques:

Formal, impersonal approaches - memos, schedules, project milestones

Formal, interpersonal procedures - status review meetings and design and code inspections

Informal, interpersonal procedures - group meetings and problem solving

Electronic communications - e-mail, videoconferencing, etc.

Interpersonal networking - informal discussions with team members.


The Product: Software Scope

The first step in each project is to determine software scope.

Context - part of a large system

Information objectives - what customer visible data objects are produced as output from the software. What are the input.

Function and performance - what function does the software perform to transform input data into output?


The Product: Problem Decomposition

Problem decomposition is the core of software requirement analysis.

Applied to two major areas:

1) The functionality

2) The process

Based on divide and conquer strategy.


The Process

The project manager must decide which process model is most appropriate for:

the customers and the users

the characteristics of the project itself

the project environment in which software team works


The Process: Melding the Product and the Process

Project planning begins with melding the product and the process. Each function to be engineered passes through a set of framework activities.

Customer communication

Planning - to refine resources, timelines

Risk analysis - tasks required to access both technical and management risks

Engineering - tasks required to build one or more representations of the application

Construction and release - task required to construct, test, install, and provide user support

Customer evaluation - tasks required to obtain customer evaluation


The Process: Melding the Product and the Process


The Process: Process Decomposition

A small, relatively simple project might require the following work tasks for the customer communication activity:

•Develop list of clarification issues.

•Meet with customer to address clarification issues.

•Jointly develop a statement of scope.

•Review the statement of scope with all concerned.

•Modify the statement of scope as required.


The Process: Process Decomposition

A more complex project might require the following work tasks for the customer communication activity:

•Review the customer request.

•Plan and schedule a formal, facilitated meeting with the customer.

•Conduct research to specify the proposed solution and existing approaches.

•Prepare a "working document" and an agenda for the formal meeting.

•Conduct the meeting.

•Jointly develop mini-specs that reflect data, function, and behavioral features of the software.

•Review each mini-spec for correctness, consistency, and lack of ambiguity.

•Assemble the mini-specs into a scoping document.

•Review the scoping document with all concerned.

•Modify the scoping document as required.


The ProjectDoes it go wrong? John Reel defines ten signs that indicate that an information systems project is in jeopardy:

•Software people don't understand their customer's 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.


The ProjectReel suggests a five-part commonsense approach to software projects:

•Start on the right foot. Building the right team and giving the team the autonomy, authority, and technology needed to do the job.

•Maintain momentum. Many projects get off to a good start and then slowly disintegrate. The team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team's way.

•Track progress. For a software project, progress is tracked as work products (e.g., specifications, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity.


The Project•Make smart decisions. In essence, the decisions of the project manager and the software team should be to "keep it simple." Whenever possible, decide to use commercial off-the-shelf software or existing software components, decide to avoid custom interfaces when standard approaches are available, decide to identify and then avoid obvious risks, and decide to allocate more time than you think is needed.

•Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project. Evaluate the planned and actual schedules, collect and analyze software project metrics, get feedback from team members and customers, and record findings in written form.


The W5HH Principleof Barry Boehm

What questions need to be answered in order to develop a project plan?

Why is the system being developed? The answer to this question enables all parties to assess the validity of business reasons for the software work. Stated in another way, does the business purpose justify the expenditure of people, time, and money?

What will be done, by when? The answers to these questions help the team to establish a project schedule by identifying key project tasks and the milestones that are required by the customer.

Who is responsible for a function? Earlier in this chapter, we noted that the role and responsibility of each member of the software team must be defined. The answer to this question helps accomplish this.


The W5HH Principleof Barry Boehm

Where are they organizationally located? Not all roles and responsibilities reside within the software team itself. The customer, users, and other stakeholders also have responsibilities.

How will the job be done technically and managerially? Once product scope is established, a management and technical strategy for the project must be defined.

How much of each resource is needed? The answer to this question is derived by developing estimates based on answers to earlier

questions.


Critical Practices

Developed by Airlie Council in order to help develop guidelines for best practices in software engineering.

Formal risk management. What are the top ten risks for this project? For each of the risks, what is the chance that the risk will become a problem and what is the impact if it does?

Empirical cost and schedule estimation. What is the current estimated size of the application software (excluding system software) that will be delivered into operation? How was it derived?


Critical PracticesMetric-based project management. Do you have in place a metrics program to give an early indication of evolving problems? If so, what are the current requirements?

Earned value tracking. Do you report monthly earned value metrics? If so, are these metrics computed from an activity network of tasks for the entire effort to the next delivery?

Defect tracking against quality targets. Do you track and periodically report the number of defects found by each inspection (formal technical review) and execution test from program inception and the number of defects currently closed and open?

People-aware program management. What is the average staff turnover for the past three months for each of the suppliers/developers involved in the development of software for this system?

developed by reneta barneva, suny fredonia project management concepts

Documents

reneta barneva

software people

people product process

performance management

management constraints

project managers

process process

successful project