Fire, Ready, Aim

I recently read an interesting article from the September 25th Wall Street Journal Business Technology Section, see the  article “Try Software on Workers First, Fix It Later” by Ben Worthen (

Arizona State University (one of my alma-maters) implemented enterprise-resource planning software including the payroll module.  They used a unique approach.

The basics of the plan referred to as “Implement, Adapt, Grow” by ASU IT managers included:

  • Knowingly allowing bugs into production and utilizing “users” to identify the bugs (when errant paychecks were issued),
  • Deploy crack teams of fixers to rapidly address the problem.  This team consisted of accounting staff ready to true up paycheck errors as well as programmers needed to fix the code to correct the problem, and
  • Stick to a rigid schedule to control costs and hit deadlines, knowing that your plan allows for production errors.

As a result, the project came in significantly under budget (approximately $35M!), admittedly remarkable for these types of complex projects.

Yet this approach did result in many problems.  Early ASU payroll runs had much higher than normal error rates and some employees had to wait in long lines because their departments did not have the needed terminals to enter time clock data.  Tempers flared, and as a result, the HR department needed armed police to ensure cooler heads prevailed as disgruntled employees worked with HR to straighten out payroll glitches.

My initial reaction is this is a brute force alternative to managing schedule and scope.  Rather than design and implement a solid test plan, you’ve opted to use live test data and people to identify your issues and then use the resulting pressure cooker to motivate your IT and HR staff to straighten it out fast.  The results were predictable – very low morale in both the HR and IT departments, and lots of frustrated users.

But what about the $35M in savings?  I say not worth it.  IT needs to do better.  We need a better state of the art approach to implementing these kinds of projects based on good PM practices:

  • Solid functional requirements,
  • Diligent scope management,
  • Quality assurance that begins with a Software Design Life Cycle project methodology and ends with requisite testing (as opposed to QA being solely test),
  • Augmented staff of been-there / done-that experts needed to get these kinds of large jobs completed (hey, I work for a consulting company, what did you expect?)

But, at the end of the day, $35M is a large sum of money.  Maybe this is a valid alternative.

I welcome your comments,
Mike Brannan