First part of this, is let\u2019s define \u201cregulation\u201d in context.\u00a0 Specifically, I\u2019m referring to ISO 13485, EU medical devices (GMP, or \u201cGood Manufacturing Practice\u201d), and FDA medical device standards.<\/p>\n
Let\u2019s also be clear, these aren\u2019t just \u201cguidelines\u201d (insert Barbarossa quote here), they\u2019re law.<\/p>\n
As law, what is their purpose?\u00a0 The goal of this regulation is to make certain that the products made by manufacturers are safe, effective, consistent and unadulterated.\u00a0 As a result, this means that they end up being implemented in such a way as to minimize mistakes and errors, and reduce or eliminate contamination where such can occur. \u00a0Consumers as the beneficiaries of the regulation are guaranteed a high level of security that the products and devices they are exposed to do the job they are supposed to in a way that is not dangerous to them.<\/p>\n
It is also worth noting here that as law, violations can result in steep fines, product recalls, and potentially even jail time.\u00a0 This is serious stuff.<\/p>\n
That means you, as a leader, have the responsibility to implement compliance measures, and to ensure that your IT and Software groups understand and follow the measures you put in.<\/p>\n
The requirements of regulation can result in direct opposition to some of the activities your group performs.\u00a0 Quite often a software group will be operating on an \u201cAgile\u201d methodology, with possibly scrum sprints and so forth \u2013 and these methods are oriented towards speed.<\/p>\n
Regulatory requirements will impair that speed and that slowdown will appear to be simply \u201cgetting in the way\u201d of work.\u00a0 Persons unfamiliar with the need for regulation will see it as unduly burdensome \u2013 indeed, I can quote a peer who totally missed the mark of what those regs were for:\u00a0 \u201cNo one cares anyway, these are just here to make it look good.\u201d<\/p>\n
Needless to say, he didn\u2019t last long.\u00a0 Sadly, many developers \u2013 including most who come directly from university \u2013 have no experience with such regulation and will view them as unnecessary impediments.\u00a0 I myself, as a software developer many years ago, left a contract that I felt overly constraining to me because it was operating under FDA medical devices regulation, and I didn\u2019t appreciate why it took six months to get from proposing a spelling change to final deployment of the release containing the correction.<\/p>\n
These requirements make progress feel very plodding and restrictive, particularly for those junior members of your team.\u00a0 And they never end<\/em>.\u00a0 They are part of the job, every single day.\u00a0 It isn\u2019t just something you do once, qualify for, and then amble merrily forward \u2013 these actions and activities go into the job and become part of the fabric of how you operate.<\/p>\n What can good leadership do in such a conflict?\u00a0 What is to be done here, and how can we exert good leadership in this environment?<\/p>\n Let\u2019s examine the conflict first.\u00a0 There are a few sources of conflict here:<\/p>\n Needless to say, rising to the occasion here requires a lot of patience and discipline.\u00a0 It also needs a great communicator, which I\u2019ll get to in a moment.<\/p>\n A lot of what you do, whether it is network infrastructure or software development, will require up-front planning \u2013 and most importantly, documentation of that planning, in order to provide an audit trail.\u00a0 Whether you\u2019re aiming to be compliant with ISO, GMP, or FDA, there\u2019s a key question that you have to ask before you begin an operation:<\/p>\n Will my action, or any effect of my action, have direct impact on our final product?<\/em><\/p>\n For some things, the answer will of course be \u201cno\u201d \u2013 for example, establishing a new backup plan for your email server.\u00a0 Regardless, before you begin, that question has to be asked and the answer documented.\u00a0 For most regulation, that documentation ends when the answer is \u201cno.\u201d<\/p>\n However, what if the answer is \u201cyes\u201d?\u00a0 In that case, you have to assess what you are doing, why you are doing it, why you think doing it will satisfy the original stated need, what are the risks, plan mitigation for those risks, and have your rollout staged to assess success or fail conditions at every milestone.\u00a0 This entire process is generally called \u201cvalidation\u201d.<\/p>\n In my own context, I created a form that enabled myself and others on my team to ask that question, and then to lay out the long set of considerations on changes to hardware and software in the IT group.\u00a0 That form went into our Confluence server, and could be linked from there to Jira tickets created to represent the progress of the tasks being tracked.\u00a0 For your own use, in whichever issue-tracking system you use (I refer to Jira here, just because it\u2019s so common and it\u2019s the one I\u2019m most familiar with), you can put a field in your issues asking the very question about impacting the final product.\u00a0 Then you link it to a new issue page with the content required for the \u201cyes\u201d answer.<\/p>\n And once filled out, the page may need to be locked in read-only status (GMP and FDA requirements both demand that no editing or deletion be available after finalization).<\/p>\n This satisfies the regulatory requirement, and the organization provides your team with clear addenda to the original requirements.<\/p>\n The need for organization (and communication, below) requires your Commitment.<\/u>\u00a0 Not just commitment to the team, but commitment to the mission of the company and the production of whatever products require the regulatory oversight.\u00a0 Your IT \/ development group are key players in delivery of solid product to market.\u00a0 If the commitment isn\u2019t there, the team will know and it\u2019ll show in how you deliver.<\/p>\n Quite possibly, this should be your first consideration, but I wrote it second here and we\u2019ll leave it at that.<\/p>\n In your team, from day one of a person\u2019s start or day one of implementing compliance, communication of the compliance effort will be key to making sure everyone stays on board with it.<\/p>\n I\u2019ve found in both software development and network architecture that the most important factor in keeping the team aligned is making sure everyone knows and is clear about the answer to the question: \u201cWhy are we doing this?\u201d\u00a0 Knowing why gives us all not only a common ground and a team unifier, it also helps us all determine potentially better solutions than we could with just a team head knowing the why and issuing directives to meet it.<\/p>\n This also applies to ensuring the team gets on board, and stays on board, with compliance efforts.\u00a0 They have to see the broadest picture of how the regulations help the business<\/em>.\u00a0 If your company manufactures widgets used in surgeries, your team needs to be reminded (perhaps even daily) that what you do helps people safely undergo and survive life-saving operations.\u00a0 Their actions, every one of them, can potentially impact how well a widget works after manufacture.<\/p>\n In a lot of ways, this means that what you\u2019re doing is linking the following of the regulation with the provision of a quality product, and instilling a culture of quality that goes into the tiniest details of everything your team does.<\/p>\n Which, when you think about it, is generally needed for a company to become great, isn\u2019t it?<\/p>\n I make it sound easy, but it isn\u2019t.\u00a0 You have to beat this drum every day, and you yourself, as the leader, need to be its biggest evangelist.\u00a0 Your Personality<\/u> and Knowledge<\/u> (see Part 1) tie in here, and are key factors in enabling this \u2013 you have to be able to be positive about the requirement of regulation and knowledgeable about its execution.\u00a0 There will be days when you are tired, and simply don\u2019t want to deal with it.\u00a0 But remember \u2013 those widgets depend on you.\u00a0 They depend on your team.\u00a0 And the people undergoing surgery depend on you all.<\/p>\n I don\u2019t\u2019 want to really call this a \u201cfinal\u201d topic, because there\u2019s an enormous quantity of factors that can affect this topic.\u00a0 But I only have so many hours of the day, and I\u2019m calling these my top three items for being a successfully leader in this environment.<\/p>\n Setting expectations of stakeholders and team members for the execution of projects and tasks is a key element of all work, whether it\u2019s regulated or not.\u00a0 Telling your boss how long project Y will take, and getting good estimates from your staff on how long tasks A, B, and C will take are key to that.\u00a0 Regulations increase workload, there\u2019s no two ways about that.\u00a0 They also slow down progress.\u00a0 But they do enhance quality.\u00a0 They benefit consistency in the product(s) your company makes.\u00a0 Knowing what features are being prepared and what to expect in each release, as well as knowing what steps are being taken to mitigate the risks involved will put everyone more at ease (and will ensure no interruption or disruption in production).<\/p>\n Linking the goals of the regulation with the production of a quality product falls directly into your skills of Motivation<\/u> for your team.\u00a0 Getting the team\u2019s buy-in by involving them in the setting of proper expectations is the way to ensure the best possible motivation for success.<\/p>\n Making sure your team knows to take into account the added burden of the regulatory requirements will get you a good ways towards ensuring that you don\u2019t have overblown demands on your team.\u00a0 It also involves them all along the way to ensure they retain respect and participate in their own work environment.\u00a0 This really applies to all environments, but it deserves special attention in a situation where a great deal of up-front and ongoing efforts require such detail.<\/p>\n Well, no.\u00a0 Obviously there\u2019s no \u201csilver bullet\u201d answer to anything in IT, but there are some very cool tools that can help you along the way.\u00a0 I\u2019ve mentioned Jira and Confluence already, and these are insanely useful in establishing organization, team communication, and helping to set expectations.\u00a0 Really if I were setting up practically any environment, these tools would be first on my list.<\/p>\n There are also document management systems which enable GMP\/FDA-compliant protection of docs, which might be required.\u00a0 When these enter the picture, I generally advise that one keeps only what is absolutely necessary in such a DMS, and the rest in Confluence.<\/p>\n Additionally, Jira or other issue-management systems can be tailored to monitor risks and mitigation efforts, as well as validation efforts.\u00a0 The reporting capabilities of these systems can make scrum meetings much simpler, as well as providing outgoing communication to non-IT stakeholders in the form of expected- versus delivered-work estimates, etc.<\/p>\n Gathering this up, a regulatory environment heightens the need for a clear communication path as well as requiring a more organized IT department.\u00a0 The company\u2019s, and really the market\u2019s, expectations of your firm\u2019s output puts an additional burden of caution on your IT staff.\u00a0 This may not be suitable for all tech people, and there\u2019s no shame in recognizing that you might not be one of those people for whom this is a good working environment.<\/p>\n If you\u2019re comfortable with it, though, you\u2019ll find that your skills in communication and organization are being called upon considerably more strongly than in a \u201cnormal\u201d non-regulated situation.\u00a0 You\u2019ll still be responsible for aiding in motivation, commitment, and the rest, but GMP and FDA regs put you in a special situation where you have to be stronger in certain areas to enable your team to succeed.<\/p>\n Leadership in its raw form doesn\u2019t change \u2013 but different aspects of it are called upon more strongly in a regulated environment, and you need to be prepared to engage appropriately.<\/p>\n Part 1<\/a><\/p>\n Part 2<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Part 3 \u2013 now let\u2019s introduce regulation First part of this, is let\u2019s define \u201cregulation\u201d in context.\u00a0 Specifically, I\u2019m referring to ISO 13485, EU medical devices (GMP, or \u201cGood Manufacturing Practice\u201d), and FDA medical device standards. Let\u2019s also be clear, … Continue reading \n
Let\u2019s begin with organization<\/u>.<\/h2>\n
Next step we should look at is communication<\/u>.<\/em><\/h2>\n
Finally let\u2019s talk expectations<\/u><\/h2>\n
Is there some magic bullet here?<\/h2>\n
In Summary<\/h2>\n