I am sitting in a hotel room in Southern California. It’s a beautiful, sunny day.  The surfer’s are catching waves and the ocean is calling. One could say I’m wasting a sunny day. On the other hand, I was headed here for an 11:00 business meeting. Along the way I received a call from my office, I answered, hands free of course, and found that my 11:00 meeting was canceled.  The organizer’s plane had engine trouble and landed in Grand Junction, Colorado.  I was wondering what I should do for 4 hours. Fortunately, my general manager, who is also my wife, mentioned I could write a blog.  Blogs are never top priority, and so, I often put them on the bottom of all my priorities.

That got me thinking about implementations.  Why, because every implementation has its own delays and changes.  Of course, implementations are never far from my mind, as that is our business. Many times, there are delays with the implementations because interdependent tasks are not completed on a timely basis or are delayed because of the amount of work involved.  When this happens, the whole project may suffer a delay.  However, if the project manager is on top of things, he or she will have a list of other, non-dependent tasks to be completed so that progress continues.

Practicing this same sort of procedure for our personal spare moments might help us all.  For example, do you carry with you a list of tasks that you can complete in odd moments? Perhaps you are sitting in a doctor’s office for an extra hour because their schedule backed up.  Do you have something that you can do? Perhaps you can do what I’m doing right now, write a blog.  Consider jotting down a few notes, type a note on your phone, or, take the time to expand an idea that has been floating around in your head.  You might pull out a report or article from your briefcase that you put there for just such an occasion.

I frequently have five or ten minutes between two meetings, or between the end of a task and the start of a meeting…  It’s not enough time to start something.  I always seem to have something that I would like to investigate on the Internet, but don’t have the time do so. I try to keep a list of these topics handy so that I can use these free moments to explore these issues.  Many times I find my answer and still get into my meeting on time.  (I have a hard time waiting for meetings to start and always want something to do to make the time useful.)

So, back to implementations and the normal delays that we all experience.  Implementations are made up of many small tasks.  Many of these tasks are interdependent and sequential.  Other tasks are parallel and can be done alongside other tasks.  The challenge is to know which is which and how best to intermix the two.  Many times, the whole project goes through what feels like starts and stops.  For example, with the implementations of Microsoft Dynamics NAV ERP (formerly known as Navision), one of the foundational tasks is establishing a chart of accounts and Dimensions for business and financial analytics.  Many companies have a chart of accounts that will work well, but most need to digest the flexibility of Dimensions.  (Dimensions, for those of you not familiar with NAV, are values that you can add to all transactions to facilitate business analysis and reporting.  For example, you can use Dimensions to evaluate information from sales transactions plus general expenses like advertising, telemarketing or direct mail expenses to evaluate the effectiveness of a marketing campaign.)

You can do a few tasks in parallel, but for the most part, defining Dimensions is a primary task and must be completed before beginning other areas.  (Customers, Items, Vendors, GL accounts all can use Dimensions, so you need to define Dimensions before you create these records to avoid going back later.)  However, even before you can determine what these dimensions values will be, you must define your business objectives.  (If you’re read anything I write, you know I sound like a broken record, but objectives are foundational in the ERP implementation process.)

You can complete your business analysis of various departments in parallel.  However, when the analysis is completed, there is a choke point.  The choke point is the compilation of the objectives and requirements into the foundational document for all the other decisions you will make during your implementation.  Once you have completed this document, you can begin developing the Dimensions necessary to analyze your business objectives.

Imagine your project as several cups full of sand that you must put through a special device.  The device is made up of several hour glasses glued together and standing on end.  The top hourglass has no cover.  You pour sand in until the bowl is full.  The sand represents your business requirements and the details that you must develop and bring together in order to determine what ERP functions or what method of implementation will be best for you.  Another cup of sand is all the tasks and training that you must do prior to going live.  The compilation of this data is the choke point (bottleneck).  There are ways to make this choke point larger, but, since all the objectives and requirements are part of one contiguous system, they must be harmonized for the system to work together.  After the sand flows through the choke point, it flows into the larger open area.  Imagine a plate with many holes in it, much like a sieve, separating the bottom of the first hour-glass from the top of the second hour-glass.  This plate represents tasks which you can do in parallel, if you are prepared to do them.  However on the other side of the plate, there is another choke point.  This choke point is typically the testing.  Once testing is completed, you now are pouring sand into the open bowl again, followed by another plate with holes and then another choke point. The choke point this time is all the work that must be done in the hours prior to going live.  If you’ve done your planning correctly, much of the work that you’ve done in previous steps will simplify and streamline the tasks that you must complete before going live.  If you haven’t, this is a huge choke point and your implementation will suffer.

So, going back to our earlier discussion of utilizing time when our progress slows because of a choke point, what do we do?  Obviously, we want to keep all restrictions from the choke point to maximize flow.  However, the real magic is in moving sand from one bowl to the next without going through the choke point.  One method of doing so is to develop a system that formalizes training during the choke points.  This could be as simple as reviewing online documentation, or as complex as a formal classroom training or process and workflow testing.  With a good schedule, these times allow people to internalize the new software and be ready for the next step in that process.  Without taking advantage of the slow times, your busy times (when work is flowing through the separator into the bowl below) will be consumed with critical tasks and the learning that takes place may be less effective.

The trick is to develop this task list during the business analysis process of the implementation.  List the business tasks that require that you use the software to develop your workflow.  Use this list to prioritize your training or testing time.  The real benefit in this process is that, when you get past the choke point, you will be able to move the whole process forward more quickly because you will understand the software better and be quicker at spotting issues.