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

The Project Office

Whatever the size of the project it will create a lot of paper work and a variety of procedures.
Even for fairly small projects this can present problems in trying to keep track of originals, revisions, recalls, procedures and schedules etc.

This area needs to be organised so that at any one time anyone can access a required document that is up to date and to make sure that all relevant documents are in place.
Some sort of archiving system with the accompanying procedures should be put in place.
This will have clear links to the Quality Plan.

If the size of the project cannot justify a separate Project Office this job will fall to the Project Manager to organise.
However, this is not ideal as the Project Manager should be concentrating on delivering on the fronts of performance, time and cost (as well as scope).

For larger projects this should become the sole responsibility of the Project Office.
This is the department having accountability to provide this service for all projects within the company.
It can be looked upon as a business resource.
They should have all the necessary expertise, particularly in the use of suitable software and software related reporting systems.

Whilst everyone on the project team should be familiar with interpreting software generated schedules it is not necessary for them to have detailed expertise in its use.
It makes more sense to have a member of the Project Office seconded to the project team, if necessary, to provide these services.

The Project Office may mean different things to different people.
Under PRINCE2® it is referred to as Project Support.

For coverage under PRINCE2 2005 [see Organization - part 3] and under PRINCE2 2009 see [see Organization - The PRINCE2 approach - The project management team - Project Support]

It is really a group that will manage all of the documentation and data aspects across all the projects that the organization has running.
It is inefficient for different parts of the project team to generate and control their own documentation.
For good control it requires consistency and the Project Office provides this.

It will be in a position to help the project with:

Preparation of schedules

The preparation of schedules requires a lot of expertise with the appropriate software.
This is a very good reason for centralising this task with those having a high standard of skills in this area.
The project schedule is a fundamental document for project controls and must be accurate.

Accuracy means that all tasks, start and end dates, dependencies, durations and resource are correct.
In addition, the copy in circulation must be the latest version.
When modification of the schedule is needed it is important that the new version is prepared and circulated as soon as possible.
The Project Office can manage version control, circulation and recall of old copies.

Under PRINCE2 [see ‘The Complete Project Management plus PRINCE2’] the document control is the responsibility of the Configuration Librarian and part of Configuration Management.

Work breakdown structure

The project schedule derives from the work breakdown structure.
The software expertise of the representative from the Project Office is ideally suited to put together the project schedule.
Each department should break down its activities to the smallest work package that can be managed.
Too many sublevels might mean the project scope is flawed in some way.

These activities have to be measurable (cost, effort, who, duration), have clear start and end dates and be the responsibility of just one person (usually a project team member who will delegate the tasks).

When all of the basic tasks are known their interdependencies can then be considered both internally and externally to the relevant department.

Tasks carried out externally need to be carefully considered.

Keeping a record of the work breakdown structure and making sure that versions are controlled can also be carried out by the Project Office.

Progress against plans and budgets

The Project Office should be able to produce reports showing variances against budget.
These could be derived from the scheduling software.
Some liaison with the finance department may be appropriate.

Reports should not be prepared just because the data exists.
The Project Manager should agree what is required with the Project Board.

Resolution of dependencies and issues

The management of dependencies using software is not a straight forward matter.
Software expertise is needed to fully understand the links between the tasks.

The software will be able to update those tasks that comprise the critical path and highlight them to make monitoring them easier.

Management of changes and enhancements

All modifications to the schedule and any other documentation needs to progress swiftly and smoothly.
A Project Office is the best way to maintain good standards in this area.

Tracking and resolution of issues

The person running the Project Office is an extension of the Project Manager and may take action, where warranted to avoid or clarify issues, for example, clarifying aspects of the plan during its preparation.

Some areas that a Project Office would be involved with could be:

• Preparation of schedules
• Time keeping sheets
• Document control
• Scheduling meetings
• Control of meeting minutes

All systems should be kept as simple as possible.
Individual departments may control some of their own specific documentation, for example, operating procedures.

Amongst other items the Project Office might wish to record and archive are task (work package) descriptions, assumptions and constraints,deliverables, specialist skill or resource needs.

Outline plan and milestones

Key milestones (with deliverables, which may well have decision points) should be identified and recorded.

Information security

Information including all documentation has to be organised and available to the project team.
Whether this is hard copies or computerised copies the information is valuable.
As such, matters of security should be considered as well as confidentiality.
It’s worth bearing in mind that information obtained may well be confidential and should be treated as to the wishes of the provider. Computerised material should be suitably backed up.

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