1. 60-499 Project Management: Techniques & Tools % of commercial projects fail. % of open source projects fail. Chapters 1-2

2. 60-499 Project Management: Techniques & Tools 80 % of commercial projects fail. % of open source projects fail.

3. 60-499 Project Management: Techniques & Tools 80 % of commercial projects fail. 90 % of open source projects fail.

4. 60-499 Project Management: Techniques & Tools 80 % of commercial projects fail. 90 % of open source projects fail. Why?

5. 60-499 Project Management: Techniques & Tools Course Overview What we’ll be doing this year

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

7. 60-499 Project Management: Techniques & Tools Why do projects fail?

8. 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 6. Closing 5. Monitoring & Controlling Built the wrong thing Ignored potential pitfalls Overly optimistic schedules Poor team dynamics Poor development practices No customer acceptance

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. 60-499 Project Management: Techniques & Tools 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 Defining Planning Launching Monitoring & Controlling Closing

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

20. Extreme project management Defining Planning Launching Monitoring & Controlling Closing 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. 60-499 Project Management: Techniques & Tools 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. 60-499 Project Management: Techniques & Tools Project Milestones

37. 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. 60-499 Project Management: Techniques & Tools Questions?