Effective Project Management: Traditional, Agile, Extreme

1. Effective Project Management: Traditional, Agile, Extreme Managing Complexity in the Face of Uncertainty Presented by (facilitator name) Ch03: How to Scope a Project

2. Summary of Chapter 3 Ch03: How to Scope a Project • Managing client expectations • Conditions of satisfaction • Planning and conducting a project scoping meeting • Gathering requirements • Diagramming business processes • Prototyping your solution • Business validation • Procurement Management • Writing an effective Project Overview Statement (POS) • Approval to Plan the Project

3. Ch03: How to Scope a Project Tools, Templates & Processes used to Scope a Project • Conditions of Satisfaction • Project Scoping Meeting • Requirements Gathering • Diagramming Business Processes • Prototyping • Validating Business Cases • Procurement Management • Outsourcing • Project Overview Statement • Approval to Plan the Project

4. Managing Client Expectations • Somehow clients always seem to expect more than project managers are prepared for or capable of delivering. • This lack of communication starts at the beginning of a project and extends all the way to the end. • The project manager assumes he or she knows what the client is asking for, and the client assumes the project manager understands what they are asking for.

5. NEEDS WANTS Ch03: How to Scope a Project Client Wants vs. Client Needs Dilemma What your client wants may not be what your client needs. Your job is to make sure that what they want is what they need and that you will deliver what they need.

6. Client Wants vs. Client Needs Dilemma • The disconnect may come about because the client is swept up in a euphoria over the technology (for example, they may be enamored with what they see on the Web) • The disconnect can also come about because the client does not really know what they need. • Wants tend to be associated with a solution that the client envisions. Needs tend to be associated with the problem. • To be safe, always ask the client why they want what they want.

7. Conducting Conditions of Satisfaction • You should begin every project with a communications tool called Conditions of Satisfaction (COS). • The COS is a structured conversation between the client (the requestor) and the likely project manager (the provider). • The deliverable from the COS is a one-page document (with attachments) called the Project Overview Statement (POS).

8. Conducting Conditions of Satisfaction… • The POS is a template that is used to clearly state what is to be done. • It is signed by the requestor and the provider who participated in the COS exercise. • When the POS is approved by senior management, the Scoping Phase is complete.

9. Conducting Conditions of Satisfaction… • The process of developing the COS involves the following four parts: • 1. Request. A request is made. • 2. Clarification. The provider explains what he or she heard as the request. • 3. Response. The provider states what he or she is capable of doing to satisfy the request. • 4. Agreement. The requestor restates what he or she understands the provider will provide. The conversation continues until the provider is satisfied that the requestor clearly understands what is being provided.

10. Establishing Clarity of Purpose • The next step in the COS process is to negotiate to closure on exactly what will be done to meet the request. Obviously, some type of compromise will be negotiated. • The final agreement is documented in the POS. • As shown in Figure 3-1, this process repeats itself until there is an agreed-on request that is satisfied by an agreed-on response.

11. Establishing Clarity of Purpose • As part of this agreement, the POS should include a statement of success criteria that specifies when and how the request will be satisfied. • The success criteria will become part of the POS. • The result is documented as the COS and serves as input to the POS. • This early step of establishing and agreeing to what will be done is very important to the project’s success.

12. Ch03: How to Scope a Project Establishing Conditions of Satisfaction Clarify Request Response Request Agree on Response Negotiate agreement and write Project Overview Statement Figure 03-01

13. Specifying Business Outcomes • it is a good idea to specify within the COS exactly what outcomes demonstrate that the COS has been met. The outcomes have been called success criteria • it is a quantitative measure (for example, profit, cost avoidance, and improved service levels) that defines success.

14. Conducting COS Milestone Reviews • The COS is not a static agreement. It is a dynamic agreement that becomes part of the continual project monitoring process.

15. Planning and Conducting the Project ScopingMeeting • You may have had a COS session and agreed on a high-level scope for the project but need more detail in order to write a POS. • The Project Scoping Meeting takes the COS deliverable to the next level of detail. • In this meeting, the core project team will be present, as will the client, several key managers, staff, and end users of the project deliverables.

16. Ch03: How to Scope a Project Planning and Conducting the Project Scoping Meeting • Purpose • Document requirements • Project Overview Statement • Attendees • Project Manager • Client Group • Core Team Members • The Facilitator & Technographer

17. The facilitator group • This group comprises two or three individuals who are experienced in conducting scoping and planning meetings. • The facilitator group will have a meeting facilitator, a requirements gathering facilitator, and a position that the author calls a technographer. • The two facilitators are often the same person. • A technographer is the recording secretary for scoping and planning meetings who has solid experience using a variety of high-tech tools. Larger projects may require two such professionals.

18. Ch03: How to Scope a Project Planning and Conducting the Project Scoping Meeting • Agenda • Introductions • Purpose of the Meeting (led by Facilitator) • COS (conduct or review if done earlier) • Description of current state (led by client representative) • Description of problem or business opportunity (led by client representative) • Description of end state (led by client representative) • Requirements definition and documentation (led by facilitator) • Discussion of the gap between current and end state (led by project manager) • Choose best-fit project management approach to close the gap (led by project manager) • Draft and approve the POS (whole scope planning group) • Adjourn

19. Ch03: How to Scope a Project Planning and Conducting the Project Scoping Meeting • Deliverables • COS • Requirements Document • Best-fit project management life cycle (PMLC) • POS

20. Ch03: How to Scope a Project Who is Our Client? Good Client • Know what they want • Know what it takes to deliver • Work towards best solution • Easy to work with • Meaningfully involved Not So Good Client • Not sure of what they want • Constantly change their mind • Not interested in solving project problems • Hard to satisfy • Not very involved Project manager & team (PT) must satisfy the needs of both.

21. Ch03: How to Scope a Project What Are Requirements? A requirement is something the product/project should do/produce or a quality that it must have.

22. Ch03: How to Scope a Project Different Perspectives on Requirements How the customer explained it How the project leader understood it How the analyst designed it How the programmer wrote it How the consultant described it Figure 03-02 How it was supported What the customer really needed How the customer was billed How the project was documented What operations installed

23. Ch03: How to Scope a Project Categories of Requirements • Functional • Non-functional • Global • Product/project constraints

24. Ch03: How to Scope a Project Definition: Functional Requirement Functional requirements specify what the product or service must do. For example: ‘‘The service shall accept a scheduled time and place for delivery.’’

25. Ch03: How to Scope a Project Definition: Non-Functional Requirement Non-functional requirements demonstrate properties that the product or service should have in order to do what must be done. These requirements are the characteristics or qualities that make the product or service attractive, usable, fast, or reliable. For example: ‘‘The product shall have a homemade appearance.’’ or: ‘‘The product shall be packaged so as to be attractive to senior citizens.’’

26. Ch03: How to Scope a Project Definition: Global Requirement Global requirements describe the highest level of requirements within the system or product. They can be thought of as general requirements. For Example: ‘‘The system shall run on the existing network.’’ or ‘‘The system must be scalable.’’

27. Ch03: How to Scope a Project Definition: Product/Project Constraints Product/project constraints are those requirements that, on the surface, resemble design constraints or project constraints. Project constraints cover the areas of budget and schedule along with deadlines and so on. For example: ‘‘The maximum system response time for any client-based transaction must not exceed 4 milliseconds.’’ or ‘‘The total cost plus five-year maintenance must not exceed $35 million.’’

28. Ch03: How to Scope a Project Approaches to Requirements Gathering • Facilitated Group Session • Interview • Observation • Requirements Reuse • Business Process Diagramming • Prototyping • Use Cases

29. Approaches to Requirements Gathering… • Selecting the best methods to generate potential requirements for the project is the responsibility of the project manager, who must evaluate each method for costs, ease of implementation with the client, and risks. • Further, selection of a particular method should be based on specific product and project needs, as well as proven effectiveness. • Certain methods have been proven effective for specific client groups, industries, and products.

30. Ch03: How to Scope a Project Facilitated Group Session Method Strengths • Excellent for cross-functional processes • Detailed requirements are documented and verified immediately • Resolves issues with an impartial facilitator Risks Untrained facilitators can lead to negative responses Time and cost of planning and executing can be high Table 03-01

31. Ch03: How to Scope a Project Interview Method Strengths • End user participation • High-level description of functions and processes provided Risks Descriptions may differ from actual detailed activities Without structure, stakeholders may not know what information to provide Real needs ignored if analyst is prejudiced Table 03-01

32. Ch03: How to Scope a Project Observation Method Strengths • Specific/complete descriptions of actions provided • Effective when routine activities are difficult to describe Risks Documenting and videotaping may be time consuming, expensive and have legal overtones Confusing/conflicting information must be clarified Misinterpretation of what is observed Table 03-01

33. Ch03: How to Scope a Project Requirements Reuse Method Strengths • Requirements quickly generated/refined • Redundant efforts reduced • Client satisfaction enhanced by previous proof • Quality increase • Reinventing the wheel minimized Risks Significant investment to develop archives, maintenance and library functions May violate intellectual rights of previous owner Similarity may be misunderstood Table 03-01

34. Ch03: How to Scope a Project Business Process Diagramming Strengths • Excellent for cross-functional processes • Visual communications • Verification of “what is/what is not” Risks Implementation of improvement is dependent on an organization being open to changes Good facilitation, data gathering and interpretation required Time-consuming Table 03-01

35. Ch03: How to Scope a Project Prototyping Strengths • Innovative ideas can be generated • Users clarify what they want • Users identify requirements that may be missed • Client–focused • Early proof of concept • Stimulates thought process Risks Client may want to implement prototype Difficult to know when to stop Specialized skills required Absence of documentation Table 03-01

36. Ch03: How to Scope a Project Use Case Scenarios Strengths • State of system described before entering the system • Completed scenarios used to describe state of system • Normal flow of event/exceptions revealed • Improved client satisfaction and design. Risks Newness has resulted in some inconsistencies Information may still be missing from scenario description Long interaction required Training expensive Table 03-01

37. Project goal and solution Requirement 1 Requirement n Function 1.1 Function 1.2 Function n.1 Function n.2 Function 1.3 Function n.3 Sub-function 1.2.1 Sub-function 1.2.2 Sub-function 1.2.3 Feature n.3.3 Feature n.3.1 Feature n.3.2 Feature n.3.4 Feature 1.2.1.4 Feature 1.2.1.1 Feature 1.2.1.3 Feature 1.2.1.2 Ch03: How to Scope a Project Building the Requirements Breakdown Structure Figure 03-03

38. Building the Requirements Breakdown Structure • The RBS is a hierarchical description of what the solution has to do in order to acceptably meet client needs.

39. Project goal and solution Requirement 1 Requirement n Function 1.1 Function 1.2 Function n.1 Function n.2 Function 1.3 Function n.3 Sub-function 1.2.1 Sub-function 1.2.2 Sub-function 1.2.3 Feature n.3.3 Feature n.3.1 Feature n.3.2 Feature n.3.4 Feature 1.2.1.4 Feature 1.2.1.1 Feature 1.2.1.3 Feature 1.2.1.2 Ch03: How to Scope a Project RBS – The Reality Functional Requirement n

40. Ch03: How to Scope a Project Characteristics of the RBS • The RBS is intuitive and most meaningful to the client • The RBS is a deliverables based approach • The RBS is consistent with the PMI PMBOK • The RBS remains client facing as long as possible into the planning exercise

41. Ch03: How to Scope a Project Advantages of using the RBS • Does not require a trained facilitator • Does not require learning one of the contemporary approaches to requirements gathering • Presents an intuitive approach to gathering requirements • Allows the client to work with the project team in an environment familiar to them, i.e., to stay in their own comfort zone • Paints a clear picture of the degree to which the solution is clearly defined • Provides the input needed to choose the best fit PMLC Model

42. Ch03: How to Scope a Project What is a Business Process? A business process is a collection of activities that take one or more inputs from one or more different sources and produces a change of state that delivers business value. Input A Change of state Input B Input C Business Process Figure 03-04

43. Ch03: How to Scope a Project Creating a Business Process Diagram Figure 03-05

44. Creating a Business Process Diagram…. • Operation— Denotes that a change has taken place. The input is somehow changed as a result of having gone through this process. • Movement —Denotes the movement of output from one process step to become the input to the next process step. • Decision —Denotes that a question needs to be answered. There are two flow paths that emanate from a decision box: Yes or True and No or False. You follow one of these paths based on the decision. • Inspection— Someone other than the person producing the output must inspect it for quality, conformance, or some other tangible characteristic.

45. Creating a Business Process Diagram…. • Document—Denotes a paper document. • Delay —Denotes a wait state in a process. It’s usually associated with something joining a queue and waiting for the operator of the next process step to become available. • Storage— Indicates that an item has been placed in storage and must wait for a release before moving to the next process step. This usually represents wasted time that must be removed from a process.

46. Creating a Business Process Diagram…. • Annotation—Provides added detail about some process, which is needed for clarification. It might also include the position title of the person responsible for the process. • Direction of Flow — Denotes the order of process steps. • Transmission —The interrupted arrow indicates when information is to be transmitted from one physical or virtual location to another.

47. Creating a Business Process Diagram…. • Connector— Connects the flow between two separate locations; often used as an off-page connector. • Boundaries— Denotes the initiating and closing processes of a flow diagram. Usually the words START or BEGIN are associated with the initiating process, and STOP or END with the closing process.

48. Business Process Diagram Formats • Three common formats are used: • The top-down and left-to-right format: It is commonly used in program and system flow charts. • ‘‘Swim-lane’’ format: It identifies the actors who participate in the business • Context Diagrams: One way to describe your process at a very high level

49. Ch03: How to Scope a Project The Top-Down Left to Right Format Figure 03-06

50. Ch03: How to Scope a Project The Swim Lane Format Figure 03-07