Product Lifecycles


Published on

The presentation compares products to living beings and follows their development, emphasizing the competencies required to achieve quality

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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 spon­tane­ity 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 innova­tion. Exploration (of new technologies and ways to apply it) and redoing are encouraged. Control is lax, although these groups usually work un­der 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 develop­ment 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 imple­mentation phase. (Although this so-called “waterfall model” is strictly se­quential, it is seldom the case that the developers “run” the activities in such clear-cut or­der. They usually go back and forth from requirements to design. They might even move forward to im­plement 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 dis­couraged and rework is considered a necessary evil. Control is strict, and budgetary con­straints are strongly tied to project man­agement. 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 ex­pected as an outcome, and the costs of the product are indirectly (as we shall see when we look at Role 3) dependent on the ex­penses 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.
  • Product Lifecycles

    1. 1. From Lust to Dust: A Product’s Life Cycle And the Roles that Make it All Worth It Jorge Boria
    2. 2. Our Purpose Tonight <ul><li>Answer the questions: </li></ul><ul><ul><li>What is Quality? </li></ul></ul><ul><ul><li>How can quality be achieved? </li></ul></ul><ul><ul><li>Is there more than development and maintenance? </li></ul></ul><ul><ul><li>Does it matter who does what? </li></ul></ul>
    3. 3. Agenda <ul><li>Attempting to Define Quality </li></ul><ul><li>The product life cycle </li></ul><ul><li>Defining Roles </li></ul>
    4. 4. Define Quality
    5. 5. Quality is… <ul><li>Different things to different people </li></ul><ul><ul><li>that’s what quality is! </li></ul></ul>Quality is Subjective
    6. 6. Subjectivity in Quality <ul><li>Quality is not an attribute of a product </li></ul><ul><ul><li>it is an attribute of the relationship between a product and the person that perceives that quality </li></ul></ul><ul><ul><li>it can be good or bad </li></ul></ul><ul><ul><li>it can be measured for a set of people </li></ul></ul><ul><ul><ul><li>a population segment </li></ul></ul></ul><ul><ul><ul><li>under certain hypothesis of uniformity of criteria </li></ul></ul></ul><ul><ul><ul><li>if quality would be objective there would be no competing products </li></ul></ul></ul>
    7. 7. Quality is… <ul><li>Different things at different times </li></ul><ul><ul><li>that’s what quality is! </li></ul></ul>Quality evolves with time
    8. 8. Evolution of Quality <ul><li>For a new product, ‘quality’ might be novelty </li></ul><ul><li>As the product ages, ‘quality’ turns into availability and dependability </li></ul><ul><li>Even later in the product’s life, support can be ‘quality’ </li></ul>
    9. 9. The Underlying Premise <ul><li>The quality of a product is preeminently influenced by the quality of the processes used to develop, acquire, and maintain it. </li></ul>you should already have the best available you should already have the best available PROCESS PEOPLE TECHNOLOGY
    10. 10. How to Produce <ul><li>From the previous: </li></ul><ul><ul><li>there should be no one-size fits all process </li></ul></ul><ul><ul><li>processes should take into consideration the stage of development </li></ul></ul><ul><ul><ul><li>focus on processes to drive innovation are expensive and counterproductive in the late stages of a project </li></ul></ul></ul><ul><ul><ul><li>too much focus on engineering and documentation can stifle creativity in the initial steps </li></ul></ul></ul>
    11. 11. Agenda <ul><li>Attempting to Define Quality </li></ul><ul><li>The product life cycle </li></ul><ul><li>Defining Roles </li></ul>
    12. 12. Products Have Life Cycles, Too <ul><li>We can compare software products to human beings </li></ul>
    13. 13. 1: Pre-conceptual Stage <ul><li>Influences are already in place </li></ul><ul><ul><li>External conditions </li></ul></ul><ul><ul><ul><li>technology </li></ul></ul></ul><ul><ul><ul><li>market needs </li></ul></ul></ul><ul><ul><li>Internal conditions </li></ul></ul><ul><ul><ul><li>skills </li></ul></ul></ul><ul><ul><ul><li>cultural drives </li></ul></ul></ul><ul><ul><ul><li>personal competencies of individuals, </li></ul></ul></ul><ul><ul><ul><ul><li>managers and line personnel </li></ul></ul></ul></ul>
    14. 14. 2: Research and Development <ul><li>Light in product requirements </li></ul><ul><li>Large in customer needs </li></ul><ul><li>Exploratory </li></ul><ul><li>Time bounded </li></ul><ul><li>Agility is preferred over sound engineering </li></ul><ul><ul><li>‘good enough’, proof of concept, prototype </li></ul></ul>
    15. 15. 3: Initial Engineering <ul><li>Performed through a project </li></ul><ul><li>Preferred firm product requirements </li></ul><ul><li>Guided process </li></ul><ul><li>Quality goals, time constrained </li></ul><ul><li>Sound engineering is preferred over agility, still… </li></ul><ul><ul><li>Everyone expects the newcomer, no one is sure what it will look like, many expectations surround it, and it almost sure that it is going to keep us sleepless for many weeks after it arrives! </li></ul></ul>
    16. 16. A New Product is Born!
    17. 17. Change Adoption And Time Time Early Adopters 13.5% Early Majority 34% Late Majority 34% Laggards 16% Innovators 2.5% The Chasm
    18. 18. 4: Deployment Stage <ul><li>What is produced not always what is needed </li></ul><ul><ul><li>what they say, what they want, what they need; the requirements guessing game </li></ul></ul><ul><li>The product does not stand on its own </li></ul><ul><li>Babbles when it wants to speak </li></ul><ul><li>Has to be cleaned every few hours </li></ul>Expect Visionaries to Adopt
    19. 19. 5: Early Adoption Stage <ul><li>The inception stage, </li></ul><ul><ul><li>many things go wrong but are overlooked </li></ul></ul><ul><ul><ul><li>they will be soon solved </li></ul></ul></ul><ul><ul><li>Versions act up </li></ul></ul><ul><ul><ul><li>destroy your expectations </li></ul></ul></ul><ul><ul><ul><li>need urgent corrective measures. </li></ul></ul></ul><ul><li>Inception is a lot like adolescence. </li></ul>
    20. 20. 6: Institutionalization <ul><li>Users learn to trust it </li></ul><ul><ul><li>it is institutionalized into common use </li></ul></ul><ul><ul><li>it has achieved maturity and reliability </li></ul></ul><ul><ul><li>most changes are enhancements </li></ul></ul><ul><ul><ul><li>not difficult to implement </li></ul></ul></ul><ul><ul><li>adjustments to environmental changes </li></ul></ul>
    21. 21. 7 Decay <ul><li>The product ages </li></ul><ul><ul><li>Many changes over long periods </li></ul></ul><ul><ul><li>New technological developments </li></ul></ul><ul><li>The product is </li></ul><ul><ul><li>progressively less reliable </li></ul></ul><ul><ul><li>harder and harder to maintain </li></ul></ul><ul><ul><li>cannot be adjusted to the new technology </li></ul></ul><ul><ul><li>people tend to work around it, instead of through it </li></ul></ul>
    22. 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 …
    23. 23. Development <ul><li>The process of producing new features for a product. </li></ul><ul><ul><li>it could be considered an addition to an existing product </li></ul></ul><ul><ul><ul><li>in iterative development, it is the way of the land </li></ul></ul></ul>
    24. 24. Maintenance <ul><li>The application to an existing product of </li></ul><ul><ul><li>Additions </li></ul></ul><ul><ul><ul><li>extensions to the product. </li></ul></ul></ul><ul><ul><li>Fixes </li></ul></ul><ul><ul><ul><li>changes done to the product to eliminate its defects. </li></ul></ul></ul><ul><ul><li>Adjustments </li></ul></ul><ul><ul><ul><li>changes done to the product to accommodate external changes </li></ul></ul></ul><ul><ul><li>Migrations </li></ul></ul><ul><ul><ul><li>induced by changes in the underlying technology platform. </li></ul></ul></ul>
    25. 25. Support and Maintenance <ul><li>Good practice: </li></ul><ul><ul><li>during support only do (quick) fixes </li></ul></ul><ul><ul><li>create engineering projects for </li></ul></ul><ul><ul><ul><li>additions, </li></ul></ul></ul><ul><ul><ul><li>adjustments, </li></ul></ul></ul><ul><ul><ul><li>large clusters of fixes, </li></ul></ul></ul><ul><ul><ul><li>migrations, </li></ul></ul></ul><ul><li>Treat these activities as part of the normal development cycle for new versions. </li></ul>
    26. 26. Development and Maintenance <ul><li>From the above, development and maintenance do not define whether you are in Engineering or Support. </li></ul><ul><ul><li>you could conceivably do either in both </li></ul></ul>CUSTOMER NEEDS  CHANGE REQUESTS PROJECT ENGINEERING quick fixes controlled changes INSTALLATION AND SUPPORT
    27. 27. Controlled Changes <ul><li>If a customer requests a change, it can </li></ul><ul><ul><li>be rejected </li></ul></ul><ul><ul><li>be postponed </li></ul></ul><ul><ul><li>be introduced immediately as a quick fix </li></ul></ul><ul><ul><li>be added to the next release as a feature </li></ul></ul><ul><ul><li>be introduced immediately AND added to the next release as a feature </li></ul></ul><ul><ul><ul><li>the team has to carefully merge changes in the current version with their work </li></ul></ul></ul>
    28. 28. Question to the Audience Does it matter who does what?
    29. 29. Agenda <ul><li>Attempting to Define Quality </li></ul><ul><li>The product life cycle </li></ul><ul><li>Defining Roles </li></ul>
    30. 30. Roles in Engineering and Support <ul><li>Research and Exploration </li></ul><ul><ul><li>focus on innovation </li></ul></ul><ul><li>Engineering </li></ul><ul><ul><li>focus on quality and costs </li></ul></ul><ul><li>Quick Fixes </li></ul><ul><ul><li>immediate response </li></ul></ul>
    31. 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
    32. 32. Kano’s Model of Customer Satisfaction Satisfied Customer Unsatisfied Customer Satisfied Requirement Unsatisfied Requirement <ul><li>Obligatory requirements </li></ul><ul><li>implicit </li></ul><ul><li>self evident </li></ul><ul><li>not expressed </li></ul><ul><li>obvious </li></ul><ul><li>Linear </li></ul><ul><li>Requirements </li></ul><ul><li>expressed </li></ul><ul><li>specific </li></ul><ul><li>measurable </li></ul><ul><li>technical </li></ul><ul><li>Attractive requirements </li></ul><ul><li>not expressed </li></ul><ul><li>tailored to the customer </li></ul><ul><li>cause delight </li></ul>cost of entry commodity differentiators
    33. 33. Without Creativity (R&E) <ul><li>Your product is not valuable </li></ul><ul><li>Your cost of entry is very high </li></ul><ul><li>You are stuck with faster – cheaper – better </li></ul><ul><li>You better have LOTS of quality </li></ul>
    34. 34. Without Engineering <ul><li>Your product will have many defects </li></ul><ul><li>Your support costs will go up </li></ul><ul><ul><li>these are variable costs! </li></ul></ul><ul><ul><li>they depend on the number of customers, not just the defects </li></ul></ul><ul><li>Your competitiveness will erode quickly </li></ul><ul><li>You will probably stumble with the chasm </li></ul>
    35. 35. Final Conclusion <ul><ul><li>If you want to control maintenance and support costs, </li></ul></ul><ul><ul><ul><li>the only variable costs in all three modes </li></ul></ul></ul><ul><ul><li>Focus on the engineering role: </li></ul></ul><ul><ul><ul><li>focus on quality increments fixed costs </li></ul></ul></ul><ul><ul><ul><li>lowers variable costs of the support role </li></ul></ul></ul><ul><ul><li>Counter intuitively, focusing on quality will raise productivity, </li></ul></ul><ul><ul><ul><li>it eliminates costly re­work. </li></ul></ul></ul>
    36. 36. Bad Software Engineering Focus on Delivery Date Low Quality Rework Late Delivery Vicious Cycle ©2007-2009 . worse practices bad practices defects
    37. 37. Good Software Engineering Focus on Quality Good Quality Little Rework Timely Delivery Virtuous Cycle ©2007-2009 . best practices good products better practices
    38. 38. Any Questions? thank you for your time [email_address]