SE201 - Comprehensive Guide to Project Management Principles
Demonstrate project management skills by working effectively in small teams, and cooperatively with other teams.
Software project management is a critical discipline that focuses on planning, organizing, and controlling software development projects. Effective project management ensures that software projects are delivered on time, within budget, and meet quality standards.
Effective software project management focuses on four key elements, known as the Four P's:
The most important element of a successful project. This includes stakeholders, team members, and all individuals involved in or affected by the project.
The software to be built. Understanding the product scope, requirements, and constraints is essential for project success.
The set of framework activities and software engineering tasks required to get the job done. This includes the chosen development methodology.
All work and planning required to make the product a reality. This encompasses schedules, resources, and deliverables.
Define business issues and provide strategic direction with significant project influence.
Plan, motivate, organize, and control practitioners who perform software work.
Deliver technical skills necessary to engineer a product or application.
Specify requirements and have peripheral interest in outcomes.
Interact with software once released for production use.
The ability to encourage technical people to produce to their best ability through push or pull strategies.
The ability to mold existing processes or invent new ones to translate concepts into final products.
The ability to encourage creativity even when working within established bounds.
Agile philosophy emphasizes individual competency coupled with group collaboration as critical success factors:
Understanding the product scope is essential for effective project management. The scope defines what will be built and establishes boundaries for the project.
How does the software fit into a larger system, product, or business context? What constraints are imposed as a result?
What customer-visible data objects are produced as output? What data objects are required for input?
What function does the software perform to transform input data into output? Are there special performance characteristics to address?
The software project scope must be unambiguous and understandable at both management and technical levels:
Decomposition is a core activity in software requirements analysis, sometimes called partitioning or problem elaboration.
A complex problem is partitioned into smaller, more manageable problems, providing a reasonable understanding of the information to be produced.
The process model defines how the software will be developed. The team must select an appropriate model based on multiple factors.
Choose appropriate process model
Create preliminary project plan
Define task sets for each activity
Project planning begins with applying the process to the problem. Each function to be engineered must pass through the framework activities defined for the organization.
Major product functions such as text input, editing and formatting, automatic copy edit, page layout capability, automatic indexing and TOC, file management, and document production all pass through common process framework activities including communication, planning, modeling, construction, and deployment.
The Project Team is the primary resource!
Almost all software products are obtained via projects with limited resources achieving interdependent and conflicting goals.
Project Concern: Deliver on time and within budget
Progress is tracked as work products (models, source code, test cases) are produced and approved through technical reviews as part of quality assurance.
Getting to the essence of a project requires answering these fundamental questions:
Why is the system being developed? Establishes business justification.
What will be done? Establishes the task set required for the project.
When will it be done? Establishes project schedule with task timing and milestones.
Who is responsible? Establishes roles and responsibilities of each team member.
Where are they organizationally located? Indicates that responsibilities extend beyond the software team to customers, users, and stakeholders.
How will the job be done technically and managerially? How much of each resource will be needed?
It is essential for a software organization to deliver a quality product, keeping costs within the client's budget constraint and delivering the project as scheduled.
There are several factors, both internal and external, which may impact this triple constraint triangle. Any of the three factors can severely impact the other two.
Project scheduling refers to the roadmap of all activities to be done in a specified order with a time slot allotted to each activity.
The hierarchical decomposition of a project into phases, activities, and tasks with their sequences. Some tasks are performed in parallel while others follow sequentially.
Project Goal (0)
├── Phase 1
│ ├── Activity 2.1
│ ├── Activity 2.2
│ │ ├── Task 2.2.1 (Primitive)
│ │ ├── Task 2.2.2 (Primitive)
│ │ └── Task 2.2.3 (Primitive)
│ └── Activity 2.3
├── Phase 2
└── Phase 3
PDM is a technique for scheduling project activities by displaying them in a network diagram to identify the critical path.
| Activity | Predecessor | Duration (Days) |
|---|---|---|
| A | --- | 1 |
| B | --- | 2 |
| C | --- | 2 |
| D | A | 4 |
| E | B | 5 |
| F | B | 4 |
| G | C | 6 |
| H | D, E | 6 |
| I | G | 2 |
| J | F, H, I | 3 |
The critical path is the sequence of connected activities that produces the longest overall time period. This represents the minimum time required to finish the project.
Example Critical Path: B → E → H → J (Total Float = 0 for each task)
| Task | Early Start | Early Finish | Late Start | Late Finish | Total Float |
|---|---|---|---|---|---|
| B | 0 | 2 | 0 | 2 | 0 |
| E | 2 | 7 | 2 | 7 | 0 |
| H | 7 | 13 | 7 | 13 | 0 |
| J | 13 | 16 | 13 | 16 | 0 |
| A | 0 | 1 | 2 | 3 | 2 |
| C | 0 | 2 | 3 | 5 | 3 |
| D | 1 | 5 | 3 | 7 | 2 |
| F | 2 | 6 | 9 | 13 | 7 |
| G | 2 | 8 | 5 | 11 | 3 |
| I | 8 | 10 | 11 | 13 | 3 |
Risk management is concerned with identifying risks affecting the project schedule or software quality and drawing up plans to avoid or minimize their effects.
Affect schedule or resources (e.g., loss of experienced programmer)
Affect quality or performance (e.g., failure of purchased component)
Affect the organization (e.g., competitor launching new product)
Identify project, product, and business risks
Assess likelihood and consequences
Draw up mitigation plans
Regularly assess and revise
| Risk | Type | Probability | Effect |
|---|---|---|---|
| Organizational financial problems force budget reductions | Organizational | Low | Catastrophic |
| Impossible to recruit staff with required skills | People | High | Catastrophic |
| Key staff ill at critical times | People | Moderate | Serious |
| Faults in reusable components need repair | Technology | Moderate | Serious |
| Requirements changes require major rework | Requirements | Moderate | Serious |
| Organization restructured | Organizational | High | Serious |
| Database performance below expectations | Technology | Moderate | Serious |
| Development time underestimated | Estimation | High | Serious |
| Software tools cannot be integrated | Tools | High | Tolerable |
| Customers fail to understand requirements changes impact | Requirements | Moderate | Tolerable |
Reduce the probability that the risk will arise. For example, dealing with defective components by thorough testing and verification before integration.
Reduce the impact of the risk on the project or product. For example, having backup personnel for staff illnesses or maintaining cross-training programs.
Prepare plans to deal with the risk if it arises. For example, having alternative vendors identified or maintaining relationships with contract staff.
| Risk Type | Potential Indicators |
|---|---|
| Estimation | Failure to meet agreed schedule; failure to clear reported defects |
| Organizational | Organizational gossip; lack of action by senior management |
| People | Poor staff morale; poor relationships; high staff turnover |
| Requirements | Many requirements change requests; customer complaints |
| Technology | Late delivery of hardware/software; many reported problems |
| Tools | Reluctance to use tools; complaints about CASE tools; demands for upgrades |