Success Oriented Approach
Success Oriented ApproachSuccess 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:
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:
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)
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:
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)
SuccessEvery Day
The FrequentBuilding and release of the application or Package, preferably on a daily basis, with a test, FixBeforeProceeding methodology. (Success every day)
Some Quotations on Success
Success Criteria
Organizational Success Oriented Methodologies
EditText of this page
(last edited April 15, 2011)
or FindPage with title or text search