How Documentation Can Be Your Secret Sauce

Effective development teams use a set of best practices that are almost unnoticeable, but they can make all the difference.

One of those best practices is documentation. When teams prioritize documenting along the way, they save time, money, and grief down the road. This is even more important in a regulated industry like medtech.

In this article, we’ll cover a few key types of documentation and why we consider them to be standards that benefit clients and developers.

Where to Start with Documentation

Documenting starts in the same place as most projects: identifying the objective. This usually starts by asking what problem you are trying to solve, and then gaining alignment around how you plan to solve it. Capturing this information from the beginning gives you a record to which you can refer during the project life cycle to validate the line of thinking and the discussions that have taken place.

The main reason that teams don’t document properly is that it can take time. But having a paper trail is essential for any business.

Compliance Documentation

Medtech companies, especially medtech software businesses, tend to be aware of the documentation required for compliance and regulatory audits. They invest heavily in certifications that demonstrate their safety, security, and compliance in regulatory environments. Some of the more common certifications include HITRUST and SOC 2 (“Service Organization Control 2”). HITRUST is a certification that provides evidence of compliance with HIPAA-mandated security controls required by all major U.S. healthcare payers. SOC 2 compliance demonstrates a high level of information security for third-party service providers. 

Both processes are contingent on an outside agency vetting the company and showing proper growth and remediation for issues that arise. Because there aren’t shortcuts around these processes, it’s the developer’s duty to be aware of the documentation and provide or create it prior to the start of any compliance audit or certification process.

End User Documentation

“Make it intuitive.” 

Sometimes, that’s the only instruction that clients give to developers. They might not prioritize the need for end user documentation, i.e. materials that demonstrate how to use the application. But no matter how intuitive it seems to be, you can count on two things. People are still going to have questions, and the app will still require updates. Therefore, you need a way to pass that information back to the users. 

The dev team also might feel like it isn’t the best use of their time. A lot of freelancers don’t think about it because it can feel like red tape, and they’d rather spend their time creating. But like other types of documentation, capturing information for end users is much easier to do as you go, which can save a lot of headaches down the road. 

There are several effective approaches:

• You can compose an external document. 
• You can create a tutorial that highlights different parts of the interface and links to more in-depth information. 
• You can embed the documentation directly into the application. This can be in the form of graying out the screen and popping up an alert that invites the user to review changes. This can be especially useful for a software update. 

However you execute it, don’t skip this vital step. Your users will thank you.

Project Communication and Client Engagement

Another area of documentation that can be overlooked is project communication. When key stakeholders have frequent visibility into the status of a project, it brings immense value to everyone. This commonly takes the shape of reporting the current status of the work, demonstrating how progress is taking shape, and capturing and subsequently answering questions that are asked. 

Think about other areas of your life. We go to experts all the time to complete work that requires more skill, knowledge, or time than we currently have. It’s true personally and professionally – everyone from plumbers to financial planners! We pay them for their work and trust their skills. The trouble can come when they don’t communicate the details of their work. If you don’t get visibility into what they’re doing, it’s natural to question whether they’re ripping you off or hiding something. At that point, you can wonder if you’re getting the value that you’re paying for. 

A strong dev team will understand this and prioritize project communications in their workflow. Developers sometimes just want to be left alone to make something, but that almost invariably leads to not making the thing that the client needs! It also isn’t a good way to build trust. Developers should understand that it’s quite reasonable to be asked to explain their work in detail. They shouldn’t shy away from feedback and communication. They should value it and provide it without being prompted. And while there’s a point where status updates can be so frequent that they feel like micromanaging or get in the way of completing the project, there’s a sweet spot in the middle that brings value to everybody. A weekly milestone report, for instance, can give enough detail to stakeholders without interfering with the day-to-day project work. Keep it simple and frequent. 

This leads to documentation’s role in client engagement: feedback is vital to a project’s success. It’s a vehicle to convey the value throughout the life cycle and validate the client’s objectives while there’s still time to adjust requirements. No one wants to get to the end of a project only to receive an onslaught of feedback that should have been provided earlier in the process. (That scenario typically means that the project will take longer and cost more.) 

Project documentation is one of the easiest and most effective ways to facilitate a continual flow of feedback. Again, this is a best practice that strong dev teams should already be doing. It’s a fast track to project success.