New CIO - Phase 1 - Learn!

I just finished my first 5 weeks in a new CIO position. Fun. Hectic. A ton of learning. I set out with a 90 day plan divided into 3 phases. The first phase focused on learning, the second on analysis, and the third on planning.

During the first phase - roughly the first month - I focused on learning two areas: the business and current IT environment. My new position is with a mid-size fast growing retailer - an industry where I have minimal experience. Learning our business in particular - and the retail business/industry in general - were equally important. On the business side, I first sat down with the IT management team and reviewed the business end-to-end from an IT perspective, i.e., what were the major systems and the major interfaces as you follow our product from conception through sales. I then had meetings with each department/business unit to learn about their business functions, their major systems, and their view on what makes us unique. This last point will become critical as we move forward with long term IT planning to make sure we understand how and where to prioritize investment dollars.

The second area of learning focused on the IT environment itself. People, processes, technology. I reviewed our many lists of tasks and projects. I reviewed the inventory of systems, technologies, tools, etc. I reviewed the relationships with existing partners and contractors. At this point, I have a handle on our current business and IT environment and can start working to identify areas for improvement and growth.

Read More...

Summary only...

Popping the Bubble

If you rub your hand along a carpet starting along one wall and continue to the opposite wall, your hand will always move steadily and level but a bubble will slowly grow. Eventually, you'll have to pop the bubble to reach the opposite wall.

Many projects, especially IT related projects, develop a bubble throughout the project. In fact, many projects appear to move steadily onward while the bubble grows larger. The challenge for project managers is to identify the growing bubble and do whatever it takes to stop the bubble from growing. In most cases, any problems or issues should be resolved promptly - don't let them add to the bubble and potentially create other dependent problems and issues. Sometimes it's not clear that a bubble exists.

With our recent warehouse automation initiative, we did not identify all the corrupt data until the 11th hour. During our pilot, we actually were compounding the problem due to an internal system error. Eventually, we tackled the problem (literally) using a small army of employees to correct the data over a period of several days. During our postmortem, I remembered the "popping the carpet bubble" metaphor as we discussed the series of events that led to our final push to complete the project.

Read More...

Summary only...

Build vs. Buy

I was reminded today about one of the key decisions a CIO must make when evaluating new applications - build vs. buy. Building a custom application is time consuming, costly, risky, and often painful. However, sometimes it does make sense.

The key to the decision lies in the business strategy and the key differentiators for the business. Jim Collins, in his book "Good to Great," talks about the hedgehog concept - the idea that a company should focus all resources on the areas where they excel. This includes IT resources.

If the business has found a way to perform a particular function in a unique manner that provides competitive advantage - then it would be hard to find a pre-built solution that you can buy to automate this function. This is the area where it's worth building a custom solution and maintaining that competitive advantage.

However, other areas of the business that do not directly contribute to a unique differentiator should easily be satisfied with off-the-shelf solutions.

The bottom line: Invest in the aspects of the business that set you apart from the pack and don't worry about using standard common tools for those aspects that don't.

Read More...

Summary only...

Making warehouse automation stick

Warehouse Automation systems, like other systems, sometimes create more work (or at least perceived more work) for warehouse personnel.

Taking a warehouse and logistics facility from a paper based organization to a systems based organization presents many technical and managerial challenges. Keeping inventory accurate using handheld computers for recording material movements and inventory transactions can be an arduous process for warehouse employees. The 'big' benefits from a warehouse automation initiative are often in other functional areas of the company - not just the warehouse.

Like most other systems' initiatives, include the users in key steps of the implementation process to create ownership and awareness. For example:

• The handhelds are new toys - include all members of the warehouse when selecting and evaluating the new toys. Options include keyboard layout, displays (color or monochrome), keyboard size (watch out for those big fingers!), form ('gun style', 'brick style', 'PDA style', 'tablet style', etc.)
  
• Warehouse location labeling has many options - create a focus group to help design the layout and have warehouse employees practice finding locations using different labeling and numbering schemes

The more employees are included in the design and implementation of the new system, the more they'll understand the issues, challenges, and ultimate benefits.

Read More...

Summary only...

Quality & Production: Too many cooks ...

Or too many inspections in this case. It's human nature. If two people are told to count the pages in a book and record the results - it's natural that if one does it before the other one, then the 2nd person might rely on the results of the 1st person.

During a review of common and frequent problems on our production lines, I believe that we have too many checks and double-checks and overlapping responsibilities between the Quality department and the Production department.

It's too easy for the production line supervisor to rely on the Quality inspector and visa-versa. It's not a true separate independent check.

Production needs to take responsibility and make sure the production line supervisors are not relying on the quality inspector to "catch" any problems. The current in-process quality inspection should actually be reduced and moved to the end of the production line.

In a recent book, The Tipping Point: How Little Things Can Make a Big Difference, the author refers to this problem as the "broken windows theory" and sites studies where crimes witnessed by multiple observers are reported less often than crimes witnessed by one observer. With multiple observers, everybody thinks someone else will report the crime. Another recent story centered around the number of editors involved in a book publication at a major publishing house. Over the years, the organization kept adding more editors to the review process only to discover after several years that they had 11 editor reviews and errors were not reduced. Everybody thought everybody else would catch the errors.

More people is not the solution. The right person doing the job right the first time is the answer. They need to have responsibility and not rely on downstream checks and double-checks.

Get the extra cooks out of the kitchen.

Read More...

Summary only...