I know of an excellent project that was spun up in a hurry to write a small amount of really tough code and roll it out.  It was a “quick win” project, so named because you can get value out the door quickly. 

I say “was” for two reasons. 

One: the quick part is over.  It is going into production.  Now comes the really slow part: owning it.

Two: the Win part is over too.  It’s value has been demonstrated. It reduced cost or increased capability as expected.

The problem with a “‘quick win” project is that code, quickly written, requires quick replacement. 

Now that this code is in production, it is time to purchase a commercial package, for less money, and greater capability, to augment it.  The alternative is to slowly, expensively, add one feature after another until the IT group has written so much code that they will hold on out of pride, even though a commercial package is (a) available, (b) less expensive, and (c) more fully featured. 

You see, if you invest in a quick win, you have to settle for the quick replacement that follows.  Otherwise, you are taking a success and letting it sink into failure.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

5 thoughts on “When "Quick Win" is an oxymoron”
  1. Quick Wins are rewarded by the management-by-quarter method of doing business. The value of the win only exists during the quarter and therefore, another quick win must be created in the following quarter. The pattern has a positive feedback loop.

  2. I disagree.  You cannot solve a problem with the same thinking that created it.

    Each "quick win" project builds up developer debt.  (For people outside the agile development circle, developer debt is the notion that developers, making short-sighted decisions, are leaving code for someone else to refactor, and that it is nearly always more expensive to fix the problem later.)

    Quick win projects build up "architecture debt".  You can do one.  You might be able to do two.  But you are going to hit a 95% likelihood of failure at the third.  

    So, the only time this creates a positive feedback loop is when the business leader gets to claim victory and then change jobs before the bill comes due.  (It’s a little too common, even then).

Leave a Reply

Your email address will not be published. Required fields are marked *

12 − 11 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.