PM ?

1. PM ? • Fools rush in where angels fear to tread. • A stitch in time saves nine. • Measure twice, cut once. • Look before you leap. • What do all these sayings have in common? • They're all about thinking before acting. Why? • Because it saves time, money, effort and embarrassment. • It's plain common sense, yet, serious !!

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

3. 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?

4. 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

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

6. 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

7. 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

8. Project management approaches • The 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)

9. 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

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

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

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

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

14. I. Defining • We need to determine what the customer wants (needs) • Stakeholder (See notes - 1) • We do this by identifying: • Requirements • Goals • A goal is normally a solution to a problem • From the prioritized list of needs, create a set of goals that can be easily measured. A technique for doing this is to review them against the SMART(See notes -2) principle. This way it will be easy to know when a goal has been achieved. • Once you have established a clear set of goals they should be recorded in the project plan. It can be useful to also include the needs and expectations of your stakeholders. • Deliverables • Scope • Risks • Impact • Probability

15. I. Defining • We need to determine what the customer wants • We do this by identifying: • Requirements • Goals • Deliverables • Deliverables are the actual artifacts created by the project team for the customer • Add the deliverables to the project plan with an estimated delivery date. • These typically include: • Binary packages • Source packages (in open source projects) • Documentation & tutorials • Version history • Utilities • Installation software • Scope • Risks • Impact • Probability

16. I. Defining • We need to determine what the customer wants • We do this by identifying: • Requirements • Goals • Deliverables • Scope • The project’s scope defines its boundaries • This could include specific statements called requirements • This could also include general statements to incorporate changes => Thus, scope deals with both requirements and changes • Risks • Impact • Probability

17. I. Defining • We need to determine what the customer wants • We do this by identifying: • Requirements • Goals • Deliverables • Scope • Risks - 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?

18. Risk Planning 1. Learn about the risk 2. Plan to avoid the risk 3. Move the risk 4. Create a risk-management plan 5. Mitigate and control the risk 6. Tolerate the risk 7. Document the risk 8. Monitor the risk

19. Example Risk Document

21. II. 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)

22. Work Breakdown Structure • Normally created from Top down • Work • A WBS considers the work that needs to be performed • This includes development, but also user manuals, sales support, administration, deployment, media, etc. • Breakdown • Work is broken down (decomposed) into small pieces (activities) • Activities are eventually broken down into tasks • A task is something that takes less than a week to complete • Activities are normally assigned to individuals • Structure • Each unit of work is broken down into a number of components • The result is a hierarchical structure • The lowest layers are tasks • e.g. A function that generates a polynomial collision-handling hash function is completed • e.g. Send user manual prototype to printer for an estimate • The middle layers could be milestones • e.g. “Getting started” tutorial is completed • The highest layers are normally deliverables • e.g. Source code distribution, with configuration and makefiles, is completed

23. WBS • Activity: • Some behavior that needs to be done • Produces some outcome (e.g. a deliverable) • Is often decomposed into other activities or tasks • Task: • An activity that is not decomposed • Is at the lowest level of the WBS • Also called a work package

24. Example WBS Usability Training 1 - Personnel Available 2 - Training Seminars Booked 57 - Hotel Rooms Reserved … … … 2.1 - Deal Made with Susan Carleson 2.2 - Budget Approval Form Submitted to Accounts Payable 2.13 - Cheque Requisition Made to Accounts Payable …

25. When is a WBS done? • Since WBS is iterative, it could go on forever • There are guidelines for what is enough: • Status/completion is measurable • The activity/task is bounded • The activity/task has a deliverable • Time and cost are easily estimated • Activity/task duration is within acceptable limits • Work assignments are independent

26. Advantages of a WBS • The WBS: • Gives you a somewhat complete list of tasks • Later, this can be a checklist to show how much is still to be done, and how much is done • Allows you to easily assign work to team members • Requires you to solidify things that are still vague, even after requirements analysis • Generating a WBS enables you to methodically decompose the work, exposing new risks and resource requirements

27. III. Launching • We have a detailed work plan • Now, we get the work underway

28. IV. 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)

29. V. 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?

30. Project milestones for 321 • Goals • Risk document • Work Breakdown structure • Communication plan to progress reporting • Weekly milestones to be submitted every week • Minutes of weekly meetings with group members, instructor • Post-mortem analysis : • Lessons learnt • Final Deliverables : • Written report (details to be given later) • Soft copy of the code (including a Readme file ) • User manual • Frequently asked questions for your project

31. Post-Mortem Analysis • A post-mortem involves analyzing the project upon completion • 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

32. Defining Planning Launching Monitoring Closing Defining Requirements Design Implementation Maintenance SDLC and PM • The systems development life cycle (SDLC) becomes part of the project life cycle (PLC).–The PLC focuses on the project management phases, processes, tools and techniques for effectively managing the project.–The SDLC focuses on the software engineering phases, processes, tools and techniques for building and/or implementing the IT solution. Project Life Cycle SDLC

33. SDLC and PM • In project management a project has both a life cycle and a "systems development life cycle," during which a number of typical activities occur. • The project life cycle (PLC) encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements.

34. SDLC and PM • The PRODUCT ~ The PROJECT • SDLC is simply a set of critical activities that takes place during PM “Execution “ phase or “Launch” phase