Knowledge Sharing Pattern Language


Pattern

KSP04
Trust or Check

Dimensions and Knowledge Flow:
 


I1
Knowledge Sharing
in a Project Team

 


Work Status
L2 Project Realization
 

Project
Manager
 

<---- 

Project
Team
Member

   

Problem A project manager is unsure about how to follow a project team member’s progress in a project.
 
Initial Context The check activities here are introduced in addition to the normal quality assurance activities defined in software development processes. Here it is assumed, that normal document reviews, code reviews and testing are implemented.
Roles A Project Manager managing the project. The project manager is the key actor in this pattern. A Project Team Member, normally a Software Engineer, implementing tasks in the project.
 
Forces The results of the work of a project team member implemented in a project are visible normally only when some testable and/or visible artifact is produced. In some cases this may result in a situation, where a project team member implementing a single assignment behaves as if everything would be fine and the delays or problems are visible only after the deadline of the assignment. The purpose of this pattern is to help to have an understanding of possible problems as early as possible.

Constant checking and surveillance by the project manager takes time and may affect negatively the team spirit. It is not reasonable always to follow all project team members and their progress at a detailed level. Some kinds of criterion is required to determine when more follow-up might be required and when not.
 

Solution
 

  1. Define trust or check requirements:
    1. Define Task Criticality
      Critical: check
      Not critical: trust
    2. Define Performance of the Person
      Do you know well enough the performance of the Project Team Member implementing the task?
      Known, good performance: trust
      Known, poor performance: check
      Unknown: check
  2. Decide the approach based on: i & ii. Plan required check activities. See e.g. section Practices.
    • Trust & trust: Trust, no additional check activities are required. Stop implementation of this pattern here.
    • Check & trust or trust & check: decide if you need any additional check activities. Plan light check activities.
    • Check & check: Plan check activities.
  3. Implement check activities and follow the results (including also: Participate check, Reports requested and Observe and evaluate.
    Be open to the team member, tell him/her that because you are new to each other or because it is a very critical assignment, you need more information regarding the progress and thus will implement these checking activities together with this person (or ask some other team member to do those with this person).
 
Resulting Context After implementing these kinds of checking activities, the project manager knows the project team member better and can, in the future, either trust easier or knows what kind of checking activities are required. One result can also be that the person is found not to be suitable for these kinds of assignments.

The potential negative results of the surveillance must be followed. See also the potential pitfalls.
 

Instances This pattern should be used always when assigning a new project team or when assigning a task (must be decided for all project team members participating in the task implementation). In many cases the pattern implementation is finished after deciding that a person can be trusted and the normal quality assurance activities in the project are enough.

Potential pitfalls:

  • Checking activities starting to take too much time.
  • Team spirit changing to negative because of detail level surveillance.
Process Connection Supports Project Management process, project realization.
 

Practices

 Examples of recommended practices for check activities (see step 2 above):

 

Home
Catalog

Last changes at 26th December 2007