For the electronics project team at bf1systems, a leading provider of electrical, electronic, and composite solutions for the motorsport, automotive, aerospace, and sports industries, the lack of a comprehensive project management solution caused several issues. Project estimates were unreliable and priorities often shifted based on ever-changing customer demands. After using date-driven project management solutions proved unsuccessful, the company adopted LiquidPlanner, which employs a people- and priority-driven approach to getting things done. Project planning and estimation have improved, as have collaboration and communication, and the team is now able to successfully push back against ad-hoc requests.
United Kingdom-based bf1systems is a leading provider of electrical, electronic, and composite solutions for the motorsport, automotive, aerospace, and sports industries. The company’s products are used across all top-level motorsport disciplines—including Formula One, Indycar, World Rally, and Moto GP—and in high-end automobiles from Ferrari, Lamborghini, Bentley, Aston Martin, and Maserati. Its diverse engineering capabilities have also enabled bf1systems to work with major players in the aerospace industry, such as Rolls Royce and Airbus. The company has more than 100 employees in its 25,000 square-foot UK facility, where capabilities include design and production of wiring harnesses, electronics for tire pressure and temperature monitoring, force measurement systems, composites, and special projects.
At bf1systems, the company’s electronics project team consists of approximately 15 hardware engineers, design engineers, applications engineers, and test technicians. The team juggles up to 40 projects at a time—ranging from one-month projects (such as designing a new housing for an existing sensor) to “major” 18-month projects with multiple deliverables. One example of a major project is the development of an entirely new wheel sensor system for a Formula One team, which might include sensors, control modules, antennas, embedded software, and diagnostic software. A few years ago, bf1systems had no standard toolset or methodology for project management.
The lead engineer on each major project also managed it, typically capturing the required tasks in Microsoft Project or Excel at the start and then managing the work as he or she saw fit. Smaller, ad-hoc projects were typically “squeezed in” as time allowed and were left up to the assigned engineer to manage as desired. Even for major projects, regular updates to the plan as the project progressed were the exception rather than the rule, only occasionally making it back into whatever tool had been used to capture the plan. “Even when Microsoft Project was used, it provided little more than a static list of tasks to complete,” says Peter Harris, electronics project manager at bf1systems, who joined the company a few years ago. “It was mainly used to create an initial plan, rather than as a tool to help track and manage the work as the project progressed.”
Too Much Work, Too Little Time
For Harris, the biggest problem all this presented was an inability to accommodate change. “We have a huge push at the start of the Formula One season when things can change on a daily basis,” he explains. “Without proper project management, if a customer wanted a change on Project A, we had no way of evaluating the impact on that project—let alone the effects it would have on Projects B, C, D, and so on. The lack of a consolidated view of resource usage across all projects only exacerbated this pain.” Because no project history was captured, Harris had no firm data with which he could push back on requests for new projects.
“People would often come to me with a request for small, ad-hoc work with the expectation of it only taking a few days,’” he explains. “Instinct and experience told me that wasn’t really the case, but without any hard data on how much work it had taken to fulfill similar previous requests, I was unable to prove otherwise and decline or negotiate the request.” Lack of broad access to the project plan and its current status was another major drawback. “Because the project plan lived only on the lead engineer’s computer, it was virtually invisible to other members of the team as they went about their daily work,” says Harris. “We really needed a solution that could help pull together the entire team—keeping everyone on the same page, working toward the same priorities, and accountable for their assigned tasks.”
For Harris’s team, the end result of all this was excessive pressure to meet customer needs. “We were always up against a deadline,” he recalls. “We met our promised customer dates, but it took a few late nights; subsequently, internal projects were often delayed. We were constantly scrambling to meet ever-changing customer needs and, because daily priorities were often unclear, that might mean pulling someone off a larger project to work on one that would only deliver one-tenth the revenue.”
Determining Requirements the Hard Way
Harris initially attempted to use Viewpath, an online project management tool, to address these issues. “Viewpath looked a lot like Microsoft Project and, in fact, was entirely too similar to Project to be truly useful,” he recalls. “While it would show if someone was double booked, I couldn’t get it to adjust for those problems or perform resource leveling across multiple, stacked projects. The problem, as I began to see it, was that both Viewpath and Project appeared to be date driven, whereas we needed a project management solution that was priority and effort driven.”
Harris also had problems extending the new project management paradigm he was trying to implement to his engineers, software developers, and test technicians. “Viewpath may work well for project managers, but we have a team of engineers and technicians,” he says. “Even with a web-based solution, communication was mostly one way; I still ended up having to print the project plan on a regular basis and put a hard copy on each person’s desk.” After several months attempting to use Viewpath, Harris had an informed idea of what he really needed from a project management solution. “We needed a tool that would give us an accurate picture—and defensible proof—of our team’s true capacity and throughput,” he says. “I once again began to look for the right solution; this time, however, I had a firm set of defined requirements.” Those requirements included the following:
- Effort- and priority-based versus date-based
- Support for multiple projects
- Resource leveling across projects
- Project history and time-tracking capabilities
- Extensible to the entire team—in a way they would use