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

1/41

Project Management for Modern Software Development

Timothy KorsonSothern Adventist University

2/41

Software Project Management

Direct

3/41

Recommended ReadingAddison WesleyISBN-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 www.pmi.org

4/41

Management Activities

Planning the workMeasure the project

Manage risk

Resource planning

Foster reuse

Ensure quality

Communicate with stakeholders Manage the project team

5/41

What Do Project Managers Do?

Team Management

Plan, Schedule, Track

Resource Allocation

Project Direction

Politics

Remove Project Obstacles

Direct

6/41

Team Management

Manage the people on the team Motivation Conflict resolution Evaluation, promotion Recruitment, retention Career development Task assignment

Direct

7/41

Scheduling

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

Direct

8/41

Management

The basic questions:

Where are we?

Are we making progress?

When will we be finished?

How much will it cost?

What is the quality?

Question

9/41

Resource Allocation

Staffing Software development tools Software components Computer resources External resources Space Etc.

Direct

10/41

10 - 44

Direction

Keep the project direction aligned with the stakeholders vision

Quality vs. Functionality vs. Cost tradeoffsDirect

11/41

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

12/41


Daily Project Meeting Identifies Bottlenecks Needed resources Issues that need resolving Conflicts between stakeholders Differences between plans and

actualities Processes that need improvement

13/41

How Does The Use of Agile Processes Affect These Management Tasks?

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

Direct

14/41

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

15/41

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]

16/41

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

17/41

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

18/41

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

19/41

Don’t Build The Right Thing

Incorrect focus on requirements rather than on business goals and objectives.

Examples:

Inventory

NASA

Road

20/41

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)

21/41

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

Project Management To The Rescue

22/41

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

23/41

Managing Project Risk

Risk Dimensions

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.

24/41

Managing RiskThe most serious risk factors that affect development projects are:

1) Requirements ProblemsIncorrect, incomplete, misunderstood, or creeping

2) Management Malpractice2.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

25/41

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

26/41

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

27/41

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

28/41

Risk profile of a typical modern project across its life cycle.

High

Low

Pro

ject

Ris

k E

xpos

ure

Project Life Cycle

Inception Elaboration Construction--Transition

Risk Exploration Risk ResolutionPeriod Period

Modern ProjectRisk Profile

Conventional Project Risk Profile

Controlled RiskManagement Period

Royce

29/41

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

30/41

Top 10 Principles of Modern Software Management

1. Base the process on an architecture first approach.

2. Establish an iterative lifecycle process that confronts risk early.

3. Transition design methods to emphasize component-based development.

4. Establish a change management environment.

5. Enhance change freedom through tools that support round-trip engineering.

6. Capture design artifact in rigorous, model-based notation.

7. Instrument the process for objective quality control and progress assessment.

8. Use a demonstration-based approach to assess intermediate artifacts.

9. Plan intermediate releases in groups of usage scenarios with evolving levels of detail.

10. Establish a configurable process that is economically scalable.

Royce

Direct

31/41

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. Software Acquisition Best Practices InitiativeAirlis Software Council

Direct

32/41

Top 30 Principles of Conventional Software Engineering

1. Make quality #1.• Depends what one means by quality

2. High–quality software is possible.• Agreed, but bug free software is next to impossible

3. Give products to customers early.• Yes, but

4. Determine the problem before writing the requirements.

• Domain analysis before detailed use cases

• Develop the requirements incrementally

ISBN: 0070158401 McGraw Hill

33/41

Top 30 Principles of Software Engineering cont.

5) Evaluate design alternatives.• Make sure to to test the design against the business goals

6) Use an appropriate process model.• Configure yes, but don’t neglect the fundamentals

7) Use different languages for different phases.• Use cases, class diagrams, …

8) Minimize intellectual distance.• Absolutely

34/41

9) Put techniques before tools.• The good old days are long gone….

10)Get it right before you make it faster.• Yes, but

11)Inspect code.• Not in the top 30

12)Good management is more important than good technology.• Let me explain...


35/41


13) People are the key to success.• Should be in the top 5

14) Follow with care.• Good advice

15) Take responsibility.• Your parents should have taught you this

16) Understand the customer’s priorities.• Change customer to stakeholder.

17) The more they see, the more they need.• True, but don’t let that stop you

36/41

18)Plan to throw one away.• Too waterfall...

19)Design for change• Absolutely, but formally define the scope of anticipated change

20)Design without documentation is not design.• False

21)Use tools, but be realistic.• Also be realistic about what will happen if you don’t use tools!

22)Avoid tricks.• How about: “document your tricks”


37/41


23) Encapsulate.• Move this to the top 10

24) Use coupling and cohesion.• A bit simplistic

25) Use the McCabe complexity measure.• If you suspect the quality of your software engineers ...

26) Don’t test your own software.• Don’t be the only one to test ...

38/41

27)Analyze causes for errors. • A principle of process improvement

28)Realize that software’s entropy increases.• Only if you let it

29)People and time are not interchangeable.• But they are linked

30)Expect Excellence.• And you may get it


39/41

What Do Project Managers Do?

Team Management

Plan, Schedule, Track

Resource Allocation

Project Direction

Politics


Direct

40/41

Management

Management is more than the ability to estimate, plan and track

Good managers understand the fundamentals of good software engineering, and build an environment and culture that reward quality.

Direct

41/41

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

Documents

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