Class I Medical Device Should have a DHF

If you are developing a class I medical device, you could make a solid argument for not documenting Design Controls and not maintaining a Design History File (DHF). In fact, your argument would be supported directly by FDA Design Control regulations. Very few class I devices even require Design Controls per FDA.

However, if this is the approach you decided to take, I would advise against this. You might argue that documenting Design Controls will only slow you down on your process to bring your class I device to the market. Perhaps.

So why do I recommend documenting Design Controls and maintaining a DHF for your class I medical device?

Design Controls are documented, objective evidence that the product development process has been followed. Design Controls help ensure that User Needs are translated into Design Inputs. That Design Inputs result in drawings, specifications, etc. (Design Outputs). That Design Verification demonstrates the Design Outputs meet Design Inputs. That Design Validation demonstrates the User Needs have been addressed. That the product design was reviewed throughout (Design Review) to ensure the product design is safe and effective. That the product design has been transferred to production (Design Transfer).

Design Controls are proof that you designed the right product, that your product is safe for its intended use, and that your product can be manufactured.

Yes, Design Control documentation and records do take some effort, and time. And if you think it’s worth it to shave a little bit of time in order to get to market faster, this is your choice. As noted, FDA does not require you to document Design Controls for your class I (unless your device is on the special class I devices requiring Design Controls).

But what will happen after you launch? What happens when the product needs to be changed? What happens if you receive a customer complaint?

Okay, Design Controls does not prevent these things from happening completely. But Design Controls, provided you follow the premise and intent rather than just satisfying a checkbox, are intended to find issues during the product development process before being manufactured and used.

Why the Indications for Use of Your Medical Device is Important

The last post was about capturing User Needs for your medical device project. Related to User Needs is the indications for use. Another term that is often used is intended use. There are some debates about the difference between intended use and indications for use. For the sake of this post, I’m considering these two terms to be synonymous–or at least similar enough that debating the nuances and differences is trivial.

Part of a FDA 510(k) submission is the Indications for Use statement. According to FDA:

The statement should include specific indications, clinical settings, define the target population, anatomical sites, etc. This statement must be consistent with your labeling, advertising and instructions for use. 

As you can see, the Indications for Use is very much related to User Needs.

Which comes first? User Needs or Indications for Use? I guess it doesn’t really matter. The point is, you need to have both. And you should be documenting both very early in the medical device product development process.

We’re working on a product development project where we are in the process of establishing and defining the indications for use. This is important due to the regulatory implications and classification for the product. Knowing the desired indications helps us determine possible FDA product codes, which in turn dictate classification and type of clearance required (same is true for EU, Canada, and in many other places in the world).

With the draft indications for use, we were able to identify possible product codes and classifications. Some of the options are class I, others class II requiring a 510(k). Knowing the desire to get to market quickly, we are able to identify ways to modify the product User Needs and Indications for Use in such a way that would allow our team to first pursue the class I product codes options. The Indications for Use help us to define what the product can do, how it can be used, and how to eventually market the device.

How Do You Capture User Needs for a Medical Device?

Why do you engage in medical device product development? The ultimate purpose is to solve unmet clinical needs. To develop products, technologies, and services which sustain and improve quality of life.

If your experience as a medical device product developer has been anything like mine, starting a new project is often very fuzzy and raises more questions than answers. How you start a project is very important. And this is something that took me many attempts before I truly understood.

What do you need to start a new medical device product development project? If your company is anything like those I’ve worked with, chances are the reason to start a project is often times very vague. Basically, it boils down to someone making a financial commitment to begin the endeavor.

But as a product developer, you want and need more. You want to understand what clinical needs this idea will solve. You are seeking knowledge about how the user will interact, how the patient will interact. You want User Needs.

You go to FDA Design Control regulations to seek some guidance and direction on what User Needs are but are left scratching your head. No real help. You find a couple references to user needs:

820.30(c) Design Input states “. . . ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient . . .”

820.30(g) Design Validation states “. . . Design Validation shall ensure that devices confor to defined User Needs and intended uses . . .”

Not really all that helpful.

You decide to check out the FDA Design Control Guidance and are thankfully provided a few more tidbits of what User Needs are. At least “User Needs” is shown in the classic Design Control waterfall diagram:

From the guidance document, you learn that as a product developer, you have to translate User Needs into a set of requirements that can be validated prior to implementation. You finish reading the guidance (and I do recommend doing so–it is a helpful document) and have a little better idea of these things called User Needs. But you still don’t know really what these are or how to capture these.

Maybe I can help you a little. Think of User Needs as a bit of a wish list about what the device does or should do. Some questions for you to consider when capturing User Needs include:

  • Who will use this device?
  • How will the user and patient interact with the device?
  • What type of procedures will the device be used?
  • What type of environment will the device be used?
  • When will the device be used?
  • Is the device used one time or over and over?
  • What other products will the device interact and interface with?

I could go on with the list of questions to consider. But hopefully, you are beginning to understand what User Needs are.

Write them down! Ideally you write them down some time near the beginning of a project. If you are downstream in product development, there is still value in writing them down! At some point you will need to prove that your device meets those User Needs.

User Needs are very important to capture, though as early as possible in a project. Why? User Needs are the precursor to Design Inputs. And Design Inputs are the king of Design Controls. Design Inputs capture specific, measurable, objective details about your device. Their foundation must come from User Needs. In fact, every Design Input does have an origin to at least one User Need, whether stated or not.

As the waterfall diagram above suggests, User Needs gets the Design Control ball rolling.

greenlight.guru Helps Ensure Medical Device Design Control Compliance

You might have read about some of our adventures with greenlight.guru. Today, I’d like to share another chapter in this startup journey.

We had a call with a potential investor / resource. The guy had 20+ years experience in the medical device industry. The purpose of the call was to share a little more about greenlight.guru and do a brief product walk through. As we did so, the guy had strong energy about him. Every time we would offer an opinion, comment, or share details about the software, it felt as though he was bringing bad juju and negativity.

Going into the call, I had good energy and an open mind. Right after the call, I felt like someone ran over my dog and slashed my tires.

Now that there has been some time since the call, though, I have had an opportunity to let some of the comments from this guy sink in, trying very hard to scrape away the toxic affects before they sink into my brain.

“Venture backed startups implement enterprise software solutions based on what their investors recommend.”

Maybe in this guy’s experience. This just hasn’t been the case in mine. In fact, of the dozen or so venture backed medical device startups we have worked with over the years, I don’t recall a single one of these companies having any enterprise software in place. Further, the only medical device companies I have worked with throughout my career (which probably totals 4o or more) using enterprise software have been VERY large companies.

“You just have a process flow / spreadsheet that uses FDA Design Control terminology.” (he said in a snarky tone)

Exactly!

I walked this guy through how simple it is to use greenlight.guru to input User Needs, Design Inputs, Design Outputs, Design Verification, and Design Validation content. And how the tool automatically builds the traceability matrix for your Design Controls as you go. Yes, I’m biased, but damn, our software development team created a wicked good, simple, easy to use, intuitive way for medical device companies to manage Design Controls.

You see, I’ve sat directly across from ISO and FDA auditors who had technical files and Design History Files in front of them, picking them apart limb from limb. Most of the ripping apart pertained to our inability to clearly and accurately show complete Design Control traceability from User Needs through Design Validation. Of course we had the home grown Excel spreadsheets printed on 28 pages in size 8 font. Cells merged and linked to attempt to demonstrate traceability. Sometimes, I had an hand in creating these wonderfully, painful spreadsheets. Other times, I was there to defend spreadsheets I had no hand in creating. In every case, the audit was painful. In some cases, we survived, relatively unscathed. Other times, findings.

I know our greenlight.guru “spreadsheet” is good. I know it will help every one of our customers ensure compliance with FDA Design Control regulations and ensure compliance with Design & Development requirements of ISO 13485. I know that when our customers have greenlight.guru up during either a FDA / ISO audit, that they will be able to quickly and easily show complete Design Control traceability.

While we only have a process flow and spreadsheet, it’s a pretty damn important process flow and spreadsheet.

Medical Device Project Updates Buried in Emails

How many email messages do you get a day? I’m guessing your inbox is probably very similar to mine. I’m also guessing there is a very good chance that you have multiple email addresses. Are you good about email management? I used to think I was very good about this. However, the volume of emails these days is just crazy. I could literally spend the next few days just getting caught up on emails.

And I would totally make the current situation worse. Because how would I improve my current email backup? Likely respond with a follow up email message.

Ugh.

What’s worse than death by email? It’s getting updates on medical device projects via email. I try to flag, sort, and organize messages by project–and thankfully I have a ton of help with this task. Even following this method does not help.

I wish there was a better way to communicate project updates in some other, more efficient way other than email.

I don’t keep track of how many hours I spend per day sifting through emails to get project updates. But I’m guessing it’s easily 10+ hours. That’s significant! I’m losing one work day per week keeping caught up. It’s actually probably worse than that. I’m actually losing time during evenings and weekends. :(

Imagine if everyone on your project team also is dealing with similar time losses just trying to find and respond to emails regarding project issues. The hours lost by your medical device team can become pretty significant pretty quickly. It is very realistic that a project of any size is losing the equivalent of a full time resource per week (4 team members losing 10 hours each = 40 hours).

If you could recover 40 hours per week on your project team, what could you do with this extra time?

What choices do you have? How can you flip this time loss issue around in your favor?

UniDoc is now greenlight.guru

Greenlight GuruIn case you missed it, UniDoc is now greenlight.guru.

Why did we change the name?

Greenlight means go! And medical device product developers are seeking out greenlights to proceed towards market launch.

Our software does this. Provides greenlights to medical devices.

Joy of 510(k) Clearance

Cinco de Mayo was a good day–for many reasons! One of the reasons is that I received notification from FDA that a 510(k) we submitted for our startup medical device client received clearance. Did I mention “5″ is my number? 510(k) clearance on 5/5–pretty sweet!

The project has been rewarding and challenging, as with most medical device product development projects.

I especially found the FDA 510(k) review process to be a bit more challenging than I had expected. A few rounds of “refuse to accept” followed by a reviewer who seemed to challenge just about everything we provided as supporting evidence. Having gone through this experience with a tough and difficult reviewer is something I do appreciate. Working with him actually made the second submission much more complete and smoother (so far) with FDA.

Receiving a FDA 510(k) clearance letter is no small feat. Especially in today’s medical device regulatory market. So much more to do, however. I’ll not dwell on this too long.

Some Cool Cats in Medical Device Industry

You probably already know about the benefits of networking. I sometimes go through cycles where I forget about it. And when I do and thrust myself back into networking mode, I become amazed again at the benefits and opportunities gained from networking. I’m not just talking about job and project opportunities. Actually, I’m talking more about the types of people you get to meet and the things you get to learn. Being in the medical device industry, too, means that when you network, you are going to meet some really cool cats doing some really amazing things to save and sustain human life.

One of these cool cats I recently got to connect with is Tom KraMer at Kablooe Design. Okay, when you go to the Kablooe website, you are presented with this image:

Design Driven Development

It’s very catching and memorable. And then when you learn more about Kablooe through the YouTube videos and other pages on their website, you really get an opportunity to learn about an innovative company led by an innovative person. Okay, after you get done stalking Tom and Kablooe, make the effort to connect with him. He’s very active on LinkedIn and pretty accessible.

I have yet to have had an opportunity to work directly with Tom and Kablooe, yet look forward to doing so sometime in the future.

Medical Device Design Control Greenlight

What do you think of when you hear the term “green light”? I hear “go”! In the medical device world, getting the “green light” can mean a lot of things–all positive. Getting the green light from FDA means your submission is cleared, and you can go to market.

But as medical device product developers, we often have a great deal of uncertainty while in the trenches of product development. We don’t have good tools to give us the proverbial green lights we seek. We are often tasked with aggressive timelines and tight budgets, with a need to ensure all product development and Design Control documentation is current, up to date, and compliant. Pressure, pressure, pressure!

You seek tools and opportunities to communicate, collaborate, and gain efficiency. You want to know that when we document our Design Controls that the results are sound, thorough, and complete. You often create spreadsheets and organize folders on the network drive to ensure organization and traceability of all the documentation you need to generate throughout the product development process. The tools available rarely meet your needs, but you make due.

All the while, you are seeking a better way. You are seeking a smoother way. You are trying to find ways to get those wonderful green lights during product development and Design Controls.

I assure you a better way to allow you to get those green lights is available.

What If You Could Have A New Design Control Experience?

Since starting my career in the medical device industry over 15 years ago, there have been a few constants. One of these constants is that many medical device product developers loathe Design Controls. Many of the comments I’ve heard over the years have claimed that Design Controls often hamper and slow down product development. And nearly anyone who has worked with existing product development processes at a medical device company seems to cringe at least a little at the mention of “Design Controls”.

Let’s just say there are very few individuals I’ve encountered during my career who are genuinely excited about Design Control documentation, processes, forms, etc. I’ve perceived actually that there is a fair amount of “pain” felt regarding this topic.

It’s because of this pain that has led me and a small software team to find a better way. This better way is called greenlight.guru. Our team has had there head down for the past few months developing this tool. On April 1, we are releasing a “sandbox” to a group of early adopters who can also start to learn about the better way of documenting, collaborating, and managing Design Controls and Design History Files.

I’ve had a chance to play in this sandbox before releasing it. I’m VERY excited about how UniDoc works and the impact I know it will make in the medical device industry.

Do you want to be a part of a new Design Control experience? Contact me and let’s figure out how to make this happen.

Importance of Medical Device Design Controls – Part 2

Read part 1 of Importance of Medical Device Design Controls.

Now for part 2 . . .

If you evaluate the regulatory trends and hot topics, Design Controls usually makes it into the top five. However, the current culture of the medical device industry rarely push Design Controls to the top. Rather, topics like Complaint Handling, Corrective & Preventive Action (CAPA), and Risk Management often dominate medical device industry blogs, conferences, and hot topics. This is somewhat justified due to the focus and attention regulatory bodies across the world have paid to these other important elements. Let me take a few moments to talk a little about each of these other topics with respect to Design Controls.

Complaint Handling pertains to medical device product issues and failures. This topic has received a great deal of attention because so many companies struggle with how they handle complaints. Complaint handling processes are poor at best with supporting documentation being equally as poor. I don’t discount the importance of a sound Complaint Handling process. However, if we spent as much time on the front end during the medical device product development process to ensure the products we design are safe and effective, would complaints go away? Of course not likely. But could the occurrence rate be reduced? Perhaps. Wait, don’t we have mechanisms in place to do just that? Yes, we do. Design Controls.

Corrective Action pertains to fixing product (or process) issues. Preventive Action pertains to having some foresight to fix an issue before it happens or becomes a big deal. Okay, if we spent time up front during Design Controls, could we reduce the need for so many CAPAs? I postulate maybe.

Risk Management pertains to documenting the hazards, harms, risks of medical devices. In a nutshell (please don’t shoot me for oversimplifying), Risk Management is documenting what can go wrong when a medical device is used. Again, if we evaluate the origins of Design Control, safety and effectiveness were intended to be embedded within Design Controls all along. If fact the FDA Design Control regulation for Design Validation includes the term “risk analysis”. In recent years, though, Risk Management has been likely driven more because of our litigious society.

No, I’m not so naïve that I think Design Controls fixes all issues and makes Complaint Handling, CAPA, and Risk Management less important. Clearly, Design Controls is largely part of medical device product development. And once a product is launched into the market and manufacturing, other processes need to take over. Very valid point.

One of the necessary product lifecycle processes is Change Control. Change Control pertains to monitoring, documenting, and maintaining a medical device product throughout its lifecycle. In my way of looking at this, Change Control is a natural progression, maybe even an extension of Design Controls. Change Control is a way to ensure the medical device evolves based on clinical needs. In my opinion, the bond between Design Control and Change Control should be strong. As you likely know, the culmination of all Design Controls results in the creation of a Design History File (DHF). Many ascribe to the belief that a DHF is a snapshot in time of a medical device during the product development process. Okay, I understand that, to a point. I’ve often wondered, though, if a DHF should continually be up to date based on the current medical device design. Those in the DHF is a snapshot in time camp will point to Change Control as the continuation of the medical device design; Change Control is the “living” documentation and records. Maybe a matter of semantics.

But whenever we make changes to a medical device in production, we must assess the impact on verification and validation. Aren’t these Design Control elements? What if we had a way to maintain Design Controls as living throughout the entire product lifecycle?

I’m sharing these thoughts for a purpose. Primarily, I hope to provoke a new way for the medical device industry to think and behave. I truly believe Design Controls are the foundation of all medical devices and think it is time that we treat them as such. To do so, we need better tools and processes for documenting medical device Design Controls.

Importance of Medical Device Design Controls – Part 1

Is medical device product development really all that different than product development of other products and technologies? If you take a moment to really think about this, the answer is not all that easy to address. From one perspective, no, the medical device product development process is by and large just like any other product development process. Sure, some of the work products and deliverables and regulatory requirements are different. But overall, the process is the same (or at least it should be): establish a business case, capture user needs, define requirements, figure out how to build it, prove that it is safe, prove that it works, prove you can make it. From another perspective, yes, the medical device product development process is vastly different than other product development processes. Why? Regulations, largely. Regulations that dictate what to do and when to do it in order to prove and demonstrate that a medical device is safe and effective.

In the end, the question is really not all that relevant. Sometimes we like to brag (and other times complain) that the rules we have to follow are strict and difficult. We brag when we think about how and who the medical devices we design and develop will be used. We complain when we are up against deadlines to get tasks done. Regardless, the rules of medical device product development are somewhat defined. Yes, sometimes those of us in the medical device industry are sometimes proud that we have our own unique lexicon of terms to describe product development. We refer to these rules as “Design Controls”—mostly because the U.S. FDA has defined the medical device design control regulations (refer to FDA 21 CFR part 820.30).

We can debate if Design Controls is synonymous with medical device product development or if Design Controls are proof and objective evidence that regulations have been met during medical device product development. I’ve been part of some very heated and passionate conversations on the topic. Interestingly, the answer does not matter. Regardless of your point of view about the relationship of Design Controls and medical device product development, I suspect we all accept that Design Controls are expected behavior when it comes to medical device product development.

Briefly, Design Controls includes: Design Planning, User Needs (although not explicitly part of regulations), Design Inputs, Design Outputs, Design Verification, Design Validation, Design Changes, Design Reviews, and Design Transfer. Some also throw in Risk Management. For now, I want to leave Risk Management out of this and revisit it later. Design Controls dovetail nicely with a natural progression through a product development process. A nice linear path. Just like product development is intended to be. Or at least this is how we often describe and depict the process. Do this and then that and so on. But medical device product development is most definitely NOT a linear process.

Again, this is a concept that can elicit heated and passionate conversations.

All medical devices on the market today at some point in time began as an idea to solve a clinical need. All medical devices on the market today at some point in time went through a product development process. And conceivably, within the past fifteen or so years, many medical devices likely have supporting Design Control documentation and records. Suffice it to say that Design Controls are the foundation of a medical device.

Interestingly, the topic of Design Controls is still very confusing to many within the industry. I think it is confusing because we (collectively speaking) have made it that way. We have married Design Controls to sometimes convoluted and complicated business processes. In other cases, we feel compelled and sometimes forced to follow the linear “rules” of Design Controls, that we have more rigidity than need be. When asked to think about Design Controls, many think of documents, tables, and spreadsheets. We seldom describe Design Controls for what they are: objective evidence to prove our medical devices are safe and effective. We have lost sight of the importance Design Controls truly plays in the health of the medical device industry.

Building Strategic Partnerships in Medical Device Product Development

The term partnership is strong. When I hear the word “partner”, I think of other words such as equal, support, team. This is true for medical device product development. Whether you work for a completely vertically integrated company or are a startup leverging relationships with third party suppliers, you need to build strategic partnerships to be successful with your medical device product development efforts.

I recently posed the question “What do you do to form partnerships with key suppliers?” in a LinkedIn discussion. I asked the question from the perspective of a startup. A few of the comments are shared below:

  • Supplier become part of the team as a partner that can be relied on to meet all solution needs
  • If the startup vision and supplier motivations do not complement one another, there will be issues
  • Takes time to build the relationship and above all this must be based on mutual trust

Of course there is a great deal that goes into establishing a true partnership. It’s not like you can wave a magic wand and partnerships are formed.

Keep in mind that to form solid, reliable business relationships, you have to be willing to answer “what’s in it for me”. Some may think this sounds selfish. Yes, we hear all the time about “win / win”. Sure, I guess. When you answer WIIFM, you need to try and answer the same for all the other stakeholders. And, I’ve found that it can be very helpful to have a very candid conversation with potential strategic suppliers from the very beginning. If everyone can be honest and answer the “what’s in it for me”, then we should all be more aware of the individual motivations involved in the product development efforts.

As the one comment from the LinkedIn post indicates, building strategic partnerships takes time. And trust. When trust is broken (or never established), building a partnership becomes challenging.

Keep in mind, too, that never every supplier relationship has to evolve into a strategic partnership. Sometimes you might only be interested in working with a particular supplier for a certain product or service. That’s fine too.

Medical Device Prototypes Can Mislead

Once upon a time, I was a huge proponent of prototyping medical devices as soon as possible. Today, I’m a little more hesitant. Don’t mishear me–prototypes of your medical device can certainly be extremely valuable. However, I think it is VERY important to be clear about what you hope to learn from the prototype. Equally important, it is VERY important to understand what the prototype can not do. In other words, know what decisions can be made based on the type of prototype you have.

Let me expand a little.

Several months ago, we were initiating a medical device design and development project. We had some product designs sketched and started to narrow the list down to just a few concepts. Once narrowed, the design resource offered to “grow” some 3D prototypes. Within a few days, we had 3D concepts in our hands to better evaluate some of the design ideas we had been discussing a viewing on screen. Having the prototypes in hand was helpful. We were able to better evaluate features and aspects of the product design. We were able to play around with component interfaces and get a feel for how the user would interact with the device. We made a few tweaks but soon, we decided to proceed with cutting steel for injection mold tooling.

Tooling was to take ~10 weeks. We made progress on other parts of the product design while we patiently waited for those first articles. When the tooling was completed, first articles were provided soon after. We were all anxious to evaluate these parts. When we did, the design presented to us via concept sketches and 3D prototypes did not seem to translate into injection molded parts. What happened? Why not? The design resource offered that the prototypes might not have been an ideal representation of the injection mold parts. They also stated that they could make a few minor modifications to fix some of the design concerns. Another round of prototypes and another round of discussions.

Why was this round of 3D prototypes any different? I guess we trusted that the designers would make the design right.

Several more weeks were necessary to modify the tools. And eventually another round of first articles. Which once again, failed to hit the mark we needed with the product design. Frustrated began to mount. And I kind of scratched my head. What went wrong? Why were the prototypes so bad at representing the product design?

Then it hit me. Medical device prototypes are not the end all be all. Prototypes have limitations. You have to understand what the 3D prototype can and can not do for your design efforts. I learned that SLA-type of prototypes is not a real approximation of what you might expect from injection mold tooling.

When you get prototypes for your next project, take a few moments to truly understand what these prototypes can tell you. What exactly can you learn? More importantly, do not fall into the trap that a 3D prototype can answer all your design questions. It’s a tough trap to avoid. The proliferation of 3D CAD tools and easy access to affordable 3D printers has allowed the rapid proliferation of prototypes. Sometimes we have a tendency to make 3D prototypes just because we can and it’s cool. Rather, we should be striving for effective prototyping.

I was once told that if a picture is worth a thousand words, then a prototype is worth a thousand pictures. No truer words have ever been said. But if you do not fully understand what the prototype can teach you about your product, it doesn’t matter if the prototype is worth one million pictures.

Startup Medical Device Project Lessons Learned

From time to time, I like to share some lessons learned from current projects. We are in the middle of product development for a medical device startup project and have plenty of recent lessons learned to share.

In no particular order—

Dates Are Wrong

We all know this. Yet there is also a compelling need to drive towards completion of tasks. Does having a due date help or hurt? I can find plenty of people to support either argument. I don’t like dates anymore than the next person. But at the same time, my opinion is that without a target date for completing a task, a task could linger.

Of course if you are surrounding with people who are checklist oriented, accountable, and driven towards getting things done, dates probably don’t matter all that much.

However, I have rarely been involved with any initiative of any kind where all people involved were wired in this fashion. Because of this, dates are a necessary evil.

A trick as a project manager is to figure out each person’s buffer. I often refer to this as a “fudge factor” (I know this term was ingrained in my brain somewhere along the way; I just can’t remember when or where). What I mean by this is in my experience, when prompted to provide a date, most people will give you a best case scenario response. The challenge is to figure out how far off their best case is from reality. You won’t learn this initially. You will have to let the person give you false information a time or two first to establish their particular fudge factor.

Hierarchy & Order Are Important

What I mean by this is that it is important to have a process in place and to follow the process. I think this is especially true when startups are mostly virtual and rely heavily on suppliers. Some suppliers may have process in place. Others may not. To complicate it further, each supplier might have a slightly different process too. In all cases, it is important to establish at the beginning what process will be followed. It is important to outline and identify the specific deliverables, along with when each of these deliverables is to be accomplished.

Scope Creep Will Happen

Despite your best efforts, scope creep will happen on every project. To expect that you can clearly and completely articulate, communicate, and establish a scope of work at the beginning of a project and that this will not change as the project progresses is unrealistic.

Rather than resist scope creep, figure out how you can manage it. The most challenging scope creep issues pertain to the expectation that the budget and timeline won’t change. Scope creep, more than likely, will affect both budget and timeline. When a scope change is suggested, take a moment to evaluate what this means to the project and communicate this to the stakeholders.

Double Check Always

You would think I would have learned after the first few times a resource told me a task was done only to find out otherwise that I would have started double checking sooner. I mean, come on, I’m working with adults, right? When someone tells me they got something done, I should expect that it is done. Yes, that statement is true. However, it’s also true that people don’t always complete what they say they’ve done. I think this is because the person expects they will get the task done before you actually find out.

I now will do my best to always double check and to get objective evidence that a task is done.

Have a Back Up Plan Brewing

You never know when you will need a back up plan. I can tell you from experience numerous times on this project that developing a back up plan after it’s already needed is not fun. Yes, I want to trust all the resources I’m working with. However, this project has taught me that I always need to have a back plan in the works, just in case.