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?
Branches that own business functions
Who does the analysis?
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
Prepare implementation
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.
Process administrator
3 Update change register
Process administrator updates change register, or ensures that it is up to date.
Process administrator
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.
Process administrator
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
Design Model Implement Monitor Refine
31
Table 11: Design process steps
Step Process Description Actor
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
Design Model Implement Monitor Refine
33
Table 12: Model process steps
Step Process Description Actor
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.
Site visits of INZ offices.
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:
Site visits of INZ offices.
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
Step Process Description Actor
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
Prepare implementation
materials
1 2
3
4
5Sign off
implementation materials
6
8
Prepare training material
7
Prepare implementation
plan
Diagram 10: Implement process map
Design Model Implement Monitor Refine
44
Table 18: Implement process steps
Step Process Description Actor
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
Design Model Implement Monitor Refine
47
Table 19: Monitor process steps
Step Process Description Actor
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
Step Process Description Actor
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
Design Model Implement Monitor Refine
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
Top Related