Introduction

• General
  • What is a project?
  • What is project management?
  • What does a project management system consist of?
  • Project visualisation
  • Why breakdown a project?

Topics

• Simple process parts
  • Concept or idea
  • Feasibility study
  • Initiation
  • Specification
  • Design
  • Build
  • Implementation
  • Operation and review
• Basics
  • Project Notebook
  • Assumptions
  • Assumptions and constraints
• Problem statement
• Mission statement
  • Mission statement
  • Mission statement Simple approach
  • Mission statement Formal approach
• Strategy
  • Strategy
  • Selecting a strategy
  • Recording the strategy
• Scope
  • Scope
  • Scope areas affected
• Objectives
  • Objectives reasons for setting
  • Objectives should be
  • Customer analysis
• Deliverables
  • Deliverables
  • Exit criteria
  • Product specification
• Schedules
  • Work breakdown structure part 1
  • Work breakdown structure part 2
  • Work breakdown structure part 3
  • Types of plans
  • Schedules
  • Resources cost
  • Control system
  • The Gantt chart
  • Authority roles responsibilities
  • Authority
  • Risk areas
  • Benefits What are they
  • Terms of Reference
• Planning
  • Planning part 1
  • Planning need to answer
  • Introduction schedule overview
  • Task characteristics Work package
  • Task information
  • Milestones General
  • Milestones Deliverables
• Control
  • Why - what can go wrong?
  • Monitoring
  • General
  • What scope?
  • Time
  • Cost
  • Cost - common terms
  • Cost overspend
  • Cost cash flow
  • Progress reporting general
  • Progress reporting Project Board
  • Progress reporting what data?
  • Taking action what does this entail?
  • Assessing the situation
  • Resolving issues and problems
  • Contingency
  • Areas of review
  • Controlling change part 1
  • Controlling change part 2
  • Document control procedures
  • Project completion
  • Quality management plan overview
  • Plan - areas to define
• Quality
  • Quality management plan overview
  • Plan - areas to define
  • Statistical control
• Risk management
  • Overview
  • General approach
  • Health and safety
• Project review
  • The benefits
  • The report
• Project manager
  • Overview
  • Choosing the project team
  • People recruitment
  • Communication
  • Managing user expectations
  • Systematic approach
  • Empowerment
  • Appointment
  • Project organisation The Project Office
• Construction
  • Construction projects part 1
  • Construction projects part 2
  • Construction projects part 3
  • Construction projects part 4
  • Construction projects part 5
  • Construction projects part 6
  • Construction projects part 7
  • Construction projects part 8
  • Construction projects part 9
  • Construction projects part 10
• Reports
  • Writing reports part 1
  • Writing reports part 2
  • Writing reports part 3
  • Writing reports part 4
  • Writing reports part 5
• Manual methods
  • Time and duration
  • Precedence grid
  • Task flow charts
  • Task flow charts Activity-on-Node networks bubble diagrams
  • Task flow charts Activity-on-Node networks bubble diagrams
  • Task flow charts Activity-on-Arrow networks
  • Task flow charts Activity-on-Arrow networks arrow diagrams
  • Task flow charts Activity-on-Arrow networks arrow diagrams float v slack
  • Contingency 1 General
  • Contingency 2 The weather
• Resource
  • Resource procurement part 1
  • The schedule
  • Resource levelling part 1 summary
  • Resource levelling part 2 techniques
  • Reducing project durations
• Project management systems
  • Six sigma part 1
  • Six_sigma part 2
  • Six_sigma part 3
  • SCRUM part 1
  • SCRUM part 2
  • SCRUM part 3
  • Earned value management part 1
  • Earned value management part 2
  • Earned value management part 3
  • Earned value management part 4
  • Earned value management part 5
  • Earned value management part 6
  • Sensitivity analysis
  • PMBOK part 1
  • The Project Management Knowledge Areas part 2
  • The Project Management Knowledge Areas part 3
  • The Project Management Knowledge Areas part 4
  • The Project Management Knowledge Areas part 5

Detailed planning

• Overview
• Initial estimation simple cost plan
• Initial estimation high level plan first review
• Initial estimation high level plan second review
• Initial estimation budget cost plan
• Estimating overview
• Estimating why are estimates too long
• Estimating why are estimates too short
• Estimating data usage
• Dependencies 4 basic types
• Dependencies (schedule)
• PERT and slack (float)
• PERT part 1
• PERT part 2
• PERT part 3 Cumulative Probability graph
• Elapsed time example for a task
• Roles and responsibilities
• Responsibilities and resources
• The Gantt chart
• Constraints resource
• Critical path part 1
• Critical path part 2 choosing one
• Criticalpath part 3 eliminating one
• Critical path part 4 reducing durations

SCRUM – part 2

The Product Owner

The Product Owner (could be a key user) prioritises the Product Backlog.
A single person must have the final authority when representing the customer's interest in Product Backlog prioritisation and requirements questions.

The Scrum Team examines the list of priorities in the Product Backlog and decides on the top priority tasks that will be completed during a sprint.
These items become the Sprint Backlog.

Hence, these tasks will be the most important to the Product Owner.
The Product Owner does not add any tasks to the sprint.
This supports the commitment of the team to complete the high priority tasks.

Any change that occurs will be outside of the sprint.
Once a team begins the sprint it should be completely focused on its completion.

The Product Owner should be available to the team at any time, especially during the Sprint Planning Meeting and the Sprint Review Meeting.

Challenges will include:

• He or she must resist the managing the team. The team should sort out issues for itself
• The Product Owner does not add any tasks to the sprint
• He or she must be able make hard choices, as necessary, during the sprint planning meeting
• Balancing the interests of competing stakeholders

Sprint

This is a short burst of work lasting approximately 30 days.
During this period an executable and other deliverables are built by an engineering team, as indicated by the assigned Product Backlog.

A sprint lasts no more than 30 days.
A sprint is undertaken by a cross functional team consisting of no more than 9 members.
Every sprint has a specific goal.
An executable demonstrating the goal will be completed by the team during the sprint.

The sprint team has the final say in estimating and determining what they can accomplish during the sprint.

Once the sprint is underway, a new Product Backlog cannot normally be added to the sprint.
This can only happen if:

The Scrum Master determines that a new Product Backlog item will enhance the viability of the product, is in alignment with the sprint, builds on the sprint’s executable, and can be completed within the sprint’s time frame, the Product Backlog item can be added.

If it is realised that the sprint is working on the wrong thing, a sprint can be halted and restarted with new Product Backlog and purpose.

At the end of each sprint the team demonstrates the completed functionality at a Sprint Review Meeting.

Sprint Planning Meeting

The meeting is attended by the Product Owner, Scrum Master, the entire Scrum Team, and any interested and appropriate management or customer representatives.

The product owner describes the highest priority items to the team.
He may not have the time to describe them all and may focus on the high priority items.
Others can be left for another meeting.

The team listen and ask questions.
They are then able to go off and determine which tasks they will move from the Product Backlog to the Sprint Backlog.

A sprint goal is agreed describing what should be achieved at the end of the sprint.
Success will be measured against this goal at the Sprint Review Meeting.

After the sprint planning meeting, the Scrum team meets separately.
They will discuss the described items and will agree on the task load for the coming sprint.
There may be some negotiation with the product owner.

Sprint Backlog

At the start of each sprint a Sprint Planning Meeting is held during which the Product Owner prioritises the Product Backlog.
The Scrum Team then selects the tasks they can complete during the coming Sprint.
These tasks are then moved from the Product Backlog to the Sprint Backlog.

The sprint backlog can be maintained as an Excel spreadsheet.
Software is very useful for sorting large lists against pre-defined fields.

Whilst the sprint is underway the Scrum Master updates the sprint backlog by recording completed tasks.
He or she should also identify actions for those tasks not yet finished.
The estimate of work remaining is calculated and recorded graphically.
This will lead to a burn down chart.

The aim of the team is to try its best to agree to the right amount of work for the sprint.
However, during the Sprint planning meeting the team may get too much or too little.
Tasks may need to be added or removed.

Scrum Master

The Scrum Master upholds the values and the practices of Scrum within the team.

He or she manages the team commitment and makes sure that the work taken on is realistically achievable during the sprint.

The Scrum Master facilitates the daily scrum.
He or she is responsible for removing any obstacles raised during a Scrum team meeting.
Whilst the role could be filled by anyone it is usually a project manager or a technical team leader.

The Scrum team

They are not usually comprised of traditional roles such as programmers or testers.

The team forms a closely bonded unit that is committed to completing the tasks agreed in the sprint.

Whilst the team size is normally 6 to 12 persons there are reports of successful teams consisting of many hundreds.

When larger teams are used they can be arranged into a team hierarchy.
When larger numbers of people are involved the number of levels may increase.
Here the smaller teams choose a representative to attend a ‘higher’ ‘Scrum of scrums’ team meeting to review progress.
These may not be run daily but every 2 or 3 days or whatever time frame is deemed suitable.

More information can be found in the online encyclopaedia Wikipedia.

Under PRINCE2® 2009 [see ‘The Complete Project Management plus PRINCE2’] planning is covered by the Plans theme.
The purpose of the Plans theme is to facilitate communication and control by defining the means of delivering the products (the where and how, by whom, and estimating the when and how much).
[see Plans - Purpose]

PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.