Immigration New Zealand Process Management Framework for Visa ...

1

Immigration New Zealand

Process Management Framework

for Visa Processing

2

Contents

Lists of tables and diagrams .............................................................................................................. 4

Key terms .......................................................................................................................................... 5

Executive Summary .......................................................................................................................... 6

1. Introduction .............................................................................................................................. 8

1.1. Background ........................................................................................................................ 8 1.2. What is a Process Management Framework? ................................................................... 10 1.3. Process management cycle .............................................................................................. 11 1.4. Overview and administration of INZ’s process management ............................................ 13 1.5. Standards for INZ process management ........................................................................... 15

2. Governance framework and responsibilities ........................................................................... 17

2.1. Process definitions ........................................................................................................... 17 2.2. Who owns business functions?......................................................................................... 20 2.3. Who undertakes process analysis? ................................................................................... 21 2.4. Process roles and responsibilities ..................................................................................... 21 2.5. Who signs off process change? ......................................................................................... 23 2.6. Changes to INZ products .................................................................................................. 25

3. Process management cycle ..................................................................................................... 27

3.1. Summary of INZ’s process management cycle .................................................................. 27 3.2. Change initiation .............................................................................................................. 28

4. Phase one: Design ................................................................................................................... 30

4.1. Purpose............................................................................................................................ 30 4.2. Process map: Design ........................................................................................................ 30

5. Phase two: Model ................................................................................................................... 32

5.1. Purpose............................................................................................................................ 32 5.2. Process map: Model ......................................................................................................... 32 5.3. Success criteria................................................................................................................. 35 5.4. Metrics............................................................................................................................. 35 5.5. Pilots ................................................................................................................................ 38 5.6. Evaluating process exceptions .......................................................................................... 42

6. Phase three: Implement .......................................................................................................... 43

6.1. Purpose............................................................................................................................ 43 6.2. Process map: Implement .................................................................................................. 43 6.3. Implementation plan ........................................................................................................ 44 6.4. Communications .............................................................................................................. 45 6.5. Implementing process exceptions .................................................................................... 45

7. Phase four: Monitor ................................................................................................................ 46

7.1. Purpose............................................................................................................................ 46 7.2. Process map: Monitor ...................................................................................................... 46 7.3. Scheduling ....................................................................................................................... 47 7.4. Ongoing reviews of INZ process ........................................................................................ 47

3

8. Phase five: Refine .................................................................................................................... 49

8.1. Purpose............................................................................................................................ 49 8.2. Process map: Refine ......................................................................................................... 49

9. Resources and tools ................................................................................................................ 51

9.1. Style information ............................................................................................................. 51 9.2. Templates ........................................................................................................................ 53 9.3. The Global Process Manual .............................................................................................. 53

Appendix A: Ownership of information and process repositories................................................... 55

Appendix B: Simple sign-off template............................................................................................. 56

Appendix C: Business functions out of scope of Process Management Framework ........................ 58

Appendix D: Visa Services process owners (managers) ................................................................... 59

Appendix E: Change request template ............................................................................................ 60

4

Lists of tables and diagrams

List of tables

Table 1: Process roles and descriptions ............................................................................................ 11

Table 2: Standards for INZ process management ............................................................................. 15

Table 3: Business functions directly impacting visa processing ......................................................... 17

Table 4: Process levels ..................................................................................................................... 19

Table 5: Ownership of business functions by INZ branch................................................................... 20

Table 6: Roles and responsibilities for business functions (R.A.C.I. diagram) ..................................... 22

Table 7: Sign-off matrix for process proposals .................................................................................. 23

Table 8: Degrees of impacts ............................................................................................................. 24

Table 9: Examples of degrees of impacts .......................................................................................... 24

Table 10: Change initiation process steps ......................................................................................... 29

Table 11: Design process steps ......................................................................................................... 31

Table 12: Model process steps ......................................................................................................... 33

Table 13: Common metrics for visa processing ................................................................................. 36

Table 14: Reasons for undertaking a pilot ........................................................................................ 38

Table 15: Pilot process steps ............................................................................................................ 39

Table 16: Materials needed in preparation for a pilot ...................................................................... 41

Table 17: Potential risks and benefits of exceptions ......................................................................... 42

Table 18: Implement process steps .................................................................................................. 44

Table 19: Monitor process steps ...................................................................................................... 47

Table 20: Refine process steps ......................................................................................................... 49

List of diagrams

Diagram 1: Elements of a process management framework ............................................................ 10

Diagram 2: Process management cycle ............................................................................................ 12

Diagram 3: Overview of Immigration New Zealand's process management ..................................... 14

Diagram 4: Allocation of change requests and work items ............................................................... 21

Diagram 5: Summary of Immigration New Zealand's process management cycle ............................. 27

Diagram 6: Change initiation process map ....................................................................................... 28

Diagram 7: Design process map ....................................................................................................... 30

Diagram 8: Model process map ....................................................................................................... 32

Diagram 9: Pilot process map .......................................................................................................... 39

Diagram 10: Implement process map .............................................................................................. 43

Diagram 11: Monitor process map................................................................................................... 46

Diagram 12: Refine process map ..................................................................................................... 49

5

Key terms

Bottom-up change A process change initiated from within INZ.

Branch One of the major groups within Immigration New Zealand: Compliance,

Risk and Intelligence Services; Service Design and Performance;

Settlement, Protection and Attraction; and Visa Services.

Business function An aspect of INZ operations which affects or is affected by operational

processes.

Degree of impact How significant the consequences of a process change is, categorised as

high, medium, or low.

Ownership Who is accountable for the functioning and governance of a process or

business function.

Process exception Approved change to a process which makes it different from the globally

accepted norm. This does not include variations or nuances in processing

needs that are defined at the establishment of new global processes.

Process level The level of granularity at which a particular process sits, ranging from

the most strategic (level 1 processes) to the most task-orientated (level 5

processes).

R.A.C.I. diagram A table that indicates who is responsible and accountable, and who

should be consulted and informed, for process proposals affecting any

given business function.

Responsible Who is responsible for day-to-day oversight of a business function and

who usually undertakes analysis for a change in a process/business

function.

Accountable Who approves (or declines to approve) a process proposal and is

accountable for a process/business function.

Consulted Major stakeholders for a process and who should be given the

opportunity to input into the process proposal.

Informed Minor stakeholders for a process and who only need to be told of a

process change or new process.

Top-down change A process change initiated from the Minister of Immigration, Immigration

Policy, or an external stakeholder such as the Office of the Ombudsman.

6

Executive Summary

Effective process management within Immigration New Zealand (INZ) supports process consistency

across the global INZ office network and reinforces operations that are geared toward continuous

improvement, while being responsive to changeable business needs.

Ownership and administration

INZ’s Process Management Framework (PMF) establishes the governance of visa processes by

setting out the ownership of business functions that are integral to visa processing operations.

Responsibility for the management of a particular process or process change therefore depends on

the level of the process being defined and the range of impacts on associated business functions. 1

Visa Services own lower-level process change and business functions associated with the

basic visa processes.

Service Design and Performance (SDP) own higher-level process change and also business

functions associated with the overall functioning of the visa processing system. Where a

lower-level process change impacts on one of the business functions owned by SDP, analysis

of the change is undertaken by SDP.

Compliance, Risk and Intelligence Services (CRIS) own business functions related to the

overall management of risk and intelligence services, and the specialist resolution of visa

processes associated with those services.

Ownership of business functions also influences which parties are consulted and informed of any

process proposals under consideration.

Sign out of processes is dependent on the branches2 that own those business functions impacted

and the degree of the impact. Low- and medium-impact process proposals are signed out by fourth-

tier managers, while high-impact process proposals are signed out by third-tier managers or the

Business Rules and Innovation Committee (where multiple branches are impacted). Proposed office

or regional exceptions to processes are also signed out by third-tier managers.

Overall administration of the PMF and the associated Global Process Manual is the responsibility of

SDP. When a work request for process introduction or change is received, it is SDP’s responsibility to

identify the impacts initially and allocate the item to the appropriate branch.

Analysis, implementation and monitoring

Once allocated, process proposals undergo a process management cycle consisting of several

phases:

Design: The phase in which analysis and consultation is undertaken.

Model: Runs concurrently with the design phase and is where process options are analysed

in detail (based on evidence and data available), success criteria and metrics are defined,

and any pilots are run if needed.

1 See p.20 for a list of business function ownership by branch. 2 A “branch” refers to the major groups within INZ: Visa Services; SDP; CRIS; Settlement, Protection and Attraction; and the Office of the Deputy Chief Executive.

7

Implement: Ensures that the processes created during the design and model phases are

translated into real operational changes.

Monitor: The phase in which the introduced process is reviewed and evaluated. Ongoing

monitoring of process performance and adherence is also fundamental to the success of the

system.

Refine: Ensures that processes are reviewed effectively and continuous improvement is

achieved.

As one of the primary aims of the PMF is to ensure consistency across INZ’s office network, to be

approved process exceptions need to demonstrate that not having an exception would create a

significantly detrimental outcome to the business.

Publishing processes

Process proposals should be presented in a way that best fits the needs of the intended

audience.

Managers who decide whether to approve a process proposal should be given succinct

information with enough detail of impacts to make an informed decision. Process maps for

simple changes or changes that have small impact are not always necessary.

Process analysts may need to create process maps to demonstrate both current-state and

future-state processes effectively, and to communicate processes to stakeholders.

Frontline staff should be given process steps to the required level of granularity. Process

maps are used frequently.

Process mapping software should be used, such as Microsoft Visio. Templates for change

requests and memorandums for sign out by decision-making managers are included in the

appendices.

8

1. Introduction

1.1. Background

Vision 2015 envisages consistent, efficient and transparent decision-making processes that

support Immigration New Zealand’s (INZ) global visa operations “to be recognised as a trusted

partner, delivering outstanding immigration services and bringing in the best people New

Zealand needs in order to prosper”. Therefore INZ needs to continually improve processes and

enable quality decisions to be made quickly and effectively by:

Achieving consistency through centralised process management.

Being responsive to the processing needs.

Creating transparency in the way that process change is undertaken and

communicated.

A Process Management Framework (PMF) is crucial to the continual improvement of

performance in an ever-changing business environment and, by facilitating this continual

improvement, is vital for realising and safeguarding process-based benefits associated with

Vision 2015. The PMF achieves this principally through the clear definition of visa process

ownership and management; clear communications between people involved in implementing

processes and frontline staff; and defining the administration of a Global Process Manual.

Problem statement 1.1.1.

INZ needs an effective process management regime to ensure rigorous yet responsive process

design and control, and to define best practice. In doing so, it enables consistent and

transparent change management across INZ’s visa processing operations. An effective approach

to process management must address exceptions to global processes that may be desirable

from time to time to ensure fit-for-purpose processes.

Scope of this framework 1.1.2.

The PMF achieves the following aims:

Clarifying process ownership, and management roles and responsibilities for visa

processing.

Outlining processes for designing, approving, documenting, publishing, embedding and

maintaining business processes down to a procedural level. This includes a process for

approving exceptions that may be required for genuine business reasons.

It is also supported by the Global Process Manual.

The PMF includes processes and business functions of INZ that impact visa processing directly.

Functions owned by Visa Services, Service Design and Performance (SDP) and Compliance, Risk,

and Intelligence Services (CRIS) are the primary focus because of the core roles these have in

the visa processing system. Other branches within INZ, such as Settlement, Protection and

Attraction (SPA) are also referenced.

9

Detailed discussions of INZ’s non-visa processing functions, such as settlement, refugee

services, border operations and the management of appeals and complaints, are excluded from

this framework.3 However, the PMF is designed to enable further work on non-visa processing

process management in the future: the business functions, the use of process maps and R.A.C.I.

diagrams, and the outline of the Global Process Manual are designed to be easily replicated or

added to.

3 The PMF aligns with level 4 and 5 initial process design undertaken for Vision 2015 as it applies to visa application processing. At the time of this PMF’s development, this does not include the design of non-visa application processes. Inclusion of non-visa application processes in this PMF was considered inappropriate as the future operating model processes for non-visa processes would not yet be defined. Their inclusion would likely cause confusion in some areas of INZ if the PMF were implement before the establishment of the processes it is designed to manage.

10

1.2. What is a Process Management Framework?

A PMF provides robust and responsive process management mechanisms for business

operation, enabling the realisation of effective, efficient, consistent and transparent processes.

To do this, it establishes:

Well defined ownership of processes.

Responsive and robust analysis mechanisms for process design and change.

Strong review mechanisms.

Trusted feedback and process refinement loops.

Governance of process management tools and the use of templates.

Elements of a Process Management Framework 1.2.1.

A PMF has several elements. For INZ’s PMF, these are grouped into four sections: definitions,

governance, process flows, and tools and resources.

Diagram 1: Elements of a process management framework

Each element of a PMF is important for realising process benefits. The elements address:

Which processes are included in the framework.

Who owns business processes and the roles associated with them.

How the visa processing change is completed and sign off achieved.

How monitoring and review mechanisms are undertaken.

How staff at different levels of the organisation participate in the process

management system.

• Process definitions

• Role definitions Definitions

• Process ownership

• Process responsibilities

• Sign off processes Governance

• Change and analysis processes

• Piloting and implementation processes

• Review processes, plus metrics and methodologies Process flows

• Templates

• Style guide

• Global Process Manual

Tools and resources

11

Which tools are needed to achieve effective process management for INZ.

Process management roles 1.2.2.

Several roles are influential in managing organisational processes. They are important for the

generic process flow of change requests and analysis, and are outlined in table 1 below.

Table 1: Process roles and descriptions

Process role Description

Process administrator In charge of handling change requests and new work items, and allocating those work items to the appropriate branch. Also in charge of administrative functions in the Global Process Manual.

Process manager In charge of managing process analysis and approving some aspects of process change, such as implementation plans. This corresponds with the person responsible in the R.A.C.I. diagram (see p. 22).

Lead analyst In charge of completing the major analysis tasks for a process change and preparing relevant documentation. This work is often delegated from the process manager to the business lead.

Stakeholders Parties interested in a process and potentially impacted by any process change. This corresponds with the persons consulted and interested in the R.A.C.I. diagrams

Process owner In charge of deciding whether a change should be undertaken. This corresponds with the person accountable in the R.A.C.I. diagrams.

Secondary analyst Analysis functions may be delegated to analysts other than the lead analyst, if deemed necessary by the process manager.

Monitoring analyst In charge of reviewing processes that have been introduced or changed, as well as ongoing monitoring of BAU processes.

For the practicalities of analysing process changes, roles may be divided more intricately than is

discussed above, or as outlined in the R.A.C.I. diagrams on page 22. For example, although the

R.A.C.I. defines one actor as being “responsible” for a business function, in practice more than

one person may be needed to progress a process change. The parties practically “responsible”

for undertaking work on a process may include a process manager, a lead analyst and a

secondary analyst.

1.3. Process management cycle

A PMF achieves the optimisation of a process or a set of processes through the application of a

process management cycle. This cycle progresses through the design, modelling and

implementation of process change to the monitoring and refinement of the processes

introduced. The cycle has to be repeated to ensure continual improvement of processes and to

guarantee they remain fit for purpose.

Each phase of the process management cycle is described in more detail below.

12

Diagram 2: Process management cycle

Design 1.3.1.

Design focuses on how end-to-end work occurs; identifies any problems that need to be

addressed in this process; and identifies what process changes need to be made. This phase

should:

Identify what processes are undertaken currently (i.e. define the current state).

Define what the processes should be, including what, when, where, who and how

questions about the future process (i.e. define the desired future state).

Consider dependencies, environmental factors, risks and benefits of a process change.

Ensure that management controls and metrics are properly accounted for in the design.

Model 1.3.2.

The modelling phase establishes the detail of the design of the proposed process(es). It

includes:

The elaboration of design options, as well as costs, benefits and impacts.

Process modelling used to determine opportunities for change, as a basis for discussion,

and to document the intended end state for training and compliance purposes.

Firm definition of key metrics and success criteria.

Assess whether a pilot should be completed on a case-by-case basis and prepare for and

undertake any such pilot(s).

Information for models can be gained through direct observation, interviews, surveys, or

workshops.

Implement 1.3.3.

Implementation includes the planned execution of processes and the definition of benefit

realisation. It can be full implementation or partial implementation (e.g. the use of a pilot or

phased implementation). Effective implementation will have the following characteristics:

Design

Model

Implement

Monitor

Refine

13

Key stakeholder engagement and support was obtained at the design and modelling

phases.

Objectives, deliverables, success criteria and metrics are defined properly.

Timeframes for deployment consider required dependencies.

Communications, training, behavioural, technology and policy changes may be included

in implementation.

Monitor 1.3.4.

The performance and outcomes of processes are monitored in this phase. A post

implementation review approach may be used. The phase is critically linked to the success

criteria and metrics, which are identified and defined through the model phase.

The purpose of the monitoring phase is to do the following:

Identify what information needs to be evaluated and the purpose of this evaluation.

Employ a systematic methodology to capture and assess information.

Refine 1.3.5.

Process refinement is aimed at continuous improvement and process optimisation. This

includes:

Retrieving process performance information from model and monitor phases.

Identifying opportunities for improvements, cost savings, or process bottlenecks.

If processes become out-of-sync with business environment, a larger-scale process

review may be needed.

The process management cycle begins again from the design phase to realise process

refinement.

1.4. Overview and administration of INZ’s process management

The diagram below is a high-level overview of INZ’s process management. It indicates process

flows and who has responsibilities for process change stages:

The change process extending from requestors from within INZ.4

A process management administrator receiving and allocating a work item to the correct

branch.

Substantive analysis.

Process sign off.

Implementation of a process.

Monitoring and review processes.

4 This may originate from outside INZ, but in most cases is likely to be requested to an actor within INZ who will then pass the request onto the process administrator.

14

Diagram 3: Overview of Immigration New Zealand's process management

Administration of INZ process management 1.4.1.

The overall administration of INZ process management is the responsibility of SDP. This includes

ownership and administration of the Global Process Manual (see section 9.3 for more

information on the Global Process Manual). SDP will also have the following particular

responsibilities:

Receipt change requests and the administration of a change register.

Acknowledge the receipt of a change request.

Ensure that details of a change request are entered into a change register.

Allocate change requests or work items to the correct INZ branch (see section 3.2 for

more information on allocation processes).

Administration of the Global Process Manual.

Define who has access to change processes and other roles within the Global Process

Manual.

Oversee of INZ’s Process Knowledge Management toolset in its entirety, although

ownership of some individual process knowledge tools will fall to other INZ branches (see

Appendix A).

Updating the Global Process Manual is the responsibility of the process administrator.

15

1.5. Standards for INZ process management

INZ’s PMF aims to ensure consistency across the visa processing network to achieve better

quality, efficiency and customer services. Those designing, amending, documenting and

monitoring processes should hold consistent standards so that processes are administered and

communicated effectively. Detailed standards for various aspects of the PMF are discussed in

the relevant sections of this framework. A brief outline of these standards follows:

Table 2: Standards for INZ process management

Activity Applicable standards

Acknowledging change requests

When a change request is made from the business, an initial acknowledgement should be sent to the requestor within one working day of the request, and a more substantive response within two weeks of the request.

Design and modelling processes

Analysis undertaken during the design and modelling phases of the process management cycle must be based on available evidence and data.

Design of processes includes:

Impacts – Assessments, based on evidence and data, of who and what will be affected by the proposed changes and how these will be affected (see p.33).

Risks and benefits – Assessments of what the pros and the cons of the process proposals are, in terms of business/immigration benefits, and converse costs and risks (see p.33).

Appropriate consultation – Based on the business functions associated with a process proposal and the consultation needs indicated in the R.A.C.I. diagram (see p.22).

Definition of success criteria and metrics – Defined early in the process, where possible based on measurable outcomes (see pp.34-37).

Amending processes A final decision to amend processes should be taken if there are demonstrable benefits to the process change (this will be determined through the model phase and/or through the success criteria and metrics for the processes).

Alternatively, there may be a change in the business environment that requires process amendments. This should also be based on the demonstrable advantages of taking up a process change.

Documenting processes

The documentation of processes during the model phase should be done to the standards set out in Section 9.

Documenting processes for the purposes of sign off may use process mapping (such as Microsoft Visio flow charts) and, where process mapping is used, the associated standards. Often for small changes a process map is not required for sign off.

Documenting processes in final publication should use the standards set out in the Global Process Manual (see section 9.3)

Sign-off standards Documentation used for gaining agreement to process change or new process introduction should use the appropriate sign-out memo (see section 9.2).

Monitoring process Two complementary approaches should be undertaken in the monitoring of processes that have been introduced to INZ (see section 7.4).

Adherence to processes: Adherence to processes is primarily monitored by the Performance and Assurance team in SDP, through measurements such

16

as Q3 assessments.

Performance of processes: Ongoing monitoring of the system is also undertaken by: o A post implementation review should be undertaken at a set time. This

should be judged against set success criteria and using metrics defined during the model phase.

o Performance issues revealed through quality assurance mechanisms (such as Q3 assessment undertaken in the Performance and Assurance team in SDP).

o A proactive regime of process review that examines processes identified as needing review in a given year.

These two mechanisms use pre-set criteria for the assessment of process success.

Process exceptions Process exceptions generally have a higher degree of sign-off requirements than global process change (with the exception of high-impact global process change). Therefore, any process exception affecting Visa application management seeking a deviation from the global process norms must have approval from a third-tier manager (see section 2.5.1).

Important note: A process exception does not include the establishment of different processes that account for needs at diverse locations throughout INZ’s office network.

17

2. Governance framework and responsibilities

2.1. Process definitions

Processes are defined in terms of their business functions and, in some instances, process

levels. These business functions and their interrelationship with one another are discussed

below.

Business functions 2.1.1.

A business function is an aspect of INZ operations which affects or is affected by operational

processes (e.g. identity management / specialist identity resolution, quality management,

document management). The set of business functions described below are designed to

accord as much as possible with the business capabilities developed for Apply, and Assess

and Decide for the new operating model.5 The table below outlines the business functions

that affect visa processing directly.

Table 3: Business functions directly impacting visa processing

Business Function Description

Visa application management

Activities associated with receiving, processing and deciding visa applications in accordance with instructions, operational guidelines and quality standards.

Visa application management is divided between higher level processes (levels 1 to 4) and lower level processes (level 5).

Business rule management (level 5)

Activities associated with the definition and ongoing management and maintenance of workflow, business rules and criteria that support the visa processing system (to level 5).

Channel management (excluding online channels)

The management and maintenance of application and enquiry channels through which customers, partners and intermediaries interact with the visa processing system, and INZ interacts with external agencies regarding applicant information.

This excludes online channel management (i.e. for online applications, Visa View and related functions), which is included in the ICT systems management function.

Client risk assessment Activities associated with assessing and mitigating operational risk – including verification of information.

Client risk and intelligence management and resolution

The design and maintenance of the overall risk framework that supports/governs activities associated with managing and mitigating risk, as well as maintenance of templates and tools that support operational assessment of risk.

The collection, analysis and conversion of customer, business and risk data into intelligence and triage rules.

This includes specialist risk resolution, which is the specialist risk

5 Disparity between business functions defined in the PMF and business capabilities defined in the Vision 2015

operating model arises from the need to define definite ownership of business functions in the PMF, while ensuring that the ownership is relatively easy to follow. Making business functions equivalent to business capabilities would have required a much more complex operation of the PMF.

18

assessment of individual cases.

Document management (physical documents)

Activities associated with storing, using, transporting and managing documents submitted by applicants. This excludes the management of electronic documentation, which instead is included in the ICT systems management function.

ICT systems management Management and maintenance of business applications (e.g. AMS, Online Services) relating to the visa processing system.

This function also includes the management of digital documents and information.

Identity management / specialist identity resolution

Activities associated with collecting, matching, resolving and sharing biometrics and biographic identity information.

Activities performed by specialists within the visa processing system that provide identity resolution expertise.

Policy and business rule management (level 1 to 4 business rules)

Activities associated with the definition and ongoing management and maintenance of policy criteria and higher-level business rules (levels 1 to 4) that support the visa processing system.

Process management The activities associated with the design, management, monitoring and control of business process framework integral to the visa processing system.

Product management Activities associated with managing, maintaining and updating product suites including immigration instructions, tools and publications associated with visa processing, as well as defining and managing new products.

This includes the management of online channels such as online submission, Visa View, and related website functions.

Quality management The design and maintenance of the overall quality framework that supports visa processing. This includes the overall system health, but excludes performance management of individual staff and quality review within the visa process (e.g. “2pc”).

Quality review within the visa process falls within the Visa application management function. The performance management function falls outside the scope of the PMF.

Specialist resolution (medical)

Activities performed by specialists within the visa processing system that provide medical resolution expertise.

Note, specialist identity services and risk resolution is included in the Client risk and identity management and resolution function.

A list of other business functions that affect the Apply and Assess and Decide processes, are

outlined in Appendix C. These should also be considered when determining the impacts of

any kind of process change. However, they do not influence who should undertake analysis

and who should sign off process change for visa application processing directly.

Interrelationship between business functions 2.1.2.

Business functions often affect each other directly, with a change in one functional area

requiring corresponding changes in other areas. For changes affecting multiple areas, the

19

core analysis will be undertaken in one branch6, which will need to ensure that proper

consultation is undertaken with affected areas.7 The ownership of each business function

does not change and representatives from all impacted groups need to be involved in final

sign off.

Process levels 2.1.3.

INZ’s visa processing operation has five process levels which range from the most strategic

(level 1 processes) to the most task orientated (level 5 processes).

Table 4: Process levels

Level Description

Level 1 Domains Outlines strategic areas of INZ’s visa processing operation

Level 2 Processes Details process phases for particular strategic areas (e.g. interest; enquire; apply; assess and decide)

Level 3 Activities Details a particular activity flow for high-level processes (e.g. receive; lodge; assess; verify)

Level 4 Tasks

Details high-level office tasks that need to be undertaken to achieve an activity (e.g. what processes need to be undertaken to verify the information provided with a visa application)

Level 5 Steps Details specific steps and procedures to achieve each task (e.g. a support officer emails template letter A to the client)

Level 1 and 2 processes have the greatest impact on the functioning of INZ. Due to the

high-level significance of level 1 and 2 processes across INZ, process changes at these levels

are less frequent, and their analysis and sign off subject to more rigour. Generally these may

be evaluated through a separate project, with separate process analysis and sign-off

procedures.

Process Level 3 changes are also rare, but may be the subject of discussions from time to

time.

Process levels 4 and 5 are subject to the most frequent change and are most prone to

process variation.

Level 4 processes 2.1.3.1.

Level 4 processes set out INZ office processes in general terms, with reference to generic

roles and teams, system interactions and an indication of the tools and templates to be

used. They are less detailed than level 5 and do not define the following:

6 The term “branch” referenced throughout this document refers to the major subdivisions within INZ: Visa Services; SDP; CRIS; and SPA. It does not refer to INZ offices that carry out visa processing operations, as previously has been commonly used within INZ. 7 In practice, changes that affect multiple business functions will often be analysed by SDP.

20

Detailed roles, such as “a senior immigration officer”.

Specific system interactions, such as which screens to go to in an online tool.

Specific templates to use when interacting with a client.

Level 5 processes 2.1.3.2.

Level 5 processes set out the following:

Detailed standard operating procedures.

Specific roles.

System interactions, such as the use of a specific AMS application type.

Templates, such as a specific template letter.

They are more detailed than level 4 processes and give firm details for staff to undertake

each aspect of the visa application process.

2.2. Who owns business functions?

What is process ownership? 2.2.1.

Process ownership indicates who is accountable for the functioning and governance of a set

of processes. Generally this ownership is determined by the business function that the

process falls under.

Ownership of business functions 2.2.2.

Ownership of business functions related to visa processing is spread between Visa Services,

SDP, and CRIS. The ownership of specific business functions is outlined in table 5 below.

Table 5: Ownership of business functions by INZ branch

Business functions Owner

Visa application management (level 5) Visa Services

Business rule management (level 5) Visa Services

Channel management (excluding online channels) Visa Services

Client risk assessment Visa Services

Document management (physical documents) Visa Services

Specialist resolution (medical) Visa Services

Visa application management (levels 1 to 4) SDP

ICT systems management SDP

Policy and business rule management (levels 1 to 4) SDP

Process management SDP

Product management SDP

Quality management SDP

Client risk and intelligence management and resolution CRIS

Identity management / specialist identity resolution CRIS

21

2.3. Who undertakes process analysis?

Who undertakes analysis of a process or process change is determined principally by who owns

the business functions affected by a change.

If the business functions owned by only one branch are affected, that branch should

undertake analysis.

Where several business functions owned by different INZ branches are affected, the

substantive analysis and consultation will be undertaken by SDP. The exception to this is

where a process impacts on business functions owned by CRIS and Visa Services, but not

by SDP. On these occasions, analysis and consultation will be undertaken by CRIS. The

diagram below illustrates this.

Where a process change or a proposal to a higher-level business function also affects a

lower-level function (e.g. a proposal affecting both level 4 and level 5 visa application

management processes), analysis is undertaken by the person responsible for the higher-

level business function (in the example, the person responsible for level 4 visa application

management processes). However, the stakeholders affected by changes to both higher-

and lower-level processes should be consulted as appropriate.

Branches that own business functions

Who does the analysis?





Service Design &

Performance

Visa Services

Service Design &

Performance

CRIS

Visa Services

CRISVisa Services

Service Design &

Performance

Service Design &

Performance

CRIS

Diagram 4: Allocation of change requests and work items

Work items should be sent to the relevant manager in charge of allocating work items. Usually

this is a fourth- or fifth-tier manager.

2.4. Process roles and responsibilities

The R.A.C.I. diagrams below indicate who is responsible and accountable, and who should be

consulted and informed, for process change affecting any given business function:

Who is responsible (R) indicates who will usually be undertaking analysis for a change in

a specified process.

Who is accountable (A) indicates who usually is required to approve a process change.

Who should be consulted (C) indicates major stakeholders for a process.

Who should be informed (I) indicates minor stakeholders for a process.

22

Table 6: Roles and responsibilities for business functions (R.A.C.I. diagram)

23

2.5. Who signs off process change?

The sign off of a process depends on the INZ branches (i.e. Visa Services, SDP, CRIS, or SPA) impacted

by the change and the degree of its impact. The table below shows the sign-off authority in any given

instance.

Table 7: Sign-off matrix for process proposals

INZ branch impacted Degree of Impact

High Medium Low

Multiple branches (e.g. both SDP and Visa Services)

Operational System

Integrity Committee

4th tier managers

responsible

4th tier managers

responsible

Single branch 3rd Tier manager

responsible

4th tier manager

responsible

4th tier manager

responsible

If deemed appropriate, sign-off authority may be delegated to a lower-tiered manager.

Sign off for any change may also be escalated to a higher decision making body: Fourth-tier managers

reviewing a medium-impact change may refer a decision to the Operational System Integrity

Committee (OSIC) or the OSIC may refer a decision with a high degree of impact to the Immigration

Leadership Team for a decision or for noting.

Process exceptions 2.5.1.

In addition to the above processes, where exceptions are sought from a particular INZ office, region

or business area to undertake processes that are different from those defined globally, authority

must be given by the third-tier manager(s) responsible as well as the decision making authority

outlined for usual approvals.

“Exceptions” do not include variations or nuances in processing needs in different locations that are

defined at the establishment of new global processes (e.g. the particular verification needs for a

particular market).

An exception is a change to a process which makes it different from the globally accepted

norm.

A variation is a distinct process for a location (or locations), which is either defined as part of a

new process, or is a process change put in place of an existing variation.

Discussion of the analysis of exceptions is outlined at section 5.6, with a discussion of how to

approach the communication of process exceptions included at section 6.5.

Determining sign-off needs 2.5.2.

Sign-off needs are identified early in the assessment process by the lead analyst in conjunction with

the process manager. To do so, a lead analyst needs to consider:

The INZ branches impacted – which branch of INZ owns the functional area or areas are

affected by the change (i.e. Visa Services, Service Support, CRIS, or SPA).

24

The degree of impact – the significance of the consequences of a change.

The degree of impact can range from high to low, and is dependent on several risks and potential

impacts.

The degree of impacts should be identified early in the Design process (see section 4). This

assessment should always be informed by evidence at hand and where possible quantifiable

measures should be used. Although it is not possible to provide quantifiable criteria for this within

the PMF due to the number of variables in immigration process design, the measures should

correspond with the metrics outlined in section 5.4. The logic of the sign-off channel should be

demonstrable through the evidential measures used (see also p.31)

Table 8: Degrees of impacts

Degree of impact

Descriptions

High Likely to:

have significant impacts on business processes or

carry a moderate or significant risk to the immigration system or

have a high impact on immigration stakeholders, markets or clients or

carry significant reputational risk for INZ or the New Zealand Government.

Medium Likely to:

have a moderate impact on business process and

pose no more than a moderate risk to the immigration system and

have a moderate or minor impact on stakeholders or immigration clients and

carry minimal reputational risk for INZ and the New Zealand Government.

Low Likely to:

have only minor effects on the business and

carry minimal risk to the immigration system and

carry minimal reputational risk for INZ and the New Zealand Government and

not have a significant impact on clients or other immigration stakeholders

Examples of high, medium and low impact changes, and the rationale for the assessment of their

degree of impact, are outlined below.

Table 9: Examples of degrees of impacts

Degree of impact

Example of change Rationale

High Requiring all applicants to undergo testing for an emerging disease before applying for a visa.

May have large and across-the-board impacts on visa processing.

May have a negative impact on some clients (declined applications), but its inclusion could be important to the health of New Zealand and the functioning of its health system.

High A country entering into a visa waiver agreement with New

Introducing this may have a significant impact on the processing in some INZ offices and may

25

Degree of impact

Example of change Rationale

Zealand also have significant importance to New Zealand’s international relationships.

Has an impact on fee revenues for INZ.

High Adding or removing several people from a list of people prohibited from entering New Zealand.

May carry a significant reputational or political risk to New Zealand or the New Zealand Government.

Medium Removing a requirement that students who since the age of 17 have spent all their time in New Zealand from providing a police certificate from their country of citizenship.

Moderate impact on applicants for student visas and on application processes.

Small risk to the objective of Government character policy.

Medium Requiring one nationality to undertake an extra, minor, step in the visa application process. e.g. requiring Indonesian student applicants to provide evidence of funds in a particular form.

Scope of the impact is limited.

May increase the resource needs for processing, but is unlikely to be a significant impact.

May have moderate impact on applicants from country requiring additional step.

Medium Opening a new visa application centre with a current visa application centre provider.

May have a moderate to significant impact on a INZ office that processes those applications, but this is likely to be localised.

Has known processes for implementing visa application centre change, as the provider current services visa applications for INZ in other locations.

Low Changing the storage location of documents, with no adverse impact on their accessibility or security.

Minimal risk of change, with minimal impacts on INZ offices.

Low A new AMS application type which replicates existing functionality, and which does not add any significant time to the processing of an application.

New AMS type is likely to have small impact on INZ office processes, approach to decision making, or staff performance of functions.

Likely to have no impact on clients.

2.6. Changes to INZ products

Changes associated with wider process changes 2.6.1.

Product changes (to guides, checklists, template letters, the INZ website and other publications)

associated with process proposals only need to be signed out by owner of the business function.

They do not need to be signed out by impacted stakeholders, or owners of business functions

impacted by the wider process change. Such stakeholders should be consulted in accordance with

the R.A.C.I. diagram on page 22.

26

Changes to forms and immigration instructions should be agreed to by Visa Services, Legal Services

and other directly-impacted MBIE stakeholders before submission to the Deputy Chief Executive.

Changes without impacts on processes 2.6.2.

Where they do not have associated impacts on processes, changes to the following products do not

need to follow the ordinary change request or sign-off processes:

Forms.

Guides.

Template letters.

Referencing or typographical errors in the INZ Operational Manual.

Such changes requests should be emailed to the Operational Policy team in SDP.

Sign off is sought through Operational Policy team in SDP and, in the case of changes to forms or

the INZ Operational Manual, through the Deputy Chief Executive or the Minister of Immigration.

Note that changes to the INZ Operational Manual that do not address referencing or typographical

errors should follow the ordinary change request process (see p.28).

INZ website changes 2.6.3.

Any changes to the INZ website relating to visa application processes or requirements should be

prepared using the applicable website change template, and should be sent to the Operational

Policy team for approval before being sent to the web team for publication. However, INZ office

specific web pages do not need to be approved by Operational Policy and may be sent to the web

team for publication after approval from the relevant Area, Assistant Area or Market Manager.

27

3. Process management cycle

3.1. Summary of INZ’s process management cycle

The process management cycle includes Design, Model, Implement, Monitor and Refine phases. Each of these is outlined in the following sections. The

following process map outlines at a high level the relationship between processes undertaken during the Design, Model, Implement, Monitor, and Refine

phases of the process management cycle.

Summary of process management cycle

Des

ign

Mo

del

Imp

lem

ent

Mo

nit

or

Ref

ine

Init

iati

on

Initial analysis

Consult

Make proposal

Analyse & model

Prepare implementation

materialsImplement

Review process model

Assess against success criteria

Sign off proposal

Sign off implementation

Further significant design work

needed?

Yes

Minor adjust process model (if necessary)

No

Start

Initiation of process

change or introduction

Define metrics and success

criteria

Undertake pilot if

necessary

Informs the process monitoring


planInputted into implementation plan

Collect information

from metrics

End

Collect evidence and data

Diagram 5: Summary of Immigration New Zealand's process management cycle

Design Model Implement Monitor Refine

28

3.2. Change initiation

The process management cycle outlined in the following sections is particularly useful for

the analysis and sign out of complex changes. Steps undertaken for straight-forward or

low-impact process changes, while following the same processes, should be brief and

responsive to INZ’s needs and the needs of any requestor.

Initiation processes are undertaken before Design, Model and Implement processes.

Change requests 3.2.1.

“Bottom-up” 3.2.1.1.

Process change can come from the “bottom-up”, as a change initiated from any within INZ,

usually this will be initiated by INZ offices. Such change requests need to be signed out by a

market manager or a more senior manager.

Change requests can be made in one of two ways:

Changes to processes may be sent through the Global Process Manual or emailed to

the Operational Policy team in SDP.

Changes to immigration instructions and INZ products (e.g. templates, forms, guides)

may be emailed to the Operational Policy team in SDP.

“Top-down” 3.2.1.1.

“Top-down” process change, as a change initiated from the Minister of Immigration,

Immigration Policy, or an external stakeholder such as the Office of the Ombudsman.

Nevertheless, these follow the same basic process flow. However, these do not need to

follow the same request sign-off or change request templates.

Process map: Change initiation 3.2.2.

Change process initiation

Pro

cess

ad

min

istr

ato

rP

roce

ss

man

age

r

StartRequest received / Identify need for

change

1 4

5

2

EndPrioritise

work item

Check priority and assess ownership

Allocate to lead analyst

Allocate work item to relevant

INZ branch

3

Update change register

6

Diagram 6: Change initiation process map

29

Table 10: Change initiation process steps

Step Process Description Actor

1 Receive request / identify the need for change

Need for change is identified. A change is requested and received by the process administrator.

The change request needs to have been signed out by a market manager or a more senior manager if it is received from a Visa Services office.

Acknowledgement is sent to requestor within one working day of receiving the request. A more complete response is sent to the requestor within two weeks of the request being received.

Process administrator

2 Check priority and assess ownership

Process administrator undertakes high-level prioritisation and assessment of ownership of the process change request.


3 Update change register

Process administrator updates change register, or ensures that it is up to date.


4 Give work item to relevant INZ branch

Work item is given to the relevant branch INZ that owns the process that is being considered for change.


5 Prioritise work item within team work programme

The process manager, who sits within the branch that owns the process being considered for change, prioritises the work item in the context of their own work programme.

Process Manager

6 Allocate to a lead analyst

Work item is allocated to a lead analyst to undertake substantive design, modelling, and implementation work. Secondary analysts are also allocated if required by the scope of the work.

Process Manager

Prioritisation of work items 3.2.1.

Ordinarily the priority of work items is determined by the manager of the relevant business area that

undertakes substantive analysis. However, direction may be received from the Immigration

Leadership Team (ILT) on the prioritisation of large pieces of work or any other piece ILT is interested

in.

30

4. Phase one: Design

4.1. Purpose

The design phase is the primary phase in which analysis is undertaken within the process management cycle. Ensuring the proper engagement of

stakeholders and effective analysis of processes is fundamental to achieving better processes. The model phase runs concurrently to the design phase, and

inputs into analysis and final process modelling decisions.

4.2. Process map: Design

The process map below outlines the processes undertaken during the Design phase of the process management cycle.

Design process map

Pro

cess

m

anag

erLe

ad a

nal

yst

Stak

eho

lder

sP

roce

ss o

wn

er

Start

End

Stakeholder review of proposals

(where appropriate)

Identify stakeholders

Analyse core problem and

high-level options

Prepare proposal

Finalise proposal

1

2

3 4 5 6

7

8

9

Review proposal

Impact assessment

to determine sign off channel

YesAgree to change?

No

Model process change

Diagram 7: Design process map


31

Table 11: Design process steps


1 Analyse core problem and high-level options

Identify the core problem that needs to be addressed, analyse initial options for addressing it. This should also provide an indicative timeframe for analysis and possible implementation.

Lead analyst

2 Impact assessment to determine sign off

The severity and the range of impacts of the options presented in the proposal should be assessed to determine the appropriate level of signoff.

As far as possible, the severity of the impact (as determined for the purposes of sign off) should be informed by quantifiable measures of impact such as the number of products or markets impacted, efficiency or quality measures. The logic of the sign-off channel should be demonstrable through this evidential measure.

Lead analyst and process

manager

3 Identify stakeholders

In identifying probable impacts of options (these will be refined during the model phase), the stakeholders who will need to be consulted or considered during the rest of the design and model phases are also identified.

This stage should also indicate the success criteria and the metrics that will inform the further design and model work. Specifically this informs which data and evidence to use to inform the process development and will be expanded upon and defined more firmly during the model phase.

Lead analyst

4 Model process change

Undertake model processes outlined at 5.2 Model. Lead analyst

5 Prepare proposal

A draft written proposal is prepared for final sign off of the process change.

Lead analyst

6 Stakeholder review proposals (where appropriate)

Any stakeholders that should be given provision to vet the final proposal are given an opportunity to review and critique the final written proposal. This may include, for instance, subject matter experts, ICT experts, or Legal Services.

Lead analyst and

stakeholders

7 Finalise proposal

The written proposal should be peer reviewed and finalised. It should be presented using a template that is appropriate to the level of signoff that has been identified in step 7. Any additional cover memos, if needed, should also be completed at this phase.

Any critical stakeholders who need to give formal agreement to the proposal may be given an opportunity to review the final proposal.

Lead analyst

8 Review proposal

The process manager should undertake a final review of the process proposal and any accompanying documentation before it is submitted to the decision making body for final consideration. Any aspects requiring amendment are given back to the lead analyst to complete.

Process manager

9 Agree to change

If the process owner is the only person responsible for final sign off, they decide whether or not to sign off process change. If final sign off is not undertaken by the process owner, the written proposal is submitted to the appropriate decision making body and a final decision is taken whether or not to proceed with the change.

Process owner / Decision makers

32

5. Phase two: Model

5.1. Purpose

A model is a simplified version of the processes being designed (or which are in use currently).

The Model phase is often undertaken during the Design phase. The substantive analysis,

definition of options, metrics and success criteria, and pilot processes (if required) occur during

the model phase.

Process modelling is undertaken to:

Validate that the proposed change meets all business needs, while producing real

operational benefits.

Predict how well the process will operate under different conditions (e.g. with a change

in staffing resources or an increased volume of work).

Compare process designs by altering variables.

Define and test measurable criteria for the desirability and the success of a process

proposal.

5.2. Process map: Model

Model process map

Pro

cess

man

ager

Lead

an

alys

tSt

akeh

old

ers

Pro

cess

ow

ner

Pilot analysis and processes

Process analysis

Start

Collect available data and evidence

Agree to options, metrics and success

criteria?

Analyse process options in depth

Model process options

Consult with stakeholders in the modelling

process

Identify metrics and success

criteria

Agree to pilot and associated requirements?

Define metrics and success criteria in

implementation plan

No Yes

Assess whether pilot

is needed

Review pilot recommendations,

metrics and success criteria

Undertake and

review pilot

Define metrics and success

criteria in pilot plan

Pilot successful?

End

No

Yes

1 2

3

5

6 8

7

9

10

12

13

14

15

Identify process variations &

assess exceptions

4

Yes

No pilot needed

Requirements need to change

Recommend pilot?

No

Yes

11

Diagram 8: Model process map


33

Table 12: Model process steps


1 Collect available data and evidence

Sources of data on the process and other evidence of process effectiveness are gathered. This should focus on any known measures (such as those for efficiency and quality) and problems that have been identified as affecting the process.

Lead analyst

2 Analyse process options in depth

Analysis should be undertaken to identify potential process options and the ramifications of those options. This will include:

Evaluating the data and evidence gathered to identify potential options for process introduction or change.

A cost / benefit analysis of options detailing the drawbacks and the benefits or a process. These may be analysed through a comparison table.

Risk and risk mitigation of options: major and minor risks should be listed as well as potential mitigations to ensure that any potential “showstoppers” are identified and that risks can easily be compared with process benefits.

Impact assessment, which identifies stakeholders, outputs and the ramifications of those outputs on stakeholders and secondary processes. This may use analysis methods such as SIPOC diagrams.8

The analysis process influences informs the model and consultation processes, so that these three form a “loop” in developing new processes.

Lead analyst

3 Identify process variations and assess exceptions

Any need for variations or exceptions to the standard process in one or more locations are identified and either accounted for as variations, or accounted for global processes.

For more information on identifying valid process variations and exceptions see section 5.6.

Note that variations do not need to follow higher sign-off processes, whereas exceptions do. See the definitions of process exceptions and variations on section 2.5.1.

Lead analyst

4 Model process options

Options that are deemed feasible to be included in the process proposal should be modelled to a level appropriate to INZ’s needs to identify impacts, efficiencies, risks and benefits. This process modelling may include:

Electronic modelling through process mapping software.

Workshops and modelling processes through white boarding, flip charts, or post-its.

Other information and data can be used to inform the process modelling that is undertaken. This may include surveys, interviews, direct observation, and quantitative data gathered on pre-existing metrics or other sources.

This mapping informs both the analysis of process options and variations (steps 2 and 3) and the consultation of stakeholders (step 5).

Lead analyst

5 Consult with Stakeholders should be engaged through the modelling process and Stakeholders

8 SIPOC methodology gives a high level picture of what Suppliers, Inputs, Processes, Outputs and Customers are involved or impacted by a process change.

34

stakeholders when a firm option for process change has been identified. Stakeholders both internal and external to the organisation may be given the opportunity to input into the final proposal for change and to suggest adjustments to that proposal.

When processes are sufficiently analysed, modelled and consulted, the model process proceeds to the next step: Identify metrics and success criteria.

6 Identify metrics and success criteria

A targeted standard which the process should achieve should be defined. This should use metrics, and organisational priorities and objectives (see 5.3 Success criteria).

The metrics used to assess if a process is operating as desired should also be defined. These could, for example, include timing, quality or customer satisfaction measures (see 5.4 Metrics).

Lead analyst

7 Agree to options, metrics and success criteria?

Process manager decides whether the options, metrics and success criteria are sufficient to evaluate the process proposal.

If the process manager agrees that they are then step 8 occurs; if they do not agree, steps 2 to 6 are revisited as appropriate.

Process manager

8 Define metrics and success criteria in implementation plan

Once agreed, metrics and success criteria are recorded in the implementation plan.

Lead analyst

9 Assess whether pilot is needed

An assessment of whether a pilot should be undertaken to check the benefits, costs, risks and impacts should be made using the criteria set out at 5.5 Pilot processes.

Lead analyst

10 Recommend the use of a pilot?

The lead analyst decides whether to recommend the use of a pilot for the proposed processes.

Lead analyst

11 Define metrics and success criteria in a pilot plan, if a pilot is needed

If a pilot is assessed as being needed, the metrics and success criteria for the pilot should be defined before its implementation. These should be outlined in a pilot plan (see section 5.5.2.5).

A recommendation outlining why a pilot is needed and its parameters and prepared for submission to the process manager and the process owner.

Lead analyst

12 Review pilot recommendation, and associated requirements

The process manager should review the pilot recommendation, plan and any associated requirements before it is submitted to the process owner.

Any amendments should be incorporated by the lead analyst.

Process manager

13 Agree to pilot, and associated requirements?

The process owner reviews the pilot recommendation, plan and associated requirements. They decide whether to proceed to implement the pilot, or whether the requirements associated with the pilot need to be revised.

Process owner

14 Undertake and review pilot

If agreement is given by the process owner, the pilot is undertaken within set parameters. It is paramount that the pilot is monitored. A review of the pilot is undertaken after its completion.

Lead analyst

15 Assess whether pilot was successful

The pilot is assessed against set success criteria, using predefined metrics, to determine whether the process proposal is fit for purpose to be implemented in other areas of the business. If it is not, then the analysis step is revisited (step 2). If it is, then the process management cycle progresses to the next step in the Design phase (see section 4).

Lead analyst

35

5.3. Success criteria

Defining criteria to evaluate the process success before a change is implemented is important

for ensuring there is standard or “baseline” against which ongoing monitoring and review can

be achieved. It also encourages the business to seek ongoing ways of improving the outcomes

of processes.

Measurable 5.3.1.

Success criteria should be a specific and measurable set of conditions that shows that the

benefits of a process change have been achieved. For instance, it could be a set target for

the timeliness of decision making in INZ offices; set measurements of process consistency; or

throughput.

Prioritised 5.3.2.

Each measure within the criteria outlined should be prioritised as this will ultimately help in

the evaluation of the success. For example, a MoSCoW technique could be used, where each

criterion is allocated with a “must have”, “should have”, “could have”, or “won’t have for

now” status. This will be especially important if there are multiple measures of success for a

process change.

Correlations between metrics occur frequently, underlining the need for properly measured

and prioritised success criteria derived from the purpose of the process. A gain in one metric

may have a positive correlation with another: for example, increased efficiency may be

paired with an increase in customer satisfaction. Contrastingly, a negative correlation may

also occur: for example, increased throughput may be paired with a decrease in the quality

of decision making.

5.4. Metrics

A metric is a measure used to track processes and indicate how well they function. Identifying

appropriate metrics is key to monitoring and assessing the validity of a process or process

change. They enable the identification of opportunities for process improvement and provide a

baseline from which other changes can be assessed.

Common areas for success criteria and metrics for INZ 5.4.1.

INZ often targets common areas to measure performance improvement or success criteria

for its visa processing operations. The below sections outline the potential metrics that may

be used to measure the performance of key aspects of INZ processes. This is not an

exhaustive list of targeted areas or metrics, but is intended to give a broad framework from

which the majority of processes may be assessed.

36

Table 13: Common metrics for visa processing

Targeted area

Description Example of Measurement

Efficiency The amount of visa processing output from the resource put into a process.

Process timings

Quality How well decisions, processes, and products conform to prescribed expectations.

Decision quality measures (e.g. Q3; QAP)

Decisions overturned by IPT

Review of complaints

Throughput The number of decisions or activities undertaken during a set timeframe.

Number of approvals made

Consistency How much variation between INZ offices there is in the processes undertaken.

Number of variations from the approved process

Customer satisfaction

The opinion of customers’ experience of their dealings with INZ.

Results from customer surveys

Number of customer complaints

Staff morale The degree of enthusiasm and confidence that staff have in their work with INZ.

Per cent of voluntary staff turnover

Staff survey results

Efficiency 5.4.2.

Process efficiency is determined by the amount output from the resource put into a process.

A more efficient process has a large amount of gain from a relatively small amount of

resource. For the purposes of INZ, commonly this is determined by the number of visa

application, or expression of interest, decisions made in comparison to staffing, marketing or

infrastructure resources put into visa processing.

Measurement: Process efficiency is often measured by timing measures (e.g. measuring

process lead and touch times), or by the analysis of process steps (e.g. wastage from

reworked step). This may include any aspect of an individual sub-process within visa

processing; at times it may also measure the process as a whole. They can be derived

from the following:

ICT system outputs, which are readily reportable.

Site visits of INZ offices.

A more in depth analysis of staff notes within the system.

Quality 5.4.3.

Quality is how well decisions, processes, and products conform to policy provisions and

expected business standards. INZ has an established framework for monitoring the quality of

operational performance and decision making. However, the establishment of a Process

37

Management Framework will require close attention to how new and amended processes

affect the quality of INZ processes and decision making.

Measurement: Quality measures can be derived from the following:

Samples of INZ decisions and data entry.

Q3 results.

Statistics derived from IPT decisions and analysis of those decisions.


Number of complaints.

Throughput 5.4.4.

Throughput is a measure of the number of visa decisions, or activities, made during a set

period and which are affected by a process.

Measurement: Measures of throughput can be measured through system outputs,

which are readily reportable.

Consistency 5.4.5.

Consistency measures the standardisation of processes across staff and locations throughout

INZ. It also indicates the degree to which staff are aware of the processes that they should

be undertaking.

Measurement: Consistency measures have a diverse array of places where information

can be gathered. These include the following:


Samples of INZ decisions and data entry (such as Q3).

Statistics derived from IPT decisions and analysis of those decisions.

ICT system outputs, which are readily reportable.

Number of complaints.

Customer satisfaction 5.4.6.

The opinion of customers’ experience of their dealings with INZ, including the degree to

which and the proportion of people satisfied with their dealings with INZ.

Measurement: Customer satisfaction can be measured by customer surveys or analysis

of customer complaints received.

Staff morale 5.4.7.

Staff morale is the degree of enthusiasm and confidence staff have in their work with INZ.

Amongst other things, this can be important to ensure the efficiency and quality of the

system overall.

Measurement: Staff morale can be measured by the proportion of voluntary staff

turnover, and regular staff surveys.

38

5.5. Pilots

A pilot is undertaken to test the introduction of a new or changed process on a limited scale

before it is released more widely. Its advantages are to achieve the following:

Manage risk.

Assess actual performance of the process solution.

Identify additional improvements.

Ensure difficulties in implementation are identified before the solution is provided more

widely.

Should a pilot be undertaken? 5.5.1.

Consideration of whether to undertake a pilot for a change should be considered on a

case-by-case basis. Pilots may be particularly desirable for large-scale or complex changes.

The following factors should be considered and may indicate a pilot should be undertaken

before a wider implementation of processes.

Table 14: Reasons for undertaking a pilot

Reason for pilot Description

Complexity of change The change is broad or complex in its own right (e.g. a new process with multiple steps and actors involved).

Wide-reaching change The change is far-reaching, in that it will be used by many INZ locations over the world.

Expense of change Implementation is likely to be expensive and any problems in wider implementation may exacerbate costs.

Irreversibility of change

The changes process may be difficult to reverse.

Increase buy-in Sceptical people within the business may buy into the change through a piloting process if they can see the change’s benefits before full implementation.

39

Components of undertaking a pilot 5.5.2.

The steps associated with undertaking a pilot are designed to ensure the pilot meaningfully

tests that the proposed process addresses INZ’s needs, and that it collects enough

information for evaluating the performance of the proposed process.

Process map: Pilot 5.5.2.1.

Pilot process map

Lead

an

alys

tR

elev

ant

bu

sin

ess

area

Tech

nic

al

trai

ner

s

StartPrepare

materials for pilot

Undertake pilot

Undertake staff training, if necessary

Evaluate pilotPrepare training

material and communications

1

4

2

3

5

End

Monitor pilot

6

Diagram 9: Pilot process map

Table 15: Pilot process steps


1 Prepare materials for pilot

Before a pilot’s implementation, the resources, training and guidance requirements for the pilot need to be provided for. This includes the provision of the materials outlined at 5.5.2.4 Materials needed for pilot.

Lead analyst

2 Prepare training material

With the guidance of the lead analyst, technical trainers prepare any training materials required for the success of the pilot.

Technical trainers

3 Undertake staff training and communications

Any technical training material is deployed to the relevant office(s) undertaking the pilot, and any associated support is made available.

Technical trainers

4 Undertake pilot The pilot should be implemented into the business for a limited time and within a limited area of the business, as defined in the parameters. Any communication needs of the pilot should be considered and defined in the pilot plan.

Lead analyst / Relevant

business area

5 Monitor pilot The lead analyst and management in the relevant business unit(s) monitor the progress of the pilot while it is being undertaken.

Lead analyst / Relevant

business area

6 Evaluate pilot Review and evaluation of the pilot occurs after its completion. This review should assess:

Lead analyst

40

How well the pilot performed as measured against the success criteria (as determined through the relevant metrics).

If any unexpected problems occurred through the implementation, or if there is any indication that wider rollout will have significant negative consequences.

Whether there has been any change to the business environment or need that would affect the desirability of rolling out the change to the wider business.

After this assessment is done, final agreement to proceed with full implementation should be sought from the process manager.

Lessons gathered from the process pilot should be recorded so that they can be incorporated into future process development.

Parameters 5.5.2.2.

Location: When determining the parameters of a pilot, particular attention should be given

to the location of the pilot.

A potential pilot location should sufficiently represent the other locations of the organisation

(be a typical operational example) and, as much as possible, the varying dimensions of

business functions that may be encountered elsewhere. This ensures that varying

operational environments across the organisation will be properly considered. If business

variation cannot be accounted for through piloting at one location, it may be desirable to

consider multiple pilot locations.

Duration: A pilot should have defined starting and ending points. The duration of a pilot may

be determined by several factors, including the business need for a change to be

implemented, wider project schedule commitments, or upcoming changes in the global or

local immigration environment. The duration of the pilot, however, should always give

sufficient time to collect enough data to meaningfully evaluate the performance of the

change.

Some contingency may need to be built into the duration to provide for unforeseen events

or outcomes that may necessitate an extension to its duration.

Expertise: From the outset, a pilot should have sufficient expertise, particularly of managers

directly involved in the pilot, to control, monitor and give meaningful feedback on the pilot.

It is critical to ensure that all staff involved have sufficient buy-in to maximise the probability

of the pilot’s success.

Metrics and success criteria 5.5.2.3.

Success criteria should always be set before the outset of the pilot. Metrics used should be

meaningful and be able to be used to compare performance before and after the pilot. They

should also allow for any business-wide changes or improvements that have taken place

during the period in which the pilot has run. Like the evaluation of wider process

implementation, pilot success criteria may include, for example, measures of:

Timeliness

Quality

Customer satisfaction

41

Level of complaints

Materials needed for pilot 5.5.2.4.

The following materials may be needed in preparation for implementing a process pilot.

Table 16: Materials needed in preparation for a pilot

Materials Description

Staff training Training needs to be provided to ensure that staff involved in the pilot are clear of the processes that need to be followed, the resources available to follow them, and any other technical needs that they have.

Staff must have sufficient expertise to undertake the processes that are being rolled out in the pilot.

Physical and electronic equipment

Any new equipment needs for the pilot need to be developed and implemented. This includes any system changes that need to occur for the pilot.

Process documentation

Processes for the pilot need to be documented down to a level that will enable staff to follow the new processes that are being implemented.

Management Management personnel need to be aware of:

What process changes are being introduced.

Who is undertaking the process changes.

How change performance is going to be measured/monitored.

Any critical indicators that may mean that any pilot needs to be abandoned.

Management should also be aware of the wider stakeholder needs throughout the business and externally, and business expectations around the pilot.

Communications for stakeholders

Any communications with both internal and external stakeholders should be prepared and implemented (as appropriate) prior to the implementation of the pilot.

Pilot plan 5.5.2.5.

A pilot will need to be compiled, as outlined at step 11 of the Model process (see p.33). The

information outlined in the pilot plan largely reflects the information that will need to be outlined in

a wider implementation plan (see p.44). A pilot plan should include:

Who will be responsible for the pilot.

When the pilot will occur, and associated timelines.

What material needs and expertise are needed to ensure the implementation is successful.

The success criteria and metrics used to evaluate the pilot and where the information for

this will come from (see sections 5.3 and 5.4 for more information on success criteria and

metrics).

The outline of how the process is going to communicated to staff and stakeholders.

The materials needed to run the pilot and who is responsible for the development of these.

Any other parameters that are needed for the pilot.

42

5.6. Evaluating process exceptions

Process consistency and standards are fundamental for a global operating model and enable

quick and easy assessment of any change impacts and implementation of change. Therefore,

exceptions to processes need to demonstrate that not having an exception would create a

significantly detrimental outcome to the business, due to the unique circumstances faced by a

particular office or region. The benefits of granting an exception (such as avoiding problems

through not having an exception, timeliness gains, addressing particular local needs) should be

weighed against the negative outcomes of granting an exception (for example, reduced

consistency, fairness and transparency). The case for an exception must be clear and based on

demonstrable evidence or data. Considerations should be outlined to the decision making

authority in the form of a risk / benefit analysis. Some examples of potential positive and

negative considerations are outlined in the table below.

Process exceptions should be signed out by a third-tier manager or managers, as applicable and

outlined in section 2.5.

Table 17: Potential risks and benefits of exceptions

Potential benefits considered Potential risks and costs considered

Avoiding negative outcomes of not having an exception.

Perceived or real lack of fairness across regions.

Time efficiencies gains through undertaking exception.

Increases risk of inconsistent decision making across INZ offices.

Exception address local verification needs. May increase confusion for clients, who may not be given a clear communication about processes.

Process addresses local context that is significantly different from the context of other INZ offices.

Risks reducing transparency to clients.

May undermine INZ’s movement towards greater consistency in decision making.

May create confusion for the Immigration Contact Centre when giving information about processes.

43

6. Phase three: Implement

6.1. Purpose

The Implement phase ensures that the processes created during the design and model phases can be

meaningfully translated into real operational changes.

6.2. Process map: Implement

The process map below outlines the processes undertaken during the Implement phase of the process

management cycle.

Implement process map

Lead

an

alys

tP

roce

ss m

anag

erR

elev

ant

bu

sin

ess

area

Tech

nic

al t

rain

ers

End

Start

Liaise with stakeholders

Undertake staff training

Deploy full implementation

Sign off implementation

plan


materials

1 2

3

4

5Sign off

implementation materials

6

8

Prepare training material

7


plan

Diagram 10: Implement process map


44

Table 18: Implement process steps


1 Prepare implementation plan

An implementation plan should be prepared. Details of what this implementation plan should include are outlined at section 6.3.

Lead analyst

2 Liaise with stakeholders

Any internal or external stakeholders that are keys to the success of implementation should be consulted. These should review the implementation plan (and pilot plan if applicable), and particularly elements that directly affect them or fall within their areas of expertise.

Lead analyst and

stakeholders

3 Sign off implementation plan

The final implementation plan should be forwarded to the process manager for their agreement and sign off to proceed. This should include the pilot plan if a pilot is being undertaken.

Process manager

4 Prepare implementation materials

The lead analyst is in charge of ensuring that any materials, documentation, and guidance needed for full implementation are prepared.

Lead analyst

5 Sign off implementation materials

Implementation materials, documentation, and guidance is reviewed and approved (or returned for amendments).

Process manager

6 Prepare training materials

Any technical training materials, if needed, are prepared. Technical trainers

7 Undertake staff training

Staff undertaking implementation should be given the technical training and guidance material.

Technical trainers and lead analyst

8 Deploy full implementation

The proposed changes are rolled out to all affected areas of INZ. This may use a staged approach using pilots. See sections 5.5 and 6.5.

Lead analyst and relevant

business units

6.3. Implementation plan

An implementation plan should be completed and signed off at the outset of the

implementation process. Generally, it should include the following:

Who will be responsible for implementation.

When implementation will occur, and associated timelines.

What material needs and expertise are needed to ensure the implementation is successful.

The success criteria and metrics used to evaluate how effectively the new process operates

after implementation and where the information for this will come from (see section 7

Monitor for more information on success criteria and metrics).

The outline of how the process is going to communicated to staff and stakeholders. For

particularly complex processes or process changes, this may require the development of a

communications plan as a sub-plan of the implementation plan. For more information on

communications needs, see section 6.4 Communications below.

45

The implementation plan should be agreed to by the process manager before proceeding to

partial implementation (e.g. a pilot) or full implementation.

6.4. Communications

As a part of the implementation plan, it will be necessary to define how communications will be

addressed. For simple process change, this may be straight forward. For more complex change,

however, a more structured and rigorous plan will be necessary as a sub-plan to the

implementation plan. The needs of a process change will depend on the scale and the type of

the change that is being proposed, as well as the stakeholders who are impacted.

Communications plans may include the following parts:

Background information: a brief description of what the process achieves, what changes

have been made and who is impacted, as well as an overall story of the process change (if

appropriate).

General approach: a description of the change that is being made or the process that is

being introduced.

Stakeholders: A list of the stakeholders who will be the primary or secondary audience of

communications (both internal and external).

Key messages: Any key messages used for implementation.

Key dates and deliverables: A list of key dates and deliverable for communications.

Risks and risk mitigation: A list of risks and issues associated with implementation and

communications, and how these will be mitigated.

Any more details of the material that will be used as a part of the communications process.

6.5. Implementing process exceptions

Implementing exceptions to processes in one or more locations will follow the same processes

undertaken for the roll out of a global process change. The exceptional implementation needs

of an office or region that undertakes an approved process that is different from the rest of

INZ’s global office network is outlined in the implementation plan and any communications

needs in the communications plan.

46

7. Phase four: Monitor

7.1. Purpose

The monitor phase identifies which information needs to be evaluated and the purpose of this

evaluation. It uses a systematic (evidence based) methodology to capture and assess

information and provides a purposeful review mechanism within the process management

cycle.

7.2. Process map: Monitor

The process map for undertaking monitoring processes is set out below:

Monitor process

Mo

nit

ori

ng

anal

yst

Stak

eho

lder

sLe

ad a

nal

yst

Seek further information or

clarification from

stakeholders if necessary

Gather and organise data Assess against

success criteria

Start

End

2 4

Success criteria and metrics defined and

agreed

1

3

Diagram 11: Monitor process map


47

Table 19: Monitor process steps


1 Success criteria and metrics defined and agreed.

The success criteria and relevant metrics are defined during the model and implement phases.

Lead analyst

2 Gather and organise data

Data to measure the process is gathered, in accordance with the agreed metrics. Data needs to be organised in such a way that is easy to assess against the success criteria.

Monitoring analyst

3 Seek further information or clarification about data

If ambiguities arise, or if there are incomplete aspects of the data obtained, it may be necessary to seek further information or clarification from the relevant stakeholders.

Monitoring analyst and

stakeholders

4 Assess against success criteria

Data on the processes should be assessed against the pre-determined success criteria. Other factors that may be relevant to the assessment, such as any shift in organisational priorities, may also need to be flagged and considered.

Monitoring analyst

7.3. Scheduling

The definition of goals and metrics for monitoring processes should be undertaken at the same

time as the modelling process. The remaining process steps for monitoring should be

undertaken at predefined frequency and timing after the implementation of the process

change. These considerations should be set out in the implementation plan.

7.4. Ongoing reviews of INZ process

The ongoing review of published processes within INZ is achieved through the assessment of

both process performance and adherence.

Process performance 7.4.1.

Review of process performance is triggered by ad hoc feedback on processes, scheduled

process reviews after the introduction of a process change or new process, and proactive

(targeted) process review for selected processes that INZ uses.

Ad hoc feedback 7.4.1.1.

During INZ’s “business-as-usual” work, INZ offices and other areas throughout the

organisation make change requests. These may refer to operational difficulties or

observations that an office has encountered and, after due assessment of the problem

encountered and the potential impacts, may lead to process change.

Scheduled process reviews 7.4.1.2.

As described in the Monitor phase process map (see section 7.2), processes that have been

introduced or amended are reviewed at a set period after their introduction. This

assessment is based on set success criteria and metrics.

48

Targeted process review 7.4.1.3.

SDP ensures the ongoing and proactive review of processes. The proactive review identifies

processes for review based on the following criteria:

Anecdotal indications of process inefficiency or quality concerns.

Importance of a process due to volume or immigration risk/value.

Known Government priorities.

How long it has been since the process was last reviewed.

Through this targeted review, several processes are actively reviewed each year.

In addition to the approaches outlined above for scheduled and targeted process reviews,

other methodologies may be used as appropriate. For instance, standard approaches, such

as Lean and Six Sigma, may be used to identify process efficiencies.

Process adherence 7.4.2.

Adherence to INZ processes is monitored by the Performance and Assurance team in SDP,

through measurements such as Q3 assessments, which indicate how much INZ offices follow

applicable policies (immigration and operational instructions), processes, and principles. At

times these assessments may indicate a process is less effective in one area of the business,

due to difficulties in application or another reason. Where this occurs further investigation

is undertaken by SDP to determine any further work needed to amend the process, or if any

other measures should be taken to further encourage the adoption of relevant processes.

Visa Services Operations Support will also have oversight of the adherence of INZ offices to

defined processes. These review processes will inform both Performance and Assurance

team reviews of process adherence and wider process performance as outlined in section

7.4.1 above.

49

8. Phase five: Refine

8.1. Purpose

Process refinement is a critical link to ensure that processes are reviewed effectively and

continuous improvement is achieved. It also ensures that processes are responsive to changing

business environment needs.

8.2. Process map: Refine

Process map: Refine

Pro

cess

m

anag

erLe

ad a

nal

yst

Stak

eho

lder

sP

roce

ss o

wn

er

Model process change

Prepare recommendation

End

Consult with stakeholders

2

34

Start

1

Review recommendation

Agree to process change?

5

6

7

Yes

Undertake Implement processes

8

End No

Substantive review or a small change

needed?

Small change

Restart from Design phase

EndSubstantive

review

2a

Assessment shows further changes to

process may be desirable

Diagram 12: Refine process map

Table 20: Refine process steps


1 Previous assessment shows further changes to process may be desirable

Process is triggered when assessment against success criteria in the monitoring process shows that a further process change may be desirable.

Lead analyst


50

2 Substantive review or a small change needed?

A more in depth assessment of the process effectiveness is made to determine whether a substantive review/significant change to the process or only small adjustment to the new process is needed.

Lead analyst

2a Restart at Design process

Where a substantive review or significant change is needed, the Phase 1: Design process (see p.30) is undertaken.

Lead analyst etc

3 Consult with stakeholders

Important stakeholders, both internal and external to the organisation should be given the opportunity to input into the proposal for change and to suggest adjustments to that proposal.

Lead analyst and stakeholders

4 Model process change

Viable options for changing processes should be modelled to validate and refine their working. This step is discussed in more detail at 5.2 Model.

Lead analyst

5 Finalise proposal The written proposal should be peer reviewed and finalised. It should be presented using a template that is appropriate to the level of signoff that has been identified. Any additional cover memos, if needed, should also be completed at this phase.

Lead analyst

6 Review proposal The process manager should have a final review of the process proposal and any accompanying documentation before it is submitted to the decision making body for final consideration.

Process manager

7 Agree to change? The written proposal is submitted to the appropriate decision making body and a final decision is taken whether or not to proceed with the change.

Process owner

8 Undertake Implement process

Where a change is agreed to, the Phase 3: Implement processes are undertaken (see p.43).

Lead analyst

51

9. Resources and tools

The resources and tools section outlines the style guide, templates and Global Process Manual used

for the functioning of the PMF.

9.1. Style information

This information is designed to give lead analysts, process managers, and process

administrators the tools to communicate processes consistently and effectively to key

audiences.

Key principles 9.1.1.

Audience perspective 9.1.1.1.

The needs of the audience who view visa processes drive how the processes should be

presented. There are three primary audiences:

INZ senior managers: Managers need to have a short summary of the processes that

are proposed for change, the impacts of any change, and the risks (or costs) and

benefits. The aim of messaging to them is to provide sufficient information to make

an informed decision about whether to take up a change.

Frontline immigration staff: Immigration staff need to know clearly the steps that

they will need to follow for a process, and understand fully any changes that have

been introduced from previous processes.

Process analysts and managers: Process models and documentation may also be

needed for the purposes of analysis. These may not need to be shared with another

audience.

Consistent and simple messaging 9.1.1.2.

Consistency of messaging and style ensure a common understanding of expectations and

that processes are followed correctly across INZ.

Process and change communication 9.1.2.

To managers deciding whether to take up a process 9.1.2.1.

Key considerations: The following considerations should be kept in mind when producing

process documentation for decision makers:

Keep explanations simple and concise.

Process maps are not always needed:

o Straight forward processes or process changes will not require inclusion of

process maps in documentation to managers, provided a short explanation

communicates the change sufficiently.

52

o More complex process or process changes may benefit from the inclusion of

process maps. These should be presented along with a short written explanation

of the change.

Include explanatory subtitles where useful.

Provide a short background explanation of the problem encountered with the

current process and why this change is desired.

Provide the risks/costs and benefits of the change to the level they need to make

the decision. Keep in mind that they will need to know the ramifications of the

changes proposed for introduction.

Alternative options to the proposed change may be desirable for complex or high

impact changes.

Templates: Ordinarily, the templates used for high and medium impact process changes will

be the same regardless of the process that is under consideration. At the discretion of the

deciding manager(s), low-impact changes may not require as much information or the same

memo template as high or medium impact changes.

High and medium impact process change should be submitted to managers in the form of a

memo.

Low impact process change should also be submitted in the form of a memo. However,

low-impact or simple process change may not require all the information outlined in the

memo template structure and a simple sign off sheet may suffice (see Appendix B). Other

templates and sign-out mechanisms may instead be approved at the relevant sign-out

manager’s discretion.

To frontline staff involved in or supporting a process 9.1.2.2.

Key considerations: Process documentation published for frontline staff should incorporate

the following:

Clearly outline process steps to the required level of granularity.

Keep explanations simple and concise.

Clearly show who is responsible for the completion of each task.

Process maps frequently will be useful. But this may not be the case for very simple

or very low-level tasks.

Outline process steps that staff should follow, in a way that supports the

presentation of any process maps. These should be concise and outline directly the

tasks that need to be undertaken by staff and should be done even if no process

maps are created for a process or set of processes.

Supporting communications may be needed at implementation to ensure that staff

understand what changes have been made to previous processes (if the process is a

change to an existing process).

Templates: The presentation of process information should be based on the relevant styles

needed in the Global Process Manual in which the processes are presented to staff. This will

53

take the form of a basic process flow (which does not need to take the form of a specific

modelling language (see section 9.1.3 below)).

Documentation for process development 9.1.2.3.

Key considerations:

Process maps will frequently be needed to identify shortcomings in existing

processes and demonstrate the value of process change. The development of these

is also important for communicating changes to stakeholders and reviewers (such as

the process management).

Process map presentation 9.1.3.

Where a lead analyst considers a change to a process flow is significantly complex, a process

map is written for the proposals. Usually this will be a basic cross-functional process diagram

(swim lane diagram) completed, but may sometimes vary according to the needs of the

process being described. This should use the formats indicated in Microsoft Visio and should

also detail each step in a table associated with the proposed process map.

9.2. Templates

Requesting changes 9.2.1.

A change request may be submitted to the Operational Policy team in SDP using the

template include at Appendix E. This must be signed off by a sixth-tier manager (or more

senior).

Sign-off documentation 9.2.2.

High- or medium-impact process proposals submitted to managers or to the OSIC should use

a memorandum template. Managers may also requested a simplified form of sign-off

documentation (included at Appendix B), which may be preferred in simple or low-impact

process changes.

9.3. The Global Process Manual

The Global Process Manual is critical for the overall documentation of INZ processes and

ensuring that those processes are understood correctly by staff engaging them across INZ. It

should have the following characteristics:

The architecture of the manual should be user-friendly and navigable, so that staff can

easily find the processes they require information about.

The manual should complement the other places where guidance or policy is made

available to staff (such as the INZ Operational Manual, Internal Administration Circulars,

or the Verification Toolkit).

Processes within the manual are easy for a process administrator to update.

The manual encourages reviews to be undertaken after a set period.

54

The manual has a standard approach for documenting processes, particularly for

complex processes where several actors are involved .

Associated steps will be outlined for processes to be followed.

Links to applicable documents, instructions, or external information will be included as

appropriate.

Allow for the centralised documentation of process change or equivalent change

register.

55

Appendix A: Ownership of information and process

repositories

SDP-owned Visa Services-owned CRIS-owned Technical trainers

Operational Manual ICC Knowledgebase Verification toolkit/material

Training material

Global Process Manual

INZ website

IGMS toolkit

AMS toolkit

ICT systems

56

Appendix B: Simple sign-off template

57

Immigration New Zealand sign-off form

To: [Sign out manager name], [Position], [Area]

[Sign out manager name], [Position], [Area]

cc: [Name], [Position], [Area]

[Name], [Position], [Area]

From: [Lead analyst], [Position], [Area]

Date: DD/MM/YYYY

Subject: [Explain what the proposal is]

Please find attached proposed changes to [explain process proposal].

Please sign and date below to formalise your agreement to the proposed new immigration

instructions.

[Manager’s name] [Manager’s name]

[Position] [Position]

[Area] [Area]

Date: Date:

58

Appendix C: Business functions out of scope of Process

Management Framework

The following are business functions9 that have only indirect impacts on Apply and Assess & Decide

processes, and are therefore out of scope of the Process Management Framework.

Business Function Description

Operations Support and Advice

Specialist technical advice on policy and procedures.

Load demand management

Proactive management of global load demand through redistribution and shifting of work across the visa processing locations.

Integrity management

Activities focused on managing and monitoring internal risk assurance and controls.

Manage Relationships

The governance, structures and capabilities that establish, control and maintain relationships with third parties including other government organisations, outsource partners (VACs). This also includes a range of ongoing stakeholder management activities.

Manage Attraction and Protection

The activities associated with managing the effective use of channels and partners to promote NZ as the country of choice to attract the best people and skills that are required for our economy, as well as implementing NZs international obligations to refugees and protected persons

Manage Border The activities associated with passenger processing starting at ticket purchase, through check-in, travel, arrive and departure. Includes referral, detention and refused entry border processes.

Manage Settlement

The activities associated with supporting migrants refugees’ and their families’ (newcomers) settle into NZ

Manage Enforcement

The activities associated with managing enforcement operations (Fraud & Compliance) planning, investigations, intelligence, search warrants, detention and deportations.

Manage Customer Experience

The activities associated with owning the end-to-end customer experience through consistent communications and touch points delivered through our channels.

Manage Customer Enquiries

The activities associated with receiving and resolving customer enquiries.

Manage Trusted Partnerships

The ongoing maintenance of trusted partnerships with external providers through monitoring of SLAs, audits, and enquiries and communications.

Reporting The effective capture and conversion of data (customer data, volumes etc.) into information (reports, KPIs) to enable informed and effective operational and strategic decision making.

Privacy management

Activities associated with ensuring that client privacy is maintained in compliance with statutory and regulatory obligations.

Performance management

The activities and tools associated with monitoring performance of the system as a whole, including operational performance and staff performance.

9 These align with business capabilities outlined in: Business Transformation, August 2014, Business process design document: Manage Applications.

59

Appendix D: Visa Services process owners (managers)

Process Owner Responsibilities

Develop strategy and measure performance

Manager performance and planning

Key Performance Indicators

Vision 2015

Drive consistent processes and service standards

AGM Operations Operational Manual

Motivate our multicultural workforce

AGM New Zealand/Northern Culture

Align Organisation for Future Operating Model

Promote NZ in local market AGM New Zealand/Pacific N/A

Gather local market intel AGM New Zealand/Pacific Capture intel

Forecast local market immigration demand

AGM Offshore East Global workload management

Inform applicants of how to apply

AGM New Zealand/Northern Channels

Receive applications Commercial Relationship Manager

On-shore lodging

Manage third party providers Commercial Relationship Manager

Third party providers

Manage workflow by triaging based on value and risk

AGM Offshore West IGMS triage rules

Make decision and advise of outcome

AGM Offshore West Verification

Visa Services Quality

Line calls

60

Appendix E: Change request template

61

PROCESS AND PRODUCT CHANGE REQUEST

Problem / Issue (please give detail of the problem that needs to be addressed)

What impact does this problem have? (please give as much detail as possible description)

[e.g. How many immigration applicants are affected? How often?; How does this issue affect

processing timelines?; Are their concerns about the integrity of immigration?; Are there any other

impacts?]

Proposed solution (please briefly describe the proposed solution to the problem)

Indication of impacts (please indicate what the likely impacts of this proposal will be)

Business functions likely to be impacted

Immigration instructions

Visa application processes / standard operating procedures

Work flow criteria and policy criteria interpretation

Client risk assessment processes

How physical applications are received

Document management processes

Specialist medical resolution processes

ICT systems and electronic applications

INZ products (e.g. INZ forms, guides, checklists, template letters, or the INZ website).

Quality review processes

Client risk and intelligence processes

Identity management or specialist identity resolution processes.

Any additional comments

If you have additional documentation you wish to include, please email it together with this form.

Please email the form to Service Design and Performance.

Title of change request

Requester

Date Submitted

62

Sign-off

Name Office / Branch Position

Area / Market / 4th Tier Manager

SERVICE DESIGN AND PERFORMANCE TO COMPLETE

Impact

Significant

Medium

Small

Priority

High

Medium

Low

Immigration New Zealand Process Management Framework for Visa ...

Documents

Transcript of Immigration New Zealand Process Management Framework for Visa ...