Software Project Planning: Identifying Stakeholders and Defining Needs

1. Applied Software Project Management Chapter 2 Software Project Planning [Modified version of Stellman and Greene’s Chapter 2 slides. Adapted for use only in the CS 709B course at UNR, Spring 2012] http://www.stellman-greene.com

2. Who Needs Software? • Most software is built in organizations for people with specific needs • A stakeholder is a anyone who has an interest (or stake) in the software being completed • A user is someone who will need to use the software to perform tasks • Sometimes stakeholders will be users; but often the stakeholder will not use the software • For example, a senior manager (like a CEO or CTO in a company) will usually have a stake in the software that is built (since it affects the bottom line), even if she won’t ever use it http://www.stellman-greene.com

3. Who Builds Software? • Software is typically built by a team of software engineers, which includes: • Business analystsor requirements analysts who talk to users and stakeholders, plan the behavior of software and write software requirements • Designers and architects who plan the technical solution • Programmerswho write the code • Testerswho verify that the software meets its requirements and behaves as expected http://www.stellman-greene.com

4. Project Management • The project manager plans and guides the software project • The project manager is responsible for identifying the users and stakeholders and determining their needs • The project manager coordinates the team, ensuring that each task has an appropriate software engineer assigned and that each engineer has sufficient knowledge to perform it • To do this well, the project manager must be familiar with every aspect of software engineering http://www.stellman-greene.com

5. Identifying Needs • The project manager drives the scope of the project • The project manager should identify and talk to the main stakeholder(s) • The effective way to show stakeholders that their needs are understood and that those specific needs will be addressed is with a vision and scope document http://www.stellman-greene.com

6. Vision and Scope Document • A typical vision and scope documentfollows an outline like this one: • Problem Statement • Project background • Stakeholders • Users • Risks • Assumptions • Vision of the Solution • Vision statement • List of features • Scope of phased release (optional) • Features that will not be developed http://www.stellman-greene.com

7. Vision and Scope Document * • The vision and scope documentitems should be discussed with the stakeholders • It can be used as an agenda for an initial meeting • A lot of notes should be taken • The document is used to build consensus and acts also as a summary of discussions • After it is written it should be reviewed by every stakeholder, representative users, and members of the development team. Agreement by all is important. • Recommended extra reading: Scott Berkun, The Art of Project Management, O’Reilly 2005. http://www.stellman-greene.com

8. Vision and Scope Document* • Problem Statement • Project background: • Problem, its reasons, brief history, prior attempts to address it, how a decision to tackle it was reached • Stakeholders: • Bulleted list: roles, titles, or names + main needs for each • Users • Idem, but if many users, roles or titles should be used • Risks • Main potential risks, issues, external factors • Assumptions • Use Wideband Delphi estimation technique or a brainstorming session http://www.stellman-greene.com

9. Vision and Scope Document* • Vision of the Solution • Vision statement: • What the project is about, what is expected to accomplish • Should provide compelling justifications for funding • List of features: • Feature: cohesive area of the software that fulfills a specific need by providing a set of services or capabilities • Any software package can be broken down into features • Chose here the right level of granularity. Recommended: about 10 features • For each feature: name + brief description • Scope of phased release (optional): • Sometimes it is useful to have the features implemented in 2 or 3 releases • A feature can also be divided over 2 releases, but that needs to be explained clearly • Features that will not be developed • Unrealistic or lower priority features should be listed here http://www.stellman-greene.com

10. Project Plan • The project plan defines the work that will be done on the project and who will do it. It consists of: • A statement of work (SOW) that describes all work products that will be produced and a list of people who will perform that work • A resource list that contains a list of all resources that will be needed for the product and their availability • A work breakdown structure and a set of estimates • A project schedule • A risk plan that identifies any risks that might be encountered and indicates how those risks would be handled should they occur http://www.stellman-greene.com

11. Statement of Work • The statement of work (SOW) is a detailed description of all of the work products which will be created over the course of the project. It includes: • A list of features that will be developed • A description of each intermediate deliverable or work product that will be built (with one paragraph description for each): • SRS, design and architecture specs, code and software packages, test plans and test cases, user acceptance plans, source code, executables, documentation, tutorials, user manuals, all other work products that will be created. • The estimated effort involved for each work product to be delivered http://www.stellman-greene.com

12. Resource List • The project plan should contain a list of all resources that will be used on the project. • A resourceis a person, hardware, room or anything else that is necessary for the project but limited in its availability • The resource list should give each resource a name, a brief one-line description, and list the availability and cost (if applicable) of the resource http://www.stellman-greene.com

13. Estimates and Project Schedule • The project plan should also include estimates and a project schedule: • A work breakdown structure (WBS) is defined. This is a list of tasks which, if performed, will generate all of the work products needed to build the software • An estimate of the effort required for each task in the WBS is generated • A project schedule is created by assigning resources and determining the calendar time required for each task Estimates and project schedules will be discussed in detail in later slides http://www.stellman-greene.com

14. Risk Plan • A risk plan is a list of all risks that threaten the project, along with a plan to mitigate some or all of those risks • The project manager selects team members to participate in a risk planning session: • The team members brainstorm potential risks • The probability (from 1 – highly unlikely to 5 – very likely to occur) and impact (1 – low impact to 5 – huge impact) of each risk are estimated • A risk plan is constructed • The session normally takes about 2 hours http://www.stellman-greene.com

15. Risk Plan* • To draw the risk plan • Brainstorm potential risks and make initially vague risks (“the project might be delayed”) concrete • For estimation, percentages can also be used • A simple technique for prioritization: • Identify the top and bottom items (probability and respectively, impact) and give them values 5 and, respectively, 1. Then assign all other items values from 1 to 5 based on comparison with these “extremes” • Also for prioritization, use: probability x impact • Start mitigation plans for the highest priority items • For mitigation: alter project plan (e.g., alter schedule), add additional tasks, plan for risks http://www.stellman-greene.com

16. Risk Plan Example http://www.stellman-greene.com