of commercial projects fail. of open source projects fail.

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

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

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

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

19. Adaptive project management

20. Extreme project management

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?