One of the hardest battles in managing complex design projects is how to keep the admin from overshadowing the design work. It can be a tough balancing act. Not enough admin and your project is at risk of missing deadlines, blowing budgets, or going off the rails. But too much administrative process and your team ends up spending more time in spreadsheets than in SolidWorks.
Since nobody wants to have engineers wasting their time and effort on tasks that add little to no value, it’s not always easy to find the line between overcommunication and good practice. When we’re moving fast to deliver on a project, we often need to take the path of least resistance. So if it’s going to take an annotated CAD slideshow and an hour of PowerPoint-ing to get everyone on the same page, it’s not going to happen. Cumbersome admin tasks fall to the wayside when they’re more trouble than they’re worth. That’s true in any organization, in any industry.
For teams working on complex mechanical design, this can mean that critical project information ends up living in engineers’ or managers’ heads. When that info never gets recorded anywhere—or is only recorded in fragmented documents or emails that aren’t easy to look back on—a lot of value gets tied up within the team’s institutional memory. So what happens to that valuable unrecorded knowledge when people leave? Retire? Take time away? And what impact is that lost history having?
This post highlights some key reasons to create processes that allow critical project information to get documented (without adding excessive administrative burden to your team).
Traceability: Having a History of Your Decision-Making
Depending what regulatory requirements you’re dealing with, there’s likely already some level of traceability built into your design process. For industries like medical device manufacturing, the need for traceability is non-negotiable. But regardless what type of product design and development you’re involved in or what specific requirements you’re dealing with, the process for documenting decisions is going to look different for different teams.
It’s one thing to be able to show verification that a design meets certain standards. But there are so many factors that come into play throughout the design process beyond solely satisfying regulators. Revisions might be made for a number of reasons—improving manufacturing efficiency, delivering on an aspect that’s important to the customer, acting strategically for the company as a whole, etc.
Often, the conversations that lead to certain design decisions are hard to capture effectively. Whether they happen verbally or using common communication tools like emails, chat messages, slideshows, and spreadsheets—any notes that are documented tend to be siloed from the design files themselves. This disconnect makes it difficult to look back at a particular design and trace the decision path that led to the final output, even for the people involved in the original discussions. In an organization where documented decision histories are mandatory, that means some serious detective work to find those records—regardless of who else’s inbox they might be in. When information only ever lived in someone’s head, or in some email or document that’s now buried in a folder, it gets harder and harder to recover it as more time passes.
Improvement: Keeping Track of Lessons Learned
Being able to look back at the design discussions that led to a final outcome is about more than just having an auditable decision history. It creates a greater ability for present and future team members to learn from previous work. Looking back on past project information can become a valuable source of insight that teams can use to continually improve.
But having a “Lessons Learned document” is not necessarily going to make a big difference on its own. It’s not the act of recording the information that allows people to learn. It’s having that information recorded in a way that’s easy to find, quick to reference, and accompanied by meaningful context.
Nobody has time to be digging around in SharePoint for documents all day, or trying to search their email inbox to pull up an old thread. So even when information isn’t necessarily living in engineers’ heads, it still may not be living in a place where it can be useful to the organization in a real and practical way—which is exactly how teams can end up seeing the same mistakes get duplicated in future projects.
Oversight: Knowing Where Things Stand at Any Time
It’s one thing to be able to look back at past projects to see why a decision was made or what was learned along the way. But what about being able to oversee your current projects? How can an engineering manager keep things on track, if it takes hours of digging to know where things stand? When getting the latest information means asking individual team members for an update, it can really mess with everyone’s workflow and hamper productivity.
Sometimes it’s not a practical or worthwhile interruption to your day, or to the person with the information you need, to ask a small question—especially one that, realistically, you’d probably be able to answer for yourself if the right process and tools were in place. Yet when there’s no reliable place to check for the most up-to-date information or status on a project or issue, the options are limited. You either proceed with the info you already have or you have to hit pause on what you’re doing to make a call, write an email, or send a message over chat, and then wait for the response.
On a small scale, this can be somewhat manageable. But it quickly becomes infeasible as more people, projects, and/or design components become involved. Without a shared place for everyone involved in a project to easily add updates on their progress, that information stays invisible. It takes more and more admin work to maintain adequate oversight as the project moves along, which takes time away from the actual design work your team wants to focus on.
How to Let Your Team Focus on Engineering, Not Admin
Ultimately, it’s not hard to understand why critical project information shouldn’t live in engineers’ heads. When this is happening on a team, it’s not because anyone wants it to be that way. It’s likely because the cost of spending too much time on administrative tasks is too great to justify. Cumbersome manual processes are not only tedious, they’re not a good use of engineers’ time or talent.
So if it’s difficult and time-consuming to have project information documented in a way that’s useful, clear, and relevant, it’ll only happen when it has to and it’ll only get referred back to when there’s a pressing reason. And although there’s technology and software to help with these sorts of problems, the nature of mechanical design work and the difficulty of sharing CAD files among stakeholders has made it difficult for engineering teams to adopt these better solutions.
But that’s exactly why CoLab was founded. Teams can move faster when there’s a centralized place for sharing CAD files, reviewing designs, leaving feedback, and tracking issues. Information doesn’t have to live in team members’ heads because it can be captured quickly, easily, and right on the design itself so the relevant context is always there. Because mechanical engineering teams deserve tools that let them focus on engineering—not administration.