Chapter 2: Envisioning

Transcription

1 Chapter 2: Envisioning The first phase of the MSF Process Model is Envisioning, producing an overview of the business problem to be solved. Even with limited-scope projects involving small teams, it is critical to establish a clear vision of what the customer wants to achieve with the solution and to begin planning the development. Use the envisioning phase to: Identify the problem Develop a solution vision Prepare a solution concept Address solution feasibility Define project scope limits Prepare an initial project schedule and resource estimate Gain approval of project vision and scope Specific responsibilities of project team members during Envisioning and every other phase naturally depend on the team member s role in the Team Model. For small projects, one person often has to adopt multiple team roles. In these situations, it is important for the team member focus on what role they are taking when preparing the documentation. Broadly, development team responsibilities during Envisioning are: Product management. The responsibility of product management includes ensuring that the team addresses the customer requirements. The product management role collaborates with the program management role and drives the effort to establish a shared project vision. To accomplish this goal, product management studies and analyzes the business problem, business requirements, project vision, business goals, and user profiles. Program management. Program management establishes project design goals, defines success factors and measures, articulates the solution concept, and sets up the project infrastructure. Development. The development team provides feedback to the team on the technical implications of developing the product and on the feasibility of the solution concept. User experience. The user experience team analyzes the performance needs and support issues of users and considers the product implications of meeting those needs. Testing. The testing team provides feedback to the team on the quality goals for the solution and specifies the actions required to achieve that level of quality. The testing team then applies decisions about the quality goals to testing strategies and acceptance criteria that will be used to measure quality. Release management. The release management team identifies what will be required to deploy the product, how the product will be deployed, when it will be deployed, and whether deployment will require additional infrastructure. Vision/Scope Document Completion of the Envisioning phase is a milestone marked by approval of the project s Vision/Scope Document. During the Envisioning Phase, information is gathered using techniques like interviewing, shadowing, focus groups, and other research, and the documentation is written. Data gathering and documentation continue throughout the project, but the Vision/Scope approval milestone marks a bit of Small Project System Development p 2-1

2 freezing what the project will accomplish. If major new requirements or constraints come to light during the project, they should be addressed in a future release of the software, or the project should backtrack and reopen the Envisioning Phase. The Vision/Scope documentation is the key guide for management and development of the solution. In moderate to large enterprise-wide projects, the documentation will be comprised of several documents, and the Vision/Scope Document itself provides a summary and index to the documents. For smaller projects, it is probably sufficient and easiest to understand if a single document is prepared. Specific contents and detail of the Vision/Scope documentation may vary, but it should follow this general outline: Problem statement Vision statement Solution concept Feasibility review Out-of-scope Initial schedule Vision/Scope walkthru and approval Vision/Scope documentation is not limited to these sections. For a given project, it might make sense to include some details on project structure, risk assessment, testable features, preliminary use cases and user requirements, or catalogs of actors, business rules, and key terms. For small-scale projects, though, these details are either not needed or can be addressed during the Planning Phase. Problem Statement A problem statement is a short narrative describing the issues the business hopes to address with the project. It briefly relates the current state of business activities and, as accurately as brevity and conciseness will permit, the problem is stated. An ideal problem statement would allow a newcomer to the project to quickly see the issues being addressed and be able to put the project documentation into context. Below is a sample problem statement developed for a project concerning a medical reimbursement benefit in a business offers to employees. As a style, the problem has been italicized to separate it from the background information. Medical Reimbursement Planner Problem Statement Our Personnel Services Department manages a medical reimbursement plan which allows an employee to allocate salary from the upcoming year to be used for medical expenses during the year. This allocation is not taxed, so at least some employee medical expenses can be paid from before tax salary, a potential savings for the employee. If total reimbursed medical expenses are less than the allocation, however, the remainder of the allocation is forfeited by the employee. Employees would benefit from a method which helps them determine an appropriate medical reimbursement allocation. Vision Statement The vision statement establishes a consensus that the project is valuable to the organization and is likely to succeed. A vision statement must be short enough to be remembered, clear enough to be understood, and strong enough to be motivational. A good vision statement has the following five characteristics (with the cute acronym SMART as a reminder): Small Project System Development p 2-2

3 Specific. A vision statement should be specific and include the ideal state of the business problem so that the end result is meaningful. Measurable. By creating a vision statement that is measurable, the project team can determine the success of the project and whether it met the business goals. Achievable. Given the resources, the time frames, and the skills of the team members, the vision statement should be achievable. An achievable vision statement motivates the team to complete the project. Relevant. The vision statement should relate to the business problem being addressed. If the vision statement is not relevant, the project team might discover that they are trying to solve a business problem that does not exist, and the project might lose sponsorship. Time-based. The vision statement should clearly indicate the estimated time frame for the delivery of the solution. The example vision statement below applies the SMART guidelines to our example project. A vision must focus on outcomes, not how the project might be developed or deployed. That is, the statement Microsoft Excel will be used to develop a decision model might be a good start for a solution concept, but it is not a vision. Medical Reimbursement Planner Vision Statement By the start of the next payroll year, at least half our employees will indicate they have made a confident, reasonable decision on whether to participate in medical reimbursement, and on how much salary to allocate. Solution Concept A solution concept provides a capsule of the solution approach to be pursued in the project s later phases. It should provide some review of the project s business goals (what the customer wants to achieve with the solution), design goals (important attributes of the solution), and critical success factors along with a sense of the projects scope and user requirements. It must provide enough detail for project sponsors to understand what will be received in return for the allocation of resources. But above it, it should provide the project team with enough of a blueprint to design, develop, and test the solution. To get a better understanding, review an example from our sample project. Medical Reimbursement Planner Solution Concept Since an employees exact out-of-pocket spending for medical expenses cannot be predicted, planning an allocation for medical reimbursement needs to trade-off allocating too much (and losing income that is allocated but not used for medical expenses) with allocating too little (and having to pay medical expenses with after tax dollars). To handle the uncertainty, we will develop a spreadsheet model to investigate a range of what if allocations for an employee, and recommend that allocation which, on average, has the smallest net cost. A basic formula to be applied is NC = TA + MAX(0,AM TA))/(1-MR) Where NC = Net cost before taxes to employee for medical expenses TA = Total allocation made to the medical reimbursement program AM = Actual medical expenses incurred during the year MR = The employee s marginal tax rate This simply puts into numbers the concept that an employee will always pay (in before tax terms) their allocation (i.e., TA) plus whatever it takes before taxes to have enough after taxes to pay any medical expenses beyond the allocation (i.e., AM-TA but only when AM-TA is positive). Small Project System Development p 2-3

4 The user of the spreadsheet (an employee or perhaps someone advising them) would enter a range of likely actual medical expenses (e.g., from $1000 to $5000); this range would be where they are pretty sure their actual medical expenditures for the year would fall. The would also enter their marginal tax rate (this might take a little coaching or background and it might be possible for the spreadsheet to infer it from salary level). Based on the inputs, the spreadsheet would prepare a what if table, calculating the net cost of several allocations and actual medical expenses within the given range. The allocation with the lowest average net cost would be recommended to the user. For a concrete example, suppose that an employee is in the 10% tax bracket and estimates that out-ofpocket medical expenses will be $2000 or $2500 but the employee does not know which. From the inputs, a table can be calculated which shows the results of each scenario: Reimb Actual Medical Expenses Alloc Avg Cost $2000 $2500 $ $2275 $ $2388 $ $2500 In this particular case (though the actual analysis would be more detailed), the suggested allocation for the employee would be $2000 even though the predicted average net cost would be $2275 (the $275 came from expenses beyond the allocation). Every other allocation had a higher estimated average cost. As with most of the documentation prepared for a system development, it is unlikely that a solution concept will be understood and accepted by all team members and stake holders on the first draft. Refinement and clarification of the solution concept is part of the work of the envisioning phase, and it is only at the Vision/Scope Walkthru and Approval that the concept is accepted. It is critical to get a draft Solution Concept out for review early to get reasonable assurance that the concept is workable and that it can be understood by the others involved. Feasibility Review The development team should outline why the stakeholders should have confidence that the problem s solution is feasible (i.e., the problem can actually be solved with this Solution Concept). By following through with this discipline, the project team can limit risks associated with the development effort. For projects of our size, a quick checklist using the TELOS acronym should be more than enough: Technical: What reasons do we have to believe the proposed solution is technically feasible? Can the appropriate software be developed or purchased? Can the solution requirements be addressed using commonly available tools and practices? Economic: What reasons do we have to believe the proposed solution is economically feasible? Will the benefits of having the solution outweigh the costs of not having it? What is the project s return on investment or payback? Legal: What reasons do we have to believe the proposed solution is legally feasible? Is our approach within legislative and common-law strictures? Will it violate any copyright or licensing agreements? Does it obey industry and organizational policies and procedures? Operational: What reasons do we have to believe the proposed solution is operationally feasible? Will users be able to operate it and understand the results? Can it run effectively on existing or proposed hardware and networks? Will deployment and maintenance of the solution be difficult? Small Project System Development p 2-4

5 Schedule: What reasons do we have to believe the solution s scheduling is feasible? Will the solution be in place in time to achieve strong benefits? Can the solution really be accomplished using the proposed time and resources? What risks are associated with a late project? Taking the time to provide thoughtful answers to these and similar questions will help make a convincing case to project sponsors and also provide an early warning to the development team of problem areas. As with other elements of the solution framework, a feasibility review is not an end in itself; it is a means to communicate and make clear why we think we should continue with a project. As a tangible example, the feasibility review for the Medical Reimbursement Planner follows: Medical Reimbursement Planner Feasibility Review To demonstrate that our approach to medical reimbursement planning can be accomplished, we have reviewed its feasibility along five dimensions: Technical: The spreadsheet model will involve a few pages and only a few formulas. Given the types of problems solved by spreadsheets, the requirements of this solution are almost trivial to a developer with the appropriate background. Developing a technical solution will not a significant issue. Economic: Costs for developing a solution will be minimal: a few hours development and documentation time. Other costs to anticipate are time spent counseling and advising employees and the time employees take themselves in making calculations. Tangible, dollar returns to the organization are minimal, but an average employee with $4000 annual out-of-pocket medical expenses would save about $600 in taxes with an accurate allocation (versus paying all expenses in after tax dollars). This is a huge ROI and immediate payback when you consider employee salaries. Economically, the project makes sense. Legal: Our license with Microsoft allows Excel on every desktop, and the model will be developed in house so running the solution complies with licensing and copyright. We have some worries about the sensitive information (salaries, tax rates, medical expenses) involved, and we need to develop procedures which avoid law suits about mishandling this information. It might be argued that the organization has a legal responsibility to see that the medical reimbursement benefit is made available to employees in a clear and effective manner; this solution approach would address that responsibility. Operational: Operating the model will require a little skill with entering values and interpreting results from a spreadsheet. Also, the user will need to provide information about their anticipated range of medical expenses and some sense of their marginal tax bracket. As a result, many employees may need some counseling from human resources or management in order to take advantage of the solution. Further, HR should plan an information or PR campaign for the solution. Technically, maintenance and deployment are as easy as providing a copy of a spreadsheet. Schedule: Development and technical documentation should span a week to ten days at most (and that allows a lot of time for user feedback on the interfaces). About three months should be planned for getting information out to employees and managers, and training counselors. There is every reason to believe that by the end of this tax year, employees can be using the solution to plan next year s taxes. Out-of-Scope A larger project (and some smaller ones) would include sections on use cases, user requirements, and project scope as part of the Vision/Scope documentation. For typical small-scope projects, however, that level of detail is better left until the Planning Phase. A small project s scope should be fairly clear from the Solution Concept and Feasibility Review, but it is important to identify boundaries on what the solution will provide. As information is gathered and concepts are developed, be sure to document features or issues that will not be addressed in your solution (at least, in the current release). This is probably done easiest and best with a simple list of out-of-scope items and some comments (as shown below for the example project). As always, the goal is to provide communication among the development team and stakeholders; by documenting these issues, they are made clear. Small Project System Development p 2-5

6 Medical Reimbursement Planner Out-of-Scope The following functions identified during the Envisioning Phase are considered out-of-scope for the Medical Reimbursement Planner. They are either unnecessary or might be addressed in future versions. Function A user s marginal tax bracket is an input parameter; it will not be calculated from salary information The model will assume that actual medical expenses are uniformly distributed in the range supplied by the user The current proposal does not include the notion of a database to save and retrieve past results or results for various employees It might be a help to employees to have some tracking of actual medical expenses to help with their estimates, and to compare estimates with past actuals. Comment In principle, it wouldn t be hard to figure out someone s tax bracket. It does involve a more sensitive set of questions but might be a good feature for version 2 It is probably more realistic to use a distribution with more central tendency; this will wait until version 2 The concept is a quick-and-dirty spreadsheet model to take input and prepare an answer. Users can save a worksheet with their entries. More functionality along these lines will have to wait. This is entirely out of scope at this point. Initial Schedule Even though the planning for the project has barely begun, a preliminary schedule for the project must be developed. For large projects, it takes a great deal of experience and insight not to mention confidence in your team s abilities and some risk taking to accurately schedule a development project. In small-scope projects, the same concerns exist, but a few guidelines go a long way to helping develop a schedule. In developing and managing a schedule, always keep in mind the MSF Tradeoff Triangle introduced in Chapter 1. This reminds us that given project quality as a constant software development management is a tradeoff among resources, schedule, and feature set. This worked out to various logical possibilities such as Given fixed resources, we will choose a schedule and adjust the feature set if necessary or Given a fixed feature set, we will choose a schedule and adjust resources if necessary. During the Envisioning Phase, the development team should come up with a consensus of which dimension is most important to them; work to make that the fixed element. Whatever dimension is second most important should be the chosen dimension, leaving the least important dimension as the adjustable one. When there is no clear choice among the three dimensions, fixing a schedule is the easiest. Here is a rule-of-thumb until your estimating skills develop. For small-scope projects, plan on taking 40 to 80 (or 60 on average) person hours per team member for project work (more or less if you have a feel for how long things will take). Establish a starting date, and fix an ending date based upon 60 work hours and team member availability for the project. For instance, if team members can devote 12 hours per week to this project, plan on finishing in 5 weeks (60 work hours divided by 12 work hours per week is 5 weeks). Break up the time span into 10% for Envisioning, 35% for Planning, 15% for Developing, 30% Small Project System Development p 2-6

7 for Stabilizing, and 10% for Deploying. Now you have fixed a schedule; just make sure features and resources comply with the schedule you have established. Feature set is the suggested choosing dimension. Users and stakeholders can usually react yes or no to specific features more easily then they can to choices of dates or resource utilization. This makes the feature set a nice negotiation item. Just don t allow the choices to make the fixed schedule not achievable. This leaves the price tag (i.e., resources) adjustable. From a development management point of view, cost out the schedule and features to estimate resources needed. If two developers are needed and get paid $100 per hour for 60 hours each, this means $12,000 is required: no magic there. Resources might not be money; your project s resources may be release time from other activities or borrowing a person from another department. Of course, the resources required might cause the sponsor to ask you to revisit your schedule or feature set, or motivate them to cancel the project. That negotiation is all part of getting a project going. This may seem rather flip and unscientific. The real management of a development project especially small-scope projects comes from ensuring that what happens conforms somewhat to the plan, not from doing involved estimates. These guidelines provide some assurance that the schedule will be reasonable for a small-scope software development project. As you gain experience, you will develop your own rules of thumb. Medical Reimbursement Planner Initial Schedule Our anticipated schedule for the project is based on one developer spending 40 work-hours developing the spreadsheet and documentation. The developer can devote 10 hours per week to this project, so the planned project spans 4 weeks: Sep 1, xxxx Project Start Sep 4, xxxx Vision/Scope Approved Sep 13, xxxx Project Plans Approved Sep 18, xxxx Scope Complete Sep 26, xxxx Release Readiness Approved Sep 28, xxxx Deployment Complete The Solution Concept outlines the basic features of the software to be developed, though users will have the opportunity to identify and choose some features during the Planning Phase. We do not anticipate addressing any of the out-of-scope items in this release. While our precise resource needs cannot be established until the feature set is firmed up, we anticipate a chargeback of $4000 (40 hours at $100 per hour) for development of this solution. No other resources will be required. Vision/Scope Walkthru and Approval The envisioning phase culminates in the vision/scope approved milestone. This milestone represents the point at which the project team and customer agree on the overall direction for the project, including the scope of the solution. This baseline version of the document is an important project deliverable that is used in the subsequent phases of the project. Ideally, the Vision/Scope phase and deliverables should receive some actual signature (or some other official approval) from the project sponsor, a user manager or representative, and the development team s product and program management. The Vision/Scope Document should be formally approved in a vision/scope meeting. The team walks through the work done gathering information and documenting the results (this validation is a process that will occur throughout the project.) By having the customer validate the completed work, the team prepares the customer to understand the tradeoffs that are made in defining the scope. The customer is Small Project System Development p 2-7

8 also educated about the project and the team s approach, creating a feeling of involvement that can greatly reduce difficulties in consensus and in future feature discussions. The vision/scope meeting ensures that the team and the customer arrive at a shared understanding regarding how the proposed solution will address the business challenge and how it is applicable to the current business scenario, given the scope that has been defined. This meeting is a mechanism for the team to share ideas and achieve a shared vision with the customer. This meeting also enables the customers to understand that the team is listening to them and actively involved in the project. The team uses this meeting to decide whether the project should proceed. The available resources and the potential gains may not be worth the total cost of the project. This validation step allows the team to redefine either the project solution or the resources and constraints. Medical Reimbursement Planner Vision/Scope Walkthru Agenda August 28, xxxx Introduction of Project Team Review of Vision/Scope Problem statement Vision statement Solution concept Feasibility review Out-of-scope Initial schedule Discussion & Adjustments Signoff Followup: After a brief discussion and some minor corrections, both Samantha Hardin (HR Manager) and Pete Diggins (IT User Development Coordinator) agreed to move forward with this project as outlined in this document by signing a project agreement. Small Project System Development p 2-8