That’s Not What I Ordered
None of us would walk into a car dealership and say, “Give me a car, any car will do.” Most of the time, we put a lot of thought into the features and functionalities we need before a final vehicle decision is made. If we don’t spend time thinking through what we need and effectively communicating those needs to the salesperson, we might end up with a burnt orange station wagon when we thought we ordered a maroon sports car.
The procurement of parking technology is infinitely more complex than the car-buying process, but we sometimes fail to make sure requirements are adequately defined and documented before signing on the dotted line. The end result is usually an owner and system users who feel like they didn’t get what they ordered.
Clear and effectively communicated requirements can help ensure you implement a system that meets your needs and the needs of your customers. The following are some best practices that can be used to develop effective requirements:
Identify Key Stakeholders
Including all stakeholders in the process makes sure all needs—or as many as possible—are met. Many users interact with a parking access and revenue control system (PARCS), as an example. These include executive staff, supervisors, mangers, frontline staff, accountants, auditors, maintenance technicians, IT staff, and customers, to name a few. Identify the users and involve them in the entire process, including developing requirements for the system; they’ll be the ones affected by any deficiencies.
Draw on Industry Experience
You’re not the first one to go through this process. Chances are, many of your peers have implemented the same parking technology you’re looking to implement and they’re willing to share their war stories. Reach out to your peers and use their lessons learned to help avoid pitfalls and incorporate elements that worked well. I may be a little biased, but I think consultants are another good resource. We use experience gained through numerous system procurements involving various vendors and end users to help clients develop effective requirements.
Separate Needs from Wants
After you’ve taken the time to glean information from your peers and document your stakeholders’ desires, it’s time to take a look at that long list of needs and identify the wants that may need to be sacrificed to meet other project goals. Do you really need those built-in DVD players in the backseat? Sure, they may keep the kids from killing each other on a long road trip, but are they necessary to get your new car from point A to point B? And are they worth the extra $1,500?
Incorporate Functional Requirements with Performance Metrics
Ensuring that your wants and needs are clearly communicated to the system provider is the most critical part of the process. Requirements documents should be the basis for measuring project success and incorporated into the contract with the system provider. Developing functional requirements for each need on your list with performance metrics that must be met is an effective tool for communicating the desired results you expect from the system without telling the system provider the exact methodology that must be used to provide functionality. There will be the need for incorporating some technical requirements to ensure compliance with certain standards, but where there’s flexibility, functional requirements allow system providers to draw on their experience in developing creative solutions for addressing a desired functionality.
Following these best practices won’t guarantee you’ll get a system that meets 100 percent of your needs, but it will guarantee that simple lack of information won’t sacrifice that hot sports coupe for a burnt orange station wagon.
Neill Hurley is parking consultant, car park management systems, with Walker Parking Consultants/Walker Restoration Consultants. He can be reached at firstname.lastname@example.org or 281.280.0068.