Mindmap

PMT

Bhavit Chhatralia Englisch

Inhalt der Mindmap

PMT

Section A
- Belbin Roles
  - Background to Belbin Team Roles concepts
    - Based on many years of solid academic research – observation, theory, prediction, testing in practice.
    - Collaboration between:
      - Henley Management College
        At Henley, all management training was done using team exercises
        Use of computers enabled them to quantify results of the team exercises.
        Also to correlate these results with information on team members’ psychological traits (Belbin).
      - A Cambridge University Research Unit looking into industrial training, led by R Meredith Belbin
    - Belbin approached this research question by comparing and measuring “inputs” and “outputs” in team exercises at Henley
      - Inputs
        Quantifiable psychological traits of team members
        Focus on how psychological traits of team members affected the results of the team as a whole
      - Outputs
        Results from two new exercises, able to identify a clear winning team, that were developed for this collaboration
        Executive Management Exercise (EME) - Computerised financial markets simulation, Teams of 6, as “Companies” competing against each other.
        Teamopoly - Like Monopoly, but with element of chance removed
    - Research question – what (combination of) individual members’ psychological traits makes a successful team?
    - Belbin correlated placings in team exercises with the psychological profiles of team members
    - Teams were made up of members with various combinations of psychological traits
      - Recording results - as well as team placings, Belbin had trained observers to watch & record interactions.
    - Some test teams of all the same type of member E.g. So-called “Apollo” teams
      - Made up of the most intelligent students.
      - Most such teams did very poorly (25 Apollo teams tested)
    - Test teams may or may not be aware of other member’s psychological profiles
      - E.g “Plant” teams
      - Someone known to be especially intelligent and creative, good at generating ideas, would be added to the team.
  - Belbin Team Roles in practice
    - Good News
      - It is recommended that members’ Team Role preferences are taken into account when forming teams
      - Allocation of functional roles should broadly match, or at least not contradict, members’ team role preferences
      - In a small team, individuals would perform more than one role
      - Note that Belbin team roles are sets of behaviours adopted by a person in a team situation.
      - NOT a set of relatively fixed personality traits
      - Also influenced by past experience of teamwork
      - May change over time and with circumstances, influenced by future experience of teamwork.
      - Knowledge of team role preferences helps the individual and the team to work together.
    - Bad News
      - Belbin Associates, UK provide detailed questionnaires that produce a profile of an individual’s: Preferred team role(s) Manageable team role(s) Least Preferred team role(s)
      - two questionnaires
        Self-perception inventory (filled in subject)
        Observer Assessment (filled in by the subject’s colleagues, in workplace would include subject’s boss and subordinates)
      - Unfortunately, these are not in the public domain, nor are the algorithms used to process the questionnaires to derive the individual’s team role preferences
      - However, some knowledge of one’s own and others’ team role profiles can be deduced from studying the roles.
  - Findings
    - Belbin identified various “nodes of behaviours” of individuals when working in teams
    - From team results and observations, he identified 9 possible team roles, that an individual may, or may not, be suited to perform
      - No “good” or “bad” roles, just differences
      - Belbin argued that the best and most efficient teams are made up by combining a balanced mix of roles.
Section B
- Project Scheduling
  - Sequencing of Activities
    - Decide on a logical order for tackling the set of project activities.
    - The order may be constrained by
      - The task dependencies inherent in the process e.g. being able to start the design depends on having some requirements.
      - Resource constraints, such as availability of staff, delivery of equipment
      - Customer constraints
    - Use a Precedence Table to plan and record the sequence of activities
      - Label each activity (name + unique ID)
      - For each activity, work out what other activities need to be completed before it can start
  - Precedence Table - Example
  - table into a Precedence Network Diagram
  - Precedence Network Diagrams – Conventions and Notation
    - Each activity must have one start event and one end event
      - Activities may share start or end events
    - The project as a whole has one start event and one end event on the network diagram
    - There are two alternative notations for network diagrams:
      - AoA – Activities on Arrows (used in this unit) e.g. PERT (Program Evaluation and Review Technique) diagrams
      - AoN – Activities on Nodes e.g. Microsoft Project
  - Levelled Network Diagrams
    - On a large project, the PND may be expanded to more detailed levels
    - Top level activities might be:
      - Develop Functionality A
      - Develop Functionality B etc, etc.
      - There would be dependencies among the top-level activities
    - A separate PND would then be created for each of the top-level activities
  - Dummy's
  - Size of activities
    - duration (how long it will take – in days, weeks, etc) , staff required
    - Effort = Duration * No. of Staff (in person/hours,etc)
    - Effort can be used in calculating costs for a project
    - Estimation of activity size is the most difficult part of project planning and is inherently error-prone
    - Base estimates on previous experience and common sense
    - If possible, the staff who are likely to work on the activities should be involved in estimating activity duration and staffing
  - estimated activity sizes to the precedence table
  - durations of activities to the precedence network
  - Critical path
- Project Monitoring & Control
  - PND to help choose milestones
  - Monitoring using Milestones
    - Milestones are events which indicate that crucial stages in the project’s progress have been completed
      - E.g. events where completion of an activity means that several activies can now start
      - E.g. events where several activities must be completed before another activity can start.
    - Usually but not always on the critical path
    - Milestones should be fairly evenly spread out across the project
  - Managing Milestones
    - Milestone completion criteria must be clearly specified.
      - Identify all deliverables and the criteria for their acceptance
    - Focus monitoring on the activities and/or events leading up to the milestone
      - Different staff may be responsible for different activities
    - Have one person responsible for reporting against each milestone