Ten Ways to Help Reduce Frustration and Burnout

Hi fellow CMIOs, CNIOs, and other Clinical Informatics and HealthIT friends,

With all of the recent discussions about 'burnout' (moral injury) among clinicians and other struggles with healthcare technology, I thought I'd take a moment to share some lessons about what you can do to help reduce frustration and burnout, based on my own experiences and lessons I've learned (sometimes the hard way!) over the last sixteen years I've worked in Applied Clinical Informatics. 

10. Worry about the details.

Most providers are acutely aware of the effect of the problem, but not the cause. So when you are looking at workflow problems, try hard to resist the temptation to get overwhelmed with the details - they are very important. You can sometimes tell when people get overwhelmed, because they sometimes say things at meetings like : 

• "You can't boil the ocean!"
• "We can't get too into the weeds here."
• "Let's just look for some quick wins / low-hanging fruit!"
• "Don't fall victim to analysis paralysis!"
• "Perfection is the enemy of good!"
• "We don't have time to plan!"

Unfortunately, anything that prevents important details from being reviewed and discussed can lead to workflow problems, so it helps to set expectations early and accept that details are important - and so you should always look for ways to discuss them easily, openly, and honestly.

9. Have organized, well-developed project intake and project management processes. 

Healthcare is complicated. The need for change could come from any one of a number of different directions: 

... so you will need to plan for how to manage all of these stakeholders above. Developing an organized project intake, prioritization, and management process for all of your stakeholders to participate in will help them to see the big picture, better negotiate conflicts when they arise, and provide transparency to end-users.

8. Have an organized, well-developed change management process. 

People like predictable outcomes. While it might take some time and resources to do :

• formal evaluations of change/project requests, along with...
• the necessary policy/regulatory searches, 
• identification of best practices (e.g. through literature search, site visits, and interviews), 
• current-state/future-state ('gap') analysis, 
• design of organized blueprints, and ...
• proper identification of stakeholders and deliverables, 

... but it always pays off in smooth workflows, smooth implementations, predictable outcomes, and happy users/patients. So the answer is not to skip these necessary analysis and planning steps - The answer is to have a clear, consistent, well-developed, and well-supported change management process that - not unlike a factory assembly line - lets you accomplish all of these important steps in a smooth, well-oiled process throughout the intake, analysis, design, build, approval, training, implementation, and support phases of your projects.

7. Have standardized definitions and templates for common tools (both inside and outside the EMR).

Creating an organizational glossary (with policy-grade definitions!) and developing standardized templates for common tools will decrease training and development times, increase standardization and functionality, increase predictable outcomes, and improve user satisfaction. A common source of workflow inconsistency happens when development teams focus on developing only the tools inside the EMR (on the right below), while letting someone else worry about the tools outside of your EMR (on the left below) : 

You can help avoid those unnecessary workflow inconsistencies by using both the red and grey lists above (as a checklist!) when identifying the deliverables necessary for your requested clinical workflow implementations/updates. 

6. Worry about document control and standardized document management. 

At first, it might seem like a trivial detail. Most people don't give it much thought, but having a single, centralized catalog (source-of-truth) for all of your important operational documents (policies, procedures, guidelines, protocols, forms, etc.) can help create a great deal of clarity, understanding, and collaboration. As the saying goes, "Control your documents, before they control you." - Without good document control and management, it's easy for project implementations to be delayed and/or result in unexpected outcomes. 

5. For those who write Federal/State regulations - You can help save time and frustration by fully understanding the subject matter, working from clear policy-grade definitions, and writing clearly and succinctly.

Some of the administrative complexities of modern healthcare can result from Federal / State agencies sometimes writing vague regulations, using vague definitions, sometimes with a vague understanding of the clinical workflows and subject matter. So if you write regulations, you can help organizations to save time and reduce administrative costs by using standardized, federal policy-grade definitions and writing regulations that are clear, short, and succinct. You could even help organizations to succeed by writing more than just regulations - Consider other tools necessary for success, such as sample workflows, best practices, educational curriculum, and sample policies : 

Finally, always have a plan for expiring/retiring or updating your regulations - Regulations with no planned expiration date may not get the necessary attention and updates they deserve.

4. Always have clearly written operational policies and procedures. 

Your operational policies are the standards of your organization, and your associated procedures describe how you will achieve those standards. Not only do good policies and procedures create clarity, harmony, and understanding - but they can be used to educate staff, answer questions, and even help plan/design workflows. While some believe the mantra 'don't paint yourself into a corner' , always remember - Good policies help to create clarity, improve understanding, improve accountability, encourage teamwork, and reduce risk of harm or unexpected outcomes.

3. Have an Applied Clinical Informatics team. 

When budgeting for technology, details are important. Total Cost of Ownership (TCO) and Return-on-Investment (ROI) are crucial to make smart business decisions. Applied Clinical Informatics professionals specialize in the analysis, planning, budgeting, design, development, implementation, and monitoring/support of technology implementations. So it's very helpful - if not essential - to have a multidisciplinary team of them available to help you with your most common clinical and business needs : 

... through not just your purchasing decisions, but also for your clinical workflow analysis/designs (#BlueprintsBeforeBuild), complex tickets/projects, special event planning, compliance, maintenance, and other strategic clinical and business needs.

2. Build clear, complete, and consistent order sets.

Physicians spend a lot of time ordering. Order sets connect all of the orders they need for all of their common clinical scenarios. Having inconsistent, incomplete, or unclear order sets only creates frustration, clicks, and unnecessary pages for your physicians. So to help reduce clicks, reduce frustration, and reduce unnecessary pages - you can help ensure your order sets are always clear, complete, and consistent by : 

• Making sure you have a standardized order set template for developing your ordering tools (in a consistent manner).
• Making sure you have the terminology necessary to clearly distinguish your order sets from your other common clinical tools like protocols, guidelines, templates, and clinical pathways.
• Making sure your organizational order set development, approval, implementation, monitoring/support, and update processes are clear, well-defined, and well-supported.
• Making sure you have organized naming conventions for all of your order set types.

1. Empower your clinical leaders. 

Supporting your Physician, Advanced Practice Providers (APPs), Nursing, and Pharmacy leaders might take time, planning, and resources - but expanding their skill set with helpful information about governance, committee chairing, policy writing, operations, finance, and/or project and change management will : 

• give your clinical leaders more satisfaction, understanding, and control of their workflows, while also ...
• empowering them them to play a more active role in problem solving, project development, and project implementation.

Remember - With the necessary Clinical Informatics support, support for/from your clinical leaders, and change and project infrastructure - you too can help create the clarity, harmony, efficiency, and predictable outcomes needed to help fully see the return on your technology investments. 

I hope this blog post helps spur some discussions with your own teams on how to help reduce frustration, reduce burnout, improve planning, improve analysis/design, improve usability, improve participation, and perhaps most importantly - improve patient satisfaction and patient care. 

Remember : This blog is for educational and discussion purposes only - Your mileage may vary! Have any other helpful suggestions for reducing frustration and burnout? Please feel free to leave them in the feedback section below!

Running a meeting, for Clinical Leaders

Hi fellow CMIOs, CNIOs, Informatics friends, and other clinical leaders,

For this last post of 2022, I'm sharing some helpful slides I've used when presenting to new clinical leaders about the importance of knowing how to plan and run a good meeting : 

To keep things short, let's focus on five basic things : The importance of running a good meeting, the most common types of meetings, common meeting problems, common meeting solutions, and some final tips : 

HELPFUL BACKGROUND

As a clinical leader, running a meeting can sometimes feel a bit like herding cats - At your meeting, you will no doubt have different types of people, with different roles, different experiences, different needs, and different ideas of what needs to be done : 

So if you're planning and running the meeting, it's your responsibility to anticipate these different experiences and different needs, and create a productive discussion that helps solve a defined problem, or create a desired outcome. Especially in healthcare - failure to do this well can be very expensive, and potentially even create confusion :  

So it's helpful to keep in mind, a list of things that meetings should be, and a list of things that meetings should not be (click to enlarge) : 

Since the COVID pandemic, this has also created new challenges to running effective meetings, especially when on a video conferencing service. In-person meetings, online meetings, and hybrid meetings all have their own unique challenges and benefits, so it's helpful to plan carefully and maybe even more importantly, practice running a meeting in each arrangement : 

So what are the most common reasons to have meetings in Healthcare? They include: Education and information transfer, group decision-making, and collaborative development : 

And this leads us to the most common types of meetings in Healthcare, which include regular department meetings, emergent/urgent department/team meetings, committee meetings, planned project team meetings, and other common meetings (e.g. Morbidity and Mortality conferences, planning/strategy meetings, meetings to review clinical literature and needs, etc.)

Without good planning and support - there are some common problems which can occur, including poorly-defined charters, poorly-defined agendas, poorly-documented minutes, incorrect stakeholders, or inadequate attendance : 

Fortunately, the solution to these problems is usually to have well-defined charters, agendas, and minutes. 

THE CHARTER 

Below, I've attached some data elements for a good committee or team charter : 

Another way of looking at those same data elements, contained in a good committee / team charter, is here (click to enlarge) : 

Assuming you have a good committee charter to set your team in the right direction, with clear responsibility, authority, and metrics of success - The next steps is to make sure you have a good agenda. 

THE AGENDA

Some of the data elements contained in a good agenda are here below :

Note that the agenda items typically divide into "old business" and "new business", as recommended by Robert's Rules of Order ( www.robertsrules.com ), to allow you to revisit previous topics and add new ones in an organized, predictable way. 

For a more complete set of potentially relevant data elements that might be used in an agenda, you can also see the sample agenda template below (click to enlarge) :  

THE MINUTES 

Recording the activities, discussions, and actions of the committee will require careful documentation of minutes - typically recorded by your secretary or someone who has the training, experience, and ability to take minutes. Minutes are your official legal document, acknowledging who participated in the meeting, and what actions the committee took. They are so important that you will want to send them out to committee/team members, ask them to review them, ask for any edits/corrections, and bring back the final minutes for review and final approval at your next meeting. 

Some of the data elements contained in a good set of minutes include the below (click to enlarge) :

For a more complete set of data elements that might be used in a set of minutes, you can also see this sample minutes template below (click to enlarge) : 

HELPFUL CLOSING TIPS

This brings us to some of my closing tips for running a good meeting :

• It's very helpful for every clinical leader to familiarize yourself with Robert's Rules of Order ( www.robertsrules.com ), a well-known and helpful book on running all sorts of meetings - from small informal ones to large formal ones. In addition to meeting planning, you'll learn about chairperson responsibilities, and the different types of motions and actions that help make meetings run smoother.
• Using the sample charter, agenda, and minutes templates that I've shared above can help you run your meetings in an organized and productive way.

And for my final tips : 

• Practice, practice, practice - Running a meeting or chairing a committee takes work and practice. (Don't worry - Everyone eventually learns this skill!)
• Learn from other Clinical Leaders - What worked? What didn't?
• Remember the future of healthcare is shared governance - Healthcare is a team sport - You can learn a lot from your fellow nursing, physician, pharmacy, or other clinical leaders!
• Keep reading and keep learning!

Always keep in mind that good, well-planned, productive meetings that give everyone confidence and clarity might take some work and planning - but they are completely achievable!

Remember this blog is for education and discussion purposes - Your mileage may vary!

Have any good tips or tricks to share with clinical leaders, for creating good committees or running good meetings? Feel free to share them in the comments section below!

What can Cardiac Myocytes teach us about Teamwork and Workflow?

Hi fellow CMIOs, CNIOs, and other #HealthIT and Applied Clinical #Informatics friends,

Today's post is short, but one that I think most clinical friends will understand and appreciate. For conceptual teaching purposes only, I'm going to ask the question : 

"Q : What can Cardiac Myocytes teach us 

about Teamwork and Workflow Design?"

Here's my theory : Clinicians may actually have an advantage here. If you've ever studied the human heart - it's anatomy, it's functions, its biology, and its electrophysiology - You already know a lot about teamwork, workflow design, clinical operations, and essentially how to get things done. 

After all, cardiac myocytes and humans (clinical leaders and team members) both work towards a common goal. We both can function as individual units, but we function even better together as a well-organized, well-synchronized team : 

[ DRAFT ] TABLE - A tongue-in-cheek but honest comparison of Myocytes with Humans (Clinicians)

Let's face it, healthcare is a team sport. So when I'm working with other clinical leaders, especially new ones - For support, I often remind them of the importance of the infrastructure and tools that, especially as clinicians, we sometimes take for granted - Good : 

• Regulations (both Federal and State)
• Governance (e.g. Committee structures)
• Leadership
• Direction
• Management
• Communication
• Bylaws
• Policies/Procedures
• Training / Onboarding
• Continuing Education
• Offboarding
• Teamwork

After all, when growing a plant - it's not just the seeds you need to worry about, it's also the soil. So without enough of this 'supporting soil' (the tools above) in place, it becomes very easy to run into problems growing the seeds - And so for end-users, managers, directors, leaders, and executives alike, this can sometimes result in loss of efficiency, frustration, disorganized workflows, problems not getting solved in a timely basis, etc.

Typically, these tools don't get enough attention from new clinical leaders, because until they are in a leadership position - their focus has largely been on 'clinical things' like working with patients, diagnosing and treating diseases, performing operations and procedures, etc. While those are all the reasons we are in healthcare, it's still important to understand the many 'non-clinical' tools that make those things happen. (In truth, those tools are just as clinical as penicillin - But due to time constraints, they usually don't teach much about them in medical schools.)

What I find especially interesting is that, as a physician who during my career has treated cardiac tachyarrhythmias at the bedside (using beta-blockers, calcium-channel blockers, adenosine, cardioversion, etc.) - There are often similar analogous ways to treat these same 'human tachyarrhythmia' problems on project teams : 

So when I have the opportunity to teach a new clinical leader about how to solve problems and function in teams, I simply remind them that modern human biology has evolved over thousands of years to solve these same sorts of problems that we experience in healthcare today - And so sometimes, looking inward with a microscope is just as helpful as looking outward with a telescope. 

Finally, one of my clinical informatics colleagues and good friend Stefanie Shimko-Lin, BSN RN CD-L CD-PIC FHIMSS once shared this cardiac analogy with me : "Collateral circulation is a workaround, that happens when the desired workflow doesn't work. If you make it easy to do the right thing, people will do it."

These analogies may all seem a bit peculiar and tongue-and-cheek, but if you're a clinical leader - I hope this blog post helps to spark helpful discussion and learning with your own clinical leadership and project teams, so that you can better solve the workflow and operational issues you might encounter in your daily clinical routines.

Remember, this blog is for educational and discussion purposes only - Your mileage may vary! Have any other helpful analogies or advice for new clinical leaders? Feel free to share them in the comments section below!

Advice from a Wise Business Leader

Hi fellow CMIOs, CNIOs, and other #Informatics and #HealthIT friends,

A brief pause from Applied Clinical Informatics, just for a moment. 

Today's post is related to some helpful business ethics advice I once received from a wise and successful businessman my mother used to work for. His name was James ('Jim') Everett Robison (11/22/1915 - 2/21/1998), and he was a very successful businessman and Harvard Business School graduate who, in addition to having a wonderful and loving family, also counted Roy Little and Thomas J. Watson, Jr. as some of his business associates and friends.

(L) James E. Robison as an Air Force pilot circa 1940s, and (R) as a successful business leader circa 1990s.

A retired and decorated WWII Air Force Major (who flew 63 completed missions, 402 combat hours, 26 squadron leads, 7 group leads, and 1 wing lead!), Jim Robison lived and breathed integrity.

Growing up, I would run into Mr. Robison occasionally, while my mother was working for him in Armonk, NY back in the 1980s and 1990s. During one of my visits to my mother's workplace, he shared a message with me - one that he apparently also shared with many other people - about the importance of honesty, integrity, and ethics in business.

His message was once captured beautifully by his good friend Charles Osgood, who shared it in his November 24th, 1992 Osgood File message. 

The message is still so important and relevant, that I think it bears repeating today. Transcribed from an old cassette tape I found in my attic, here it is : 

TRANSCRIPT :

Charles Osgood

CBS 880 AM Radio 11-24-1992

[ Start of Transcript ]

The Osgood File, sponsored in part by ______ Heating and Cooling. I'm Charles Osgood.

Last night at the University Club in New York, I attended a reunion dinner of sixty (60) people who used to work for the same company my late father did. There were books of pictures, and in some of them I could hardly recognize dad because he was so much younger then, than I am now. It made me feel like Michael J. Fox in "Back to the Future".

And amongst the memorabilia I found something that impressed me so much, I wanted to share it with you, which I will do, in a moment. Stand by.

My father was in the textile business. His boss, at a company called Indianhead Mills, was a dynamic young man by the name of Jim Robison. Dad thought the world of Jim, not only because he was so smart and so successful, but also because he was such a straight shooter. Robison never wanted to outdo or get the better of anybody in a business deal. If both parties didn't benefit from the deal, he didn't want to do it.

My dad died several years ago, but last night I was invited to a reunion of Indianhead people, some of them I hadn't seen since I was a kid. Jim Robison was there, retired now and no longer a young man, but still sharp as ever. And looking through some materials they had there, I came on a company policy statement that he had issued 40 years ago. And I took a copy of it because I wanted to share it with you this morning. Here's what it said :

"There is one basic policy, to which there will never be an exception made by anyone, anywhere, in any activity owned and operated by Indianhead. That policy is as follows," Jim Robinson wrote. "Play it straight, whether in contact with the public, stockholders, customers, suppliers, employees, or any other individuals or groups. The only right way to deal with people is forthrightly and honestly. If any mistakes are made, admit them and correct them. Our commitments will be honored, and we have a right to expect the same performance from those people with whom we do business.

This is fundamental. We will not welch, weasel, chisel, or cheat. We will not be a party to any untruths, half-truths, or unfair distortions. Life is too short.

It is perfectly possible to make a decent living without any compromise with integrity."

I think I'm going to frame that and put it on the wall.

The Osgood File, Charles Osgood on the CBS Radio Network.

[ End of Transcript ]

I agree with Charles Osgood - I think I'm going to frame that and put it on the wall.

I hope this timeless message inspires you too!

Remember, this blog is for informational and educational purposes only - Your mileage may vary! Have any experience with studying business ethics? Please feel free to share in the comments below!

How I Became a 'Document Whisperer'

Hi fellow CMIOs, CNIOs, and other Applied Clinical #Informatics and #HealthIT friends,

I'm writing today to share some stories from my career path in Applied Clinical Informatics, and how I became a 'document whisperer' with regard to clinical workflow design. This post stems from a common question I get asked: 

'If you care so much about clinical workflows - Then why do you seem to care so much about bylaws, policies, procedures, guidelines, protocols, bylaws, charters, order sets, and other documents? Why don't you just worry about the things inside the EMR?' 

The reason is because all of these documents (whether they are inside or outside an EMR) work together to shape clinical workflow. 

To explain, I need to first offer some context. 

Back in 2007 when I first started my formal clinical informatics career, like most newcomers, I didn't yet have enough experience to fully understand my role. I figured my job was to 'help with the electronic medical record', so naturally, I focused mainly on the things that doctors interacted with inside the EMR. 

After a while, however, I started to see challenges we had with some of our projects. There were order sets that, after we built them, didn't get used. There were order sets that created turbulence with other workflows when we rolled them out. I received complaints from doctors who felt the computer was 'too clunky' and that 'it takes too long to get things done'. 

Initially, I wondered if this was simply a matter of an EMR just being more difficult to use. There were some people who told me, 'Oh, some doctors are just resistant to change' (which is partly true), and others who told me, 'Computers are just complicated and finicky' (which can also sometimes be true).

But I kept looking for a better answer - There must be some sort of symmetry here that I was missing. 

And then, over the next 2-3 years, I experienced two important things : 

1. I once worked on a complex titration protocol, which required an extensive analysis to fully build out the protocol, and...
2. One day, a Registered Nurse complained to me about a policy that would need to be updated, in conjunction with a project we were actively working on.

So it was while confronting the question of 'How exactly do you write a protocol?' that I started to really confront the question : "What exactly is a protocol?" This led to even more questions, like : 

Trying to find more concrete answers, I looked to various potential sources, including various regulations, the International Standards Organization (ISO), the National Institute of Standards and Technology (NIST), the CMS web site, various HealthIT/Informatics societies, ITIL, and even Black's Law Dictionary, without much help. 

So around 2010, I decided to look at this from a more analytical, design-thinking standpoint : 

"If we gathered every document in healthcare, both those sitting on desks and on hard-drives - what would they be, and what would they look like?"

This led me to scribbling down some commonly-used words people use in healthcare, putting them into a spreadsheet, and in 2010 I came up with my first CMIO's Checklist : 

[ FIRST DRAFT ] Note : My workflow definitions have evolved since this 2010 version.

[ FIRST DRAFT ] Note : My workflow definitions have evolved since this 2010 version.

... which turned out to be my first real foray into clearly-defined terms, tools, and functions. Yes, a sample size of one - based only on my own clinical and administrative experiences - but a fairly comprehensive function-based analysis, nonetheless, that helps to clarify concepts and increase shared understanding.

(What good, functional, policy-grade definitions do to clarify concepts

and increase shared understanding - Hit PLAY to see animation)

Now with this new function-based analysis in hand, I stumbled into two interesting [DRAFT] functional definitions : 

Template (n.) - A tool used to standardize and expedite the creation of a document. 

... and ...

Document (n.) - A tool used to record and transmit information.

... both of which shed light on an important concept - For many of you, this may be common-sense or trivial, but for me it was a 'eureka' moment : 

• Definitions can be used to create templates.
• Templates can be used to create documents.
• Documents can be used to store and transmit the information needed to support workflows.

So around 2015, this led me to the realization that these concepts all depend on each other. And so, realizing that workflow inconsistencies sometimes arise from misalignment of these concepts, I wrote this blog post about workflow management and the Clinical Informatics domain : 

[ SCREENSHOT ] From Informatics Domain and Workflow Management, 2015

 

This also led me to the realization that all of the documents and tools contained in drawer #4 above :

• needed to be aligned with the workflows, goals, and mission above it, and... 
• were shaped by the concepts contained in #5, #6, #7, and #8 below it. 

It also revealed to me that some of the documents and tools that support workflows are typically contained inside the EMR, and others were contained outside the EMR : 

So now being able to mentally visualize this conceptual structure (above), I also realized that : 

• Workflow depends on all of these tools (above) for support. 
• Changing workflow means changing all of the tools (both inside and outside the EMR) that are used to support the workflow.

... and so effective workflow change management means : 

1. Clearly understanding each deliverable (tool) above.
2. Identifying the deliverables (both inside and outside the EMR) that are needed (or need to change) to support the desired workflow. 
3. Quickly drafting those deliverables, to demonstrate to users and HealthIT professionals how the deliverables need to fit together,
4. Reviewing those draft deliverables with clinical stakeholders, to confirm their needs/expectations before committing them to a formal build, and to help get their input and align expectations.

So to help quickly draft the deliverables in step #3 above, I had to quickly make templates for these roughly 24 documents that we commonly use in healthcare. And this brought me back to my pursuit for high-quality, high-grade definitions so that my workflow templates were quick, easy-to-use, and maybe most important - functionally sound. 

And this is essentially how I became a document whisperer for good clinical workflow design and EMR support. Using this deeper understanding of how these common concepts are related has helped me to quickly draft the 'workflow blueprints' that help to outline workflows, identify deliverables, identify stakeholders, create clarity, develop understanding, and align expectations before beginning a project. (This understanding has proven especially useful when scoping/analyzing clinical project requests prior to approval.)

 

I hope sharing this journey helps give you a roadmap for your own journey, and helps you develop your own definitions, templates, and tools for rapid workflow analysis and scoping before undertaking any significant projects. 

Remember this blog is for educational purposes only - Your mileage may vary. Have any anecdotes or stories to share about workflow analysis or development? Feel free to leave them in the comments section below!

A Tale of Applied Clinical #Informatics, in Four Parts

Hi fellow CMIOs, CNIOs, #HealthIT, and other Applied Clinical #Informatics friends,

Today I'm writing today to share a tale of Applied Clinical #Informatics, in four parts. (Or, "Why workflow analysis, naming conventions, indexing, and usability all really do matter.")

Feel free to leave comments at the end - Hope you enjoy it!

1. PART ONE - 

"I'm sorry, I don't have time to talk about workflow analysis, naming conventions, indexing, or usability - just give me everything I need in one place, and quick!!"

2. PART TWO - 

"Wait, that's not right, I can't use that. I still don't have time to talk about any of that workflow or usability stuff, but can you just put everything I need in one place so I can see it all and easily access everything I need with just one click?"

3. PART THREE - 

"Wait, that still doesn't look right, and I'm afraid I'm going to be scrolling forever. I still don't have the time to meet, but I heard there's some tool they use at another organization - Can you just find out what tool they use to do this, and then just put my stuff into whatever tool they use?"

4. PART FOUR - 

"OK, wait... I think I see the problem. Let's make some time to talk about workflow, including exactly what these tools do - Both what I use them for, and when I use them. Then let's talk about the naming conventions and indexing for each tool, so they all have a standard look and feel. Then let's talk about usability, so that I keep the most commonly-needed tools in one place, and the less common tools in a separate but nearby place. And then finally after you build it - I'll help test it to make sure it's both functional (what-we-need) and also easy-to-use."

"Eureka - That's it!" 

[ THE END ] 

Remember, this blog is for educational/discussion purposes only - Your mileage may vary. Have a good teaching example you'd like to share? Feel free to leave in the comments section below!