1. Project Management for Modern Software Development
Timothy Korson
Sothern Adventist University

2. Software Project Management
Direct

3. Recommended Reading Addison Wesley ISBN-0-201-30958-0
For an excellent compilation of information on general project management see the Project Management Body of Knowledge published by the Project Management Institute. Information on it can be found at

4. Management Activities
Manage risk
Planning the work
Measure the project
Resource planning
Ensure quality
Foster reuse
Manage the project team
Communicate with stakeholders

5. What Do Project Managers Do?
Team Management
Plan, Schedule, Track
Resource Allocation
Project Direction
Politics
Remove Project Obstacles
Direct

6. Team Management Manage the people on the team Motivation
Direct
Manage the people on the team
Motivation
Conflict resolution
Evaluation, promotion
Recruitment, retention
Career development
Task assignment

7. Scheduling Plan and Track the project Detailed planning and scheduling
Direct
Plan and Track the project
Detailed planning and scheduling
Per person planning and tracking
Iterations
Increments
Testing, Deployment, Support
Big Picture
Functionality Time Tradeoffs
Delivery dates

8. Resource Allocation Staffing Software development tools
Software components
Computer resources
External resources
Space
Etc.
Direct

9. Direction
Keep the project direction aligned with the stakeholders vision
Quality vs. Functionality vs. Cost tradeoffs
Direct

10. Politics Project interface and team buffer
Manage stakeholder relationships
Protect the team from the whims of exterior forces
Negotiate with upper level management and project stakeholders
Manage interaction with other teams, such as testing and quality assurance
Fight for resources
Direct

11. Remove Project Obstacles
Daily Project Meeting Identifies
Bottlenecks
Needed resources
Issues that need resolving
Conflicts between stakeholders
Differences between plans and actualities
Processes that need improvement

12. How Does The Use of Agile Processes Affect These Management Tasks?
Direct
Team Management
Less Assigning of Tasks
More mentoring
Plan, Schedule, Track
Less detailed plans
More Stakeholder Education
Different Style of Contracts
Different Use of Plans
Resource Allocation
Project Direction
Alignment of Stakeholder Values
Politics

13. Stakeholders A stakeholder is any individual who
affects or is affected by the
application being built:
Client (those who are paying)
User (those who interact with the application)
Define

14. Stakeholders
“Involve real users [stakeholders] throughout the software development process; their presence is a constant reminder why and for whom the software is being crafted.” [Booch]

15. Project Management
Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project.
Meeting or exceeding stakeholder needs and expectations involves balancing competing demands:
Scope, time, cost, and quality
Differing needs and expectations among stakeholders
Identified requirements vs. unidentified requirements
Define

16. Why Do Software Projects Fail?
We fail to properly manage risks
We don’t build the right thing
We are blindsided by technology
Notice the “We”. As project managers, we develop idealistic plans, we set unrealistic schedules, we deceive ourselves and others, and we refuse to face reality. These projects eventually enter “free fall” with no one taking responsibility and everyone waiting for the crash (while sending out resumes).
Question

17. Fail To Properly Manage Risks
“Management must actively attack a project’s risks, otherwise they will actively attack you.” [Gilb]
The first step in managing risks is to identify them
people
technology
environment
dependenciies

18. Don’t Build The Right Thing
Incorrect focus on requirements rather than on business goals and objectives.
Examples:
Inventory
NASA
Road

19. Blindsided By Technology
Concepts are more difficult than they seem, tools don’t scale up or they introduce errors, suppliers don’t deliver promised functionality or performance. Interactions are more complex that understood.
(Engine Control Unit)

20. Project Management To The Rescue
Effective project management actively works to minimize these problems by:
Explicitly identifying and creating written mitigation and contingency plans for project risks
Continuous demonstration and early and frequent deployment of the product being built
Continuous validation of the technologies for use on the project

21. Top 10 Principles of Modern Software Management
Direct
Base the process on an architecture first approach.
Establish an iterative lifecycle process that confronts risk early.
Transition design methods to emphasize component-based development.
Establish a change management environment.
Enhance change freedom through tools that support round-trip engineering.
Capture design artifact in rigorous, model-based notation.
Instrument the process for objective quality control and progress assessment.
Use a demonstration-based approach to assess intermediate artifacts.
Plan intermediate releases in groups of usage scenarios with evolving levels of detail.
Establish a configurable process that is economically scalable.
Royce

22. Software Management Best Practices
Formal risk management - using an iterative process.
Agreement on interfaces - same intent as architecture-first principle.
Formal inspections
Metric-based scheduling and management - directly related to model-based notation and objective quality control principles.
Binary quality gates at the inch-pebble level - evolving levels of detail principle.
Programwide visibility of progress versus plan.
Defect tracking against quality targets - directly related to architecture-first and objective quality control principles.
Configuration management - same reasoning behind the change management principle.
People-aware management accountability.
Direct
Software Acquisition Best Practices Initiative
Airlis Software Council

23. 7(±2) Habits Of Successful Projects
A ruthless focus on developing a system that provides a set of essential but minimal characteristics.
A culture that is centered on results, encourages communication, and yet is not afraid to fail.
The application of a well-managed iterative and incremental development life cycle.
Creating and communicating a strong, coherent, and resilient architectural vision.
Effective use of object-oriented modeling.
A management team that is obsessed with quality through adherence to the fundamental principles of software development

24. Top 30 Principles of Conventional Software Engineering
Make quality #1.
Depends what one means by quality
High–quality software is possible.
Agreed, but bug free software is next to impossible
Give products to customers early.
Yes, but
Determine the problem before writing the requirements.
Domain analysis before detailed use cases
Develop the requirements incrementally
ISBN: McGraw Hill

25. Top 30 Principles of Software Engineering cont.
Evaluate design alternatives.
Make sure to to test the design against the business goals
Use an appropriate process model.
Configure yes, but don’t neglect the fundamentals
Use different languages for different phases.
Use cases, class diagrams, …
Minimize intellectual distance.
Absolutely

26. Top 30 Principles of Software Engineering cont.
Put techniques before tools.
The good old days are long gone….
Get it right before you make it faster.
Yes, but
Inspect code.
Not in the top 30
Good management is more important than good technology.
Let me explain...

27. Top 30 Principles of Software Engineering cont.
People are the key to success.
Should be in the top 5
Follow with care.
Good advice
Take responsibility.
Your parents should have taught you this
Understand the customer’s priorities.
Change customer to stakeholder.
The more they see, the more they need.
True, but don’t let that stop you

28. Top 30 Principles of Software Engineering cont.
Plan to throw one away.
Too waterfall...
Design for change
Absolutely, but formally define the scope of anticipated change
Design without documentation is not design.
False
Use tools, but be realistic.
Also be realistic about what will happen if you don’t use tools!
Avoid tricks.
How about: “document your tricks”

29. Top 30 Principles of Software Engineering cont.
Encapsulate.
Move this to the top 10
Use coupling and cohesion.
A bit simplistic
Use the McCabe complexity measure.
If you suspect the quality of your software engineers ...
Don’t test your own software.
Don’t be the only one to test ...

30. Top 30 Principles of Software Engineering cont.
Analyze causes for errors.
A principle of process improvement
Realize that software’s entropy increases.
Only if you let it
People and time are not interchangeable.
But they are linked
Expect Excellence.
And you may get it

31. Two Types of Risk Project and Process Risk
What could go wrong with this project?
Product or Requirements Risk
Which faults would be most damaging to the stakeholders?
Define

32. Managing Project Risk Risk Dimensions Problem
Uncertainty – An event may or may not happen. What is the probability of its occurrence?
Damage – What are the implications to the project if the risk occurs?
Problem
A risk that has occurred.

33. Managing Risk
The most serious risk factors that affect development projects are:
1) Requirements Problems
Incorrect, incomplete, misunderstood, or creeping
2) Management Malpractice
2.1 Excessive cost or schedule pressure
2.2 Failure to plan, track or control within the framework of a modern development process
-- inaccurate resource estimation
-- denial
2.3 Poor Team Management
3) Poor Quality Software Engineering
…inadequate technical expertise
4) Technology Failure

34. Managing Project Risk
Acceptance – The level of risk is deemed to be within acceptable limits.
Mitigation – Take steps to minimize the loss.
Prevention – Take steps to minimize the probability.
Define

35. Managing Product Risk Establish risk criteria:
Operational Profile (Frequency of Use)
Consequence of Failure
Probability of failure
Use risk analysis to allocate:
analysis resources
architectural resources
testing resources
management resources

36. Early Risk Resolution
80% of the engineering is consumed by 20% of the requirements.
80% of the software cost is consumed by 20% of the components.
80% of the errors are caused by 20% of the components.
80% of software scrap and rework is caused by 20% of the changes.
80% of the resource consumption (execution time, disk space, memory) is consumed by 20% of the components.
80% of the engineering is accomplished by 20% of the tools.
80% of the progress is made by 20% of the people.
Royce

37. Risk profile of a typical modern project across its life cycle.
Inception Elaboration Construction--Transition
High
Low
Controlled Risk
Management Period
Project Risk Exposure
Conventional Project Risk Profile
Modern Project
Risk Profile
Risk Exploration Risk Resolution
Period Period
Project Life Cycle
Royce

38. What Do Project Managers Do?
Team Management
Plan, Schedule, Track
Resource Allocation
Project Direction
Politics
Remove Project Obstacles
Direct

39. Don’t Confuse Activity with Accomplishment!
Do what you have to do
Team Management
Plan, Schedule, Track
Resource Allocation
Project Direction
Politics
But don’t neglect achieving your primary responsibility
Value to the stakeholders
Direct