Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Due to heavy attrition rate my project team usually get new developers at various stages of the projects and sometimes even in the maintenance phase.
We are currently following an informal way of knowledge transfer and it differs from person to person and team to team. Now we are planning to build a formal process for knowledge transfer with sufficient documents and information.
I would like to get your expert opinion on this.
Some time ago we had the same discussion in our organization. The knowledge was unevenly available among the team members. Senior personnel would hold the majority of the knowledge for obvious reasons (they have been there longer than you and know the historic issues and/or background of that area) whereas new personnel would struggle to assimilate such amount of information to step up and execute their roles efficiently.
We decided to introduce the Knowledge Management concept into our department to manage all relevant information and make it available to all our personnel (new and existing).
Knowledge management is essentially about getting the right knowledge to the right person at the right time.
Within broad field we have been working specifically on Knowledge Sharing (on which we also included Knowledge Transfer)
Knowledge sharing is therefore perhaps the single most important aspect in this process, since the vast majority of KM initiatives depend upon it. Knowledge sharing can be described as either push or pull. The latter is when the knowledge worker actively seeks out knowledge sources (e.g. library search, seeking out an expert, collaborating with a coworker etc.), while knowledge push is when knowledge is "pushed onto" the user (e.g. newsletters, unsolicited publications, etc).
In our situation the first initiative led us to the creation of a central location to store all the available information (already created or updated by team members) using SharePoint 2010. We structured the Team Site in multiple Site Centres depending on the business area covered and subsequently by Document Libraries.
Furthermore, several logs were created to allow users (team members) to record their issues and update them with their findings and experience. This would allow other visitors to scan through for similar issues and learn from the experience, reducing timing and duplication of efforts.
The site includes sections for links to affiliate sites or online training (specially for material that's managed by a third party).
This is a framework that is producing satisfactory results in our department. However, this is only one example of tons of available options. I would recommend investing some time researching your target so you can decide which strategy, processes and framework work best for your organization.
Have a go to this site to gather a bit of information regarding Knowledge Management. I'm quite positive that it will provide you with some tips to improve this process in your organization.
Any documentation you create will probably become out-of-date. The harder it is to write the documentation, the more likely this is.
Lightweight ways of documenting projects will have the highest chance of being updated. I've found that wikis are a great way of keeping anything that can't be kept in code.
Otherwise, consider using the code itself as documentation. Well-written unit tests, BDD-style scenarios and self-commenting code are all great ways of ensuring that the purpose, value and behavior of code is well-understood.
I recommend that the devs should particularly be familiar with refactoring techniques (read Martin Fowler's "Refactoring") and unit testing (read Dan North's "Introducing BDD" which talks about how to do BDD well at a unit level).
Aside from that, the best way to deal with the knowledge leaving is to work out why you've got a heavy attrition rate and sort that out. If your developers are leaving in droves then it's likely that you've got processes or an environment which are making it hard to get their work done, and which may also make the advice I've given above hard to implement.
You state you have heavy attrition, which is never a good thing. In particular it will mean that you will have very few, if any, subject matter experts (SMEs) with years of experience. Many would argue that it takes 10,000 hours to get really good at something.
Anyway your organization is what it is, so what you want to look for is best practices for knowledge transfer in organizations with high turnover, which is not the same as organizations with lots of senior people. Perhaps the absolute best organization at training people that will only be with them for a short time is the military. Think about it, who else can take someone 18 years old and within one year trust them with nuclear weapons?
This is much different than the medical profession where a surgeon will spend five years as a resident in training after medical school and an internship before becoming fully qualified.
The military needs to focus on the essentials and clear communication in writing while the medical profession can spend much more time on mentoring and experiential learning. In your origination with high turnover you can not afford to have your best people spending hundreds of hours mentoring someone who is going to leave within a few weeks or months.
You should focus on using as many external training resources as possible, many of which are free or low cost on line, to train things that are not unique to your firm (good coding practices, security, database design etc.) while your internal documentation should be in writing (used loosely to include PowerPoints etc, any re-usable asset) an along the lines of an Army training manual. That way you can hand your manual to a new hire and not take the time of your most senior people to do one on one training.
There are a few main issues that need consideration:
Knowledge transfer:
Since you have a lot of departures, have each departing team member spend his last month training an existing team member (not a new one) with his core knowledge.
The trainee should document the training for future reference for others.
Any new assignments during this final period should be done in a pair with someone.
Training:
Since your teams absorb a lot of new member, you will want them to assimilate quickly, therefore, you should invest in mandatory professional courses for new employees. These can either be from external training companies or from a training department.
Maintainable products:
a. Make sure you product can be divided to independent components that can be developed and tested separately (e.g. for software use inversion of control and dependency injection wherever applicable).
b. Make sure your products are developed with full automated tests
(e.g. unit tests, integration tests, system tests and acceptance tests for software or electronics).
These will enable maintenance with minimal unexpected breaking of old features.
Moral:
Since your team structure fluxuates a lot, you should consider providing frequent off-site team activities to help unite the team and keep the spirits up. After all, team work is critical to success.
Besides theses you should find ways to improve your attrition rate, but that is the topic for another question.
In our organization, we have training departments whose job it is to transfer knowledge to new team members. They don't limit themselves to just one form of communication medium.
We employ a mixture of one-on-one training or group training, which can be conducted either on site or through video calling tools such as Google Hangouts or Skype.
In addition, we've created hosted video tutorials, which we follow up with quizzes to help the employee test their knowledge. The quizzes give the employee the opportunity to go back into the video and review anything he or she may have missed, and they also give our trainers feedback in regards to who may need more individual coaching or mentoring. The training videos are put together using open source desktop recording software such as CamStudio.
Finally, we host the videos in a Google Site or MediaWiki, depending on departmental choice. The former is obviously much easier to setup, as it only requires a Google Account. Organizations using Google Apps for Your Domain can easily share Google products with members of their organization using Google accounts but with administration roles delegated within the organization.
The videos hosted on the Google Site are generally supplemented with documentation, step-by-step instructions, and much more detailed information that one might find useful.
Our goal is to not only provide our employees with a way to obtain knowledge, but also to ensure that the knowledge is transferred using the method that will maximize knowledge acquisition in a manner that is fun and interesting and that also acknowledges the fact that not everyone learns the same way.
Developers typically go through different classes with different senior developers where they work on smaller projects until the senior developers feel they're ready to take on more responsibility and work more independently.
The key though is to create a work environment that reduces the amount of turnover. Without a great work environment, it will be difficult to attract and keep good people. My suggestion is to also spend some time trying to determine why people are leaving. Patching the hole in the bottom of the boat may yield the best results for your particular situation.
