Product Lifecycles
•
1 like•248 views
The presentation compares products to living beings and follows their development, emphasizing the competencies required to achieve quality
![Our Purpose Tonight ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Product Lifecycles
Similar to Product Lifecycles (20)
More from Jorge Boria
More from Jorge Boria (20)
Product Lifecycles
- 1. From Lust to Dust: A Product’s Life Cycle And the Roles that Make it All Worth It Jorge Boria
- 16. A New Product is Born!
- 17. Change Adoption And Time Time Early Adopters 13.5% Early Majority 34% Late Majority 34% Laggards 16% Innovators 2.5% The Chasm
- 22. A Pictorial View of The Life Cycle tentative use inception institutionalization decay childhood adolescence maturity old age CUSTOMER NEEDS CHANGE REQUESTS birth PROJECT ENGINEERING engineering of version 1.0 deployment new release new release new release new release new product quick fixes controlled changes INSTALLATION AND SUPPORT RESEARCH conception product TIME engineering of version 1.5 engineering of version 2.0 engineering of version 2.1 engineering of version n.57 engineering of version 1.0 of new product …
- 28. Question to the Audience Does it matter who does what?
- 31. Comparing Roles Customer Loyalty Product Version Set of Inspirational Ideas, Prototype Outcome Patch’n’go Sequential or Spiral Evolutionary, Iterative Working Paradigm Variable Fixed Sunken Costs Very Lax Strict Lax Control Reaction Time Discipline Individual exploration Ruling Principles Problem Patcher (on-the-fly fixes) Problem Solver (applied creativity) Creative (a solution in search of a problem) Personnel Characteristics Customer Satisfaction Quality and Personal Pride Spontaneity and Inspiration Guiding Force IMPLEMENTATION AND SUPPORT ENGINEERING RESEARCH AND EXPLORATION FEATURE ROLE
- 36. Bad Software Engineering Focus on Delivery Date Low Quality Rework Late Delivery Vicious Cycle ©2007-2009 . worse practices bad practices defects
- 37. Good Software Engineering Focus on Quality Good Quality Little Rework Timely Delivery Virtuous Cycle ©2007-2009 . best practices good products better practices
- 38. Any Questions? thank you for your time [email_address] www.liveware.com
Editor's Notes
- This model, used by many, and discussed recently by Geoffrey Moore, shows an adoption curve that is a member of the “normal curve family.” The early and late majority generally fall within one standard deviation of the mean, with early adopters and laggards at two standard deviations, and a population of innovators at about 3 standard deviations. Appealing to different groups requires different tactics and timing. Innovators – ready to try anything; use them for concept exploration Early adopters –tolerant of change and revisions; use them for pilots and champions Early majority – practical people; want to see evidence this is useful; get them the results of the pilots and management support Late majority – they want to wait until the change is an established standard, management push and rewards may be necessary Laggards – want nothing to do with the new approach; will avoid as long as they can; don’t focus here The chasms shown here is one of two pointed out by Moore. There is also a smaller chasm between the early and late majority, reflecting the different approach to these two groups. However, the one between early adopters and early majority is more significant – those to the left are able to handle revolutionary change, while those to the right need evolutionary change.
- Role 1: Research and Exploration Ideas that end up in a product are often initially created by a group that is guided by spontaneity and inspiration [Olso93]. This group works best following an evolutionary model, that is, building bits and pieces and tying them together into a less than completely coherent work product, often called a “proof of concept.” The emphasis of such a group lies in innovation. Exploration (of new technologies and ways to apply it) and redoing are encouraged. Control is lax, although these groups usually work under a fixed budget. Whatever they turn out is usually well received. The goals are set in long term visions. The costs incurred in research are sunken costs to the company, that is, they are incurred without immediate accountability. Role 2: Engineering The economic viability of a software product lies in its quality and in its development costs. If quality is low, the product is not viable (see role 3 for an explanation.) If the development costs are too high, there might not be enough market to compensate these costs. When people work in this role they should be less concerned about innovation and more about quality. This role is best managed through a well defined process model, in which a requirements-gathering phase precedes the design phase, that in turn precedes the implementation phase. (Although this so-called “waterfall model” is strictly sequential, it is seldom the case that the developers “run” the activities in such clear-cut order. They usually go back and forth from requirements to design. They might even move forward to implement a little, then back to gathering requirements. However, the nature of each activity and where each belongs in a documentation scheme should be kept clear at all times.) Exploration is discouraged and rework is considered a necessary evil. Control is strict, and budgetary constraints are strongly tied to project management. Goals are now midterm, counted in the order of months, not years. The costs of activities performed in this role are fixed, but not sunken. A product is expected as an outcome, and the costs of the product are indirectly (as we shall see when we look at Role 3) dependent on the expenses of the phase. Role 3: Quick Fixes Under this role, only urgent patches are tackled. Larger fixes and enhancements are then rewoven into the fabric of the product through newer versions developed in an iteration of role 2 (version n, n>1.0). In role 3, the process changes to “fix and ship,” the emphasis at this time residing in immediate response. Exploration and redoing are now punished, because otherwise control is even less attainable. The lack of control tied to this role is linked to the fact that the costs for the role are a function of the quality of the product. Products with poor quality are harder to maintain and enhance, incrementing the costs of repair. This is truly bad, since now these costs are variable costs, a function of both the number of problems found during operation and the number of corresponding calls received.