''Success Oriented Approach '' '''Individual, Group and Organizational''' An approach taken in seeking success can have many facets. One may have personal success goals, education success goals, and career goals, all of which involve succees within a context. To experience success, all of the facets or goals must be fully integrated into the approach. I am calling the attitude one has and the implementations one attempts toward accomplishment of these goals ''orientation''. While this must seem the obvious intent of all processes toward a goal, it can be questioned as to whether in fact approaches are only and always success oriented. There are other factors and orientations that an individual, group, or organization may encounter that may not be in sync with the stated goal toward which an effort is exerted towards achieving success. ---- Related Pages: * ApproachesMethodsAndPractices * ConsiderationOfAlternatives * ThePlaceAndScopeOfPlanning * FocusInfluencesAction * AchievingMultipleGoals * PairProgrammingTeams * BiddingInSoftwareDevelopment * TheCostOfInefficiency * WhoIsInCharge * SoftwareChangeManagement ---- '''Example of an approach to a movie:''' "We prefer to take an approach highly likely to lead to our failure." TheProducersTheMovie is the only example I can think of representing a deliberate FailureOrientedApproach. ---- The heading to this page is changed to reflect changes required in response to input via agreement/disagreement, criticism, corrections, and rebuttal. Certainly one way to success involves the correction at points of failure. ---- From the above phrases I do understand (I am still in doubt, but you can blame it on my English skills this time) that your concern is to have a set of criteria/guidelines that would ensure that the main focus and the main thrust of any endeavour to be only with regards to the bottom line: the success of the endeavour itself, avoiding collateral distractions. ''(success as measured incrementally "it works today")'' see: ContinuousIntegrationRelentlessTesting) ---- '''Example''' The developers in a software project should be firmly focused towards the bottom line, which is to make the software running within the specified parameters (including quality aspects), without worrying too much whether they do XP or OO or RUP or whatever else by the book, whether the code looks nice and pleasing, whether they exercised the latest technologies and how their resumes would look after the project is done. The collateral temptations are there and it would be foolish to ignore them, but we need to have an approach/method/discipline to make sure that the strict success of our endeavour is achieved (and only if possible accommodate the other concerns). If we manage to do this, it means that our approach proved to be success oriented and this page tries to establish a set of criteria/guidelines for making sure whatever approach we have (be it XP/OO or waterfall/structured programming or whatever else), we keep it success oriented. This is the way I see it. -- CostinCozianu ''Incentives must be put in place if you actually want to bring out such behavior. You cannot rely on altruism and slogan-based-nagging alone. Human nature is human nature. Measuring, monitoring, and rewarding such behavior is the hard part with '''no magic short-cut formula''' so far, just like software design. Software and people-ware are both complex problems with many variables.'' The orientation toward success is different from that of mere involvement in a project. All projects have people involved who are there because of inducements. The orientation toward success is not and will never be found in all members. All projects have those whose motivation is not project success, but employment. They may fear the succesful outcome and the release from the project of its membership which will occur when the project comes to a successful conclusion, and who will not view as desirable a success prior to their being induced or employed elsewhere. This is particularly true for those who have been burnt in the past by not being sufficiently concerned with what is to happen in their own employment when success or cancelation brought a previous endeavour to an end. The engendering of an orientation of success must include the continuing success of those who contribute to a project successfully completed. ''There's a lot of "shoulds" that don't happen due to human nature. One must work within the constraints of human nature instead of pretend we can all be turned into Vulcans or some other species.'' ---- Here is an offering of a clear definition of what a success-oriented approach is, and how it differs from other approaches: "A success-oriented approach is one in which the definition of ''success'' is always focused upon, rather than upon plans and processes. This is in contrast to approaches where a plan or a process is selected to attain some goal, and then the participants focus upon following the plan or maintaining the process, with the belief that staying on the right "path" will eventually get them to the "destination"." A SuccessOrientedApproach is more a continuous "check" to see if the plans, methods, procedures and practices are achieving the intended "working product" and if not to make corrections to ensure that "it works", and that it works as prescribed. ---- Success oriented approach, it appears, based on this discussion, has prerequisites of: ''Defining what success is'' ''That reminds me of the old doctor?s joke ?The operation was a complete success. Unfortunately, the patient died?''. I think we need to start on a per-project basis (we can generalize later). This may include a ?mission statement? which applies to all involved. In addition to this a more specific definition aimed to help programmers, designers, managers and stake holders to make daily decisions. To achieve this everyone involved needs to buy in to this to ensure their personal success criteria are inline with the project criteria. I have seen projects where different teams have had very different and '''non-aligned definitions of success'''. Some developers defined success as learning a new technology, some project managers based success on being liked by their teams, business stakeholders based their success on deployment dates and feature lists, one technical architect didn?t buy into the possibility of an on-time deployment ''(me!)'' and based success on learning about development challenges, improving communication skills and understanding how we could do better on the next project. Would buy in this '''sample definition''' have made a difference? ''We are all successful when ProjectX is deployed and begins providing value to the business. Our success will be measured in terms of on-time deployment and a system that is robust, extensible, fast and delights the users. Every individual is to be valued and should increase their skills through the collaborative experience of deploying ProjectX.'' I see a problem when we say 'Success Oriented' everyone will just say 'of course we are success oriented'. Asking others and yourself ?were you successful today?? is too vague. I prefer asking, ?what did you learn today? Whom did you help? What did you build? What did you refactor? What might I do differently?? ''You have identified one of the necessities of a Success Orientation: MeasuringYourAccomplishments, where examination of the usefulness and appropriateness of efforts made during a period (day, week, month) as being successful or not in accomplishing the things established as being OnTarget.'' I?m not convinced we can come up a generic definition, without it being too abstract to be useful. I think we can create a case for needing one for every project. If every project needs this, time must be invested, maybe a lot of time? ? I have never actually experienced this!! What does one look like? How do we convince clients that we need one? Is the SystemMetaphor part of it, all of it? -- PaulCaswell ---- In Xp a term is used which measures success via a SuccessStatement. Such a methodology could be employed at every level of a project, from a ProjectSuccessStatement down to the level of Using a SuccessStatement for each iteration of the incremental delivery process. See: SuccessStatement SuccessStory and SuccessWithAnEmergentProcess ---- Perhaps two approaches to contrast are: 1) a project with an end date at which time "success" can be evaluated, and 2) an ongoing project where only relative improvement can be evaluated. The first might be using a SuccessOrientedApproach while the second might be using a ContinuousImprovementApproach. --WayneMack ---- I like this contrast, it highlights how we think about success: * absolute success - which we could attempt to define here * relative success - which can only be defined in unique terms based on where we happen to be I still think that a SuccessOrientedApproach is useful for continuous improvements, we have to continually define what our next success will be. -- PaulCaswell ''Note the difference in terms: "continuous improvement" vs. "continuous improvements." These are different concepts.'' Related Page: ConsiderationOfAlternatives ---- I agree with the critics at the top. Even a project with a stated goal "to fail" has an implied set of success criteria and a way to expend effort in that direction. (You can succeed in your effort to fail, in other words.) Success is too much like existence to have a meaningful orientation named after it. Goal orientation, however, involves some discipline we're not born with and can be observed more in some than in others. Franklin-Covey makes a living teaching people how to be goal oriented in a big way, and selling devices in aid of that. They will also teach you that the more fastidiously goal oriented you become, the more obnoxious you become. It's not a joke. -- WaldenMathews ---- An alternative interpretation of 'SuccessOrientedApproach' could be that you imagine how the world would look if your project was a great success, and plan/design for that future. (i.e. heavy use by lots of users). This way, the approach can be used to ''define'' goals. -- PieterVerbaarschott ---- This page fails the MeyerTest. Agree - BeginWithTheEndInMind I think passes the MeyerTest. ''Is the test an important metric?'' ---- In line with the idea that no one approach fits all possible scenarios, A list is added at this point of methods, schemes and processes which include or define a concerted SuccessOrientedApproach: ---- '''InformationUtilizationAndProduction''' There are fundamental laws that govern the fate of groups who do, or do not, interact properly with their information. The field of information science, coupled with systems thinking and control systems engineering and flavored with cognitive psychology, give us the rules. (Successful use of the group dynamic and synergies) '''InteractionDesign''' AlanCooper suggested approach which has focus on the HumanMachineInterface as a facilitator and critical to user acceptance and investment. (Success is measured by End-Usability) ---- '''A Corporate Approach ''' Select and integrate components Prepare SolutionEnvisioningMethods Utilize Databases Of SolutionCapabilityCases expressed in Business problem context: * Technologies''''''Database * Vendor''''''Databases * Product''''''Databases The method, is a ScenarioBasedMethod. Scenarios are presented in Patterns, with annotations, forces and desired results mapped to Solution''''''Capabilities. ---- '''SystemEnvisioning''' The clear definition of what a system should be and what a system should do, before commencing a project, building a component, or manufacturing a product. Wiki At http://c2.com/WelcomeVisitors (Success measured by attainment of clearly defined workings - It does what it was supposed to do) ---- '''Success''''''Every Day''' The Frequent''''''Building and release of the application or Package, preferably on a daily basis, with a test, Fix''''''Before''''''Proceeding methodology. (Success every day) *''Our business in life is not to get ahead of others, but to get ahead of ourselves -- to break our own records, to outstrip our yesterday by our today. ~StewartJohnson'' ---- '''Some Quotations on Success''' *''Success is not the key to happiness. Happiness is the key to success. If you love what you are doing, you will be successful. ~- AlbertSchweitzer'' *''Success is the sum of small efforts, repeated day in and day out. ~ RobertCollier'' From http://www.oncourseworkshop.com/Getting%20On%20Course003.htm ---- '''Success Criteria''' * User Involvement * Executive Management Support * Clear Statement of Requirements * Proper Planning * Realistic Expectations * Smaller Project Milestones * Competent Staff * Ownership * Clear Vision & Objectives * Hard-Working, Focused Staff ** http://software-quality.blogspot.com/2005/06/10-success-criteria-for-software.html ---- '''Organizational Success Oriented Methodologies''' * ExtremeProgramming ** ''The basic advantage of XP is that the whole process is visible and accountable. The developers will make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and eliminate dead-ends quickly and cheaply. -- KentBeck '' * AgileMethodology ** ''We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:'' *** ''Individuals and interactions over processes and tools'' *** ''Working software over comprehensive documentation'' *** ''Customer collaboration over contract negotiation'' *** ''Responding to change over following a plan'' * ScrumMethodology ** ScrumProcess ''is a formal RadMethod especially suitable for quickly developing enhancements to an existing system which is experiencing frequent shifts in requirements. Its name derives from the "Scrum" (yes, from Rugby), which are <30 day "all in" development periods during which requirements DO NOT CHANGE and managers (by definition not part of the Scrum team) act only to remove obstacles.'' ** ScrumSprints ''is a release is broken into number of iterations called 'Sprints', with each sprint having a duration of 4-6 weeks. The duration is kept fixed to maintain team rhythm and to allow for quick feedback from customer. During the Sprint, the team works on an agreed upon list of requirements (Sprint Backlog) in coordination with Product Owner. The beginning of a Sprint is marked by a Sprint planning meeting and the end results in a Demo of the product to Product Owner.'' ---- CategorySuccess