# Presentation: 219331

## caBIGTM Mentoring

***2007 Annual Meeting******Panel Session***

- Jessica Bondy – University of ColoradoPaul Courtney – Dartmouth UniversityLeslie Derr – NCICBSalvatore Mungal - Duke University Dianne Reeves – NCICB
**February 2007**

## Session Objectives

**Define and describe mentoring**** **
**Review alternatives to mentoring**** **
**Review the successes of caBIGTM mentoring programs to date**** **
**Explore future possibilities for mentoring in caBIGTM **** **
**Solicit feedback and ideas from the audience   **** **

**Notes:**
Slide Owner:  Leslie Derr

## Mentoring: A Working Definition

**Mentoring:  ****To serve as a trusted counselor or teacher to another person, especially in occupational settings****A developmental relationship between a more experienced advisor and a less experienced partner**
**Common Theme: ****A one-on-one relationship that is sustained over a period of time, and which focuses on a specific domain of interest**

**Notes:**
Slide Owner: Dianne Reeves

## Characteristics of Mentoring

**Allows more senior and/or more knowledgeable or experienced people to assist those newer to tools, skills or content**** **
**Most effective as work unfolds, with interventions that focus on real needs and applications**** **
**Effective when information is highly complex, or performance success is based on a number of variables **
**Decentralization of mentoring distributes the learning process through the system or organization**
**Given intensity of relationship, each learner likely to become accountable for his/her own learning **

**Notes:**
Slide Owner: Dianne Reeves

## Limits of Mentoring

**Mentoring *****does not scale well*****; one individual or perhaps a small team demands the focus of one mentor and some lessons must be repeated for each learner or group of learners**
**Mentoring is dependent upon both the *****technical***** and *****interpersonal***** skills of the mentor, so the lessons delivered are only as good as the mentors delivering the content**
***Decentralization***** of the teaching means that the content may vary from place to place – mentor to mentor – and diffusion of new insights is difficult throughout the system**
**Requires a *****time commitment***** from both mentor and mentee**
**Requires *****careful scoping***** to ensure that limits and focus are clearly understood **

**Notes:**
Slide Owner: Paul Courtney

## Alternatives to Mentoring

**Mentoring should be reserved for those situations where one on one human interactions are required to enable the mentee(s) to become self-sufficient in obtaining help using less resource-intensive methods.  Alternatives that can deliver standardized knowledge include: ****Orientation Meetings**
**	**
**	****Group Training or Boot Camps (Online or Classroom)**
**	****Community Bulletin Boards (e.g., Listservs) **
**	****Help Guides, Tutorials, and Demonstrations ****Best Practice & Lesson Learned Documents**

**Notes:**
Slide Owner: Paul Courtney

## Mentoring Successes in caBIGTM

**Two formal mentoring programs exist in caBIGTM:   **
- Vocabulary and Common Data Elements (VCDE)/Architecture**Mission:  Ensure that each caBIGTM software development project develops software in a  SEMANTICALLY (VCDE) and SYNTACTICALY (Architecture), caBIG-compatible manner.  By ensuring that domain models are annotated and exposed in a caBIGTM compatible manner, the resulting Software application will achieve interoperability with other caBIGTM applications. **** **** **
- Documentation and Training (D&T) **Mentors are available to provide one-on-one support to those responsible for creating documentation and training for caBIGTM projects.   **
**Informal mentoring relationships within the caBIGTM community have evolved naturally – these are not centrally managed**

**Notes:**
Slide Owner:  Sal Mungal

## More About VCDE/Arch Mentoring

**caBIGTM software development projects are assigned mentors at the beginning of the development life cycle; they provide support and reviews for each major deliverable **** **
**The VCDE and Architecture workspaces have created a robust Standard Operating Procedure (SOP) and review checklists for mentors to use**** **
**The workspaces conducts frequent training sessions to share lessons learned and train new mentors**

**Notes:**
Slide Owner:  Sal Mungal

caBIGTM software development projects are assigned to VCDE/Arch mentors at the beginning of the development life cycle; they provide support and reviews for each major deliverable such as:
Software Requirements document
Object Model or UML diagram
Design document
Use Case document (to name a few)

The VCDE/Arch workspaces have created robust Standard Operating Procedures (SOPs) and review checklists for mentors to use
There are existing checklist VCDE and Architecture mentors
SOPs are currently being written for mentoring and reviewing projects within Architecture and VCDE

The workspaces conducts frequent training sessions to share lessons learned and indoctrinate new mentors

Courseware is also currently being developed for the silver level reviews

## VCDE/Arch Mentoring Details

**The VCDE/Arch workspaces have created a mentor guide’s group to conduct informal training sessions to share lessons learned and train new mentors**
- The mentors are fully versed in the training materials for developers that are on line and have all seen a full life cycle of development in caBIG including the compatibility review process. The same is true for the mentor guides.
- The mentor guide’s group (mentor/guides of the mentors) meet twice a month
- They share their experiences of all of the new issues with their mentors
- They post their issues and solutions to a GForge site
- They share their knowledge with their assigned mentors
- Courseware is also currently being developed for the silver level reviews
**This mentoring process is centrally coordinated and managed by the VCDE and Architecture lead workspace leads**
**Mentoring activities are compensated under workspace participant Statements of Work**

**Notes:**
Slide Owner:  Sal Mungal

## More About D&T Mentoring

**D&T Mentors for specific projects are assigned by D&T workspace lead.  The Mentoring Special Interest Group (SIG), led by Dianne Reeves, leads mentoring capability development. **
**Only two projects have formally requested Documentation and Training mentors.  We hypothesize that the common usage of documentation tools outside caBIGTM, and the availability of caBIGTM templates and guides reduces the need for D&T mentors.**
**The Mentor SIG has developed tools to support other mentoring efforts, including a template mentor evaluation form and proposed mentoring metrics.**
**Like VCDE/Arch, D&T mentoring activities are centrally managed, with mentors compensated through workspace participation.**

**Notes:**
Slide Owner: Dianne Reeves

## Lessons from Interviews with caBIGTM Mentors

**As part of the “caBIGTM Mentoring Capability Plan” current mentors were interviewed.  Lessons learned include:**** **
- Mentoring and compatibility reviews require substantial time, and needs vary widely, based on project complexity and the developers’ and mentor’s experience and background.  Estimates varied from 6-8 hours to 30-60 hours per project.
- Mentoring becomes more efficient over time, and is impacted by the availability of reusable information and the mentor’s learning curve.
- Mentoring is most effective when it begins early in the development process, but early involvement also requires more time from mentor.
- Mentors need train-the-trainer education in the specific topic being taught. Tacit knowledge is not enough – other training and resources are needed.
- Mentoring should be rigorously supplemented by the resources and manpower needed to develop training materials – training development requires investment, but is ultimately more cost-effective than mentoring.

**Notes:**
Slide Owner: Jessica Bondy
Recognizing the importance of mentoring to the ultimate success of caBIG, last spring the Strategic Planning Committee asked that a Mentoring Capability White Paper be undertaken to examine mentoring activities to date and propose possible structure going forward.

As part of developing the White Paper, we interviewed nine veteran mentors to learn about their experiences and to hear their suggestions about how the mentoring process could be improved.  

This slide captures the lessons learned from those interviews.  As I go through these, I’ll also mention the activities already in place to address the issues that have been raised.

Mentoring and performing compatibility reviews require substantial time.  Needs vary widely – as much as ten-fold -- based on the complexity of project, the experience of the developers and mentor, and the developers’ readiness to embrace semantic interoperability.  

Mentoring has become more efficient over time, owing to several developments.  Early in the pilot, everyone -- mentors and developers alike -- was learning on the job.  
	-  Vocabulary tools were not yet stable, and 
	-  the VCDE workspace had not yet developed standard processes and procedures for performing compatibility reviews.  
Clearly defining these standard processes and procedures was cited by several mentors as critical to helping them perform their role efficiently.  Until it was decided what items would be reviewed, how each item would be interpreted, and how important each item was, it was difficult for mentors to provide sound advice.  

Mentors need to be involved early in the development process. In the early phases of caBIGTM, mentors were involved at the point of compatibility review, which sometimes led to inefficiencies because projects were required to rework their code.  As a result, VCDE mentors are now 
	- being assigned as soon as possible once a project gets underway, 
	- being required to sign off on many of the deliverables along the way, and 
	- attending face to face meetings between developers and adopters as well as project teleconferences.  
While most mentors interviewed felt that early involvement would improve the process, some noted that it would require more time from mentors.  Requiring mentors to sign off on deliverables was cited as particularly time-consuming.

Mentors/reviewers would benefit from more training.  Some mentors felt that they were hampered in their mentoring by a lack of training in how to conduct a compatibility review.  
	- Such training is now becoming available at some face to face meetings and 
	- It may also comprise one or two future modules in the caCORE or caBIGTM curricula  
	- A “recipe” document is planned, which will lay out the step-by-step process for performing a review.  
The mentors felt that comparable training and documentation should be developed for reviews in other areas in which mentoring is to occur, e.g. architecture.  
Although D&T mentors were not interviewed, it should be noted that this workspace has developed criteria for reviewing documentation and training materials and has conducted two successful boot camps on how to review and mentor these topics.

Mentoring / reviewing could be streamlined by off-loading some topics to other information-transfer approaches.  For instance, developers should be required to take the caCORE curriculum and to read the SDK manual so mentors do not need to teach that material.  The caCORE curriculum is now being offered asynchronously so that people can take it when they are engaged in the work. 

In conclusion, 
mentoring in any technical topic area will benefit from first developing standard processes for the topic being mentored.  
Documentation and training should be developed based on those standard processes as soon as possible 
Mentors should refer learners to these other modalities whenever feasible and should use them to provide targeted guidance
As new topics are encountered, it is reasonable to expect mentoring to undergo a bootstrapping phase, such as was experienced by the VCDE workspace.  But understanding the importance of standard processes, documentation, and training should limit the length of that phase.

## Potential Use Scenarios for Mentoring

**The “caBIGTM Mentoring Capability Plan”  considered four use scenarios**
- Funded developers:  organizations with funded caBIGTM development responsibilities.
- Unfunded developers: organizations with existing applications which they wish to make caBIGTM compatible.
- Unfunded adopters: organizations interested in adopting a particular caBIGTM tool
- “Interested parties”: organizations interested in caBIGTM but not yet sure which caBIGTM tools are appropriate for their environment.

**Notes:**
Slide Owner: Jessica Bondy

So that was our review of previous activities. Going forward, The white paper considered four use scenarios for which mentoring might be appropriate.  They are listed here.

Funded developer
For the most part, mentors have so far been assigned to funded developers.  We expect this need to continue.  Funded developers need mentoring in technical subjects such as vocabulary and architecture. I’ll talk more about topics on the next slide.

Unfunded developer seeking to make applications or databases meet compatibility standards
These organizations will, like funded developers, need access to vocabulary and architecture expertise.  In the past, at least one unfunded developer has received mentoring help from the VCDE workspace. This need might continue to be addressed through mentoring or possibly by a service center.

Unfunded adopter
Some organizations interested in adopting a particular caBIGTM tool will require technical help in the details of how to install it and get it working or in understanding the subtleties of how it works.  Much of this need should be addressed by the documentation and training materials developed for the tool, but in some cases, may need help getting “over the hump”. This scenario may be handled by the Enterprise Adopter program, which will be discussed later by Leslie.

5.4 Interested Party
Some organizations will be interested in caBIGTM but will not yet have identified which caBIGTM tools are appropriate for their environment.  The conclusion of the Mentoring White Paper is that such organizations will likely first encounter caBIGTM through the marketing effort. 

## Recommendations Regarding Mentoring Topics

**Key future-focused recommendations in the “caBIGTM Mentoring Capability Plan:”  **
- Mentoring is not outreach – while all are responsible for publicizing caBIGTM, mentoring is a different, and more focused, activity.
- caBIGTM mentoring should target topics that cannot be addressed by other approaches.  There must be a clear, well-defined goal to be achieved.
- Near term, mentoring should continue for VCDE/Arch and documentation and training.  It should be expanded to include Grid architecture, Grid services, and specific domain expertise in adopting and integrating caBIGTM tools into an institution’s workflow.
- Other candidate mentoring topics should be considered regularly to meet evolving needs.

**Notes:**
Slide Owner: Jessica Bondy

So, we ultimately determined that future mentoring activities would focus primarily on funded developers.  This slide captures our conclusions regarding the topics that should be covered.

First, we concluded that mentoring is not the same as outreach.  General outreach may require: 
	1) peer-level interaction with decision-makers, e.g., Cancer Center Directors speaking to other Cancer Center Directors; 
	2) broad, integrated knowledge of caBIGTM, rather than narrow, highly-technical skills; and/or 
	3) technical skills in the development of marketing campaigns.  
Because these requirements do not match the skills mentors are likely to bring to the table, the highest level of outreach should remain with the existing teams.

As has been mentioned several times, we believe mentoring should target topics that 
	- cannot be addressed by other approaches.  
	- for which there is a clear, well-defined goal to be achieved (e.g., passing compatibility review, as opposed to teaching about data quality or the science behind caBIG tools)

These principles were applied to particular potential topics, with the result that we recommended mentoring on 
	- VCDE/Arch 
	- documentation and training. 
	- Grid architecture
	- Grid services
	- specific domain expertise in adopting and integrating caBIGTM tools into an institution’s workflow.

Finally, we recognized that the topics needing mentoring are a moving target 
	- documentation and training or other modes may ultimately satisfy needs in a particular subject, 
	- an adequate level of expertise may be achieve in the community 
We therefore recommended putting in place a mechanism whereby new topics can be added and outdated topics retired.

## caBIGTM - From Pilot To Enterprise

**Expanding Community and Moving Towards Sustainability**
- Communication and Outreach
- Publications
- Websites
- Easy Access to Tools
- Application Support
- Knowledge Management and Exchange

## Future Vision for caBIGTM Mentoring

**caBIGTM Knowledge Centers**
- Provide sustained sources of expertise and support for the caBIGTM enterprise
**Domain-focused Knowledge Centers**
-  Established at institutions with demonstrated expertise in a specific domain/workspace.
**Institution-focused Knowledge Centers**
- Established to help embed caBIGTM tools across departments within an institution
**caBIGTM Knowledge Centers would be responsible for identifying and mobilizing mentors for their assigned area of expertise**

**Notes:**
Slide Owner:  Leslie Derr

## Future Mentoring “Business Processes”

**As mentoring evolves beyond VCDE/Architecture and Documentation and Training, caBIGTM leadership and Knowledge Centers will need to address several management processes: **
- Defining the *scope* of a mentor’s responsibilities
- Identifying *sources* from which mentors might be drawn
- Recruiting mentors and defining *incentives* for being a mentor
- Developing *training programs and standards* for mentors-to-be
- Matching mentoring *supply* with mentoring *demand*
*Marketing* the availability of the mentoring services - *outreach*
*Evaluating* existing mentors to ensure high quality services
- Monitoring current and emerging *mentoring* needs - prospectively
- Managing and completing *contracting* needs
*Coordinating* mentoring activities and interfacing with workspaces

**Notes:**
Slide Owner:  Paul Courtney
Scope of Responsibilities: e.g., not writing the manual, helping to identify sources of help that enable the mentee to write the manual; is this different for different workspaces or tasks?
Sources: e.g., supporting organizations outside the Knowledge Center, current participants in caBIG
Supply and Demand: also different types of mentoring? Different styles of mentoring?  
Marketing: how to make sure that newbies know?  Model of Dartmouth PAL: all freshmen are assigned an adviser/mentor to assist.
Evaluation: what if someone wants to mentor but just is not cut out for it?
Contracting and incentives: how will caBIG know if this is working or not?  How do we test this after a year?  

## Looking Further Ahead

**Possible long-term “use cases” for caBIGTM mentoring:     ****A long-time domain workspace member has worked on many caBIGTM development projects.  Her institution has also adopted other caBIGTM tools.   This person might be well suited to serve as a mentor to a new project developer team.  ****A domain tool, developed at Center Zulu, is being adopted at Center Bravo.  The domain Knowledge Center at Center Alpha serves as a “clearinghouse” for mentoring requests, connecting the new user at Bravo with an experienced mentor from the Zulu developer team.  This provides “one stop shopping” for new adopters, and leverages existing expertise across caBIGTM.  **

**Notes:**
Slide Owner:  Paul Courtney

## Looking Further Ahead

- ICR WS

**Looking Further Ahead**

- Workspace Lead

- WS Mentoring Lead

- Documentation and Training WS

- Project X  Team

- Amy Mentor

- Mark Mentee

## Conclusions

**Mentoring has served a valuable function for caBIGTM to date – and has revealed critical success factors and challenges. **
**As the community grows and broadens, additional sustained and decentralized approaches to mentoring are needed.  The program continues to evaluate alternative methods to meet these needs.  Knowledge Centers are the first step towards this future.**
**We thank all the dedicated caBIGTM mentors who have been pivotal to caBIGTM success – and invite other experienced community members to take on this important role.  **

**Notes:**
Slide Owner:  Dianne Reeves
If mentoring award recipients are present – acknowledge them.

## For More Information...

**VCDE Mentoring: ****Brian Davis - **_**[bdavis@3rdmill.com](mailto:bdavis@3rdmill.com)**__** **__** **_
**Architecture Mentoring:  ****Mike Keller - **_**[keller_michael@bah.com](mailto:keller_michael@bah.com)**__** **__** **_
**Documentation & Training Mentoring:  ****Dianne Reeves - **_**[reevesd@mail.nih.gov](mailto:reevesd@mail.nih.gov)**__** **__** **_
**caBIGTM-wide Mentoring Infrastructure:  ****Leslie Derr - **_**[derrl@mail.nih.gov](mailto:derrl@mail.nih.gov)**__** **_

## Feedback and Discussion

**Let’s hear your questions and perspectives! **

**Notes:**
Facilitation: Jenny or Leslie