1. Project Management Concepts
Developed by Reneta Barneva, SUNY Fredonia

2. The Management Spectrum
Effective software management focuses on 4 P’s:
people
product
process
project
The order is not arbitrary.
Developed by Reneta Barneva, SUNY Fredonia

3. 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.
Developed by Reneta Barneva, SUNY Fredonia

4. 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.
Developed by Reneta Barneva, SUNY Fredonia

5. 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.
Developed by Reneta Barneva, SUNY Fredonia

6. 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.
Developed by Reneta Barneva, SUNY Fredonia

7. 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.
Developed by Reneta Barneva, SUNY Fredonia

8. Developed by Reneta Barneva, SUNY Fredonia
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.
Developed by Reneta Barneva, SUNY Fredonia

9. 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
Developed by Reneta Barneva, SUNY Fredonia

10. The People: Team Leaders
How to select the leader:
motivation
organization
ideas of innovation
Developed by Reneta Barneva, SUNY Fredonia

11. 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.
Developed by Reneta Barneva, SUNY Fredonia

12. The People: The Software Team
Mantei suggests three generic team organizations:
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.
Developed by Reneta Barneva, SUNY Fredonia

13. The People: The Software Team
Mantei suggests three generic team organizations:
Controlled centralized (CC):
Has a defined leader who controls the project.
Communication between the leader and team members are vertical.
Developed by Reneta Barneva, SUNY Fredonia

14. The People: The Software Team
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.
Developed by Reneta Barneva, SUNY Fredonia

15. The People: The Software Team
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
Developed by Reneta Barneva, SUNY Fredonia

16. 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
Developed by Reneta Barneva, SUNY Fredonia

17. 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 - , videoconferencing, etc.
Interpersonal networking - informal discussions with team members.
Developed by Reneta Barneva, SUNY Fredonia

18. 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?
Developed by Reneta Barneva, SUNY Fredonia

19. 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.
Developed by Reneta Barneva, SUNY Fredonia

20. Developed by Reneta Barneva, SUNY Fredonia
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
Developed by Reneta Barneva, SUNY Fredonia

21. 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
Developed by Reneta Barneva, SUNY Fredonia

22. The Process: Melding the Product and the Process
Developed by Reneta Barneva, SUNY Fredonia

23. 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.
Developed by Reneta Barneva, SUNY Fredonia

24. 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.
Developed by Reneta Barneva, SUNY Fredonia

25. Developed by Reneta Barneva, SUNY Fredonia
The Project
Does 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.
Developed by Reneta Barneva, SUNY Fredonia

26. Developed by Reneta Barneva, SUNY Fredonia
The Project
Reel 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.
Developed by Reneta Barneva, SUNY Fredonia

27. Developed by Reneta Barneva, SUNY Fredonia
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.
Developed by Reneta Barneva, SUNY Fredonia

28. The W5HH Principle of 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.
Developed by Reneta Barneva, SUNY Fredonia

29. The W5HH Principle of 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.
Developed by Reneta Barneva, SUNY Fredonia

30. Developed by Reneta Barneva, SUNY Fredonia
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?
Developed by Reneta Barneva, SUNY Fredonia

31. Developed by Reneta Barneva, SUNY Fredonia
Critical Practices
Metric-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