Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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.
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.
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:
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:
