Effective Project Management

1. Effective Project Management Barbara Stone & Jodie Mathies September 20, 2007

2. Agenda • Review Charter / POS assignment • What is an Elevator Speech? • Requirements Gathering - overview • Requirements Gathering – class exercise • Prioritizing and iterating requirements • Alternative Analysis

3. Review Charter / POS Assignment

4. Back to Lifecycles for a moment A simple generic model: Initiation Planning Execution Close-out More Common: Initiation Analysis Design Execution Close-out Wysocki TPM: Defining Planning Launching Monitor / Control Close-out A real-world example: Phase 1 IDENTIFY AND ASSESS OPPORTUNITY Phase 2 GENERATE & SELECT ALTERNATIVE(S) Phase 3 DEVELOP PREFERRED ALTERNATIVE Phase 4 DEVELOPMENT EXECUTION & IMPLEMENT Phase 5 OPERATE AND EVALUATE

5. You created the Charter / POS in the Initiation / Definition Phase The Charter / POS document contained the level of detail needed to approve the project With your Charter / POS, you should be able to give an elevator speech

6. Elevator speeches You are:Standing Informal Informative Brief Include: Business issue you are tackling How company benefits Why you are excited to take part What the listener can do* * if you need something

7. Elevator speech • http://www.creativekeys.net/PowerfulPresentations/article1024.html • Prepared presentation • Articulates in 3-4 minutes • Who are you helping • With what problem • How company benefits • Practicing is a good idea

8. Requirements Gathering is part of the Planning phase You are now creating a Requirements specification document This document elaborates the scope to the level of detail and specificity needed to: • Evaluate and decide between alternatives for design of final project deliverable • Plan the execution phase

9. Requirements Gathering – a Business activity How does what is being described meet the business need? Include enough detail to know success. Customer Requirements Project Deliverable Customer need Project Deliverable Cust. Accept. Criteria

10. Requirements Gathering – a Business activity Try to separate Requirements from Design (specifically technical design) Requirement: ‘I need to be able to view this chart within 2 seconds’ Design: ‘Pre-calculate this chart on a nightly basis’

11. Who is involved?

12. Broadest view of sources • Requirements / deliverables from previous projects • RFP, RFI, etc. • documents used to gain project approval • feasibility study, assessment documentation • customer documentation • customers themselves • relevant third party or external media • etc.

13. Business Business process, metrics, etc. Functional What the solution can actually do Technical Performance, scalability, etc. Implementation Who rolls out, user training, documentation Project Test environments, administrative help, etc. Forms of Requirements documentation

14. Requirements Quality Gateway How do you know when a Requirement is accurate enough? All requirements – separately, and as a whole – pass through a review to determine if they meet pre-determined criteria: • Completeness • Clarity • Measurability • etc

15. Facilitated Group Session Interviews Observation Requirements Reuse Business process diagramming Prototyping User Stories Use Cases These are not mutually exclusive! Requirements Gathering approaches

16. Brainstorming Card Sorting Competitor Product Analysis Concept Testing Contextual Research Customer Needs Analysis Customer Segmentation Customer Stakeholder Analysis Environment Profiling Ethnographic Research Focus Groups Success Criteria Metrics Surveys Task Modeling Use Case Development User Profiling User stories Traditional & Agile Methods

17. Current state Existing processes Solution Detail Functional Data Inputs/outputs Screen requirements Report requirements User community Security requirements gaps Future state Required processes Quality specifications Audit Process performance Application performance User acceptance HP – generic (traditional)

18. SIPOC

19. User stories – card, conversation, confirmation (Agile) • A written description of the story used for planning and as a reminder • Conversations about the story that serve to flesh out the details of the story • Tests that convey and document details and that can be used to determine when a story is complete

20. Example: job board • Card - A user can search for jobs • Conversation • What values can users search on? State? City? Job title? Keywords? • Does the user have to be a member of the site? • Can search parameters be saved? • What information is displayed for matching jobs?

21. Guidelines for good stories • Consider each user role & identify the goals that user has for interaction • Slice the cake – but not on technical lines • Write closed stories • Put constraints on cards • Size the story to the horizon • Keep the UI out as long as possible

22. Refining goal in stories – ‘find a job’ • Search for jobs she’s interested in based on skill, salary, location, etc. • Automate the search process so she doesn’t have to search manually each time • Make her resume available so companies may search for her • Easily apply for any job she likes

23. Acceptance test (confirmation) • Try it with an empty job description • Try it with a really long job description • Try it with a missing salary • Try it with a six-digit salary

24. Prioritize

25. Prioritization 2 – identify ‘minimum requirements’ “One of our most common problems is taking on too much work – attempting to exceed requirements rather than addressing the minimum requirements to meet real needs. Thus, meeting minimum requirements is in the customers’ best interests. It helps avoid the problems of late deliveries, budget overruns, low morale, and poor quality.” Dr. Ralph R. Young, Recommended Requirements Gathering Practices

26. Traceability log • Requirements cross-referenced to deliverables • Funnels to change management matrix

27. Requirements Gathering exercise Goal: Provide I-School students with information they will need if they are at South Hall during the next ‘big one’ • Who provides requirements? • Categories of requirements • How will they be documented / shared?

28. Our list

29. Reality check 1: Is your Business Case still valid? The 4 criteria for testing the business case: • Business Needs that justify the project • How project supports Organization strategy • How project will improve Organization • Benefits the Organization will realize through project Has Requirements Gathering uncovered information that would necessitate changes? If so, what do you do?

30. Reality check 2: Do your Constraints stand? Circle back to high-level estimates for: • Scope • Budget • Deadline And any written criteria for: • Resources • ‘Quality’ Has Requirements Gathering uncovered information that would necessitate changes? If so, what do you do?

31. Think about your project for this class • How linear / iterative is your Requirements Gathering process (or will it be)? • How will Requirements be documented and who signs off on them?

32. Requirements gathering vs requirements negotiation • The problem with gathering requirements is right there in the word gathering. What images does it conjure? • Projects rarely start out with clear objectives or requirements; they begin in confusion and ambiguity. • The other problem with gathering requirements is that it suggests subservience or disinterested passivity on the part of the IT group. It gives the impression that the job of a technical team is to take orders like a waiter who couldn't care less what you eat and then deliver the cooked meal.

33. Requirements negotiation • Think of a set of requirements as being like a multilateral treaty among a group of nations. • Negotiate requirements among the many stakeholders: • the business interests of executives who fund projects • the utility needs of the users who will work with the systems every day • the technical needs of those who build, deploy and support those systems • the list can go on and on. • Successful projects begin not with a harvest, but with a difficult set of discussions on what should be done.

34. Anecdotes – what worked, what didn’t • Sticking to ‘business’ • Know your hierarchy – some requirements (eg. Regulations) trump others • ? • ? • Examples from the class?

35. Alternatives review & decision There may be multiple ways to fulfill the Requirements • Eliminate alternatives that don’t meet external constraints • For example, does your company restrict technical alternatives? • Evaluate remaining alternatives against selected criteria: • time/budget requirements • Team skillset and interests • Other criteria as team requires

36. SWOT – descriptive analysis • I have a CTGL template that includes SWOT and decision matrix that I could show

37. Numeric scoring

38. Assignments for next class • Read Effective Project Management, chapter 4 • Be prepared to give an elevator speech on your project