A Cynical View on PROJECT MANAGEMENT

1. A Cynical View on PROJECT MANAGEMENT Hope, Belief and Wizardry Markus Voelter voelter@acm.orgwww.voelter.de

2. Introduction • From the CHAOS report (1995): • 31.1% of projects will be canceled before they ever get completed. • 52.7% of projects will cost over 189% of their original estimates • Well. • This presentation contains a lot of tips of how you can increase these numbers even further.

3. Introduction • So, why the title Hope, Belief and Wizardry? • The customer often does not really understand how management and the developers try to make the project a success. The customer is typically full of hope that the project will eventually succeed. • Project management is usually very convinced of what they do. They have a firm belief that they will successfully steer the ship through the stormy seas, finishing on time and in budget. • And the developers would consider it wizardry, if all that really worked out in the end.

4. DISCLAIMER • Do not actually use the stuff! • This presentation is full of irony and cynism.

5. Project Planning and Controlling Part 1:

6. … You are running a rather big development project.

7. … How do control an plan properly?

8. Project Office • Provide a project office staffed by people who are not part of the development team. • See the project from their own point of view. • Management can be assured of their experience and competence by ensuring that they come from a big-name company. • Better even: CLUELESS PROJECT OFFICE.

9. … You have a PROJECT OFFICE in place to make sure the project stays on track.

10. … How to make them work efficiently,they should not be bothered too much by the details and day-to-day problems of the project team?

11. Clueless Project Office • Make sure the PROJECT OFFICE don’t know anything about software development, or even domain in which the project issituated. • PROJECT OFFICE has to work on an abstract level. • Ensures a “different angle”

12. … You now have a CLUELESS PROJECT OFFICE.

13. … The PROJECT OFFICE has to keep track of important activities, people, resources, milestones, etc. This needs to be abstract, they cannot be distracted by what they perceive to be inappropriate detail

14. MS Project Plan • Use a colorful MS PROJECT PLAN to provide the overview. • It is easy to use for the PROJECT OFFICE staff, • It provides a nice, management-compatible way to graph things, • and it is abstract enough to ignore all the gory details of everyday life in the project.

15. … You already have a CLUELESS PROJECT OFFICE in place using a MS PROJECT PLAN as their primary planning tool.

16. … • You, the CLUELESS PROJECT OFFICE, have to fill content into the MS PROJECT PLAN. • You want to do so without much interference with the development team. • You need a way how the plan can be populated by only talking to management (or to nobody at all). • And the plan must look consistent as a result.

17. Arithmetic Project Planning • Use simple arithmetics to fill in the MS PROJECT PLAN. • You know when the project should be finished, you know how muchmoney is available for it. Thus, first calculate how many resources you canafford: numberOfResources = availableMoney / averagePricePerResource • Then you can then determine who does what, and when. • Based on the requirements and the available time till the deadline, you can easily draw a nice-looking MS PROJECT PLAN. • If the result looks unrealistic, BUY CHEAPER RESOURCES. • If the PROJECT OFFICE staff needs information from the developers they should avoid direct contact and instead use STATUS REPORTS.

18. … The PROJECT OFFICE needs to update their MS PROJECT PLAN using ARITHMETIC PROJECT PLANNING and does not have the experience to do this without any contact to the developers.

19. … To be able to update the plan, inexperienced PROJECT OFFICE staff need information on the progress of the project from the development staff. This information needs to be stated in a way that is understandable for the CLUELESS PROJECT OFFICE.

20. Status Report • Make each member of the development team fill in a status report form every once in a while, • for example every week, on Wednesday at 4pm. • In this report, he is required to state the progress he made, report problems, and describe what he’ll do next. • If a member fails to finish with what he planned, require him to explain why. Ideally, add a “blame field” to the form where he can write down the name of the colleague whose fault it is.

21. … You get to the end of the project and ARITHMETIC PROJECT PLANNING together with STATUS REPORTS reveals that you probably won’t finish in time…

22. … How do you still finish the project in time without reducing the scope or getting more money and without having to discuss with management?

23. Buy Cheaper Resources • The solution is to use more, and cheaper resources. • ARITHMETIC PROJECT PLANNING reveals this as an effective way to increase development speed. • The only thing that might eventually suffer is quality – but that’s not something that shows up in your MS PROJECT PLAN anyway.

24. … You BUY CHEAPER RESOURCES to help you in the tight schedule towards the end of the project.

25. … How do you actually make sure that the new, cheap resource works efficiently right from the start?

26. Plug-and-Play Programmer • Make sure you only buy cheap resources, you also need tomake sure that they are actually so-called plug-and-play programmers. • Those start to be productive in any project right from the start. • They don’t need time to familiarize themselves with code, tools and the project. • Also, you don’t need to coach them!

27. … You run your project using ARITHMETIC PROJECT PLANNING.

28. Self-Motivated Peer Reviews How do you ensure the quality of the code?

29. Self-Motivated Peer Reviews • The code quality is ensured automatically by the developers. • Since they take pride in their work, they will conduct peer reviews with each other. • This happens even under the severe time constraints that result from ARITHMETIC PROJECT PLANNING, • and it works even with the recently BOUGHT CHEAPER RESOURCES.

30. … Your PROJECT OFFICE does not trust development team.

31. … How do you ensure the quality in the face of mistrust? And how do you ensure homogeneous quality and the obedience to standards all over the project?

32. QA Rulez! • Put a quality assurance teamin place. It’s task is to ensure quality of the development artifacts on an abstract level. • They usually run reviews, interviews, etc. • they are typically associated with the PROJECT OFFICE. • They have deep insight into the project and its constraints.

33. … You want to ensure code quality by using SELF-MOTIVATED PEER REVIEWS.

34. … How do you make sure everybody can understand everybody else’s code?

35. Imperative Style Guide • Let the QA team define a style guide. The guide contains everything from code layout to variable names to documentation requirements. • Place this MAGIC DOCUMENT somewhere into the intranet, the developers are happy to read it and follow it promptly. • Make sure that developers cannot easily change or adapt the document, because QA RULES.

36. Requirements,Architectureand Design Part 2:

37. … You are not able to clearly define the requirements of the project from the beginning.

38. … How do you still make sure that the customer gets all he wants with a fixed budget and a rigid deadline?

39. Half-XP II • Use half of the XPmethodology. • Do not define requirements, start developing immediately. • Developers will refine requirementsas they go by talking to the customer’s representative. • It’s not necessary, that the customer is available all the time, because the customer promised to be there whenever he’s needed. • Because you have a rough understanding on what the customer wants, it’s easy to finish with the project on time and meet the customers requirements.

40. … You use HALF-XP but the customer’s purchasing department still wants a formal requirements document.

41. … How do you state formal requirements if you don’t know them?

42. Pro-Forma Requirements Document • Write a pro-forma requirements document. It includes everything, but described in very general and weak terms. • This document can be signed easily. • Nobody will ever look at it again, and everybody knows, that the real requirements will be defined on the fly using HALF-XP. • The purchasing department is happy, though.

43. … You have just won the contract and want to provide useful code to the customer as quickly as possible.

44. … How do you get something done as quickly as possible?

45. Start Big • Start big. • BUY as many CHEAP RESOURCES as you can get right from the beginning. • The beginning is where the hard work has to be done: frameworks, base libraries and other “strategic” code. • You cannot have enough people to work on that critical phase in the project.

46. … You have STARTED BIG and you need to provide an architecture for the system.

47. … How do you define and implement an architecture while the project is in its initial phase and the MS PROJECT PLAN does not explicitly allow time for the architecture?

48. On-the-fly Architecture II • Implement the architecture and the basic libraries in parallel with the first user features. • Your best resources will define the architecture and talk to the rest of the team about what they should implement, and how. • It is not necessary to define the architecture (or at least, an outline) up front because you can REFACTOR LATER. • Note that this pattern works especially well for mission- or safety-critical enterprise projects.

49. … Your customer has some kind of technical managers.

50. … The customer requires to present them with the architecture. The audience has some technical background but is by no means up-to-date or competent with current technologies – however they usually know management-compatible buzzwords.