1. Software Engineering (CSI 321)
Project Management

2. What is a Project?
Project : A planned undertaking of related activities to reach an objective that has a beginning and an end.

3. What is Project Management?
Project management is a controlled process of initiating, planning, executing, and closing down a project.
Project management involves the planning, monitoring, and control of the people, process, and events that occur as software evolves from a preliminary concept to full operational deployment.
Software project management is an umbrella activity within software engineering.
It begins before any technical activity is initiated and continues throughout the modeling, construction, and deployment of computer software.

4. What is Project Management?
Managing the accomplishments of a software development project according to a specific project plan, in order that a project is completed on time, and within its budget , and meets its design objectives.
Project management activity encompasses measurement and metrics, estimation and scheduling, risk analysis, tracking , and control.

5. Why Project Management is important?
Developing 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.
Software project management is an essential part of software engineering and may be the most important aspect of software development.
Effective Project Management helps ensure system development projects –
Meet customer expectations
Delivered within budget and time constraints

6. The Management Spectrum
Effective software project management focuses
on the four P’s:
People – Organized, motivated, coordinated
Product – Requirements well-understood
Process – Appropriate for people & product
Project – Must be organized in a manner that enables the software team to succeed.

7. People: The Stakeholders
Senior managers/Business managers –defines business issues that often have significant influence on the project
Project(technical) managers –must plan, motivate, organize, control practitioners who do software work
Practitioners –deliver the technical skills that are necessary to develop a product
Customers –specify the requirements for the software to be engineered
End-users –interact with the software once it is released for production use

8. Characteristics of Team Leader/Project Manager
A model of leadership: The MOI model
Motivation - Ability to encourage technical people to produce to their best ability.
Organization – Ability to mold existing processes that will enable initial concept to be translated into a final product.
Innovation- Ability to encourage people to create and feel creative.
Successful project leaders apply a problem solving management style. A software project manager should concentrate on understanding the problem to be solved, managing the flow of ideas, and at the same time, letting everyone on the team know that quality counts & that it will not be compromised.

9. Characteristics of Team Leader/Project Manager
An effective project manager emphasizes four key traits:
Problem solving
Managerial identity
Achievement
Influence and team building

10. Software Teams How to lead? How to organize? How to collaborate?
How to motivate?
How to create good ideas?

11. Software Teams
What factors should be considered when the structure of a software team is chosen?
The difficulty of the problem to be solved
The size of the resultant program(s) in lines of code or function points
The time that the team will stay together (team lifetime)
The degree to which the problem can be modularized
The required quality and reliability of the system to be built
The rigidity of the delivery date
The degree of sociability (communication) required for the project

12. “Organizational Paradigms” for Software Teams
Software engineers can be organized in a number of different team structures:
Closed paradigm—structures a team along a traditional hierarchy of authority.
Random paradigm—structures a team loosely and depends on individual initiative of the team members.
Open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm.
Synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves.
…suggested by Constantine [CON93]

13. Avoid “Team Toxicity”
Why do many software teams suffer from “Team Toxicity”? // What are the five factors that foster a potentially toxic team environment?
A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed.
High frustration (caused by personal, business, or technological factors ) that causes friction among team members.
A “Fragmented or poorly coordinated” software process or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment.
Unclear definition of roles on the software team (resulting in a lack of accountability and resultant finger-pointing).
“Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.

14. Agile Software Development
The characteristics of Agile Software Development
Adaptable and incremental software process
Encourages customer satisfaction
Incremental delivery of software
Small, highly motivated project teams
Informal methods
Overall development simplicity

15. Agile Teams
An agile team is a self-organizing team that has autonomy to plan and make technical decisions.
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.
Stresses individual (team member) competency coupled with group collaborations as critical success factors for the team.

16. Agile Teams Team is “self-organizing”
A small, highly motivated, and adaptive team structure
Uses elements of Constantine’s random, open, and synchronous paradigms
Significant autonomy

17. Team Coordination & Communication
Formal, impersonal approaches
SE documents and work products, project milestones, schedules, change request documents, error tracking reports
Formal interpersonal approaches
review meetings, inspections
Informal interpersonal approaches
group meetings for information dissemination and problem solving
Electronic communication
, video conferencing
Interpersonal network
Informal discussions with team members and those outside the project who may have experience or insight that can assist team members

18. The Product
The Product(Software) scope: Software project scope must be unambigguous and understanable at the management and technical level. Scope is defined by answering the following questions –
Context: How does the s/w to be built fit into a larger system or business context? What are constraints?
Information objectives: What customer-visible data objects are produced as output? What data objects are required for input?
Function: What functions does the s/w perform to transform input data into output?
Performance: Are there any special performance characteristics to be addressed?

19. The Product Problem decomposition
Also called partitioning or problem elaboration
Sits at the core of software requirements analysis
Applied in two major areas
Functionality that must be delivered
The process used to deliver it
To develop a reasonable project plan, you must decompose the problem.
List of functions/use-cases
User stories(for agile work)

20. The Process Common Process Framework Activities:
Communication
Planning
Modeling
Construction
Deployment
Work tasks may vary but the common process framework activities are invariant. The framework activities that characterizes the software process are applicable to all software projects. The problem is to select the process model that is appropriate for the software to be engineered by the project team.

21. The Process
The project manager must decide which process model is most appropriate for –
customers
developers
characteristics of the product
project development environment

22. Customer Communication Activity
Customer Communication Activities for a small and relatively simple project:
Develop list of communication issues
Meet with customer to address clarification issues
Jointly develop a statement of scope (Statement of Work)
Review statement of scope/work (SoW) with all concerned
Modify SoW as required

23. Customer Communication Activity
Customer Communication Activities for a large and relatively complex project:
Review customer request
Plan and schedule formal meeting with customer (regular)
Conduct research to specify the proposed solution and existing approaches
Prepare working doc and agenda for the formal meeting
Conduct the meeting
Jointly develop mini-scope
Review SoW with all concerned
Modify SoW doc as required

24. The Project What are signs that a software 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.

25. Common-Sense Approach to Manage Software Projects
Start on the right foot : Accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations.
Maintain momentum: Project manager must provide incentives to keep turnover of personnel to an absolute minimum, 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 : Progress is tracked as work products are produced and approved as part of a QA activity.
Make smart decisions: “keep it simple.”
Conduct a postmortem analysis: Establish a consistent mechanism for extracting lessons learned for each project.

26. The W5HH Principle How to define key project characteristics?
==> Barry Boehm’s W5HH Principle
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 & managerially?
How much of each resource is needed?

27. Critical Software 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