NIWA Project Management Manual

Revised June 2006

NIWA

Project Management

Manual

NIWA Project Management Manual

Revised June 2006

NIWA Project Management Manual

CONFIDENTIAL – Not for distribution outside NIWA

Revised June 2006 National Institute of Water & Atmospheric Research Ltd Gate 10, Silverdale Road, Hamilton P O Box 11115, Hamilton, New Zealand Phone +64-7-856 7026, Fax +64-7-856 0151 www.niwa.co.nz

Hamilton Q:\Managers\pm-manual\PM Manual_V9 June06.doc

http://home.niwa.co.nz/admin/pm/pm-manual.pdf

Contents

1. Purpose 1

2. Context 2

3. Project management in NIWA 4

3.1. General 4

3.2. The key players 5

3.3. Risk management - business and political risk, conflict of interest 6

3.4. Risk management - Intellectual Property 7

3.5. Cultural considerations 8

3.6. Ethics 9

3.7. Health & Safety 9

3.8. Financial system 10

3.9. Contracts 10

3.10. Quality assurance 11

3.11. Performance assessment 11

3.12. Client communications 11

3.13. Tools and resources 12

3.14. Project search 13

3.15. Files and data management procedures 14

4. The project life cycle – some background and definitions 18

4.1. Definitions 18

4.2. Main phases in the project life cycle 18

4.3. Project management process 20

5. Schedule of tasks and responsibilities during project life 25

5.1. Conceive – Recognise need, define project, check feasibility 26

5.2. Conceive – Prepare proposal 27

5.3. The contract 29

5.4. Develop - Identify, sequence, analyse and schedule tasks, obtain approvals, plan work in detail 31

5.5. Execute – Doing the work and monitoring 33

5.6. Finish 35

6. Appendix I – List of abbreviations and acronyms 37

7. Appendix II – Role descriptions and responsibilities in the project management system 38

Project Leader 38

Team Member 38

Project Administrator 38

Project Manager 39

Group Manager 39

National Contracts Manager (NCM) 40

Science Leaders 41

Principal Scientists 41

Client Relations and Business Support Person 41

Key Client Managers (KCM) 42

8. Appendix III – Conflict of interest procedures 43

9. Appendix IV – Confidentiality agreements 44

Formatting checked

NIWA Project Management Manual 1

1. Purpose

The purpose of this document is to:

• Inform staff about the guiding principles of project management in NIWA.

• Provide an overview document, and reference manual of procedures and tools

and linkages to relevant policy and operational systems for managing projects

in NIWA.

The manual is not intended to be too prescriptive in order that it accommodates

operational difference between the various NIWA sites.

The NIWA Project Management Manual was first prepared in 1997. It is revised from

time to time to accommodate changes in NIWA’s operational framework and business

needs.

Comments on content are welcome anytime and should be directed to Director

Operations (Mark James) or [email protected]


2. Context

As a Crown Research Institute NIWA is a commercial science business charged with

conducting scientific research for the benefit of New Zealand and operating in a

financially responsible manner so that we maintain financial viability. Essentially, we

sell the time of our staff to clients (MFish, FRST, NIWA subsidiaries, consultancy

projects) who pay us to produce specified outputs. This puts a strong focus on client

needs/output orientation, accountability, and value for money/effectiveness and

efficiency.

A project management system is necessary to manage the resources efficiently and

standardise procedures in a large and complex business like NIWA. NIWA runs about

2000 projects in a year (totalling revenues of over $100 M) for a wide variety of

clients both in New Zealand and overseas. Projects range in size from a thousand

dollars to over a million dollars, and may take a week, or run for several years.

NIWA’s Project Management System provides a framework and tools that help us

allocate and keep track of the money, staff and equipment resources. It integrates key

aspects of our work namely: risk management, cultural considerations, ethics, Health

& Safety, the financial system, quality assurance, performance assessment and

delivery to the client (see following figure). All billable projects operate under

NIWA’s Project Management System.


Figure 1: NIWA’s Project Management System recognises the project as the basis of NIWA’s operations. It takes into account our need to work across sites (virtual teams), manage multiple projects and work both in New Zealand and overseas. Project management helps us to work under the principle of ‘no surprises’ and as a One-NIWA team, to deliver what the client actually needs to a specified quality in a safe and timely way and within budget, while minimising risk.


3. Project management in NIWA

3.1. General

NIWA runs a One-NIWA operation where staff and equipment resources are utilised

throughout NIWA and its subsidiaries. As a result projects both compete for and

share resources. This calls for good decisions on scheduling resources and prioritising

work, and adhering to time frames. Project management provides a check at an early

stage as to whether resources are available for the job and a means for resolving

resource issues. It also requires that pricing and operations are undertaken in a

uniform manner throughout NIWA. It pinpoints accountability and it helps balance

the workload. It ensures that risks, cultural issues, conflicts of interest and IP issues

are identified at an early stage and provides a process for monitoring these. It

provides a framework for monthly financial reporting and ensures tracking of where

projects are at in terms of finances and resources during the life of the project and

follow-up with the client once the job is completed.

These provisions have benefits for the client in terms of efficiency. For NIWA it

facilitates project work between sites through familiarity of systems. The trail of

documentation (electronic and paper) that it provides is insurance against staff leaving

or becoming ill because it helps others to pick up and carry on with a project. Project

management brings with it a team of administrative assistance for the technical staff

working on a job. Beyond the needs of each individual project, project management is

important for senior managers who need a pan-NIWA perspective of the business.

The key functions of NIWA’s Project Management System are that it:

• recognises the project as the basis of NIWA’s operations, including financial

control and delivery of science outputs, providing a uniform system under which

all billable projects operate;

• delegates scientific and financial responsibility to the Project Leader for day to

day running of the project and delivery of contracted outputs to the required

quality on time and within budget;

• sets agreed objectives for each member of the Project Team which form the basis

of the Team Member’s performance assessment and commitment of Project Team

Members and ownership of their tasks;


• identifies potential risks, cultural issues, conflicts of interest and IP issues at an

early stage and provides a process for monitoring these;

• identifies Health & Safety issues for project team members and NIWA to comply

with Health & Safety legislation and provide a safe work place;

• maintains quality assurance through the peer review of deliverables and science

outputs;

• links project operations to NIWA Policies (e.g., Health & Safety, Ethics, IP

strategy);

• provides tools to assist with the process and its documentation;

• provides a record (paper and electronic trail) of project information and status for

internal and external purposes (auditors).

A list of abbreviation and acronyms in the manual are given in Appendix I. Role

descriptions and responsibilities in the Project Management System are presented in

Appendix II.

3.2. The key players

The key players in NIWA’s project management system are the Project Leader,

Project Manager and Project Administrator.

The Project Leader (PL) is a key driver in the Project Management process. NIWA

delegates scientific and financial responsibility to the PL for day to day running of the

project and delivery of contracted outputs to the required quality on time and within

budget. The PL’s responsibilities also include assessing the performance of each team

member (as input to annual performance review), and reporting any incidents, near

misses, or accidents, and taking appropriate remedial action.

The Project Manager (PM) maintains an overview role to ensure that the objectives are

met to the satisfaction of the client, within budget and on time, and ensuring that the

project deliverables meet NIWA’s standards and the contractual conditions. The PM

assists the PL where necessary with proposal preparation, putting together project

teams and resources, checking and authorising the project plan, maintaining an

overview of project progress (scientific and financial), identifying and correcting out

of line situations, and ensuring all project performance assessments are completed.

The PM will normally be the Project Leader’s Group Manager (GrM), FRST


Programme Leader or Regional Manager (RM) (e.g., in the case of Capability Funded

projects).

The Project Administrator’s (PA’s) role is to work in partnership with science staff

and provide project management assistance through acting as point of initial contact

on all aspects of project management, fielding specific enquiries, advising on the

project management system and process, liaising with project leaders on a day to day

basis, assisting in the project costing, assisting with the Project Management System

checklists and forms reporting and invoicing, provide project code for data capture in

Oracle Financial System, and creating and maintain individual project files. Other roles

and responsibilities and acronyms for these are described in Appendices I and II.

3.3. Risk management - business and political risk, conflict of interest

Examples of projects carrying business and/or political risk include situations where

NIWA:

• gives advice relating to resource consents that stalls major developments;

• gets involved in legal suits involving very large companies;

• prevents an industry from operating the way it has in the past causing it new

and additional costs;

• forces building restrictions (e.g., coastal hazard setbacks) thereby devaluing

existing properties;

• provides information that is counter to policy of the Government (NIWA’s

major shareholder);

• considers the client’s finances are uncertain.

An example of conflict of interest is where NIWA staff are asked to provide

consultancy or expert services against existing or former clients. In these situations

we need to decide whether we take on the job. If we do take on the job then we must

take extreme care in defining the deliverables, the technical content of the report and

recommendations, and peer review of deliverables.

Business and political risk and conflict of interest need to be identified at an early

stage. In practice one needs a fair amount of job experience to do this. Therefore, this

if you have any concerns at all you need advice from appropriate experienced staff

(such as Key Client Manager, DSD, RM), who should also be kept informed

throughout the project and at the peer review stage.


The formal procedure for addressing risk is as follows. Once risk is identified the

matter must be raised with the Regional Manager. The potential conflict of interest

requires a classification into A, B, C or D risk. The Regional Manager should jointly

complete this classification with help from appropriate experienced staff (such as Key

Client Manager, DSD, CFO, NCM), who should also be involved throughout the

process and at the peer review stage. The impact or potential impact should be

considered not only in financial terms but, just as importantly, in terms of potential

effect on the achievement of NIWA’s objectives. A formula for classifying and

prioritising risks is based around the degree of impact of the conflict of interest and the

likelihood of the conflict of interest occurring as:

A high impact, high likelihood

B high impact, low likelihood

C low impact, high likelihood

D low impact, low likelihood

If a rating of A, B or C applies the matter is then referred to the appropriate policy

(e.g., Conflict of interest policy Appendix III). If a rating of D is applied, then the

project can proceed without referral to the procedures.

3.4. Risk management - Intellectual Property

Intellectual Property represents the property of your mind or intellect. In business

terms, this means your proprietary knowledge and it includes inventions such as novel

products and processes, new designs, original expressions of ideas recorded in some

form [including software], new plant varieties and trade marks. Intellectual Property

rights are legal rights protecting intellectual property.

NIWA has developed guiding principles for managing IP and established a formalised

framework for IP management and commercialisation that imposes appropriate

commercial disciplines. You can view NIWA’s IP Strategy at:

http://home.niwa.co.nz/policies/ip/

IP issues should be identified at an early stage and in practice this means that if you

have any concerns at all then you need advice from appropriate experienced staff

(such as Key Client Manager, NCC, DSD, RM or the Commercialisation Manager),

who should also be kept informed throughout the project and at the peer review stage.

Any agreement on IP should be specified in the contract.


During the life of a project a third party may ask you for data. The ‘rules’ by which

third parties access such data vary depending upon the contractual conditions under

which the data were gathered. In handling a request for data, a decision needs to be

made on whether the data should be supplied (“no” is a valid option). If the answer is

“yes”, then there is a need to agree the terms and conditions of release, including

price, before access is granted. In some cases data supplied to a third party is charged

for. The decision for setting a fee for supplying data is to be made in consultation

with the Regional Manager. NIWA has a standard ‘Agreement for Access to NIWA

Data’ form for these purposes (http://home.niwa.co.nz/admin/pm/forms). The terms

and conditions in this form require specifying the purpose to which the data are to be

put, limiting use for that purpose, deletion after use, prohibiting on-sell or transfer, do

not vest IP or copyright, require acknowledgement of NIWA, and place liability in

using the data with the client. These are important clauses and should not be altered.

3.5. Cultural considerations

Te Kūwaha – The Gateway – is NIWA’s Māori Development Unit, set up to advise

and help NIWA staff on all Māori matters. If you anticipate having any business

dealings with Iwi or Māori organisations, contact your local Te Kūwaha member to

ensure that you’re working with the right Iwi or Māori organisation and following

correct protocol.

Iwi issues should be identified at an early stage and in practice this means that if you

have any concerns at all then you must contact Te Kūwaha. To facilitate this a form

must be completed for every project and any unplanned opportunistic sampling

programmes in lakes, rivers and estuaries, and any other projects that could make

contact with, or be relevant to, Iwi or Maori organisations. Project Leaders must

forward copies to Apanui Skipper, the relevant Regional Manager(s), and put a copy

on the project file.

You can get this form at: http://home.niwa.co.nz/admin/pm/forms

You will find an ‘Iwi and Hapu map’ on NIWAnet that you can use to identify the Iwi

or Māori organisation responsible for any area where you plan to work

(http://home.niwa.co.nz/tekuwaha/).


3.6. Ethics

NIWA has a code of ethical conduct governing how we implement provisions of the

Animal Welfare Act 1999 with respect to experiments on animals. Staff conducting

experiments with animals are required to have approval from the NIWA Animal

Ethics Committee (AEC) prior to proceeding. Staff conducting electric fishing or

tagging of animals are required to follow approved protocols.

Application forms along with information about Animal Ethics are available at:

http://home.niwa.co.nz/groups/aec/

3.7. Health & Safety

Health & Safety is an integral part of all projects and the way we work in NIWA. The

purpose of the Health & Safety at Work Policy is to promote safe working practices

and procedures for NIWA operations. The aim is to achieve the highest feasible level

of Health & Safety for employees and, in the long run, maintain an accident free

environment. The effective way of creating a safe working environment, is to set in

place management systems which will minimise risk, monitor known hazards, and

ensure the staff are adequately trained, informed and protected. NIWA also has a

legislative duty (under the Health & Safety in Employment Act) to identify and

manage hazards.

NIWA employees are personally responsible for their own safety and health while at

work and for ensuring their actions do not harm any one else. It is the responsibility

of everyone on the Project Team not just the Project Leader and the Site Safety

Officer. With Health & Safety incorporated into the Project Management System,

there is a prompting and clear documentation of the steps that have been taken to

ensure that NIWA Procedures are adhered to. These procedures have immediate

financial benefits for NIWA that we recoup as reductions on our insurance premiums.

They provide a clear audit trail (electronic and paper trail) for compliance and when

things go wrong so that remedial action can be taken and procedures improved and to

protect us from liability.

Subcontractors employed by NIWA must complete a NIWA subcontractors agreement

and satisfy NIWA that their Health & Safety procedures are adequate. Some clients

have specific Health & Safety requirements and if your team are working on their

sites (e.g., Genesis Energy power stations) they will need special training to comply

with the conditions.


When setting up a project it is compulsory to identify potential hazards,

harm/consequences and means of control. The form ‘Project Management of Health

and Safety (PMS2)’ is designed to assist you with this. Any special high risk activities

(e.g., tagging great white sharks, working in confined spaces) that are not covered by

existing safety procedures need to be notified to the RM along with procedures to

control the hazard at the conception phase.

Information on Health & Safety is available at: http://home.niwa.co.nz/hr/hs/

3.8. Financial system

Good financial management begins with careful estimates of time and resources to

undertake the project, and budgeting these in the Project Pricing Model (PPM). You

must consider things that may affect the price such as risks and insurance for gear

deployed in waterways, the need for weather contingencies and Health & Safety

issues. Agreements with contractors need to be budgeted in a similar manner.

During the life of the project and as the nature of the project changes you will need to

update the project budget (Team Members’ hours) with the assistance of the Project

Administrators. You will also have to complete “% science complete” forecasting at

the time of monthly project monitoring, so that NIWA’s monthly financial position is

know accurately and expenditure can be forecast for the next month. It is important

that team members keep timecards up to date. Timecards are essential for tracking

resources, recognising revenue (i.e., hrs that have been put against billable projects)

and are the only means we have of recording leave. This is all the more important if

we are to manage NIWA effectively and keep track of how we are doing overall.

3.9. Contracts

All jobs must have a contract. Jobs should not start without a contract. The Contract

should specify the agreed price, outputs/promises, deadlines, reporting frequency,

invoicing frequency (if more than one event) and special terms and conditions that

apply (e.g., liability or IP issues). The main purpose of a contract is not so much to

ensure we get paid, but rather to limit our liability in the event the client takes

exception to something we've done, or perceived to have done. If this is going to

happen it will occur some period of time after the completion of the work. If we do

not have a contract in place, then our liability may be unlimited, and the period of time

elapsed since the completion of the work may also be unlimited. Thus, even a $1,000

job could result in NIWA being sued for a very large amount. Contracts are also

required to protect our Intellectual Property.


3.10. Quality assurance

It is the responsibility of the Project Leader to ensure that a project meets adequate

standards and quality agreed to with the client. For some Laboratory activities

standards are through Telarc registration. A Quality Assurance Manual is available

for NIWA’s field teams and the hydrometric and climatic archives to cover our

operations in these areas and meet the ISO9001 standard. In the case of client reports

the NIWA report format sets the standard, although some clients (e.g., ARC and

DOC) specify that their own format be used in some instances. Reviews of outputs

take the form of peer review of client or internal reports, science papers or popular

articles, and a ‘dry run’ for presentations at conferences, resource consent hearings or

public talks. Reviews of client reports must be done very thoroughly to ensure that

technical standards are maintained, that there is a good Executive Summary and that

the report meets the requirements of the contract.

3.11. Performance assessment

The project management system provides valuable data against which to evaluate the

performance of staff at the time of performance assessment. At the start of a project,

objectives are set for each member of the project team. Performance is reported on at

the end of the project. Reports on all the staff members’ projects are considered at the

time of performance assessment and contribute data to the assessment of that person’s

performance.

3.12. Client communications

Continuous communication with the client throughout the project is the key to good

project management. This ensures that the project is client focussed and the clients get

what they expect at the end of the process and with no surprises. The project

management systems helps ensure that the client is kept informed of progress and

issues through regular reporting. It’s a good idea to agree on the nature and timing of

reporting in a contract at the beginning of the project. Use the monitoring phase to

prompt yourself to keep the communication going with the client (and Team

Members), even if it is just a quick email on the project progress. When the project is

complete don’t forget to keep up the communication with the client – there may be

further work in the offing.


3.13. Tools and resources

There are various tools and resources available within the project management system

to facilitate project activities. These are available via NIWAnet and include policies,

procedures, manuals, forms, templates, capability statements, project summaries, and

other information. You will locate these via the NIWAnet home page

(http://home.niwa.co.nz/ and see following figure), under the sections named

‘Admin’, ‘Business Development & Marketing’, ‘Policies, Procedures, Manuals’ and

‘Writing & Presenting’.

Background information, forms and templates and search tools you need for project

management are available at: http://home.niwa.co.nz/admin/pm/


The forms for project management are available as Excel spreadsheets and word

documents. The PMS 1-7 forms (.xls) are the key forms that collect information at

project setup, during the life of the project, and record project completion. Team

Member performance is assessed against the objectives set up at the start of the project

on a PMS 7. The assessment is undertaken on the word document (PMS 7 – back

page) and lodged on the personal file of an individual (not the project file) for privacy

reasons. There are other forms to track contact with Maori organizations,

accidents/incidents, manuscript reviews and agreement for access to NIWA data.

3.14. Project search

‘Project Search’ is a tool available via NIWAnet for finding out about past and current

projects in NIWA. The tool accesses the complete picture of projects as held by the

Oracle financial system back to 1993. it is very useful for compiling track records for

consulting proposals or foundation bids. Project revenues (binned in ranges for

security reasons) can be retrieved, projects are tagged by ‘NIWA Activity’ or ‘Client

Sector’, project abstracts can be obtained and the tool displays information as tables

and lists and usefully dumps to simple Excel tables for further analysis or graphing.


3.15. Files and data management procedures

The NIWA system provides an ‘audit trail’ of hard copy and electronic files to ensure

that important steps are not forgotten (is there a signed contract?), correct procedures

are complied with (Health & Safety), the client is kept informed, that data and

information are stored easily accessible to the Project Team and Project

Administrators, and properly recorded and archived for safe keeping and future

reference.

3.15.1. Hard copy files

Hard copy files of information are generally stored at the NIWA site where the Project

Leader resides. The key items to be stored on the file are:

• The project pricing checklist.

• The signed copy of the contract.

• The PMS forms including the Gantt chart, but excluding the PMS7’s back

page which is located on individuals’ personal files.

• A completed Health & Safety checklist.

• A completed Animal Ethics Committee approval form (if required).

• Copies of invoices.

• The monthly P&L reports for the project.

• Project monitoring forms.

• Progress reports to the client.


• Copies of letters, faxes and emails that document key communications with

the client and subconsultants relating project deliverables, and any variations

to the contract or problems that arise during the project.

• Title pages and executive summaries of client reports or publications.

3.15.2. Electronic files

IT Managers in NIWA have agreed on standards for the Project Volume System

“O:drive”) for managing electronic files associated with projects. These procedures

must be followed. They have incorporated as many of the wishes of the various

regions as possible while trying to keep it simple so that staff will continue to use the

system across NIWA and gain benefit from it.

When a project is established a project directory is created on the O: drive of the

server at the NIWA site where the PL resides (which is usually where most of the

project activity takes place) and the project is administered from, and is named (given

a project code). The project code (sometimes referred to as project number) is unique

to the project. For commercial clients the code reflects the client and year the project

started (see below).

ARC06204 ARC client abbreviation (Auckland Regional Council) 06 financial year in this case 2005/05 2 Region code (where 1 = Auckland, 2 = Hamilton, 3 = Wellington, 4 = Nelson,

5 = Christchurch, 6 = Lauder) 4 4th project started in this 2005/06 financial year

For FRST work the project code describes the FRST programme and year. For

MFish, the code describes the fishing year in which the Ministry tendered the project.

Where the project is subdivided into tasks a project directory is established for each

task and named ‘project code-task name’. The Project Administrator usually assigns a

security classification ‘Restricted consult client’ at the establishment of the project,

unless directed otherwise by the Project Leader (the three options are Open, Restricted

consult client, and Confidential) to reflect the confidentially of the information.

Access to the Project Directory is limited to Project Team Members, and other key

personnel who may have read only access (e.g., IT staff, Project Administrators,

Business Development Managers, Regional Managers). The Project Administrators

set the project up in Oracle and on O: drive and enter this information.

The default directory structure for each individual Project is shown in the figure

below.


This structure is designed to encourage the Team Members to logically organise their

data and information for their own benefit as well as that of others in their team and

those accessing the archived project files in the future. Team Members cannot create

other directories or files at the top level of the Project and cant write files to the folder

folders called ‘Administration’. They are obliged to place files in folders called

‘Correspondence’, ‘Working’, ‘RawData’ or ‘Final’. Project members are, however,

free to create whatever directory structure they like under this mandatory structure.

The ‘.npt’, ‘project.log’ and ‘Security Status’ files are for project administration and

archiving purposes. The ‘.npt file’ records the project name. The ‘project log’ is a

record of when the project opened and closed, and the name(s) of the Project Leader

and Team Members and any changes to these during the life of the project.

The Administration folder contains forms relating to project management. It contains

the Project Proposal in a “Proposal” subfolder (stored as a PDF file so that it cannot be

corrupted), and maybe presentations prepared for the client at the time of bidding for

the work, which serve as valuable reference documents during the life of the project.

It will contain the original Project Pricing Model (stored as a PDF file). Electronic

storage of contract documents is under review. Signed contracts should be scanned

and stored in the Administration folder for security in case of fire or some other

disaster. The folder also contains the Project Management Forms that have electronic

links to relevant documentation (e.g., ‘NIWA Health & Safety Manual’). The PMS7

forms on O: drive are used for setting of objectives at the start of the project. For

privacy reasons they are not used for commenting on performance at the time of


Performance Assessment. Performance review comments are made on a separate

WORD document and filed in the appropriate personnel files.

Project Leaders and Project Managers have full ‘read/write/delete’ access to all folders

within their projects. Team Members have ‘read only’ access to the project’s

‘Administration’ and ‘Final’ folders, but full access to all others. Project

Administrators have full access to all project folders. At the closure of a project

access to all project files is restricted to ‘read only’ for all members to block further

file changes and thereby guarantee the integrity of data, working files, reports, and

publications at the end of the project. Project closure on O: drive will only occur

when the project Leader indicates all files activity has ceased. Under the present

system, FRST multi-year funded projects and consultancy project that run over several

years have the same project code/project directory for the life of the project.

3.15.3. Archives and databases

Because O: drive is not an infinite resource and to preserve the drives from clutter

from old projects, project files are migrated off to CD or other online drives (e.g., R:

drive). Large and significant datasets may be migrated to fully managed database

systems like Tideda, CliDB, Atlas (for images) or the Freshwater Fish Database.

Other databases are being developed, such as FBIS (a system for managing

freshwater-biodata information). The number of fully managed databases is likely to

increase over the next few years. In addition, a Dataset Catalogue will be used to

record some basic information about the type(s) of data collected by each project. It

will also provide advice about which fully managed database (if any) is the preferred

repository for a particular type of data. For collections refer to the Collections

Management Guidelines [http://home.niwa.co.nz/science/collections/] and ensure

samples/specimens are archived.

One of the valuable things about NIWA’s archive system is that at any time in the

future a researcher will be able to seek out the results of a particular project, and be

able to retrieve a complete set of all the files from the archive drive or CD at the time

the project was closed.


4. The project life cycle – some background and definitions

This section provides definitions and terminology used in project management, along

with a description of the key steps in the life of a project. It follows a description in

Young (2002)1 that is an excellent guide to project management. A detailed schedule

of how these steps are carried out in NIWA follows in Chapter 5.

4.1. Definitions

Project Management is the use of leadership, planning, scheduling and control

techniques to produce the project deliverable within the constraints of scope, cost,

quality and time, and to the satisfaction of the client. A Project is a piece of work

with a defined goal or a contractual commitment to a client, a clear start and finish

date, a set of logical and sequenced activities, a defined allocation of resources and a

budgeted outcome. Large projects may be split into Tasks (clearly identifiable units

of project work). Programmes are suites of projects related by content or funding

source (e.g., the FRST funded science programmes).

4.2. Main phases in the project life cycle

Projects fail because work begins without a plan (‘fail to plan = plan to fail’),

milestones are not met (often because project management tools are not used), poor

scheduling of resources at the start, and inadequate supervision and communication

within teams and with the client. Project management provides a framework and a

checklist for addressing these issues at the start and for monitoring progress as the job

progresses.

Projects are born, grow to maturity, and end. Their life may vary from days to years.

The four main phases of the project life cycle are:

• Conceive. Recognise need, determine project is appropriate, that achievement is feasible, prepare proposal or brief, and sign contract.

• Develop. The detailed plan to accomplish the goal is prepared.

1 Young, J. 2002. Orchestrating your project. The New Zealand Institute of Management Central Division Inc. Wellington, New Zealand. 317 pp.


• Execute. The project work is undertaken. Resources are procured, work assigned and the final deliverable is produced.

• Finish. The project deliverable is transferred to the client, resources are released, the project is evaluated, and the report is completed.

The four phases are not necessarily of the same duration. However, all projects

whether they are FRST, MFish or consultancy projects, pass through the same life

cycle. In practice the process means ‘planning the work and working the plan’.

The phase boundaries represent decision points (also called phase exits, exit points or

kill points) when the project can be terminated. They are control points when the

wisdom of proceeding is reviewed.

As the project moves through each phase different types and quantities of resources

are required. Cost and staff levels are usually low at the start, high during execution,

and diminish during the finish phase. An important point is that in the early stages of

the project life cycle there is certainty for the client because the client has a strong

influence over the deliverables and total financial control (i.e., client has not paid

NIWA any money). Near the end of the cycle the client has less influence and less

certainty, because progress payments have been made to NIWA but the deliverables or

final report has yet to arrive.

The first two phases, Conceive and Develop, are crucial to project success even

though they may only make up <10% of the total effort. A good proposal can form

the basis for the contract deliverables and a starting point for the final report.

Although, there can be diminishing returns in associated with highly detailed planning

at the Conceive and Develop stages.

In practice, and because projects may be pioneering endeavours, their plans are based

on assumptions which may prove wrong and see the need for reviewing and re-

planning as the project is executed. For instance, issues encountered during the

development phase may see a need to revisit the conception phase. As a consequence

projects are quite dynamic with iterations back and forth between the phases. Also to

meet challenging deadlines, phases may be overlapped/merged and/or their durations

minimised. Such measures invariably increase project cost and risk, and the quality of

the deliverables can be a casualty. Increased monitoring is required with challenging

deadlines to minimise potential increased costs and risks.


4.3. Project management process

The generic life cycle of a project is shown in the table below. Essentially it’s a series

of sequential steps, although some are done in parallel and some will require iteration.

Every project goes through this sequence. On small projects some of the steps may

just involve a few moments’ consideration and discussion and others are compressed.

On large projects some steps (e.g., preparing a proposal) become almost mini-projects

in themselves.

PLAN (plan the work) PRODUCE (work the plan)

CONCEIVE DEVELOP EXECUTE FINISH

1. Recognise

need

5. Identify

tasks

12. Obtain

approval

13. Assign tasks 17. Conduct handover

2. Define project 6. Analyse

tasks

11. Prepare

plan

14. Finalise

controls

18. Conduct finish

procedures

3. Check

feasibility/risk

7. Sequence

tasks

10. Pre-empt

problems

15. Monitor

progress

19. Evaluate project

4. Prepare

proposal

8. Schedule

tasks

9. Check

resource

availability

16. Take

corrective

action

20. Evaluate product

A short description of each of the steps follows:

1. Recognise need - Projects arise either through unsolicited bottom up initiatives

(by NIWA) or customers request or Request For Proposal (RFP), Expression Of

Interest (EOI), or Tender. They all start with the identification of a need,

problem, or opportunity, and then proceed to the client to define the projects

goals and objectives.

2. Define project - The object is to establish what is the required outcome and

constraints for the project. The client and other stakeholders need to be closely

involved. One of the biggest favours you can do for the client is helping them


identify what they really need (as opposed to what they want). The process

involves brainstorming sessions, and assumptions and risks should be identified.

3. Check feasibility - Further research into specifying the project and weighing

the risks and benefits. We need to answer whether the project is consistent with

the strategic direction of the organisation and whether the benefits outweigh the

costs. Are sufficient finds available? Do we have the resources available to do

the job and can we contract in assistance from outside? What is the cost of not

doing the project? What alternative opportunities might we forego by doing the

project? Can the deliverable be used and is it really needed? Most of these

questions need to be assessed by experienced staff such as managers and

business development staff.

4. Prepare proposal - The proposal invites approval to commit resources to

prepare a project plan. The nature of the proposal will vary with the project. It

could be a letter for small jobs or a more formal proposal for larger projects. In

NIWA templates and resources and project pricing models to assist with this

process. A well-written proposal can form the basis for contract details. The

client may ask you to give a formal presentation as part of the proposal. Time

put in at the proposal stage, is time well spent.

A CONTRACT IS SIGNED. The proposal is accepted and a contract is signed with

the client. In NIWA projects must not proceed without a signed contract.

Steps 5 to 12 that follow may be done to some extent before the proposal goes to the

client as part of detailed planning.

5. Identify tasks - This is an opportunity to elaborate on the project scope. It

involves a work breakdown structure, and the top down decomposition of a

large complex job into manageable chunks of work.

6. Analyse tasks - The individual tasks are examined separately to determine

resources needs and costs and relationship to other tasks.

7. Sequence tasks - A logical order for doing the tasks is mapped out, priorities

are identified, and critical paths determined. Network diagrams are used in this

process.

8. Schedule tasks - Assign dates to tasks. Gantt charts are used in this process.

The Gantt shows summary tasks, start and finish dates, milestones. During the


project life the Gantt can be revised. Your Project Administrator must be

informed when this is done so that Oracle can be updated with any staff or hour

changes - 3 monthly intervals are recommended for reviewing progress against

Gantts for long term projects.

9. Check resource availability - Checking availability of resources against the

schedule of tasks. It will be necessary to make tradeoffs of schedule against

budget. Project priority will determine resources. A high priority project will

have ready access to resources. A low priority project will have to make do

with what’s left. It is important to check the availability of essential support

staff as well as science staff.

10. Pre-empt problems - This is really a form of risk analysis, contingency

planning, future proofing, what-if analysis, and scenario planning. The object is

to identify issues at the beginning of the project so that actions can be taken to

work about them (limit exposure to risk). As a result of this analysis it may be

appropriate to revise the schedule, resources, budget or even project scope.

Involve the client and project manager in the analysis and resolve problems.

11. Prepare plan - This is a road map for executing the project, showing how it can

be accomplished on time and within budget. While the plan is prepared before

execution in practice it is a basis for change and the planning process continues

with refinements, modifications and corrections throughout the project life

cycle. Large, long-duration projects may be planned in stages (the rolling wave

approach), where only the next stage is planned in detail. FRST programmes

with long term funding are executed in this way.

12. Obtain approval - In NIWA this involves formally assigning a Project Leader

and Project Manager and completing the project management paperwork (i.e.,

PMS1-7 and related forms) and appropriate delegations.

13. Assign tasks - Establishing required outcomes and assigning responsibilities for

their completion. Some tasks may be subcontracted out.

14. Finalise controls - Specific agreement with those whose performance is to be

measured. This is done as part of project management setup and in particular

the PMS7 where tasks and deadlines and billable hours are assigned to

individuals.


15. Monitor progress - Common means of tracking progress include reports,

meetings, and visits. It includes specific reporting to the client and internal

monitoring reports. When monitoring ask: What is the actual status? What

caused the deviation if any? The frequency and scope of reporting depends on

the size of the task and should be specified in the contract. It’s usually better to

start with more control and then relax if performance permits.

16. Take corrective action - This is an update of the plan if needed. It calls for

rescheduling resources. The three responses to a deviation are: (1) “no action”,

(2) correct the problem or deviation, and (3) “revise the plan”. The client needs

to be kept informed if there are changes in budget or deadline and agreed

outputs. If not, then it’s an internal matter for NIWA. Variations to the plan

need careful consideration and its important to know when to abandon the

project. It’s never too late to stop (or at least renegotiate terms).

The execution phase ends with the completion of the final deliverable (e.g., final

report).

17. Conduct handover - Ensure that deliverables are as specified in the contract.

They may be a final report and presentation for a client, or completing FRST

Achievement Reports and Parliamentary Reports. In NIWA the internal review

process is a check on quality.

18. Conduct finish procedure - The project is satisfactorily closed down. This

part of the project also needs to be planned like any other task in the project,

otherwise it might go on for ever and never be properly completed. It usually

involves tidying up data and correspondence files (hard copy and electronic),

team performance reviews, cleaning away gear or the experimental work site,

disbanding the project team. A project team celebration may be in order.

NIWA has an administrative checklist (the PMS6) to follow.

19. Evaluate project - A review of the management of the project and the

deliverables. This involves assessing budget performance, schedule

performance, deliverables and client’s initial satisfaction. At this stage the

client will probably not have made full use of the deliverables, so the focus is on

schedule and budget. The evaluation may also look at team member

performance, lessons learnt, methodology improvements, and ways to improve

financial estimates. Ideally, project evaluation meetings should be conducted

internally within NIWA, as well as with the client.


20. Evaluate product - Assess the extent to which the project achieved its

purpose. The review may take place some months after handover. Key

questions to ask are: Is the end product delivering as promised? Are post-

project services satisfactory? What is proving successful? What is proving

unsuccessful? What improvements could be made? It is best that the review

its not conducted by the Project Leader, but by the Project Manager (i.e., Group

Manager or Science Leader). The client’s input is needed. Lessons learnt

should be documented on the project file for future reference.


5. Schedule of tasks and responsibilities during project life

Before a project can be set up in the Project Management System the following must

happen:

• A Project Leader is appointed by the Project Manager, with the assistance of

the Regional Manager where special issues are involved. The Project Leader

appoints the Team Members.

• FRST projects - FRST application is submitted, funded, and contract with

FRST agreed (objectives of FRST programmes are usually treated as separate

projects in the Project Management System, but may be composed of different

projects).

• MFish projects: tender submitted to MFish, project agreed with Mfish,

contract signed. Original Gantt is revised to take into account any variations

to contract or changes in staff and hours

• Other projects - the proposal is approved by the Project Manager (the

relevant Group Manager) with the assistance of the Regional Manager or

where there are special issues involved, it is priced by NIWA’s standard

pricing methodology (the Project Pricing Model), accepted by client

with/without modification and contract signed or covered by previous

agreement. Contracts must be signed as per delegated authority. Regional

Managers are responsible for ensuring that no proposals are submitted by

NIWA staff without the prior approval of a Group Manager.


5.1. Conceive – Recognise need, define project, check feasibility

Task Who2

Discussions with client. Staff member

Discuss business opportunity with GrM (KCM, RM as appropriate). Staff member

Enter ‘opportunity’ on client database (or Maximizer). GrM

Check for any potentially awkward situations. If you have any concerns at

all then you need advice from appropriate experienced staff. Follow

through with analysis and classify conflicts of interest, business risk, and

political risk.

Staff member,

GrM, RM

Check for IP issues. If you have any concerns at all then you need advice

from appropriate experienced staff.

Staff member,

GrM, RM, NCM

Check iwi issues with Te Kuwaha, and complete Register of Contact with

Iwi and Maori Organisations. http://home.niwa.co.nz/admin/pm/forms

Staff member,

GrM, RM

Any special high risk activities not covered by existing safety procedures

need to be notified to the RM along with procedures to control the hazard.

PL, PM

Check resourcing issues with GrM or RM (and ISM if appropriate). Staff member

Run preliminary budget through Project Pricing Model. Staff member, PA,

SSM

Make decision to bid/not to bid. Decision not to bid requires RM approval.

Decision to bid requires approval of RM (Authority Level 5, and authority to

commit the company in writing to income or expenditure up to $100,000) or

higher Delegated Financial Authority in situations where: (1) it’s a Tender,

(2) the client inserts non-standard conditions into a proposal, and (3) the

project life is beyond a twelve-month period. The reason for this is that we

are “committing the company in writing” which this may lock NIWA into

unacceptable conditions. In this situation the proposal must be checked by

the NCM (via the RM). Refer to NIWA Delegation Authority for details.

GrM, RM

Notes:

• A Project Leader will usually not have been appointed at the Conceive stage, and a

staff member will be running with the initiative in consultation with their Group

Manager (GrM) or FRST Programme Leader.

2 Abbreviations are defined in Appendix I.


5.2. Conceive – Prepare proposal

Task Who

Appoint a Project Leader. GrM (RM)

Prepare proposal, which can range from an email (<$2K), to a letter (<$5K), to a

proposal (>$5K), to a bid or tender (usually >$20K). Client proposals must use the client

proposal template and resources. http://home.niwa.co.nz/wp/proposals/

PL

Check to see resources are available (who is available to do the work and are there

conflicting demands for resources from other jobs) through GrMs or TCR (Time

Commitments Register) and ISM (if appropriate).

PL, GrM,

PA, SSM

Price work through the Project Pricing Model (PPM) (this must be done before giving the

client a price). Give project a meaningful short name (<50 characters) that is suitable for

use in Oracle and Project Directories. It is the Science Support Managers responsibility

to ensure the PPM is used prior to proposal/tender. Any proposal priced below the

recommended price must have RM’s approval.

PA, PL

Have proposal reviewed by at least one other person. Any proposal that involves

conflicts of interest, business risk, political risk or IP issues must be approved by a RM.

PL, GrM,

RM

If a Confidentiality Agreement is required by either NIWA or the client, ensure that it is

completed in accordance with NIWA policy (Appendix IV).

PL, GrM

(NCM,

RM)

Arrange reporting frequency/manner with client. PL

Send copy of proposal to client and / or make formal presentation to client. PL

Secure all documentation associated with proposal development (e.g., correspondence,

presentations, proposal, Project Pricing Model) on the appropriate place on the network

(e.g., ‘Marketing’ or ‘New Proposals’ folders) and note location on the database (e.g.,

Maximizer).

PL

Notes:

• Involve all the likely Team Members early on to get their advice on the project (as they

are the ones who will actually be doing the work and have the best ideas on the

time/resources needed), and need to have ownership in the project.

• If the project includes work for the Information Systems Team (e.g., new IT

infrastructure, software development or purchase, new web pages, new databases, on-

line services and after hours IT support), discuss it with the Information Systems

Manager (ISM).

• Consider any costs associated with data/specimen/sample management.

• If a contract is vessel dependant or large-equipment dependant, then confirm availability

(see contact list on NIWAnet).


• Consider risks and insurance for gear deployed in waterways as this may affect project

price.

• Consider the need for foul weather contingencies.

• Consider the need for permission to cross land or access waterways, whether consents

are required from Regional Councils or MSA to build structures or deploy instruments

in waterways, as these may require time for negotiations and cause delays to the project,

which will affect both price and deadlines. Permissions and consents must be sought

and obtained before field work begins.

• Consider Health & Safety issues for NIWA and client Health & Safety requirements

when pricing work as they can affect the way a project is done, special needs and project

price.

• Any proposal priced below the recommended price must have RM’s approval.

• Charge time spent preparing the proposal against project overhead code XXBDEV

(commercial jobs) or current FRST/MFish projects. But, where possible, try to recover

this time later in the project budget (hint – remember to set your project start date far

enough back in time to enable some of the hours spent marketing the job to be budgeted

into the project price).

• For large or high risk projects, identify a person to review the proposal, and budget for

that review.


5.3. The contract

Task Who

Log new job on database (e.g., Maximiser). GrM

Organise a contract. The Contract should specify the agreed price, outputs/promises,

deadlines, reporting frequency, invoicing frequency (if more than one event) and special

terms and conditions that apply. A PA will advise on the appropriate contract.

PL, PA,

The general rules for using ‘precedent’ contracts are to use NIWA “Terms of Engagement’

for small jobs less than $2k, IPENZ Short Form for contracts in the range $2k to 25-30k, and

the longer form NIWA agreement for contracts for contracts >$25-30k.

PA

If presented with a non-standard or generic contract by the client, or if a non-standard NIWA

contract is to be used (there may be liability or IP issues), then the contract must be checked

and approved by the National Contracts Manager who, amongst other things will look for

terms which are detrimental to NIWA’s interests – particularly liability, IP and Restraints of

Trade.

NCM

Get the contract signed off by someone with appropriate delegation authority to commit the

Company to the contract: $3,000,000 (CEO), $1,000,000 (DO, CFO), $500,000 (DSD, DR),

$100,000 (RM, a GeM), $2,000 Field Team leaders. Signatories must check that the NCM

has checked non-standard or generic contracts. PL’s can’t sign contracts, but can approve

operating expenditure for their project up to $5,000 provided it is in the approved current

year’s budget. Group Managers (often the Project Manager) can’t sign contracts, but can

approve operating expenditure for the projects they manage up to $10,000 provided it is in

the approved current year’s budget. Contracts that extend for more than 12 months must be

signed by the CEO.

RM

Advise Regional Manager that contract has been signed (if signatory was other than RM) PL

Ensure client has an existing customer account, or a new customer account is created in

accordance with NIWA Debtors Policy & Procedures, and NIWA Delegated Authorities.

PA, SSM

Two original copies of the contract need to be signed by the client and by NIWA (with one

copy retained by each party).

PA

When an executed contract is received it must be scanned and saved to a central repository

and or the project file (at the location where the project is administered) and copies

(electronic and hard) sent to the relevant persons. The contract status needs to be updated

in Oracle.

PA, SSM

Notes:

• All projects must have an executed contract prior to the project being set up and work

commencing.


• The main purpose of a contract is not so much to ensure we get paid, but rather to limit our

liability in the event the client takes exception to something we've done, or perceived to

have done. If this is going to happen it will occur some period of time after the completion

of the work. If we do not have a contract in place, then our liability may be unlimited, and

the period of time elapsed since the completion of the work may also be unlimited. Thus,

even a $1,000 job undertaken many years ago could result in NIWA being sued for a very

large amount today. (Usually liability is limited to 5 times the contract price). Contracts

are also required to protect our Intellectual Property and Restraint of Trade matters.

• Signatories have the authority to commit NIWA up to their level of financial delegation in

a contract, providing this is on NIWA’s standard terms and conditions, the standard IPENZ

short form, or some variation of these which has been approved (in advance of the work

starting) by NIWA on the advice of the NCM. The NCM will seek the advice of the CFO,

or separate legal opinion as required.


5.4. Develop - Identify, sequence, analyse and schedule tasks, obtain approvals, plan

work in detail

Task Who

Obtain delegated authority to lead project from Regional Manager. PL

Issue project code and set up Project Files (hard copy files, and electronic files on

Project Directory O: drive).

PA

Move all documentation (e.g., correspondence, presentations, proposal, Project Pricing

Model, acceptance letter from the client, the contract) associated with proposal

development to the Project Folder (O: drive) or hardcopy file as appropriate. (Scan

contracts and store on O: drive).

PA, PL

Identify, sequence, analyse and schedule tasks. PL

For jobs <$10K, fill in PMS1, PMS2 Health & Safety. No PMS3 (Gantt chart) is required.

Complete PMS7s for Team Members who are budgeted to do 37.5 hr or more (it is left to

the discretion of the Team Member and Project Leader to complete PMS7s for those

Team Members who have less time budgeted than this, and may be appropriate for

Team Members who have 20 or 30 hours in many projects in order that they get properly

assessed for their contribution).

PL

For jobs >$10K, fill in PMS1, PMS2 Health & Safety, PMS3 (the Gantt chart), and

PMS7s for all team members.

PL

Discuss objectives/tasks with each team member, Complete PMS2, identify to Team

Members any hazards and relevant Health and Safety information (manual and policies

and procedures) and initiate follow-up actions. Attach a printout of hazards to each

Team Members’ PMS7, get agreement, and signatures.

PL, PA

Send all forms to Project Manager for approval and signing. Return to Project

Administrator for filing. Do this before you start the job.

PL

Small jobs may not have a project code of their own, but may be given a generic Small

Contract Job code (SCJxxxx) that is relevant to a particular client. In this case the PA

may function as the PL and PM.

PA

Plan how the project will manage any data and samples it collects, and what will happen

to them when the project is completed.

PL

Consider any data management issues, using the Data Management Checklist on

NIWAnet and consult the DM Guidelines

http://home.niwa.co.nz/ist/dm/checklist/planning/

PL

Identify key words and prepare a short abstract (about 10 lines) for the project. These

are entered by the PA into the O:drive project file (using NPAT) for future reference.

Keywords are used obtain information on the project at some time in the future using the

Project Search tool on NIWAnet. The abstract can be extracted using Project Search to

provide information on the project and when preparing client proposal capability

statements and track records.

PL, PA


Notes:

• It’s a good idea to arrange specific invoicing instructions in a contract (i.e., invoice

monthly or quarterly). That way the PA will arrange to invoice the client at the times that

you pre-agreed. Where possible arrange for invoicing to occur in stages throughout the

project (to spread the income).

• Set SMART objectives when writing PMS7’s. SMART stands for: (1) Specific –

Objectives should specify what they want to achieve. (2) Measurable – You should be able

to measure whether you are meeting the objectives or not. (3) Achievable - Are the

objectives you set, achievable and attainable?. (4) Realistic – Can you realistically achieve

the objectives with the resources you have? (5) Time – When do you want to achieve the

set objectives?. For more information on writing SMART objectives see

http://www.wgrange.com/news/smart.html). The objectives must be agreed between the

Team Member and the Project Leader. That way both parties understand what’s required

and the grounds on which personal assessment will be undertaken.


5.5. Execute – Doing the work and monitoring

Task Who

Hold meetings of project team to review progress (monthly or less frequently as

appropriate) and follow-up with reports to client (even if it is just a quick email on the

project progress). Complete PMS5 (Monthly Project Monitoring form).

PL, PM

Check monthly financial reports from Oracle to monitor performance against budget and

Gantt chart. Fill in the Monthly Project Monitoring form (PMS5) on Project Directory (O:\

drive). Write comments on how project has gone, and on any out of line situations and

corrective action. Notify PM that this is done and/or forward copy to PM to sign off. (If

the job is too small to have a folder, send PM an email with an update).

PL, PM,

PA

Continue to re-schedule resources as necessary, update Gantt chart (record changes to

schedule of activities and milestones and peoples hours), update staff time and project

budget in Oracle.

PL, PA

Make sure that any incidents, accidents, or near misses occurring that month are

reported and that a copy of the reports are appended to the PMS5 and included on the

project file, and that Team Members are notified of any changes needed to work practice.

PL, SSM,

RM

Report to client as agreed, notify any changes from the plan, and preferably send them a

brief report even if nothing has been pre-arranged.

PL

Changes to the contract must be approved by the client in writing. PL

Estimate ‘% science complete’ for all projects for forecasting or milestones for MFish

invoicing.

PL

Undertake forecasting in February, March, April, May of each year. PA,

SSM,SAM

Arrange with Project Administrator to invoice the client at the times that you pre-agreed

by filling out an ‘Invoice request form’ (if specific invoicing instructions are not indicated

on the contract i.e., invoice monthly or quarterly).

PA, PL

Notes:

• ‘% science complete’ relates to the amount of technical work/science done, that we could

reasonably bill the client for if the project stopped now (the amount of work done, and

not the percentage of the budget spent). The percentage is based on the full project effort.

The ‘% science complete’ for each project indicates the project revenue earned (and may

be invoiced) for that month. For MFish projects invoicing is based on completed

milestones. This information is used in turn to determine the amount of Work In

Progress (WIP) (where the project has completed more work than we have actually billed

the client for) and the amount of Revenue In Advance (RIA) (where we have already

billed the client but haven’t completed the tasks yet).


• NIWA forecasting predicts the actual revenue and costs at the end of the project, or at the

end of the financial year, which ever occurs earlier. It uses the end of month financials to

review the status of projects, and those where there is a variance between forecasted

profit and the budgeted profit. Forecasting is undertaken monthly, with special emphasis

in February, March, April, and May.


5.6. Finish

Task Who

Client reports must use the Client Report Template

(http://home.niwa.co.nz/wp/reports/). Ensure peer review of report/papers is completed,

format checked and review form put on file. Reports must be signed off by the reviewer,

and “Approved for release” by the RM (who may delegate this to the GrM or FRST

Programme Leader, or another nominee). MFish project reports must use the MFish

manuscript progress sheet and any report templates required by MFish. Some client may

require special formats/templates to be used (e.g., ARC and DOC).

PL, RM,

BDM

Send copy of report to client (only as PDF if electronic). Make presentation as required.

Ensure there is a covering letter on file to record details of handover.

PL

Send copies of reports/papers (PDF of final reports) to library/regional publications files. PL

Tidy up the Project Folder (on O: drive) by deleting unnecessary files, giving remaining

files informative names, checking that source code includes appropriate comments, and

writing ‘readme.txt’ files. The owner of the data, restrictions on the use of the data, and

the name of persons who took the samples, should be recorded, either in a ‘readme.txt’,

in the header of the data file, or within the data when appropriate. Use the Data

Management Checklist on NIWAnet and consult the DM Guidelines

http://home.niwa.co.nz/ist/dm/checklist/completion/ to determine any other DM

steps appropriate for project completion. Make sure that all essential correspondence

(including emails and faxes) is filed.

PL, IT

Put a copy of the final report as a DOC and PDF file in the ‘Final’ folder of the Project

Drive.

PL, PA

Complete PMS6 located in the Project Folder (O: drive). In the case of small commercial

jobs there may be no electronic file, so fill in hardcopy documentation on the hardcopy

project file. Sign the form, print it, send it to the PM for signature, then file on project file..

PL

Request PMS7s from PA with page 2 attached. Complete assessments for Team

Members and send PMS7s to PA to distribute to Team Members and obtain signatures.

(Do this at end of job rather than waiting till end of year). The PA will put the PMS7’s on

the Team Members personal file.

PL, PA

Prepare project data for archiving or entry into a long-term database. PL, PA

Make sure that all time and expenses have been put against the project (i.e., come to

charge)

If specific invoicing instructions are not indicated on the contract (i.e., invoice monthly of

quarterly), arrange to invoice the client for the balance owing. If this is the case, fill out

an ‘Invoice Request Form’. and send it to the PA. Send a letter to the client with the

final invoice, to let the client know that the job is complete and to thank the client for the

business. Follow up to see if client is satisfied.

PL

Get all equipment demobilised/cleaned and specimens/samples/cores are put into the

store/warehouse. Ensure samples are coded with the project code and name of Project

Leader. Consult the appropriate Collection Management Guidelines on NIWAnet if your

samples are to be submitted to a fully managed collection.

PL


Have a de-briefing session at the end of the project as it helps to recognise the things we

do well and learn from our mistakes, and improve delivery to clients.

PM, PL,

TMs

The project will be closed pending archive. PA, IT, PL

Notes:

• NIWA papers, short articles and reports must be peer reviewed to ensure they meet

contracted outputs, for technical content and quality of presentation and to ensure they

meet contracted outputs. Reports must be appropriately formatted, with quality graphics

and consistency in style, and have a clear concise Executive Summary and Title Page

appropriately laid out. (see NIWAnet http://home.niwa.co.nz/policies/comm/ for

instructions). Quality assurance is the Project Leader’s responsibility.

• Client reports must use the Client Report Template. Where projects carry a high degree of

business or political risk they need very thorough review. A competent reviewer(s) must

be approved by/chosen in collaboration with the Key Client Manager. It may be

necessary to have more than one reviewer to adequately cover different aspects of the

work. The reviewer should focus on the technical quality of the report and how it

addresses the study objectives. The individual (usually the PM) undertaking the

“Approved for release by” evaluates the report at a higher level, and should check that the

report has addressed the clients questions, the contract conditions, and any contentious

issues in the report.

• Archive involves several steps that will vary from project to project. It involves moving

all project files on the Project Directory to CD or online disc archive. It may involve

migrating data to fully managed databases like Tideda, CLIDB or the Freshwater Fish

Database. The Project Directory may stay open for 6 to 12 months after ‘project end’ to

allow for editing of reports and papers at editor’s or client’s request.

• A de-briefing session at the end of the project should be organised by the Project

Manager. This helps to recognise/celebrate the things we do well and learn from our

mistakes, all which improve delivery to the clients. For small jobs involving few people

it may be as simple as the Project Leader putting an email of ideas on file. For large and

complex projects the team should debrief, with the Project Manager and maybe the

reviewers present. Information on the client’s view of the work should feed into this. A

summary should go to file.

• Don’t forget to keep the communication going with the client. It may be some months

before the client has made full use of the deliverables. Check back with the client to

gauge level of satisfaction and whether there is any follow up work to do or new

opportunities.


6. Appendix I – List of abbreviations and acronyms

Regional

PL Project Leader

PM Project Manager

TM Team Member

GrM Group Manager

SL Science Leader

PS Principal Scientist

PA Project Administrator/Analyst

CRBS Client Relations and Business Support Person

IT IT staff

RM Regional Manager

ARM Assistant Regional Manager

SSM Science Support Manager

Corporate

BDM Business Development Manager

CEO Chief Executive Officer (R. Pridmore)

DO Director, Operations (M. James)

DSD Director, Strategic Development (B. Cooper)

DR Director, Research (R. Murdoch)

CFO Chief Financial Officer (K. Thompson)

GeMABB General Manager, Aquatic Biodiversity & Biosecurity (D. Robertson)

GeMAMNP General Manager, Aquaculture and Marine Natural Products (A Jeffs)

GeMANPE General Manager, Atmosphere, Natural Products & Energy (M.Poulter)

GeMF General Manager, Fisheries (J. McKoy)

GeMFC General Manager, Freshwater & Coasts (C. Howard- Williams)

GeMEII General Manager, Environmental Information & International (B. Biggs)

GeMMDO General Manager, Maori Development & Oceans (C. Severne)

ISM Information Systems Manager (A. de Wit)

KCM Key Client Managers

NCC National Contracts Manager (Tim Mahood)

SAM Systems Support Manager (Kevin Whyte)

Role descriptions and responsibilities are detailed in Appendix II.


7. Appendix II – Role descriptions and responsibilities in the project

management system

Project Leader

The Project Leader’s role is to plan, communicate with the team, report regularly to

the client, keep records of important communications, identify to Team Members any

hazards and relevant Health and Safety information (manual and policies and

procedures) and initiate follow-up actions, deliver contracted outputs to the required

quality on time and within budget, and lead the project on a day-to-day basis. The PL

has scientific and financial responsibility, including authorisation of all expenditure

within the project budget (up to $5,000 per item). PLs cannot sign contracts. The PL’s

responsibilities also include assessing the performance of each team member (as input

to annual performance review), and reporting any incidents, near misses, or accidents,

and taking appropriate remedial action.

Team Member

The Team Member’s role is to assist with development of Project Proposal and

costings, carry out agreed objectives, keep the project leader informed of progress,

issues, and problems, keep to hours allocated for the job, report on any incidents, near

misses or accidents to the Project Leader and fill out the appropriate forms and

timesheet, and deliver contracted outputs to the required quality on time and within

budget.

Project Administrator

The Project Administrator’s role is to work in partnership with science staff and

provide project management assistance through acting as point of initial contact on all

aspects of project management, fielding specific enquiries, advising on the project

management system and process, liaising with project leaders on a day to day basis,

assisting in the project costing process by completing the PPM, assist with the

preparation of Project Management System checklists, forms and Gantt charts,

formalise and ensure that regular internal project monitoring reporting and invoicing

takes place, provide project code for data capture in Oracle Financial System, and

create and maintain individual project files.


The Project Administrator works under the guidance of the Science Support Manager

whose role is to act as a business partner to science staff by providing an efficient and

effective financial and administrative support service to the region. See generic

description of the Science Support Manager at:

http://home.niwa.co.nz/hr/jobs/expired/002_desc

Project Manager

The Project Manager’s role is to ensure the smooth operation of projects, so that the

objectives are met to the satisfaction of the client, within budget and on time, by:

assisting Project Leaders in proposal preparation and putting together project teams

where appropriate (e.g., commercial work), checking and authorising the project plan

(Gantt chart), ensuring all stages of the Project Management System are completed,

maintaining an overview of project progress (scientific and financial), identifying any

out of line situations, “variance” issues or “exceptions” , taking appropriate corrective

action and/or ensuring that the Regional Manager is informed, and ensuring all project

performance assessments (PMS7s) are completed, and approving operating

expenditure for their project up to $10,000 providing it is within the approved current

year of budget. The PM will normally be the Project Leader’s Group Manager, FRST

Programme Leader (to ensure they have both scientific and financial responsibility for

their programmes) or Regional Manager (e.g., in the case of Capability Funded

projects).

Group Manager

Staff in this role manage a group of science staff and are responsible for assisting

regional management, staff management, and project management. This role is

responsible for communication, delivery of projects led by group members, and

ensuring work is done in a timely and efficient manner to the required quality.

The role of the Group Manager in project management is:

• To act as Project Manager on allocated projects led by group members.

• Maintaining an overview of allocated projects and ensuring all stages of Project

Management System (including PMS7s) are completed.

• Monitoring overall progress (scientific & financial) of all relevant projects in

association with support staff.


• Providing accurate exception reporting and advance warning to Regional Managers

on project deviations.

• Monitoring that contracted outputs are delivered to the required quality, on time, and

within budget.

See generic description of the Group Manager role for more information.

National Contracts Manager (NCM)

The responsibilities of the NCM are to:

• maintain a central electronic register of all PMS1 forms, using these forms to oversee the process of ensuring signed contracts are completed;

• maintain a central register of all generic contracts, both electronic and hard copy; HARD COPY STORED ON PROJECT FILES?

• maintain a central register of all other non-standard contracts, both electronic and hard copy; HARD COPY STORED ON PROJECT FILES?

• provide advice and assistance to NIWA staff on the composition and the completion of commercial aspects of generic and other non-standard contracts;

• ensure generic and other non-standard contracts that are subject to term / date limitations are completed or renewed before they lapse;

• liaise with CFO and independent legal authorities where necessary, ensuring all communications with independent legal authorities are copied to CFO;

• look for early identification of conflicts of interest;

• co-ordinate the management of conflicts of interest according to policy;

• co-ordinate the management of confidentiality agreements required by clients from NIWA;

• undertake an audit role to check on the regional registry and control of standard contracts, including whether contracts are duly completed; are completed correctly; and correct authorities are being used;

• undertake, as a further audit role, a check to ensure all contracts entered into by NIWA are in accordance with the Project Management Manual.


Science Leaders

Science Leaders are established scientists with leadership roles in core areas of NIWA

science, and are generally associated with significant research programmes/groups of

projects funded primarily by FRST and/or MFish. While Science Leaders have no

formal role in project management, they will be designated Project Managers for

FRST projects in their programmes and will act in the role of peer review of

deliverables.

Generic description of the Science Leader role for more information.

Principal Scientists

This is no longer (as of 2004) a role but a title that recognises the exceptional

contribution that a staff member makes to NIWA's science, whether it be research,

consultancy or products and services. In general it aligns with the Level 4 science

competencies. A Principal Scientist may also, but not necessarily, undertake a role

such as Group Manager, Science Leader, National Centre Leader, or Production Unit

Leader.

Client Relations and Business Support Person

In some science teams the Group Manager will delegate client relations and business

support to a Client Relations and Business Support (CRBS) person. This is to share

the workload and provide the opportunity for a member of the team to expand their

knowledge and responsibilities within the team’s activities. The responsibilities of the

CRBS is to:

• maintain a sound knowledge of the groups key consultancy clients and business,

and liaise effectively with the clients;

• provide information as required for submissions related to NIWA’s business

development activities in support of the Business Development Manager;

• initiate and lead consultancy projects.

• update consultancy data (client details, proposals pending, lost and won) on the

database (e.g., Maximiser).


Key Client Managers (KCM)

NIWA is a large organisation, interacting in a complex manner with a wide range of

clients. For key clients we have a person who is a single point of contact through

which all higher level/strategic interaction are managed (where the client wants that).

This is to ensure that we don’t place ourselves in any awkward situations. KCMs need

to be informed of ALL interactions between the designated client (or client sector) and

NIWA staff from the beginning. The KCM can therefore ensure that only one proposal

is being prepared by NIWA, act to co-ordinate a suite of proposals for broader funding

pots, ensure consistency in our pricing and contractual arrangements to each client, co-

ordinate the packaging and presentation of new ‘products’ to the client, ensure that the

client receives regular reports on progress and ensure we have no conflicts of interest.

KCMs facilitate smooth interactions with NIWA’s clients, although should in no way

inhibit existing rapport that individual staff may have with our key clients. The

following are the Key Client Managers:

FRST Rob Murdoch

MFish John McKoy

Air Quality Jeff Bluett and Guy Coulson

Aquaculture Industry Andrew Jeffs

Auckland Regional Council Bryce Cooper

Australia Bryce Cooper

Contact Energy Dennis Jamieson

Department of Conservation Bryce Cooper

Fishing Industry John McKoy

Genesis Dave Roper

LINZ Fred Smits

Meridian Energy Dennis Jamieson

Mighty River Power Dave Roper

Ministry for the Environment Bryce Cooper

Capability Fund Bryce Cooper, Rob Murdoch

USA Murray Poulter


8. Appendix III – Conflict of interest procedures

If a conflict of interest has been identified as an A, B or C risk then that matter

is escalated and requires a formal response.

The co-ordination of a management of the conflict of interest under A, B or

C classification will be provided by the NCM.

The NCM will work with the RM to develop a risk management plan for

each conflict of interest under an A, B or C classification, the classification

having been jointly completed by the RM.

If a conflict of interest is identified as A or B type risk the DO and CFO

must approve the risk management plan.

Implementation of the risk management plan will be led by the RM, with

monthly reporting on program completed by NCM to the DO and CFO.

If a conflict of interest is identified as a C type risk, the response will be led

by the RM, as follows:

• To consult with the affected parties with a determination to reach an

agreement on the issue. If the agreement is not received there should

be notification to the parties of some self-imposed restriction on

NIWA activities in order to allay one or more of their concerns.

• The DO and CFO should be notified as to the outcome of all C type

risks.


9. Appendix IV – Confidentiality agreements

• The requirement for a Confidentiality Agreement by either a client or

NIWA should be recognised at the Proposal stage.

• If a Confidentiality Agreement is required by a client from NIWA, the

matter is raised initially with the RM, and the NCM is notified. The

NCM will co-ordinate the response in conjunction with the RM. Once

completed the Agreement will be held by the PA, and will also be

logged onto Maximizer.

• If in accordance with policy the RM determines that a Confidentiality

Agreement is required by NIWA, the client should be required to

complete the standard NIWA Confidentiality and Non-Disclosure

Agreement. Once completed the Agreement will be held by the PA,

and will also be logged onto Maximizer. A copy of NIWA’s Standard

Confidentiality Agreement is available on NIWAnet.

NIWA Project Management Manual

Documents

Transcript of NIWA Project Management Manual