Warehouse project problems are common and increase risk across critical supply chain projects. These problems result in failure modes such as inability to operate a facility at all; decreased throughput or storage capacity; labor retention problems; higher startup or operating costs than expected; and last, but certainly not least, safety issues. Broadly, failures can be labeled as Schedule, Cost, or Operability issues.
But those failures are the results of problems encountered during the projects. There are some common problems we've seen in these types of projects that lead to the downstream failures.
It's said that "Victory has a hundred fathers and defeat is an orphan." Here are 7 common problems with running warehouse projects and how to address them:
Decision Makers Aren't Pulling The Trigger
Maybe you've been there. An exciting project is researched. Designs are made. Vendors provide quotes. But the project just doesn't get authorized. Maybe there are grumblings about cost, and lots of back and forth to rework the design. Why don't leaders make decisions?
The root cause here is providing a compelling reason to do the project even when considering all the other things that the company resources and money can do. If you're running into authorization delays, check whether you have a compelling business case and that the project sponsor is bought in. The beginning of the project - even pre-project work - should include doing the analysis to provide a solid case for the project at all.
Often companies will have hurdle rates or payback targets, so check whether your project's numbers meet those goals. Also, as part of stakeholder analysis, consult with your sponsor and adjacent stakeholders to see whether there is something higher-priority that might compete with your project for resources.
Project Sizing Isn't Right
Warehouse and distribution projects are usually focused on design for capabilities and throughputs. What types of things can they do, and how many of those things can they produce. So when the project is finally delivered, and the project doesn't meet the actual operational needs of "how many things," it is a big problem! This problem can require a lot of time and money to fix, or else the operations team has to live with an inadequate design.
This problem can apply to projects as big as entire sites, racking and storage systems, or as small as single-function robotics additions.
To mitigate this major risk and ensure your project is sized correctly, consider these things in design:
- Throughputs: Double, triple check your planned throughputs. Get them documented and approved.
- Forecast variance: What if the forecast changes? What are favorable and unfavorable cases?
- ABC analysis: Conduct ABC movement analysis to account for disproportionate profile effects within overall forecast volumes.
- Potential future requirements: Ask what changes in the business could reasonably occur, and how they would affect the project.
Project Resourcing Isn't Adequate
Project resourcing issues (resourcing meaning people) usually take one of three forms: Not enough resource headcount; inadequately competent resourcing, by either skill or experience; or inadequate allocation of resourcing.
"Not enough headcount" is simple to conceptualize. This is when there is simply too much work and too few people to do it. As projects grow, they need more staff to attend to the work and controls in enough detail. One person, even if he is a rock-star, can't do everything. When looking at a project org chart, be on the lookout for one person as responsible in multiple workstreams or work packages. That person may be over-allocated and other resources could be needed for those workstreams or scope.
"Inadequately competent" resourcing is harder to spot. This is when someone is assigned to project work, but doesn't have the know-how or experience to execute to the right level. Or perhaps the person doesn't have the right personality or level of energy to deliver on his responsibilities. In any case, the person is unable to deliver the results. This is only apparent when someone else--the project manager or business owner or client--understands the person's scope and how the skillset matches (or doesn't) up to that scope. Inadequate competence is a silent killer because the project looks correctly staffed on paper, but there can be big issues when the right level of people are not responsible for the work.
Last, inadequate allocation is hardest to detect. This is when enough people are assigned, the people are competent, but they have other priorities competing with your project. This causes your project work to be delayed or play second-fiddle to their more important work. It can start innocuously - "Can we reschedule the Thursday meeting to Tuesday? I have standing meetings for X and Y", or "I had something come up and I wasn't able to work on the spec yesterday and today, can I send the spec over tomorrow night?" These types of events stack delays on delays. Delays in meeting, delays in delivering work product. They're especially insidious because they're very hard to plan for and compensate for in a project schedule.
Dealing with inadequate allocation requires pre-emptive planning, early vigilance, and escalation. In planning, work to get commitments for resourcing during key activities - get specific on number of hours per week that you'll need, and then ask what competing work is going on during the time. It's good to ask for clear priorities of projects that the team member is working on, and it's best if you can get a dedicated, "single-threaded" resource to support your project. This may look inefficient to the organization, but if your "under-utilized" resource is the bottleneck for your very important project, then a little inefficiency for the resource could mean moving your entire project much, much faster. Finally, if you are seeing consistent delays on work delivery due to other priorities, escalate to your steering committee and sponsor for clear re-prioritization or acceptance of the delays.
Scheduling Is Too Optimistic
The "planning fallacy" is a well-known problem in project management: the schedule durations are too optimistic! This can be true for every workstream including Strategy, IT applications and programming, Construction, Automation, Testing, and Hiring and training.
Many times schedules are built based on prior experience and are point estimates from the workstream owners.
The problem is that things happen. There are delays. Weather happens, and the switchgear lead times (which were 8 weeks for the last project) turn into 16 weeks with the latest quote. Additional requirements happen, driving customization and delays. The job descriptions take longer for headquarters to approve, and then pay scales are too low, and then hiring delays happen.
It's extremely hard to avoid all these things, especially if this is a project which is done infrequently or is new to the organization. But there are some things you can do to help manage issues ahead of time:
- Ask for the "how long do you think it will take" for likely durations, and "how long would it take if everything went wrong" for worst-case durations
- For long-lead, critical path, and sub-critical path items, build a buffer based on the "worst case" durations
- Use a schedule simulation to identify risk areas and communicate them to management
At least this will inform your planning so you can build adequate buffer into the schedule. Then manage to the likely plan, and keep buffer in reserve for when things go sideways.
Expensive and Delaying Change Orders
It's not uncommon to do a project and then find that something was missing. Maybe safety-related features or equipment were missing. Or detailed design reviews with another team member show that a new feature is needed. Perhaps there are compliance or quality needs that weren't reviewed in initial scoping. Or perhaps the project's deliverables just weren't right.
Then you have to do change orders to get the project deliverables where you want them. Adding features or equipment. Adding time to schedules. Effects on other workstreams. And all those changes add cost and complexity to your projects. Frustrating!
These warehouse project problems happen! It's hard to get all requirements right. Capturing requirements is a discipline in itself for software, not to mention for complex projects like new automated distribution centers.
To avoid change orders later:
- Approach the project with an integrated team. This means having representation from every affected functional group. There are few things worse than buying a system or solution and finding out that Inventory or Supply Chain Planning or HR requirements aren't met by your new shiny project. It is critical to avoid tunnel vision and consider the project from all aspects--technical, human, business, compliance--in early stages.
- Complete requirements gathering. Requirements identification is necessarily iterative. It is difficult to do a full design during a sales cycle. But start with big requirements, get as detailed as possible, and knock out the high-impact requirements up front.
- Document agreed-upon specifications or functionality. Easier said than done! Getting discussions translated into documentation is best done in collaborative work-sessions where documents are modified in real time by vendor and client, then sent in approved versions afterwards. Long lags in editing documents or off-the-cuff discussions can greatly reduce transmission and capture of critical design items. Clear documentation with minimum gaps is a key to project success.
- Specify quality and operability standards: It's easy to put numbers on a page. But if you care about How a vendor solution achieves its outputs, then you should specify quality standards for the system. This could include maintainability, aesthetic features, cleanliness, durability, materials specifications, or other items. If you won't be able to live with (or without) something being done a certain way, make it known up front.
Project Budgets Overrun
The project is started. Initial estimates are provided from Facilities, IT, Automation, and Operations teams. The the project starts. Smooth sailing, but then you spot a problem. This is followed by change orders, PO signatures, new scope identified, schedules updated, more change orders...
All of a sudden, the budget is spent and you're asking for more money. Uh oh! What happened?
Sometimes projects are authorized with a top-down, high-level estimate. This can come back to haunt you during the project execution. Incorrect assumptions tend to follow Murphy's law of being incorrect and not in your favor.
To avoid embarrassing, ROI-killing budget overruns, complete a thorough bottoms-up budgeting at the start of the project. Conduct stage-gate authorization for a design phase and then again for final spend when you have real quotes from the vendors. This is especially important for big projects. And budget reviews should go through Finance, Tax, and the budget line owners so you don't forget "details" like sales tax.
Then, allocate contingency based on the project risk analysis and how much experience the team has with the types of things in the project. New technology implementations plus an inexperienced team almost guarantee budget overruns - plan a lot of contingency!
Operability Problems In Production
Sometimes the sizing is right, the resourcing is right, and you've delivered on time and on budget. Then the solution doesn't work! What happened?
Operability problems in production often come from missed requirements or inadequate testing. Or really, just inadequate testing (since missed requirements will be found in testing, right?). You want to test thoroughly before going into production. Even if -- especially if-- the business is rushing to get the project deliverables deployed.
Take the time to do correct, reasonably complete testing. Be deliberate about it. Then plan a ramp period to work out any remaining bugs in a controlled way. Expectation management for the business is the critical game here. Sometimes a delay is the best thing to do for the business to make sure customers aren't affected.
It's Not All Doom and Gloom! Projects Can Succeed
The reason to point these problems out is not to say that projects are impossible. While risk does go up non-linearly with project size, the general risks are well-known. So you can anticipate them, and with good project management controls, avoid them.
This means your projects can have a good chance of being delivered as promised- with the right capabilities, to the right budget, and to an agreed schedule.
For more on how to do this, get in touch with us and let's talk about how to help your distribution projects succeed.