Is WIFO (Worst In, First Out) a good project management method? That is, should projects always prioritize work on the part or component that is the worst?

Will WIFO make project quality more even by working on the most negative parts first, or will it lead to one part being the "edge" that you focus on, even though quality is already good enough?

  • 2
    The implied assumption in your question is that all parts/components will always be in scope. If there are any features that can be de-scoped if their development hits the wall, WIFO may not be optimal for you. Jan 19, 2013 at 6:10
  • 1
    Could you please edit your question so that it explains clearly the meaning of "worst"? Indeed, considering the current answers, we (at least I) do not understand if "worst" means "existing part with the poorest quality", in a maintenance project for example, or "riskiest part". Jan 20, 2013 at 1:33
  • 1
    By the way, the question/answers so far may well be considered canonical as soon as one of them is accepted. Just sayin'... Jan 20, 2013 at 6:13
  • 1
    Nick Rosencrantz, if you like one of the answers, you can accept it by clicking on a vee-shaped button next to it. By doing this you accomplish three things: you raise your own rep score, raise the score of the person who posted the accepted answer, and help us add the Q/A to the list of so called "canonical" questions that would serve future generations of PM.SE users. Cheers! Jan 22, 2013 at 12:09
  • This was interesting and useful. Thanks a lot! Jan 28, 2013 at 0:20

4 Answers 4


I'd like to point out a major risk that lies behind your question. Let's call it good-bad dualism.

Your question includes terms like "always", "worst", "most negative", etc. Unfortunately a project is not just a single variable that we can sort to set priorities. Most of your job as a project manager is to balance between several aspects of the project, and risk or quality is only one of them. Because of that I would answer no, WIFO is not a good project management method since it focuses on only one aspect of the project, which is way too simplistic IMO.

Particularly you need to balance whatever criteria you have with value. For example in a maintenance software project where you must deal with a backlog of bugs, it is essential to schedule/prioritize work after taking in consideration the impact on users' experience, not only the risk or the quality. A defect located in a good-quality low-technical-risk part of the product, but causing an error message to happen every time the application starts is probably way more important to fix than a defect in the worst part of the project that deals with exporting in some weird outdated format that nobody ever uses anymore...but this might not always be true.

In short, there is no "Most-XYZ In, First Out". Instead there are many "The more XYZ, the more we should give a high priority, unless..." (risk, quality, technical difficulty, value delivered to end-users, cost, etc.), and you should consider all of them.

  • 1
    I agree with most of what you said, but the last sentence doesn't quite ring true. There are XYZ stacks/queues of all kinds, and each has a purpose. Their existence isn't in doubt; their applicability to a given problem domain is.
    – Todd A. Jacobs
    Jan 20, 2013 at 2:13
  • 2
    @CodeGnome Unfortunately this means that my answer is not clear enough since the last sentence was supposed to be a kind of summary. I'm trying an edit... Jan 20, 2013 at 9:17
  • Thanks a lot for pointing out this important matter. The dualism happens to me all the time and the other Swedes are very much like that in dualism (we have a strong tradition of "functionalism") so "Either it works or it doesn't" and "Either it's an improvement or shan't be done." etc oversimplifications. Jan 28, 2013 at 0:21


WIFO is really more about risk management than it is about quality management. Depending on your risk model, WIFO may or may not be a good choice.

Define "Worst"

The first thing you need to do is define "worst" for your use case. Worst doesn't inherently mean something with a high defect or failure rate (although it may); it could also be a measure of complexity, cost, scope, level of effort, or uncertainty. In other words, "worst" is generally about how your project defines and estimates its risks.

Benefits of "Worst First"

The potential benefit of working "bad" sub-projects or dependencies first is that you may reduce the cone of uncertainty for the remainder of the project. Once the hard-to-estimate or difficult-to-complete stuff is out of the way, the assumption is that there will be less variance in other aspects such as scheduling or resource requirements because the remaining tasks are better scoped and the risks well-understood.

Basically, WIFO front-loads your risk. By placing riskier elements at the front of the project when you have the most slack, budget, and resources to allocate to any issues, you may be in a better position to mitigate those risks than you would be at the trailing end of a project.

Projects that wait until the end of the project to handle "big balls of mud" like complex integration tasks are at much higher risk of failure and forced death-marches than projects that have tighter risk controls. When used judiciously, WIFO can be one effective risk control among many.

Pitfalls of "Worst First"

WIFO is intended as a risk-control measure, and doesn't focus on delivered value. If you are working on a project where earned value or modular feature delivery is important, WIFO may be a poor tool.

Remember, WIFO front-loads your risk. If your goal is to fail early, this can be a good thing, and often represents a huge cost-savings over projects that fail late in their cycles. However, depending on why the work is considered worst, placing it too early in the schedule can skew a project by introducing premature architectural, design, or engineering decisions that would have been more self-evident later on. Lean methodologies advocate reserving major structural decisions until the last responsible moment, while WIFO often forces these complex decisions to be made much earlier.

In addition, since WIFO front-loads tasks with a great deal of uncertainty, improper use of WIFO can lead to sunk costs for the project. If the front-loaded tasks consume an excess of time or budget, your project may find itself behind the curve with no incremental value to deliver. And, as previously mentioned, premature decisions about design and architecture can lead to sunk costs in labor, equipment, or product design/implementation that can be very difficult to recover from.


It sounds like you're using "Worst" as a proxy for "Most Valuable".

One thing that's nice about agile methods is that they tend to order work according to value-to-client, not according to imposing a total project execution order to minimise costs.

So you do the most important things first, then the next most important, and so on until there's nothing more to do or the client decides the work done so far is "good enough". This approach isn't always possible for some project types (eg, the cost of building a bridge one lane at a time compared to doing it in a single project is so much higher that the 'agile bridge' method is just too costly).

In your case, value seems to be related to reducing the overall "badness" of the system under consideration.

That might be a perfectly valid substitution. Or it might not.

Say for example you run a fast food franchise.

Right now you have two problems:

  1. Your crayfish milkshakes are just awful. Really vile.
  2. Your french fries are good. They could be great.

The milkshake situation is so terrible that late-night comedians are making jokes about it. Under WIFO, you might immediately begin to tackle it directly, looking for ways to make it tastier.

But in terms of value delivered to customers, the french fries are the place to focus your attention. More customers get the french fries and more of them prefer french fries to any variation of a crayfish milkshake. By focusing merely on the "worst" thing on your menu, you may raise the average quality of the menu ... but not add much to its value.


No. Two reasons:

  1. Quality is something that has to be built into a process, not 'fixed' after the fact. You can't build a quality product if you are always playing catch-up with bugs. Customers won't like it, it will eat up morale of your development team and it will cost way more money than getting it right the first time.
  2. Work should be focused on whatever delivers the greatest value to the customer. This is the best way to prioritize effort. Focusing on "worst in" means that your current efforts will be directed at whatever 'defects' were left over from who ever worked on the project last. That's no way to build value.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.