Bridging the Knowledge Gap in Projects

Question

So far we've been very comfortable managing projects that have similar technical characteristics with our past projects. For instance we choose to get involved in python-based web application development because we have some Ruby and Java web based application on our hands. It is definitely easier compared to tackling an ERP implementation, because we haven't done an ERP implementation before.

However, we have to admit that getting our heads around the different problem domain in Python is a bit different compare to Java or Ruby. In our project we are working under the assumption (which 90% of the time holds) that the organization provides a team lead/architect who has enough experience in building the application and the ability to set the technical foundation upon which the team to work. The team lead/architect acts as our deputy to translate the technical jargon or concepts from the developer to the PM team.

We do note that this arrangement is often far from perfect. Technology develops in a pace with which no one person can cope. We often do our own networking exercise, getting acquainted with experts inside or outside the project/company who we can ask for help if we stumble across a problem in our project that our own people can't solve.

We just want to know of any other techniques that other PMs in this community use to bridge knowledge gaps within the team they they are leading.

Answer 1

Good point from Steve about bringing right people in. For me it is one of the many parts you need to provide:

1. Knowledge. You can bring right people to a project in order to bring knowledge with them, but you may also cover the gaps with on-line resources, books or forums. For any given technology - which is popular enough - you shall find plenty of helpful resources.

2. Time. Although one can hire the lead architect with all the knowledge, she alone will not be able to make all the work done. One must mind the learning curve and the time needed to learn. With enough time given, the team can train, prototype, refactor and improve the architecture. Time often plays important role in projects and it is not only my experience.

3. The right people. This time it is not about the knowledge. You will probably need explorers and leaders. Most of the people do not like leaving their comfort zone. Working with technology they are not familiar with, is surely out of one's comfort zone. Explorers are ones who like to work on such projects and thrive in such environment. They will probably do most of the research work so others can easily follow. You also need leaders to overcome some harder obstacles. In such cases a team tends to loose enthusiasm and they need someone to push harder and say they surely can do it, someone who praises achievements and diminish failures.

4. Transparency. It may be an agile process or a proper risk assessment. The most important is to be aware of the project's status at any given moment. It gives you ability to react in time and keep the project on track.

Answer 2

Bring in the right people to bridge the gap. If your organization lacks capability in a certain domain then I would recommend bringing in someone who has already done what you want to do.

If you are looking at longer time frame then I would also suggest looking at some of the literature on product development and product management for lessons on increasing your organization's capabilities. I found 'Making Innovation Work', M. Epstein and 'Winning at New Products', R. Cooper to be helpful for this.

Answer 3

Gaps in knowledge, and other capabilities, will always exist in every project you ever pursue. Finding the right people to close your gaps is an ideal solution; however, what "right" means is kind of ambiguous and can mean different things to different people. It is more of degrees of right than something that is absolute. The performance curve says most of your team, and those you are selecting to join your team, will be severely average. Thus, you will simply have performance capability gaps no matter your best selection efforts.

Knowledge gaps are an area of uncertainty. Your risk management process is the right tool with which to cope. Identify those gaps, understand the drivers and areas of potential impact, prioritize the gaps in order of threat, and mitigate where you can. It might be to continue to search for a specific expertise in a high threat area and be ready to pay for him/her, fund knowledge acquisition for your existing talent, or have a back up plan, funded by your contingencies, if the solution created fails.

Mitigation of these gaps also includes the planning stages of the work. If it is in an area where you have known knowledge threats, put your target schedule and budget further out on your probabilistic estimates such that you provide more runway for your existing team to figure things out. For example, you may typically baseline the 65th percentile for normal project work where your knowledge threat is low or normal; however, in a high threat area, you may baseline the 80th to even the 90th percentile. This simply means you have more time and budget to design, build, test, design again, build again, test again, etc., to you and your team "learn."

Closing these gaps 100% is futile and holding out for the "right" people will mean your project will never start. We simply work with constrained resources and that is project management.