% of commercial projects fail. % of open source projects fail.

1. % of commercial projects fail. % of open source projects fail. Chapters 1-2

2. 80 % of commercial projects fail. % of open source projects fail.

3. 80 % of commercial projects fail. 90 % of open source projects fail.

4. 80 % of commercial projects fail. 90 % of open source projects fail. Why?

5. Course Overview What we’ll be doing this year

6. Project Management Phases 1. Defining 2. Risks 3. Planning & Scheduling 4. Launching 5. Monitoring & Controlling 6. Closing

7. Why do projects fail?

8. Why do projects fail? • We need to ask these important questions: • What kind of failure was it? • e.g. incomplete, unreliable, off-schedule/budget • Who was responsible? • What happened? • What did not happen? • Which process(es) broke down? • What module(s)/feature(s) failed?

9. Where failure can happen 1. Requirements 2. Risks 3. Planning & Scheduling 4. Launching 5. Monitoring & Controlling 6. Closing

10. Reasons for project failure • These reasons seem to blame the developers: • Poor design • Uncommitted or de-motivated developers • Weak, antagonistic, unreliable developers/contractors • Gold-plated features or documentation • Autobahn development or bug-fixing • Silver bullet syndrome • Lack of source control • Abandoned planning

11. Reasons for project failure • These reasons seem to blame the customer or upper management: • Feature creep • Unrealistic schedules • Unrealistic expectations • Incorrect requirements

12. Reasons for project failure • These reasons seem to blame the project manager: • Poor planning • Insufficient risk management • Insufficient quality assurance • Who is really responsible for these problems? • The project manager

13. A project manager’s role • A major role of a project manager (PM) is to ensure that the project succeeds • To a lesser degree, this is also a role for other stakeholders • Therefore, the PM is responsible (if not to blame) when these problems occur • A project manager must remain unbiased • Customers or upper management may ask for unrealistic features and/or schedules • It is not a project manager’s role to make such schedules work, by pushing developers harder

14. Project management careers • A PM is someone with years of experience • This is usually someone who… • has experienced successful projects • has experienced failed projects • has excellent organizational skills • has excellent communication skills • is a strong leader • Common project management certifications: • Project+: Entry-level certification, for aspiring project managers • PMP: Professional cert., for experienced project managers • Project management body of knowledge (PMBOK)

15. Project Management Overview

16. Project management approaches • The textbook three approaches to project management: • Traditional • This approach has been used for IT projects, nearly unchanged, for decades • Adaptive • This approach is one which combines some of the best features of the traditional and extreme approaches • Extreme • This approach is the project management approach that goes along with eXtreme Programming (XP)

17. Upstream activities • Upstream activities are things that normally happen prior to development • Defining • Planning • Architecture & design • Traditional • Upstream activities occur for the whole project in one step • Although changes can be made • Extreme • Upstream activities occur for each version • Each iteration produces a version that is closer to the ultimate goal

18. Traditional project management Launching Planning Closing Monitoring & Controlling Defining

19. Adaptive project management Launching Planning Closing Monitoring & Controlling Defining

20. Extreme project management Launching Planning Closing Monitoring & Controlling Defining Next version

21. Processes • Here are the processes of project management: • Defining • Planning • Launching • Monitoring & Controlling • Closing

22. Defining • We need to determine what the customer wants • We do this by identifying: • Requirements • Goals • Deliverables • Success criteria • Scope • Risks • Impact • Probability

23. Planning • We know what we want • Now, we figure out how to do the work required • We do this by: • Performing architecture & design • Identifying activities: work breakdown structure (WBS) • Identifying dependencies between activities • Estimating activity duration • Estimating activity resource requirements • Scheduling activities (start date, duration)

24. Launching • We have a detailed work plan • Now, we get the work underway • We do this by: • Choosing participants • Making participants available for the project • Assigning work to participants • Organizing participants into team(s) • Providing resources to the team(s) • Establish constraints and freedoms for the team(s)

25. Monitoring & Controlling • We have people working on activities • Now, we must ensure we are making adequate progress • We do this by: • Interviewing and observing progress reports • Implementing version control software • Providing mechanisms for requesting changes • Continually updating plans (e.g. schedules)

26. Closing • We have completed all activities • The result should be that • All overall goals are satisfied • All conditions of satisfaction are met • All deliverables are ready for roll-out • Now, we need to complete hand-over • We do this by: • Obtaining client acceptance • Deploying deliverables • e.g. media disks, printed manuals, online deployment/downloads • Performing a post-mortem analysis • How did we do?

27. Explanation of Terms

28. Goals • A goal is normally a solution to a problem • When defining goals, answer the following questions: • What problem will we solve? • e.g. Accounting department has 2 month turnaround for budget requests, which is too long. • In what sense will we solve the problem? • e.g. Our accounting software will streamline the process of budget re-work. • We often have one overall goal • This may be made up of several smaller sub-goals (objectives) • e.g. The software will look in volatile financial areas first, allowing the accounting department to quickly find the resources.

29. Success Criteria • Success criteria define what must be true in order for the project to be considered a success • These are related to the goals • However, they are attributes that can be measured • e.g. The accounting department’s time to approve a budget is reduced by at least 50%. • We can measure after the project’s completion and test for success

30. Deliverables • Deliverables are the actual artifacts created by the project team for the customer • These typically include: • Binary packages • Source packages (in open source projects) • Documentation & tutorials • Version history • Utilities • Installation software

31. Scope • The project’s scope defines its boundaries • This could include specific statements • These are called requirements • Often, a project manager will work with customers to decide which requirements are necessary, and which are not • This could also include general statements • These could be used to determine whether or not a feature request (change) is appropriate later • Thus, scope deals with both requirements and changes

32. Risks • Risks are things that could cause the project to: • Fail • Be delayed • Require additional budget • Require additional personnel • A project manager should identify: • Impact: What is the expected negative impact should it occur? • Probability: How likely is it to occur?

33. Activities • An activity is something a participant may undertake • This could be: • Designing a module • Updating documentation • Optimizing the search code • Installing the binaries in a web server • Writing a lookup method • Activities can be: • Estimated for time & resource requirements • Assigned to team member(s)

34. Schedule • A schedule is a time-plan for activities • The schedule must: • Include all activities • Show dependencies between activities • e.g. What must occur before this activity can start? • Show estimated durations for activities • Show starting points for activities • Show combined activity duration as project duration • Show estimated resources for activities • Show combined activity resource requirements as project resource requirements

35. Team • A team is a group of participants with shared objectives • However, teams do not have to have the same skills and experience • Team effectiveness is impacted by: • Individual participant effectiveness • Social dynamics within the team • Motivation • Team leadership

36. Project Milestones

37. Project Milestones • The various processes may overlap, but they should eventually produce these results: • Project charter • Project scope statement • Risk document • Work breakdown structure (WBS) • Project plan (project proposal in the textbook) • Architecture & design • Deliverables • Post-mortem analysis

38. Project Charter • The project charter defines • The business justification • The overall goals of the project • The stakeholders of the project • The desired costs and duration of the project • The project charter is often produced by the project sponsor or customer • This should be the first page in your book of project management documentation

39. Project Scope Statement • The project scope statement defines: • The project’s requirements • Goals • Success criteria • Deliverables • The project’s boundaries • What should be part of the project • What should not be part of the project

40. Risk Document • The risk document: • Identifies and describes risks • Describes what conditions make it happen • Describes the probability of it happening • Describes the impact of it happening • Describes a plan for how to (try to) avoid it happening • Describes a plan for what to do if it happens • This is only done if the probability and/or impact necessitate such a plan

41. Work Breakdown Structure • The WBS: • Defines all activities • Each system function is defined as a high-level activity • Each activity is broken down into smaller activities • This process repeats until activities are small and manageable • Shows hierarchical relationships between activities • A WBS can be represented with a tree diagram

42. Project Plan • The project plan defines: • Dependencies between activities • e.g. IVG module test design must be complete before development can begin • Schedule • Including an estimate of each activity’s duration • Initial activity assignment • Activities are assigned to fictitious team members

43. Architecture & Design • Architecture refers to the overall structure of the application • In short, an architecture defines the modules • Each module has a set of common responsibilities • Often, these responsibilities are related • e.g. The DAL module is responsible for maintaining consistency between customer objects and the database of customer data • Design refers to the structure of the module itself • This often involves creating classes (in OOD) and assigning responsibilities (functions or data) to them

44. Post-Mortem Analysis • A post-mortem involves analyzing the project upon completion • This is not to be confused with QA, which analyzes the deliverables • A post-mortem is a critical step, that many project managers miss • This is a project manager’s chance • Perhaps they can more accurately estimate activities after the experience • Perhaps they can identify mistakes made, to avoid making them again • Perhaps they can recognize personal achievements

45. Summary • Project management’s job is to ensure that projects do not fail • We must identify what the customer wants • We must identify potential pitfalls • We must list what needs to be done • We must make detailed plans • We must prepare for changes • We must ensure that our plans are being followed • We must ensure that our plans are working • If not, we must update them or take another corrective action

46. Questions?