Principles of a Robust Project Specification in Transport Data Collection
A thought leadership article by Nick Mather (Tracsis) and contribution by Nick Cottman (WSP).
Putting together a robust specification for your transport data collection project is a crucial step in ensuring the project is understood from the outset. The specification is the foundation of the project so time put into the building of the specification at the start will reduce the risk of crucial time being lost later on.
“Failing to plan is planning to fail”
Benjamin Franklin, founding father of the United States’ quotation sums it up perfectly. The specification is the key planning document underpinning the entire project.
As well as the obvious practical implications, an accurate specification is essential to ensure that all estimates are based on the same, clear set of deliverables, and to ensure that a proposal offering the best value for money is obtained and commissioned. In a time where every penny counts, particularly for Local Authorities, it is even more important that the specification is of a high standard.
This paper will outline the key principles to ensure that you provide a robust specification.
What are the common issues in a specification document?
There can be many common errors or omissions from a specification document, the most common (not limited to):
Poor or confusing overall layout or format
Lack of explanation of context/survey purpose
General ambiguity or poor understanding of the data collection options available and their strengths and weaknesses
Omission of a plan or map (a picture paints a thousand words)
Survey dates
Hours of survey required
Method of data capture required e.g. spot count/ATC, turning count etc.
Location of individual sites
Name of a site not corresponding with map location supplied
Classifications for analysis
Time periods for analysis e.g. 15 minute summaries
Time frame for response
Lead times needed for gaining permissions
What should be considered when writing a specification document?
Feasibility
Lots of factors should be considered when putting together the brief. The main consideration is simply to question; “Is the project feasible for the budget set aside to deliver the data collection element?” This sounds obvious, however, often it is clear that expectation outweighs reality on certain specification documents.
Can the work be done within the timescale? Given the constraints of school term time, events, roadworks and daylight, to list a few. Lack of awareness of realistic timescales can be one of the most common issues with a specification.
Format
The specification should be written in a logical order, perhaps grouped by type of data, method of collection or survey scheme.
Methodology
Is there an identified methodology to undertake the project? Is the proposed methodology suitable for the environment?
Permissions and authorisations
Have timescales and additional costs been considered with regards to permissions to undertake the work? Are any special measures such as Traffic Management required?
All suppliers should be adhering to the rules with regards to the obtaining of licences and permits to undertake work, and the customer should not be overlooking either cost or timescale to get the job done quickly or for a lower cost.
Health and Safety
This links to both previous points, can the tasks be carried out safely and will the supplier have the necessary qualifications, training and safety credentials to undertake the work. Is the proposed methodology suitable to meet health and safety standards, and will the supplier demonstrate this in the form of Risk Assessments and Method Statements, Work Package Plans and Safe Systems of Work to name a few? If Traffic Management is required, it should be used regardless of time and additional cost.
GDPR Compliance
Can the data be collected in a compliant manner? Has the capture of personal data been taken into account? Will the supplier have the necessary credentials to carry out the task and will they assess the GDPR risks?
Quality Assurance
How will the supplier demonstrate that the output will be of a satisfactory quality? Will they supply documentation and reassurances? Will all suppliers provide data to the same quality? What accreditations do they have?
Project Timescales
Each milestone or delivery date should be supplied within the specification.
What should be in a specification document?
All factors considered, the specification can be put together and should outline the requirements in a clear and concise way.
Context
Often this is omitted, however giving an outline of the project context and what the data is going to be used for is extremely useful for the supplier and helps with the overall understanding and aim of the project. An understanding of how data is going to be used and what the overall objectives of a study are allow a data specialist to offer advice and options for planning, delivery and reporting, potentially saving time and money overall.
Survey Requirements
A description of what data is required to be collected and where should be provided. The requirements should ideally be broken down by the type of survey required if this is known, for example, Classified Turning Counts, Automatic Traffic Counts, Pedestrian counts etc. However if multiple surveys are required at the same sites, it is best to group by site and list requirements. The classifications of vehicles, pedestrians or cycles should be stated and whether one of the specific, industry recognised classification schemes should be followed.
A numbered site list, and a written description of each site should be given alongside a clear map, preferably interactive (Google Maps link or equivalent) so that it is more efficient for the supplier to work with. The numbering and description within the document should clearly match those on the map.
The hours and days of the survey should be clearly stated. For video surveys, if footage is required for an extended period outside of the analysis hours, this should be stated. If multiple survey days are required, it should be clarified in the specification whether these should be consecutive to reduce cost, or spread out to achieve a representative sample, or options for both.
For any analysis required, it is important that both the full extent of the times required to be analysed (if different from the survey period) are set out, and the intervals the counts should be provided in, for example 5 minutes, 15 minutes or 30 minutes. The classifications required for each part of the survey should be clearly outlined. So, what classifications vehicles should be broken down into, what pedestrians should be broken down into, or whether volumes are sufficient. Units of measurement should be clearly stated, for example units for queuing vehicles such as PCU’s, metres or number of vehicles.
It’s all in the detail
Data format
The output format of the survey data set required should be specified. For example whether the data should be provided in spreadsheet, database or online dashboard format. A knowledgeable data provider will be able to offer outputs in formats which can save time and money, for example, by providing data in formats ready to be imported directly into traffic modelling software.
Assessment Criteria
The criteria by which submissions for data collection are to be judged and awarded against should be clearly stated to help ensure responses from different suppliers to the specification are streamlined and can be compared like-for-like. Any weighting for certain criteria should be clearly stated, for example the percentage weighting for price and quality of the submission.
Delivery Milestones
Any deadlines for clarifications should be clearly stated, as well as the final submission deadline, with consideration of course to a pragmatic approach to timelines as described earlier.
An experienced data specialist will be able to help and advise on any of the above aspects.
Real World Example
In this example, a well prepared survey requirements element of the specification, as well as collaboration with the data supplier led to a successful project delivery.
Tracsis and WSP recently successfully delivered one of the largest data collection projects of its kind, collecting parking information across the Borough of Croydon. A clear, concise and well thought out brief was provided which enabled the delivery team to plan and execute the project well.
"Given the scale of the survey requirement on this project it was important to get the data specification right from the beginning. We therefore chose to develop the brief in partnership with Tracsis, rather than adopting a traditional sub-contractor relationship. By taking this collaborative approach we were able to make best use of Tracsis’s experience in parking surveys."
Nick Cottman - Technical Director and London Transport Planning Team Leader
Tracsis run a series of Technology Forums with a range of core topics, and the possibility to build a bespoke subject package. Technology Forums are free and delivered by our subject matter experts, we even provide lunch for you and your team. If you would like to arrange a Technology Forum on building a robust specification, please follow the link below.
