Manufacturers, Installers, End Users, Consultants Blame Each Other for failed projects

This is the first of a series of articles, to be expanded in Parking Today, from The Temecula Group, a parking think tank that meets annually and discusses issues pertinent to the industry. The Temecula Group met the last weekend in October, 2013.

When manufacturers, installers, consultants, and end users get together to talk about the RFP process, all hell seems to break lose. The discussions rages from blame to anecdotal stories each has blaming the others for failed projects, uncompleted jobs, impossible specifications and unpaid bills. Lawsuits abound, job requirements are copies of other ones, and in the end, no one is happy with the result.

If this sounds familiar, you aren’t alone. Far too often organizations will simply take a bid spec used by another and change the names and send it out. If it worked for ABC why won’t it work for us. Even one of our parking organizations is asking for bids to be sent to them so then can distribute them to other like organizations. Its a cheap way to get a bid spec moving, and a quick way to disaster.

When the group at Temecula calmed down, they found that all those involved had similar issues, and they all seemed to go back to the initial job requirements. Does the organization purchasing the system really understand its operation and know what it needs.

Far too often an organization will assume purchasing technology will solve their operational problems without first understanding what those problems are and how the equipment will fit into their needs.  They walk a trade show floor and see fantastic new ideas from a dozen manufacturers and then write a spec containing a bit from each, perhaps not realizing that none of the manufacturers can do all the things demonstrated across a room full of booths at a trade show.

They then proceed to cause a specification to be written that none can meet, but strangely enough, some will ignore the few items that don’t fall in their spec, assuming that they can get change orders in later in the process to remove these items. Or they simply blunder their way to the end and hope they can successfully negotiate them out of the final check list.

Too often consultants are a part of this process and sign on to hammering suppliers to get what they want. They also provide specifications that require that certain tasks be done a certain way, while many manufacturers perform the same tasks with different techniques.

In addition, there is often much confusion between the customer, his IT department, the construction staff, installers, engineers at the factory and the consultants.  Far too often the information needed for a successful installation is not communicated properly, and disaster strikes.

Even when the installation goes well, the end results may not seem right because the users aren’t fully on board with the technology. Statistics have shown that less than 10% of the capability of most systems are actually used by those running the facility. Expectations by the owner that problems will be solved by the technology are smashed. In the end, no one is happy with the result.

The group felt that more time and money needed to be spent in the planning stages, in determining just how the facility is supposed to work, what problems exist, and how the technology would help fix those problems. Often the problems needed to be fixed first, and then the technology applied to automate the solutions. This requires a strong consulting effort in the beginning to bring an understanding of the individual garage or system and how it will be affected by the technology.

Bidders felt that when specs were impossible to meet, that perhaps they should actually give two bids, a ‘low’ bid with a caveat that certain parts of specification would not be met with this bid, and then a different bid that included the work needed to meet all parts of the spec.

Also, it was felt that the specification be a ‘performance’ specification. That is a description of what the operation needed, and let the individual bidders explain how they were going to meet those requirements. The goal is not to have a Ford body, and Chevy Engine, Chrysler wheels, and Toyota electronics.

Consultants need to be upfront with the organizations for which they work and understand the operations of a parking facility, not just the specifications of a dozen manufacturers. They need to be able to make operational change suggestions, as well as technical ones. But the users need to understand that this costs money, and budget for it.

Coordination is a major issue and most of the participants in the discussion recommended that a coordinator be hired to ensure all parts of the system were going in properly and communicate issues between the different stake holders when problems arise. Coordination needs to be budgeted in, but not part of the bid price, but a separate costs born by the organization receiving the system.

The vendors stressed that when ‘cutting edge’ technology is purchased, that expectations need to be lowered, particularly in the time required to make them happen. They may be technically possible, but not readily available.  The end users present stressed that seeing the technology working in the field was important and what they see is probably what they will initially receive.

Picking the consultant to help you is as important as picking the supplier of technology.  Review their successes, failures, and make the decision based on how they fit into your needs. One size does not fit all.

In sum, the overriding issue here, aside from the confusion created aspect described above, really has to do with education, time and desire on the part of those tempted to shortcut the procurement process.  Managers seeking carbon-copy RFPs need to be EDUCATED about the pitfalls of doing so before going down that trail.  Which may help them bite the bullet and see that they’ll need to invest the TIME of staff members and themselves in generating an RFP that’s absolutely right for their organization’s needs.  But in the last analysis, it boils down to a DESIRE to do things the right way:  to not take the easy way out and look for shortcuts on the front end that can too easily arrive at failures down the road.