Teaching Junior Engineers How to Author Requirements: A Guide to Knowledge Transfer
INTRODUCTION
It’s important to learn from our mistakes, but even more valuable to learn from the mistakes of others. In many cases, best practices develop from what industries or organizations learn from these mistakes.
Transferring knowledge from seasoned requirements engineers to junior requirements engineers can be a challenge for many reasons. Documentation cannot capture the finer details, and even then becomes outdated quickly.
Engineers come and go, along with their knowledge. Some folks are better teachers than others – and some better learners than others. Without effective knowledge transfer, you risk the loss of important organizational knowledge and the associated competitive advantage.
WHY KNOWLEDGE TRANSFER IS IMPORTANT
In today’s knowledge economy, a company’s most valuable assets are not usually physical assets. Rather, its competitive advantage lies in the ideas and knowledge that reside in its people.
Yet, this new economy also consists of employees who are more mobile than in the past and who often do not stay with the same employer for their entire career. Combine all of this with the possibility of an expanding company and new employees joining, and it is clear why knowledge retention and knowledge transfer are important.
Knowledge transfer should not be left to chance. It must be planned and will include more than one of these methods to form a comprehensive strategy.
At first glance, it can seem to be a waste of time, both from the company’s standpoint and in the minds of those who must take time out of their schedules to pass on the knowledge.
Some may even keep their knowledge held closely in an attempt to make themselves indispensable. Managers might find it necessary to include knowledge transfer duties in their team’s performance goals and expectations.
When most people think about knowledge transfer and training, they think about the experienced engineers who have been battle-tested and pass on their hard-earned knowledge to the engineers fresh out of school. This is frequently the case.
Remember, too, though that everyone has something to share. Even junior engineers bring a fresh perspective to share with senior engineers.
OUTSOURCE CAREFULLY
It can be tempting to solve the problem of a heavy workload by outsourcing, and outsourcing certainly has a place. However, it is important to consciously decide which tasks can be done by anyone and which are competitive advantages or are much more efficient if done in house.
Make this a part of your knowledge retention strategy. Do not let a third party be the only one who knows how to perform your organization’s core functions.
WRITTEN PROCESSES AND DOCUMENTATION
A common initial reaction to the concept of knowledge transfer is to write it down. Some knowledge does lend itself to being written down or turned into processes.
Generating documentation gives you a standard, repeatable process that can ensure your processes do not fall apart when a key person leaves. The downside is that it can be difficult to transmit finer details, experience, and the nuance of the skills necessary to be successful.
Written documentation is most useful for process requirements, for example:
- All requirements must be written in the EARS format in Microsoft Word, using QVscribe.
- Before finalizing any requirements document, it must be reviewed by a requirements engineer senior to the primary author.
These types of process requirements, while seemingly simple, can be important to the organization by ensuring that key steps are consistently applied.
Companies that rely on documentation for knowledge retention and transfer must keep in mind the challenge of maintaining the documentation and updating it when new knowledge is gained and best practices change. In most cases, someone must be assigned this responsibility.
Ideally, each document will have an owner named who must revalidate the document regularly. Most organizations will balk at the resources and cost it takes to keep documents current, so it is best to minimize reliance on written documentation except for core processes.
LIVE DOCUMENTATION SYSTEMS
Knowledge capture systems can be helpful. An internal wiki system can be a great way to document knowledge and allow others to learn from it.