Project Management

October 10, 2020

Contents

1. Project Initiation
2. Scheduling & Time Management
3. PRINCE2
4. Budgeting and Forecasting
5. Lean and Agile
6. Risk

---

Project Initiation

In general, quality is constrained by cost, time, and scope. It is important to consider where a customer’s priorities lie between these.

PMBOK Knowledge Areas

There are 10 knowledge areas defined in PMBOK, which are skills a project manager must master to manage a project efficiently:

• Scope - Work which considers the scope of the project.
• Time - Dividing the project into tasks and producing a schedule.
• Cost - Creating and managing the project budget.
• Quality - Establishing target quality level for the project.
• Risk - Identifying and planning for risks related to the project.
• Resources - Managing the human resources and project team.
• Procurement - Managing subcontractors and outside work.
• Stakeholders - Ensuring stakeholders are satisfied with the project.
• Communication - Managing communication with stakeholders.
• Integration - Tasks which hold the project together and integrate it as a whole.

PMBOK also defines 49 separate processes, each of which has certain inputs, tools and techniques, and outputs.

Process Groups

1. Initiation - Why do the project?
2. Planning - Balance time, cost, scope, risks, etc.
3. Execution - Where the ‘real work’ gets done.
4. Control - Monitor and review progress.
5. Closing - Delivery, audits, and lessons learned.

Project Mandate

The Project Mandate or Statement of Work describes:

• What exactly is the project?
• What is included and excluded from the project (scope)?
• What are the constraints (budget and time)?
• Assumptions.
• Known risks and issues.

It can also be useful to describe the business need and a strategic plan of organisation in the project mandate.

Project Charter

The Project Charter formally authorises the existence of a project and provides the Project Manager with the authority to apply resources.

The inputs to the project charter are:

• Project Mandate or Statement of Work
• Business Case - is it worth the required investment?
• Agreements and contracts.
• Environmental factors (quality standards etc.)
• Organisational process assets - standard processes etc.

The outputs of the project charter are then:

• Project purpose or justification.
• Measurable objectives and success criteria.
• High-level requirements, boundaries, risks, constraints.
• Summary milestone schedule and budget.
• Stakeholder list, authority of sponsor, assigned project manager, signing off authority.

Project Stakeholders

• Sponsor - Promotes, provides resources, leads through the initiation.
• Customer and Users - For the project’s product, service, or result.
• Sellers - Provide components or services necessary for the project.
• Partners - Provide expertise or service such as installation, training, and support.
• Internal Groups - Marketing, manufacturing, sales, customer service teams.
• Functional Managers - Human Resources, finance, accounting, procurement etc.
• Others - Anyone else who may have an interest in the outcome of the project.

Power Interest Grid

Can decide how each stakeholder should be managed by using a Power/Interest Grid.

• Low Power, Low Interest - Monitor.
• Low Power, High Interest - Keep Informed.
• High Power, Low Interest - Keep Satisfied.
• High Power, High Interest - Manage Closely.

---

Scheduling & Time Management

The first steps after the project manager takes over following completing the project charter are usually:

• Create a Work Breakdown Structure and Gantt Chart.
• Set out milestones, identify bottlenecks, optimise WBS.
• Create Budget Plan and allocate resources.

Work Breakdown Structure

A Work Breakdown Structure is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.

Each descending level represents increasingly detailed definitions of the work to be completed.

The deliverables must be consistent with project initial objectives.

A Work Package is the smallest unit of the WBS. It has:

• Set of related tasks and deliverables.
• Clearly defined interactions with other work packages.
• Clear identification of inputs, outputs, and internal activities.
• Clear estimation of cost, duration, and resources.

The size of work packages can be controlled, with the following benefits/disadvantages:

• Small Work Packages
  • Can be completed more easily in parallel.
  • Easier to estimate time and cost required.
  • Easier to control team.
  • But have more Work Package interactions.
  • May be harder to define.
  • Can lead to duplicate work being carried out.
• Large Work Packages
  • More efficiently make use of and manage team.
  • Places more assumptions on the team knowing how to organise themselves.
  • Increased risk of work overrunning.
  • Problems may be detected later compared to with smaller work packages.
  • Project Manager has less control.

The Work Breakdown Structure should be deliverable-oriented, and not objective-oriented or process-oriented. This is because:

• Deliverables are easier to estimate than objectives.
• Helps focus on the essentials.
• Allows us to manage scope.

However, the disadvantages of this are:

• Deliverables might not align with objectives.
• Processes that consume time and resources might be overlooked.
• Might not come naturally.

The tasks required by the project should be broken down until each task can be accurately defined and estimated.

Deliverables vs Objectives

Objectives are:

• Desired benefits, outcomes, or improvements.
• Good objectives are:
  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Time-bound

Deliverables are the:

• Outputs or products.
• What is delivered to the customer.
• Only produced to achieve objectives.

Both should be considered when thinking about scope - each objective should align with one or more deliverable. Deliverables which do not help achieve project objectives should be excluded.

Estimating Activity Durations

There are a few different approaches for estimating activity durations:

• Analogous - How long the activity took in pervious instances.
• Parametric - As above, but using a statistical model.
• Team-Based - Estimated by the people doing the work.
• Three Point - Uses a mean $m$, minimum $a$, and maximum $b$. There are two common distributions:
  • $t_{triangular} = (a + m + b)/3$
  • $t_{beta} = (a + 4m + b)/6$

Gantt charts

Offer a graphical visualisation of the project, showing:

• Temporal schedule of activities.
• Dependencies between activities.
• Progress of activities.

Project Network Diagram (PND)

A Project Network Diagram is a graphical way to view the project’s tasks, dependencies, and the critical path.

The critical path is a sequence of activities starting from the first activity of the project and ending with the last, and where no task on the critical path can be delayed without extending the project duration.

Critical Path Method (CPM)

The following terms are defined:

• Duration, $D$ - The duration of the activity.
• Earliest Start, $ES$ - Earliest time an activity can start (once previous activities have finished).
  • Earliest Start is the maximum Earliest Finish from immediate predecessors.
• Earliest Finish, $EF$ - Defined for an activity as $EF = ES + D$.
• Latest Finish, $LF$ - Latest time an activity can finish without delaying the project.
  • Minimum Latest Start from immediate successors.
• Latest Start, $LS$ - Defined as $LS = LF - D$.
• Total Float, $TF$ - Amount of time a task can be delayed without delaying the project.
  • Defined as $TF = LS - ES = LF - EF$.

The algorithm for finding the critical path is then:

1. Construct the PND.
2. Forward Pass
   • For each activity, starting with the earliest…
   • Calculate $ES$ (maximum $EF$ from immediate predecessors).
   • Recall $EF = ES + D$.
3. Backward Pass
   • For each activity, starting with the latest…
   • Calculate $LF$ (minimum $LS$ from immediate successors).
   • Recall $LS = LF - D$.
   • Calculate Total Float for the activity by $TF = LS - ES = LF - EF$.

Activities on the critical path have a Total Float of 0.

A Critical Task is one which cannot be delayed without delaying the project.

Drag Time is the amount of time a task on the critical path adds to the project (the length of time it would have to be reduced in order to make it non-critical). This is calculated as the minimum of the duration of the critical task and the total floats of all parallel tasks.

Crashing a Project refers to attempting to trade-off cost and schedule to try and compress the schedule slightly. The Crash Duration is the shortest possible time for which an activity can be scheduled to speed up the entire project, and is calculated as $D - Drag$ for the task.

Free Float is the amount of time an activity can be delayed without delaying the early start date of any subsequent activities. This is always less than or equal to the total float.

Program Evaluation and Review Technique (PERT)

PERT is a variation of critical path analysis which takes a more skeptical view of time estimates at each stage.

Involves estimating the shortest possible time an activity will take, $a$, the most likely length of time $m$, and the longest time it might take $b$. The distribution we assume uses the following calculations for mean and variance:

$$\text{Mean } t = \frac{a + 4m + b}{6}$$ $$\text{Variance } \sigma^2 = \left( \frac{b-a}{6} \right)^2$$

Can then use these to calculate the expected time and variance the project will take. Simply sum the total times to find the mean and variance, which can then be modelled using a normal distribution to determine the probability the project will be completed in a given amount of time.

---

PRINCE2

Roles

In PRINCE2, a project team comprises of at least:

• Project Board
  • Panel to represent stakeholders.
  • These people are held responsible and accountable for the project’s success.
• Project Manager
  • Responsible for day-to-day management.
  • Requires approval from the board to change plans beyond agreed limits.

The roles can be further categorised…

• Outside the project - sponsors etc.
  • Corporate/Programme Management - Commissioning, provide mandate.
  • Quality Assurance - Audits outcomes, ensures interests of the business are considered.
• Project Board - authority and responsibility for whole project.
  • Executive - Ultimately responsible, business-oriented, focuses on objectives and business case.
  • Senior User - Responsible for specify and monitoring needs of users.
  • Senior Supplier - Implementation, technical integrity.
• Project Management Team - responsible for day-to-day planning, monitoring, and control.
  • Project Manager - Given authority by the project board.
  • Team Manager - Manages teams/developers and production quality.
• Additional Roles.
  • Project Assurance - Assures interest of the board.
  • Change Authority - Makes some decisions on behalf of the board.
  • Project Support - Helps project manager in management activities.

Principles

PRINCE2 has seven main principles:

1. Continuous Business Justification - Is there a business benefit?
2. Learn from Experience - Don’t make the same mistake twice.
3. Defined Roles and Responsibilities - Who’s held accountable?
4. Manage by Stages - Break a project into manageable chunks.
5. Manage by Exception - Within limits, let people get on with their jobs.
6. Focus on Products - Think about outcomes and outputs.
7. Tailor to Suit the Project Environment - Customise it, don’t follow it to the letter.

Processes

Similar to PMBOK, PRINCE2 defines several processes:

• Starting up a Project (SU)
• Directing a Project (DP)
• Initiating a Project (IP)
• Managing a Stage Boundary (SB)
• Controlling a Stage (CS)
• Managing Product Deliver (MP)
• Closing a Project (CP)

Themes

There are also seven themes:

• Business Case - Feasible? Desirable? Achievable?
• Organisation - Responsibilities, Accountabilities.
• Quality - Meeting requirements.
• Risks - Identify, assess, and control risks.
• Plan - What, when, how, who, etc.
• Change - Reacting and adapting.
• Progress - Is it going to plan?

These themes can be related to the principles to some extent.

Product-Based Planning

The motivations for using a product-based rather than activity-based approach are:

• Projects deliver products not activities.
• We can write a product specification.
• We can measure the quality of a product.

Management Products

These are the documents produced by following the PRINCE2 methodology.

• Records:
  • Logs - Daily activities, lessons learned.
  • Registers - Issues, Quality, Risk, Configuration.
• Baselines:
  • Approval - Project Brief, Project Initiation, Project Product Description, Business Case, Benefits Review Plan.
  • Management Strategies - Quality, Risk, Configuration, Communications.
  • Plans - Project Plan, Stage Plan, Team Plan, Work Package.
• Reports:
  • Stage Boundary - End Stage, End Project, Lessons.
  • Change - Highlights, Issues, Exceptions.

Theme Processes

There are slides for all 7, but the two most important appear to be:

Risk Theme

The process followed is:

1. Identify threats and opportunities.
2. Assess probability, impact, and proximity.
3. Plan appropriate responses.
4. Implement the planned responses.
5. Communicate to interested parties.

The document associated with this is the Risk Register.

Change Theme

The process is:

1. Capture - Record issue.
2. Examine - Assess impact.
3. Propose - Consider options.
4. Decide - Choose whether to escalate.
5. Implement - Take corrective action.

The documents associated are the Issue Register and Issue Report.

---

Budgeting and Forecasting

Involves managing the costs associated with a project.

• Plan Cost Management - How will costs be managed?
• Estimate Costs - Approximate cost of activities.
• Determine Budget - Aggregated value - cost baseline.
• Control Costs - Monitor activity status, update baseline, manage changes.

Creating a Project Budget

Relies on understanding scope, schedule, and resources. A good budget is planned, structured, and controlled.

Inputs contributing to the development of the budget are:

• Project Management Plan.
• Project Charter/Brief.
• Environmental Factors and Organisational Assets.

The outputs are:

• Cost Management Plan - How the organisation will manage cost variance.
• Activity Estimates - Estimate the cost for each activity.
• Cost Baseline - The initial budget.

Determining Cost

There are typically three ways in which costs are calculated:

1. Cost per time unit - Typically used for budgeting human resources.
2. Cost per use - E.g. cost of venues, cleaning.
3. Cost per material consumption - Building materials, food etc.

There are a few main methods for estimating activity costs (note these are the same as estimating activity durations):

• Analogous - How much did it cost last time?
• Parametric - Same as above, but with a statistical model.
• Team-Based - Estimated by the people doing the work.
• Three Point - Using mean $m$, minimum $a$, and maximum $b$. There are two popular distributions:
  • $t_{triangular} = (a+m+b)/3$
  • $t_{beta} = (a+4m+b)/6$

It is useful to also have a measure of uncertainty.

Can also consider Vendor Bids - comparing competitive bids from different suppliers, and the Cost of (Poor) Quality - compare costs for different quality levels.

Cash Flow

Cash is not always liquid - it is important to know both how much cash is available and when it is available. Cash can be scheduled like any other resource.

We can anticipate cash flow issues by summing the daily/weekly/monthly activity costs, then either:

• Ensuring resources are in place to cover anticipated expenditure.
• Reschedule activities to smooth out spikes.

We can also build a profile of the cumulative expenditure over the lifetime of the project.

The Performance Measurement Baseline (PMB) of a work package or project is a time-phased plan of costs (budget) against which actual performance can be measured.

• Planned Value (PV) - How much of the authorised budget has been assigned to the work at a given point in time.
• Actual Cost (AC) - How much of the budget has been spent on the work at a given point in time.
  • This alone is not enough though - are we under budget or just running late?
• Earned Value (EV) - How much of the planned value has been achieved by doing the work so far.
• Budget At Completion (BAC) - Total planned value.

A Performance Measurement Baseline represent the formal plan for the project manager to accomplish all the work required in the time allotted and budget provided.

These variables give an instantaneous picture of the project at any point in time.

Variable	Description	Calculation
Budget at Completion (BAC)	Total budgeted cost of work	In Budget
Planned Value (PV)	Budgeted Cost of Work Scheduled	$BAC\times \%$ scheduled so far
Actual Cost (AC)	Actual Cost of Work Performed	Measured
Earned Value (EV)	Budgeted Cost of Work Performed	$BAC \times \%$ done
Schedule Variance (SV)	Is the project on schedule?	$EV - PV$
Cost Variance (CV)	Is the project within budget?	$EV - AC$
Schedule Performance Index (SPI)		$EV / PV$
Cost Performance Index (CPI)		$EV / AC$
Cost Schedule Index (CSI)	Overall Project Efficiency	$SPI \times CPI$

Forecasting

We can extend the previous metrics to include some to allow forecasting to take place:

• Estimate at Completion (EAC) - Estimated final total cost of the project. We can:
  • Trust the original estimate - assume remaining work will take as long as we had originally planned.
  • Assume performance (cost-efficiency) to date is a good indication of how rest of the project will perform.
  • Assume progress (schedule-efficiency) to date is a good indication of how rest of the project will perform.
• Estimate to Completion (ETC) - How much will we need to spend to finish the work?
  • Can take the difference between estimate at completion and budget at completion.
  • Or calculate from the ground up if the original estimate was fundamentally flawed.
• Variance at Completion (VAC) - The expected overspend (or cost savings).
  • The difference between what the project was originally expected to cost, versus what it is currently estimated to cost.
• To-Complete Performance Index (TCPI) - The future cost efficiency required to:
  • Achieve the original budget.
  • Achieve the estimated budget.

Each of these can be calculated as follows:

Variable	Description	Calculation
Estimate at Completion (EAC)	Estimated cost based on progress to date	$BAC / CPI$
	Estimated cost based on original estimation	$AC + (BAC - EV)$
	Estimated cost based on remaining work and performance	$AC + (BAC - (EV / CSI))$
Estimate to Complete (ETC)	Estimated remaining cost of work	$EAC - AC$
Variance at Completion (VAC)	Deviation from budget	$BAC - EAC$
To-Complete Performance Index (TCPI-EAC)	The cost efficiency required to achieve the EAC	$(BAC - EV) / (EAC - AC)$
To-Complete Performance Index (TCPI-BAC)	The cost efficiency required to achieve the BAC	$(BAC - EV) / (BAC - AC)$

Why Projects Fail

Some common factors which cause projects to fail are:

• The requirements weren’t fully or properly gathered.
• The stakeholders were not involved.
• There weren’t enough resources to complete the project.
• The expectations for what could reasonably be created during the project were too high.
• The support from above wasn’t strong enough.
• The requirements for the project kept changing.
• The project wasn’t well planned.
• There was no longer a need for the project.
• There wasn’t enough management involved.
• Those involved did not have the skills required to complete the project.

In particular for software projects:

• Planning without performing thorough discovery.
• Neglecting the content audit.
• Adding to feature creep.
• Not defining user stories.
• Skipping testing.
• Forgetting to budget for project management.
• Not taking care when planning a multi-site project.
• Skipping consulting specialists.
• Neglecting to plan continuous development policies, tools, and workflows.
• Adopting methodologies without engaging with communities.

Measuring Project Success

Commonly, a project will have budget, schedule, and scope targets.

Key Performance Indicators (KPIs) are simple metrics which can be used to help evaluate project success:

• Scope
  • Percentage of tasks complete.
  • Number of remaining tasks.
  • Number of review meetings.
• Timeliness
  • Percentage of tasks completed on time.
  • Time spend on schedule.
  • Number of schedule review meetings.
• Budget
  • Percentage of tasks on budget.
  • Budget variance.
  • Budget creation time.
  • Number of budget revisions.
• Quality
  • Customer satisfaction ratings.
  • Number of bugs or errors.
  • Customer complaints.
• Efficiency and Effectiveness
  • Resource utilisation percentage.
  • Missed milestones.
  • Rate of return.
• Project
  • Return on investment.
  • Operating margins.
  • Time to achieve value.
  • Cost of management.
  • Percentage of projects complete.
  • Percentage of project over budget.

---

Lean and Agile

Three Wastes

• Overburden (Muri)
  • People can’t work at an unsustainable pace.
  • Machines can’t work at an unsustainable pace.
• Wastefulness (Muda)
  • An activity that consumes resources without creating value for the customer.
• Unevenness (Mura)
  • Working hard in the run-up to a deadline, but then doing nothing the week after.
  • Uneven schedule.
  • Variability in ‘flow’.

Pillars of Lean Thinking

1. Identify Value
   1. Value is created by the producer.
   2. Value can only be defined by the ultimate consumer.
2. Map the Value Stream
   1. The complete life-cycle of a product - from raw materials to customer use.
   2. Some steps create value unambiguously.
   3. Some create no value but are currently unavoidable.
   4. Others should be eliminated immediately.
3. Create Flow
   1. Value stream keeps moving forward, with each step in sync.
4. Establish Pull
   1. Don’t make things ahead of time, make them just in time.
5. Seek Perfection
   1. Repeat, making continuous improvement, seeking perfection.

Lean Principles

1. Eliminate waste.
2. Amplify learning.
3. Defer commitment.
4. Deliver fast.
5. Empower the team.
6. Build integrity in.
7. See the whole.

Software Development Wastes

Industry research identifies these common software development wastes:

• Building the wrong feature or product.
• Mismanaging backlog.
• Rework.
• Unnecessarily complex solutions.
• Extraneous cognitive load.
• Psychological distress.
• Waiting/multitasking.
• Knowledge loss.
• Ineffective communication.

Waterfall Methodology

• Pros
  • Repeatable - low management overhead.
  • Clear about expectations - explicitly collected.
  • Clear responsibilities and interfaces.
• Cons
  • High risk - late detection of problems leads to major redesign (and 100% overrun).
  • One long critical path.
  • Can we plan/analyse that well?
  • Lots of documentation required.
  • No support for change.

Agile Methodologies

Agile methodologies work well in the following conditions:

• Customer preferences and solution options change frequently.
• Close collaboration and rapid feedback is feasible.
• Problems are complex, solutions are unknown, and scope isn’t clear.
• Incremental developments have value, and customers can use them.
• Mistakes provide valuable learning and are not catastrophic.

Agile methods often use User Stories, which formulate requirements as:

As a <type of user>, I want <some goal> so that <some reason>.

Can also add a priority, estimated size, and definition of ‘done’. An Epic is a group of related user stories. A Theme is a top level objective of the product/project.

SCRUM

Scrum has five main values:

• Commitment - To goals in the sprint.
• Courage - To do what you think is right.
• Focus - On the work items in the current sprint.
• Openness - About any challenges you face.
• Respect - Trust that everyone is doing their best.

There are three main roles people can take:

• Product Owner
  • Represents the stakeholder view.
  • Communicates the vision (user stories etc.) to the team.
  • Prioritises user stories, and accepts/rejects them at the end of a sprint.
  • Secures funding, manages ROI.
• Development Team
  • Developers, testers, designers, analysts.
  • Usually 3-9 members.
• Scrum Master
  • Not a manager, but a ‘servant leader’.
  • Works across teams to improve communication.
  • Hosts meetings.

SCRUM Artefacts

• User Story
  • A small piece of functionality to work on during a sprint.
• Task
  • May be unrelated to user story - e.g. investigating minor issues.
• Product Backlog
  • A list of user stories and tasks for future sprints.
• Sprint Backlog
  • A list of user stories and tasks picked from the backlog for the current sprint.
• Product Increment
  • A potentially shippable piece of functionality delivered at the end of a sprint.
• Extensions
  • Reports like Burndown Chart, Velocity, to keep track of the team’s progress.

Burndown Chart

• Displays the remaining effort for a sprint.
• Allows estimation of the velocity of the team.

Kanban Board

A ‘Work In Progress-limited pull system’.

• Work in Progress
  • ‘Limited’ to reduce overcommitment and switching overhead.
  • Team takes on a limited number of tasks.
  • It’s leaner to finish all of one thing than to get two things to 50%.
• Pull System
  • Start new work only when there is demand for it.
  • No to-do list, no work overload, just complete one thing then pull the next.
  • Team focuses on prioritising, not estimating/planning.
  • It’s leaner to focus on completing only what is required.

There are four basic principles:

1. Start with what you do now.
2. Agree to pursue incremental, evolutionary change.
3. Respect current roles, responsibilities, and job titles.
4. Encourage acts of leadership at all levels.

In a pull system, there is the possibility of reaching a state where someone can’t finish their work until someone else has finished theirs. Being ‘blocked’ forces the team to collaborate.

Priority is for completion of the highest priority work.

Other Agile Techniques

Other agile techniques include:

• Rapid Application Development (RAD)
  • Particularly suited to UI building.
  • Relies on prototypes instead of specifications.
• Test Driven Development (TDD)
  • Requirements are turned into very specific test cases, based on use cases, before writing any code.
  • Once code passes tests, it is refactored.
  • Suits situations of improving or debugging legacy code.
• Feature Driven Development (FDD)
  • Based on client-value functionality.

Lean vs Agile

Lean and Agile are complementary to each other, the key points of each being:

• Agile adds:
  • Adapt to change.
  • Short planning and commitment cycles.
  • Focus on collaboration and interaction.
• Lean adds:
  • Focus on adding value with everything we do.
  • Identify ways to eliminate waste.
  • Applies to the whole system, not just software development.
  • Limit work queues.

---

Leadership and Teamwork

There are five aspects of leadership to consider:

• Decision Making
  • Unify people on a common objective.
• Building a Team
  • Establish trust.
• Managing a Team
  • Interventions to ensure the team became productive.
• Motivating People
  • Understanding their needs.
• Understanding Personalities
  • Getting the most out of your team.

PrOACT Decision Making Model

1. Define the Problem - What is the problem? How big is the problem? Why does it matter?
2. Specify Objectives of the solution - Prioritise your aims, how can they be measured?
3. Imagine Alternatives - A decision is only as good as the next-best alternative.
4. Tabulate Consequences - Compare the consequences of each alternative.
5. Clarify Trade-Offs - If no obvious winner, weigh up the objectives. Why is one more important than than another?

It is important to be aware of cognitive biases. There are 20 of these.

Five Dysfunctions of a Team

1. Absence of Trust.
2. Fear of Conflict.
3. Lack of Commitment.
4. Avoidance of Accountability.
5. Inattention to Results.

Characteristics of Productive Teams

• Trust
  • Can speak openly and freely about your team.
  • Team members can count on each other.
  • Can tell the truth even if it’s uncomfortable.
• Respect
  • The team members are empowered to contribute their best.
  • Mutual respect and real concern.
  • Characteristics such as contempt and hostility are not accepted.
• Camaraderie
  • Empathy, good humour and playfulness are appreciated.
  • Strong sense of belonging.
  • Team members celebrate and recognise accomplishments.
• Communication
  • Clear and efficient communication is appreciated.
  • Less directed approaches (gossiping etc.) are not valued.
• Constructive Interaction
  • Conflict can arise as a mean of opportunity for discovery, creativity, and growth.
  • Team should avoid defensiveness, criticising, and finger pointing.
  • Team should give and receive feedback.
• Values Diversity
  • Team is open-minded and appreciates differences in ideas, perspectives, backgrounds, personalities, and approaches.
  • Diversity is crucial.
• Optimism
  • Team shares an inspiring vision.
  • Team members are enthusiastic and appreciative of each other.
  • Strong spirit of fighting together for the goal.
• Team Leadership
  • Strong sense of team leadership.
  • Team members contribute when the need for their leadership happens.
  • Team leader’s role is clear and supportive.
• Resources
  • Team correctly manages available resources and training to meet its objectives.
  • Atmosphere of ‘win-win’ rather than ‘win-lose’.
• Decision Making
  • Team has transparent and efficient decision-making processes, which have proven to be effective.
• Proactive
  • Team takes the initative.
  • Team is flexible in addressing oppertunities, responding positively and creatively.
  • Change is core to the team.
• Accountability
  • There is clarity of roles and responsibilities.
  • When problems occur, the team responds.
  • Team members hold each other accountable for team results and side agreements.
• Goals and Strategies
  • The team has clear, challenging targets and strategies to achieve them.
  • Team is strong and does not let their goals be defeated quickly.
• Alignment
  • The team values cooperation, coherence, and interdependence.
  • Team has a common mission and purpose.

Managing a Team

Tuckman proposed five stages of group development in 1965:

1. Forming
   • Team acquaints and establishes ground rules.
   • Members are treated as strangers.
2. Storming
   • Members start to communicate but still view themselves as individuals rather than part of the team.
   • May resist control and show hostility.
3. Norming
   • People feel part of the team.
   • Realise they can achieve work if they accept other viewpoints.
4. Performing
   • The team works in an open and trusting atmosphere where flexibility is the key and hierarchy is of little importance.
5. Adjourning
   • Team conducts an assessment of the year.
   • Implements a plan for transitioning roles and recognises member contributions.

Motivating People

Common reasons for decreases in motivation can be:

• Lack of Support.
  • Lack of trust, resources, or encouragement.
• Personal Conflicts.
  • Between team members or with managers.
• Overburden.
  • Unsustainable or realistic expectations.

Managing Team Conflict

• Defining the Problem.
  • Work with the team members having the conflict.
  • Jointly define and agree what the problem is.
• Gather Information.
  • Once the problem has been defined, collect information about the problem.
  • Should be done with an appropriate level of discretion.
• Brainstorm Potential Solutions.
  • Team members having the conflict should have input.
  • Important for everyone to be open to new ideas during this stage.
• Choose the Best Solution.
  • Hopefully team members have identified a solution which works for them.
  • Otherwise, facilitate negotiated agreement.
  • Try and aim for a win-win solution.

Managing Expectations

• Clearly define the scope of the project.
  • Clearly defining scope helps minimise the amount of scope changes.
  • Should be agreed with all key project stakeholders.
• Managing stakeholder expectations.
  • Crucial for minimising scope changes.
  • Make sure stakeholders understand cost and schedule impact of any scope change.
• Implement Change Management Processes.
  • Ensures any scope changes have been thoroughly analysed and impact is agreed by project stakeholders.
  • Helps minimise the number of scope changes.

---

Risk

The Risk Planning Cycle involves:

1. Identifying risks.
2. Assess probability and consequence.
3. Control Risks.
   • Devise strategies for detecting risks.
   • Devise strategies for limiting their effects.
   • Decide actions to take in response to identified risks.
4. Monitor the situation.
   • Handle issues.
   • Identify new risks.

Terminology

• Risk - Effect of uncertainty on objectives.
• Uncertainty - Something that is not definite (i.e. has a probability of occurring).
• Types of Uncertainty - Events that may or may not happen, lack of information, etc.
• Areas of Uncertainty - Time, Cost, Quality, Health and Safety.
• Tolerance to Risk - Person/organisation can be risk-averse, risk-neutral, or risk-seeking.
• Threats vs Opportunities - Risk not necessarily negative - may be unexpected benefits.
• Known Risks - Identified ones. Under control of project manager.
• Unknown Risks - Not anticipated. Under control of senior management.
• Issue - If the event which causes a risk occurs, it becomes an issue.

ISO 31000 defines risk as the effect of uncertainty on objectives.

Risks in Software Development Projects

• User
  • Resistance to change.
  • Conflicts between users.
  • Negative attitude towards project.
  • Lack of commitment/cooperation.
• System Requirements
  • Continually changing.
  • Not adequately defined/identified.
  • Incorrect.
• Complexity
  • Usage of new technology.
  • High technical complexity.
  • Developers unfamiliar with technology.
• Planning and Control
  • Lack of effective project management.
  • Lack of close monitoring.
  • Inadequate estimation of costs or resources.
  • Milestones not defined.
  • Ineffective communication.
• Team
  • Inexperienced team.
  • Lack of training/skills.
• Organisational Environment
  • Change in organisational management.
  • Negative corporate politics.
  • Unstable environment.
  • Organisation restructuring.

Assigned Responsibilities

When an issue arises, we want to have clear and unique accountability decided beforehand.

We can use a Responsibility Assignment Matrix (RACI Matrix).

• Clarifies roles and responsibilities for each item in a WBS.
• Records who is Responsible, Accountable, Consulted, and Informed.
• All tasks should have at least one person responsible.
  • Otherwise, nobody will actually do the work.
  • But too many could cause difficulties managing the work.
• All tasks should have exactly one person accountable (the person ultimately answerable for the task).
  • With more than one, they could just blame each other.

Identifying Risks

There are a few methods of identifying risks:

• SWOT (Strengths, Weaknesses, Opportunities, Threats) Analysis.
• Risk Breakdown Structure (RBS) - Breaking down into small units.
• Delphi Technique - Request for information to experts who participate anonymously and iterate until a consensus is reached.
• Decision Tree Analysis - Model of decisions, change, possible outcomes, costs, and utility.
• Simple diagramming using mind maps etc.

SWOT

Involves a grid from Helpful -> Harmful and Internal -> External.

	Helpful	Harmful
Internal	What are you good at? What do you do better than competitors?	What do you need to improve? What can your competitors do better than you?
External	What are your objectives? What do you hope to achieve?	Who are your competitors? What challenges do you face?

Decision Tree Analysis

• Decisions represented with squares.
• Chances represented with circles.
• Outcomes represented with triangles.

At each edge, estimate the value of that path. These can be computed for choice nodes by taking into account probabilities and value of later paths. Outcome value taken by summing all the paths.

Then Estimated Monetary Value can be propagated back to earlier choices.

Identifying Risk Causes

Ishikawa (Fishbone) Diagram

Cause and Effect is often represented using a Fishbone or Ishikawa diagram. With these, we work backwards from a risk to think about how it can be mitigated.

Can be used generally categorising risks as relating to either:

• Policies
• Procedures
• People
• Plant (Technology)

Sensitivity Analysis

Determines how different values of an independent variable impact a particular dependent variable under a given set of assumptions. There are a few approaches to this:

• Simple Estimate - Estimate a range of values, e.g. low/mid/high.
• Simulation - Model the system and measure effects on a variable.
• Empirical Data - Use correlations between risk and outcome.

A Spider Graph plots the dependent variable against deviations of independent variables (usually in %) from a baseline. All lines should intersect in the middle (where the baseline is 100%). Greater gradient for a variable indicates it has a greater overall effect on the outcome.

Planning Risk Responses

A Risk Management Plan is a plan for when something goes wrong. The Risk Response depends on probability and impact.

• High Probability, High Impact - Avoid the risk, planning so it won’t ever happen.
• Low Probability, High Impact - Transfer the risk, by buying insurance etc.
• High Probability, Low Impact - Mitigate the probability or impact.
• Low Probability, Low Impact - Accept the risk, and respond if it happens.

Risk Matrix

Categorises risks according to probability and impact. The responses in each cell reflect the attitude to risks in that particular scenario.

Failure Mode Effects Analysis

A table of:

• Failure Modes - Things that might go wrong.
• Failure Effects - The damage caused by the failure.
• Possible Causes.
• Detection Measures.

We assign a score from 1-10 to:

• Severity
• Probability of Occurrence
• Detection Rate

We then calculate Criticality as Severity $\times$ Probability, and Risk Priority Number by multiplying Criticality and Detection rate.

This helps prioritise which risks to try and address.

This can be extended to Extended-FMEA (EFMEA) by incorporating corrective actions. For each corrective action:

• Recalculate severity, probability, detection rate, and RPN.
• Add a measure of feasibility also from 1-10.
• Choose corrective actions which give the most feasible reduction in risk.