First-time project teams are a little bit like the youngest athletes at the Olympics. It's refreshing to see them show-up the old pros from time to time.

When a major project has a shaky startup, it's industry news. We expect people with experience to get it right. But, many smaller projects are successfully completed by teams with little or no experience with the technology. Consider these two projects.

1) A parts manufacturer had managed a warehouse with storage locations dedicated to products, and in part number sequence. Increasing business volume and decreasing order sizes led to the implementation of a batch picking and sortation system with primary pick faces and reserve storage supported by a home-grown WMS.

2) A small distributor had been operating a DC with a simplified enterprise locator/pick list system. To deal with additional product, order and tracking complexity, a more sophisticated WMS was selected.

The first project, managed by first-timers, was up and running 10 weeks after the new building was available for equipment installation. But, the second project, which was managed by people who had done it before, is still working out some significant bugs after almost five months of shaky operation.

Both projects will ultimately succeed. Here are a few of the things done well, and a few pitfalls to avoid.

DO set your sights high. Expecting success is the first step to getting there.

DON'T lose focus on the big picture and let little things dominate time and effort.

DOdevelop a hybrid solution. It will be more productive, overall. And, including a manual option for key processes will be very useful if there are start-up problems with the automation or software.

DON'T spend too much time planning one key function, at the expense of rushing through others. I have seen teams get mired down in defining receiving functionality, and have little time left to plan picking processes.

DOchallenge the physical and operational plan with plenty of real-life examples in the design phase. Only the operations members of the team can perform this vital role.

DON'T choose an operating process without evaluating other viable methods. One new idea may look really good when compared with your current operation, but it may not be the best of the available ideas for your operation.

DOplan the move and transition carefully, well in advance and in conjunction with the solution design. It will provide time to catch the little things that you forgot.

DON'T cut short the testing effort before go-live. It takes a lot of effort to define and replicate problems so that software changes can be made quickly.

DO force the schedule to take advantage of special resource availability. In the first project, the move to the new facility was scheduled to coincide with summer vacation to make use of student labor.

DON'T expect the operations staff to have time to do debugging after the system is in use. They will be busy enough just getting products and orders out the door.

So, even if you don't have the experience of several tough projects, learning from others' successes and failures, and careful preparation can bring you victory.