Process Refactored

I recently held a project management summit at Vortex Mobile where I asked my project managers to question each of our existing processes and come up with new approaches to any of our endemic challenges. Although refactoring code is commonplace among progressive software development companies, few companies talk about refactoring methodology. For many, it’s easier to either cling to outdated processes (remarkably, Staples still offers next day delivery on carbon paper) or invest in the development of cumbersome enterprise-scale methodologies intended to predict and accommodate any conceivable circumstance.

At Vortex, developing new processes is recognized as critical to remaining competitive in the marketplace. We use the following criteria when deciding whether to initiate a new process:

A new process must…

  1. …address a current need or a need which is anticipated on the near horizon (no more than six months away);
  2. …use unique language to differentiate itself from other existing processes;
  3. …execute without top-down oversight, except at key approval points;
  4. …contain cross-incentivization or other checks and balances to ensure any missed steps are caught; and
  5. …be explainable in under two minutes to any non-participant.

No existing process is granted amnesty from being reengineered, although generally the older a process is, the more likely it is to continue to survive unmolested, since continuous usage tends to wear down any abrasive edges.

Comments are closed.