Task: Provide Method Adoption Support |
|
 |
Mentor a project team in the execution of a new process, including all elements of planning, coordination, configuration, tailoring, and training as necessary to ensure effective adoption. Help the team learn and apply the process in the context of real project work.
|
Disciplines: Software Capability Improvement |
|
Purpose
Mentoring accelerates adoption of software development capabilities by a project team. Mentors play a catalytic role in
making change successful. People will accept change if they feel confident of the outcome. Good mentors not only
transfer skills but also instill confidence.
|
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| Optional:
|
Outputs |
|
Main Description
The most effective method for introducing change is to tie improvement efforts directly to the work being performed.
Use project and iteration planning to drive the introduction of new processes, just ahead of when they should be
applied. Jump-start changes and facilitate skills transfer through a series of focused workshops followed by hands-on
mentoring.
Guide and advise the project team so that they can apply process appropriately:
-
Lead workshops, create usage models, and review artifacts.
-
Help the project manager create and execute plans and manage issues and risks.
Introduce the "right" amount of process so as to not to slow down the project's progress:
-
Follow "minimal but sufficient principle."
-
Mentoring is about "leading change."
-
The goal is to make progress in the project, not tool or process ceremony.
-
Mentoring is not about theoretical discussion of the features of the process.
-
Mentoring is not about religious battles between different usage models.
A key part of the mentoring effort is providing feedback and lessons learned in order to improve the
process.
|
Steps
Conduct mentoring kick-off workshop
During the kick-off session the project team and mentor discuss and determine:
-
mentoring objectives for the project team
-
roles
-
training that the project teams need
In this workshop the mentor learns the context and background of the project.
|
Create deployment and action plan for the project
Create a simple plan of process deployment and adoption activities for the project. This plan should take the team's
project plan into consideration. A key objective is that the deployment and adoption activities should
have minimal to no negative impact to the project. The scope of mentoring may vary depending on the enterprise process
adoption schedule, the specific project and project team.
Assess the current state of capability of the project team (their strengths and weaknesses) in various disciplines and
then determine where to focus first.
Process adoption must take place in an iterative, incremental and evolutionary manner. Plan mentoring activities
and deployment of the process with this in mind.
|
Provide training sessions in the process areas
Conduct training sessions to introduce the team to key concepts of the processes. This is only a precursor, not a
replacement, for the learning that takes place through execution on the project.
|
Conduct mentoring sessions
-
Conduct regular mentoring sessions with the team. There must be at least one session per week (on-site or
remote).
-
Create a clear agenda for each session. Only the relevant roles (e.g. Project Manager, Analyst, Designer) will
attend.
-
Check what tasks have been completed since the last mentoring sessions. Check the status of issues, risks and
defects. Check what tasks/activities need to be completed this week.
-
Discuss and point to concepts, guidelines, and examples. Artifact examples are always very helpful for
project teams.
-
At the end of each mentoring session, review the task list that needs to be completed by the project team by
the next mentoring session.
For guidance on how to plan and schedule for mentoring sessions see Guideline: Plan the Mentoring Schedule.
|
Review the artifacts created by the project team using the process
As a project progresses, document the process the team applied during each iteration. This enables the organization
to collect experiences across projects. It also enables teams to not only apply process changes in subsequent
iterations of current projects, but also to use them as the basis for new projects. This results in a process that is
grounded in practical experience and can grow to support the organization's specific needs. Instead of being a theoretical
exercise, process definition emerges from the experience of solving problems and delivering results. |
Identify potential new mentors
Identify team members who are good candidates to mentor other teams based on what they learned executing the process on
this project.
|
Collect measurements and lessons learned
Provide feedback about the team's adoption of the process. These lessons learned provide critical feedback that
enables continuous improvement of the process. Examples of helpful feedback to collect throughout the mentoring
project include:
-
incompatibilities between the process and tool capabilities
-
impact of process to the project (positive and negative impacts)
Collect the following feedback from the project team:
-
effectiveness of the process
-
effectiveness of training sessions
-
effectiveness of mentoring sessions
|
Regularly check the project after exiting
Confirm continued self-sufficiency, answer questions and provide advice. |
|
Key Considerations
-
Mentoring is successful if the project team shows improved project performance (e.g. iterations on time, on
budget, fewer issues, fewer risks, lower defect rate)
-
A good mentor must be able to adjust the Mentoring Action Plan "on the fly" based on the needs of
the project.
-
A project team may need multiple mentors in different areas
-
The mentoring relationship must be terminated if the project team is not making desired progress. The Center
of Capability must investigate and determine the root cause. Either the mentor or the project team (or a
specific role) or a broken process could be primarily responsible for the failure.
|
More Information
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|