The Long Tail Why the future of business is selling less of more ▫ISBN = ▫Chris Anderson Low Distribution and Inventory costs allow companies to realize significant profit How do you make a profit? ▫Selling small volumes of a lot of hard to find items ▫Rather than selling “hit/hot” items ▫The total number of sales of theses “non-hit” items is referred to as the long tail

Team Skill 4: Managing Scope Establishing Project Scope (18)

Project Scope What is project scope ▫Product Functionality ▫Project Resources ▫Available Time 3

Project Scope Brooks Law ▫Adding personnel to late project makes it later How to determine achievable scope? ▫Effort Required = Resources Available Projects that run over there estimates are typical ▫Usually by a factor of 2 4

Project Scope First step is establishing a baseline ▫Over budget projects incur more time ▫Time = money ▫Poor estimates cost money ▫Effecting companies projects 5

Project Scope Keys to success ▫Communication and Participation among stakeholders ▫Have defined processes  Requirements management  Change control  Defect management 6

Project Scope Involve them early and often ▫Product Manager  Manages the Business Requirements ▫Project Manager  Manages the projects timeline and resource assignment ▫Architect  Define changes to the structure of the system (Class, DB, …) ▫Developers  Will code the project ▫Testers & QA staff  Will test the resulting project ▫Technical writers  Will have to document the project (User’s manual, Help Docs, …) ▫Users dedicated to project  Testing, design input, … ▫Technical resources  Standards committees, Third party systems, … Why is it important to have all of these people involved so early in the process? 7

Project Scope Device Considerations ▫Workstations ▫Software tools ▫Simulation Systems ▫etc. 8

Project Scope Brooks Law ▫Can’t manage scope by adding people  Especially late in project Why ▫Lower productivity ▫Ramp-up time 9

Project Scope Study from the beginning of class (Standish Group) ▫Most projects more than double their estimate ▫How can we fix the problem?  Reduce scope by at least 50%  Reduce or remove:  Quality assurance  Testing  Documentation Taking any action besides scope reduction will result in a bigger hole later on. 10

Project Scope Reducing scope: ▫Still has to be a useful system ▫List of features ▫Features are clearly defined ▫Business and the Customer have to agree on acceptable functionality ▫Reduce so that the scope of the project meets resources and time 11

Project Scope Leffingwell Suggests ▫Create a features list ▫Define a baseline ▫Manage Scope in this fashion What is the weakness of this approach? 12

Project Scope Weakness of Leffingwell’s Approach ▫Features can be too general What should we use? ▫Use Cases Why? ▫More detailed definition of the baseline ▫A Use Case scenario can be broken into parts  Base Case  Alternative flows ▫These parts can then be deferred to different releases 13

Project Scope Creating our new baseline from Use Cases ▫Categorize by  Priority  Risk  Effort 14

Project Scope Priority ▫Who determines priority?  Customer?  Project/Product Management?  Development?  QA?  Architecture? 15

Project Scope Risk ▫Difficulty of implementation ▫Can be the most time consuming  From both an analysis and development ▫Development and Architecture need to be involved Rank Hi-priority / hi-risk UCs at top of list ▫Number rankings 16

Project Scope Effort ▫Estimate required for each Use Case ▫Use Case scenario must be complete  Can be alternative scenarios once the base case is complete 17

Project Scope Finalizing the baseline ▫Schedule high priority/ high risk ▫Tackle as many of these as possible until you have fully utilized all resources ▫All other Requirements/Use Cases are deferred Must manage this via some tool (Excel, MS Project, …) 18

Project Scope Managing scope is managing expectations ▫Iterative processes Assists in this  Customer sees working system each iteration  Ability to re-prioritize remaining reqs each iteration  Producing a useful system 19