Critical Success Factor

A sine qua non. Generally used for the key objectives of an endeavor, where the failure to accomplish any one means the endeavor as a whole is deemed a failure, no matter how well any or all of the other objectives (including other critical success factors) have been met. When used correctly, the term CriticalSuccessFactor refers to one member of a subset of the endeavor's highest priority objectives, those that are mandatory components of success. Meeting all the critical success factors is a necessary but not a sufficient condition for a successful project.

While some customers may indicate that everything is critical at the start of a project ("IwantaPony!"), RealWorldSuccess? requires balancing what is desired with what is possible. The customers must recognize that not everything is possible. Critical success factors are those objectives that must absolutely be met, even after all tradeoffs, customer priorities, and qualified successes have been determined.

Sometimes the customer's CriticalSuccessFactors are impossible to obtain. In that case, either walk away or prepare for a DeathMarch.

Critical success factors can change, and whether anyone should choose to be explicit about them at any point in time is an entirely open question. Defining one or more critical success factors, moreover, is in no way tantamount to trying to come up with a complete finite list of requirements prior to starting a project. It is more akin to saying: "to hell with the details, let's just crack on and do this, at least!" (where this is a candidate CriticalSuccessFactor). [Note that this is not particularly recommended.] In my experience, the rule of SevenPlusOrMinusTwo applies to CriticalSuccessFactors.

I don't think the following points are specific to XP, apart from terminology. If we eliminate the confusion between Objectives and Requirements, as above, it seems that it only remains to agree that relative priority is not a consideration. "Critical success factor" is synonymous with "mandatory component of success". However interesting what follows may be, it doesn't seem to belong on this page any more.

There is still a large ambiguity about whether you are defining Critical Business Success Factor(s), or Critical Team Performance Success Factor(s). When the word "objectives" above was instead actually the word "requirements", it seemed almost definitely slanted towards team performance. Objectives still leaves room for interpretation - business objectives or development team objectives? The two different perspectives will have different objectives and could easily reach different conclusions based on the same project.

I'm sorry. I really can't see any ambiguity at all. The reason that it should be "objectives" rather than "requirements" is that the concept cuts across all manner of endeavors (which is why it is "endeavor" rather than "project"). The people who are specifying what "success" shall mean in the given context are free to designate as "critical" whatever "factors" they please. Ambiguity arises, I would contend, not from the definition but from the multiplicity of perspectives on a single endeavor. The chances are, though, that if the whole team is not driving towards a pre-agreed target, the target will not be hit. This leaves some members of the team able to claim that the endeavor was a "success" from their point of view, while others consider it a complete failure. Or as TomGilb put it: "Projects without clear goals will not achieve their goals clearly".

Consider when the GoalDonor and GoldOwner have different objectives. From the GoldOwner's perspective, the CriticalBusinessObjectives? could be considered CriticalSuccessFactors. From the GoalDonor's perspective, the development team's objectives (requirements) could be considered CriticalSuccessFactors. Note that the GoldOwner is not necessarily higher ranking in the organization than the GoalDonor, they are just different roles.

Yes. And from the development team's perspective, having the apparent conflict resolved before we go haring off in what might well be the wrong direction should definitely be considered a CriticalSuccessFactor!

This is what I was referring to below just above "mixture of the two notions of success". The term CriticalSuccessFactor quite deliberately does not specify whether one should be considering business objectives or development team objectives or anything else. The following states the XP view of how to deal with requirements (development team objectives).

On an ExtremeProgramming project, requirements (team objectives) are identified as UserStories. The highest priority UserStories are done first by definition. You mean that delivering all of the highest priority user stories first is a critical success factor: if you don't do it, you've failed (by definition). Maybe that's the only Critical Success Factor that any XP project ever has...

Highest (Critical) priority UserStories can be added or removed throughout the project.

Also, the priorities of the User Stories are allowed to be changed by the Customer over the course of a project (not generally during an iteration) as the Customer better understands what he/she is getting.

The result of this is that CriticalSuccessFactors as defined previously ("[team] objectives that must absolutely be met", and not materially different as currently defined), would be equated with HighestPriorityUserStories? on an ExtremeProgramming project. Prior to starting a project the HighestPriorityUserStories? is equal to the first iteration.

Furthermore, at almost any point in time other than at the very start of the project, the list of HighestPriorityUserStories? would generally be a list of UserStories already completed. To me, on an XP project, this is an almost completely useless list to try to define.

HighestPriorityUserStoriesRemaining? would be a much more interesting list. Unfortunately, this list is already defined. It's the list that happens to be equal to the next iteration.

Of course, even ExtremeProgramming projects generally operate within a context where someone (the GoalDonor or GoldOwner) is providing funding with some idea of what the benefit of spending the money is. There will almost certainly actually be critical success factors in this wider context, though whether you know what they are, and whether you want to, are entirely separate questions.

If you define success in terms of meeting requirements, to me you are talking about the performance of the development team. In that case, see above. Any mention of requirements that are not UserStories from the Customer cannot be applied easily to ExtremeProgrammingCorePractices.

If you define success in terms of whether or not the project provides sufficient business value, that is something else. That requires that the business decision makers are making good decisions and is not directly related to the performance of the development team, as long as the project does not go materially over budget. But, what is material is again a decision of the business decision makers.

Perhaps there is difficulty reaching agreement here because of a mixture of the two notions of success as described above.

Possibly. But I think it's because you think XP is an exception to what I think is a universal.

I looked but could not find the CriticalSuccessFactor. What is it? What singular factor is most critical to success. I thought for a moment, and lo and behold I had an aha moment! If there is just one factor that is critical to success, and that applies no matter what it is you want to be successful at, it must be that it is worthy. I could be wrong, but since this page, at least by the title, is singular ("factor"), I felt I should offer my idea of "the" critical success factor. I use the word "worthy" to signify that it is "valued". It is not a moral term as I use it. Successes are accepted because they add something or accomplish and end. Any other thoughts?

If there were just one factor that is critical to success, it would probably be intent. If the question is: What do all forms of success have in common? The answer might be that the outcome is worthwhile, which is not quite what I understand by the word "worthy". Put the two together and you might have the SecretOfSuccess?: Intend to do something worthwhile.

To illustrate consider the ManifestoForAgileSoftwareDevelopment. It is a statement about success and is predicated by the phrase "We have come to Value". This is a measure of worth, the items which follow are a collection (plural) of the valued things.

Perhaps we can agree that the definition of this very useful buzz phrase is: The single most important aspect of operation for the product. If the product fails to accomplish this one facet of operation then it is a failure, regardless of how well it may do any number of other things.

This term is used during the requirements phase to ascertain what requirements will be set in stone. Once the critical success factor has been set, that’s it – no more changes. That's how you figure out what kind of product you are making. If somebody wants to change the critical success factor then they need to define a different product. No more moving goal posts, eh?

CategoryRequirements, CategorySuccess