The youth of today?!?

Insiteability provide support for learning and dissemination on enterprise workflow.

Insiteability was employed by the Programme Office to support the National Project in three interlinked areas: toolkit development, Web support and quality assurance.

In doing this, it was able to draw on a broad range of experience and expertise across the different areas of public sector management.

We have a long-standing appreciation of the demands faced in local government. And as one of the biggest providers of Web services to the UK public sector, we are also well practised at providing information and advice in an accessible digital form.

In supporting the Programme Office and its partners, we were therefore keenly aware of the wider audience for project learning. Like the Roman God Janus, it wore two distinct faces: one pointing inward, to facilitate effective project collaborations, the other looking outwards to the wider local authority world – for which project learning was repackaged and disseminated.

The Story

Early discussions about toolkit and quality assurance identified two key principles.

Firstly, the value – and ultimately the quality – of the toolkit would be dependent upon its ability to guide potential users through the whole project cycle, from developing plans and strategies for enterprise workflow, through to implementation and routine operation. Rather than simply documenting the solutions delivered at the end of project, therefore, emphasis was also placed on capturing the whole journey of workflow related change. Put another way, while local authorities would be interested in what the National Project achieved, they were also particularly interested in how its partners got there.

The second principle recognised that, in documenting learning about the project process, data would be much more reliable if captured and codified as events unfolded. In other words, learning needed to be logged on an ongoing basis, rather than dredged up from memory and compiled post hoc.

In building the National Project website, there were two audiences – and two sets of functional requirements – to respond to. On the one hand, the website was the main means of communication to the wider community. Here, easily accessible
and engaging content was required. On the other hand, there were the project
partners (the Programme Office, the ODPM, the transformation projects and IPF),
whose needs in respect of project management and collaboration had to be met.
The site – www.workflownp.org.uk – is shown below:
Figure 1
Enterprise Workflow National Project Website
In using the site, both partners and external visitors first needed to register, which
involved entering their email addresses, in response to which a password was
automatically issued. This allowed the system to recognise users from partner and
non-partner organisations, and thus offer differential access to web resources and
functions (the screens taking on a different appearance in each case). For each
partner organisations, this effectively meant access to an ‘extranet’, whereby a
designated system administrator could provide users from his or her authority with
permissions to enter content on the site.
Having set the system up in this way, it was then possible to add functionality that
supported internal communication between project partners. This was particularly
important given that several organisations from differ parts of the country were
involved in the project, with personnel only meeting at monthly project and
programme boards. So far as learning and toolkit develop were concerned here,
the most important web component here was the ‘learning logs’.
Learning logs
In addition to supporting project management generally, the project-partner part
of the website provided important functionality as an electronic learning repository.
This allowed partner authorities to record and share project experiences, as well
as position papers and details of problem solving work.
For this to operate effectively, as well as to provide direct support for toolkit
development, a degree of structure was first needed around the learning
categories. At the commencement of the project, therefore, a workshop was held
to develop an outline specification for the toolkit. This was used by IPF to create a
set of categories and subcategories, which could then be used as a framework for
describing and recording project learning. This process is described in Figure 2.
Figure 2
Specifying the toolkit requirements and learning logs
The specific categories derived and populated during the course of the project are
shown in Figure 3. Partners were able to log items in more than one category, of
course, reflecting the fact than any area of learning will speak to more than one
workflow issue. They also had the option to log (sensitive) items confidentially, in
which case only the members of IPF’s toolkit team were able to access the
content. These items apart, the logs were fully searchable by all partners using
online tools.
Figure 3
The learning log categories
Enterprise Workflow
National Project
Outline specification for
toolkit
Learning log categories
derived
Toolkit components
evolved
Project Extranet
Content
Meetings
Project Logs
Learning Logs
Overview
Browse Logs
Search Logs
My Logs
Proof of Product
User Admin
Site Stats
Suppliers
Workflow Concepts (49)
Specific Learning Log Categories
Workflow and Strategic Change (39)
Workflow and Operational Change (35)
Business Cases (37)
Workflow Issues Within Agendas For Change (44)
Hardware Issues (1)
Background (21)
Inter-agency Working (14)
Change Management (50)
Descriptions of Software and Rationales for their Adoption (35)
Implementing Workflow Software (34)
Interface Issues (27)
Workflow Software (39)
Standards Issues (15)
National Standards (14)
Description of Standards (15)
Standards (18)
Re-engineering and Redesign (45)
Process Mapping Tools (26)
Process Maps (42)
Re-engineering and Process Mapping (54)
Hardware (11)
Software (31)
Consultancy (24)
Suppliers (35)
A brief example of a learning entry can be seen below. This was recorded under
the following categories, for obvious reasons: Change Management,
Re-engineering and Process Mapping, Workflow Concepts, Workflow Issues Within
Agendas For Change and Workflow Software.
It is important to recognise when looking to introduce workflow systems, that
workflow is first and foremost about layers rather than slices. What I mean by
this is that, while users may see things from a vertical silo perspective (and
hence, left to their own devices, would look for vertically integrated silo
applications), workflow really needs to be seen as a set of cross-organisational
systems built up in layers (that deliver common functionality to all). This is why
workflow is like cake making; the users may eventually see just one (vertical)
slice from the cake, but the cake most definitely needs to be ‘constructed’ one
broad layer at a time, with each layer then being laid on top of – and support
by – the one below. In this way, everyone gets the same functionality and
ability to handle workflows, from pre-defined production workflows to createdon-
the-fly ad-hoc ones. What users do with the cake slices once they are given
them, however, is then up to them!
Figure 4
Example of a learning log entry
The outline specification for the toolkit was also used by IPF in site visits to project
case studies, where first-hand data was collected on workflow developments and
experience. In addition – and so as not to re-invent ‘workflow wheels’ – efforts were
also made to combine project learning with documented best practice from beyond
the National Project.
Combining Best Practice
In one sense the development of the toolkit had a very specific goal: providing
guidance to local authority managers on implementing enterprise workflow. In
doing this, cognisance was needed of the local authority context, in terms of
purpose, culture, structure, governance arrangements, statutory requirements,
political pressures, and so on. In other words, while workflow maybe a universal
concept and tool, the particular issues faced by local government users needed to
be foremost.
This said it was also recognised that other sectors – particularly the private sector

• had been using workflow for many years. Much of this experience had been
  document in business and information systems literature and offered valuable
  inputs and starting points in building a framework of ideas for local government.
  IPF therefore undertook background research on workflow and enterprise systems
  and combined this with project learning in developing the toolkit.
  Re-specifying the toolkit
  Interim meetings about the toolkit soon drew out two underlying requirements:
  while it should meet address an authority’s needs during the course of a workflow
  project, it also had to recognise a range of different users – each with their own
  interests, understandings and capabilities. In a sense then, the market for the
  toolkit’s products needed to be segmented.
  The key ‘customers’ here were seen to be:
  • Councillors, chief executives and senior managers
  • Programme managers and change management boards
  • Project managers
  • Process analysts
  • IT managers
  • Service managers
  • Users
  Each would need to be understood in their own right, spoken to in their own
  language and supported in their own needs.
  It was also recognised that many stakeholders in local authorities were unlikely to
  have come across the term ‘workflow’ or ‘enterprise workflow’ before. The toolkit
  therefore needed to undertake an educational role, explaining to the uninitiated
  about the nature of workflow and where it fitted in with the local authority agenda –
  especially on e-Government.
  The outline toolkit
  As the project developed, the structure of the toolkit evolved around three key
  (interlinked) areas.

1. At the highest (‘introductory’) level, the components played an educational role

• explaining what workflow ‘is’ and identifying the contexts within which
  discussions should be located.

1. At the next level – and before workflow could ‘get off the ground’ in an authority

• was the need to aid executive understanding and decision-making. Here, an
  executive or programme board would identify a high-level business case for
  workflow and commission and review exploratory analysis and oversee the
  implementation of workflow solutions.

1. The third level, it was soon realised, was the heart of the toolkit. It was here
   that the detailed tools would be needed to guide project managers, process
   analysis and IT specialists through the process of delivering workflow-related
   change. This included analysis, scoping, re-engineering, project management,
   implementation, integration and change management.
   The links between the three levels is shown in Figure 5.
   Enterprise Workflow
   National Project
   Figure 5
   The three toolkit levels
   The toolkit reports
   In addition to the diagrammatic version described in Figure 5, the bulk of the
   toolkit content will be contained within a set of short reports. These will be
   available on the project website, in both word/pdf and html. The html versions will
   also provide linkages to other project outputs, such as technical reports and case
   studies. The toolkit reports will therefore involve:
2. An introduction
3. High level introduction to workflow
4. Workflow technologies and architectures
5. Planning and managing workflow projects
6. Building the business case for Enterprise Workflow
7. Identifying and scoping workflow projects
8. Workflow modeling and BPR
9. Change management
10. Design, Implementation and operation
11. Doing workflow with external parties
12. Glossary of terms
    Working with the Programme Office, IPF will, in due course, repurpose this
    content, providing interactive functionality, available via the project website.
    The Authority
    Key Lessons
    Users of the toolkit need to
    know about the process of
    workflow-related change.
    The toolkit design had to
    recognise this and support
    potential users through the
    whole journey of designing
    and implementing workflow
    solutions.
    To understand properly the
    process of change, learning
    had to be collected on an
    ongoing basis. A system
    needed to be set up to do
    this.
    The toolkit needed to
    recognise the range of
    potential users. Each of
    these had their own set of
    needs and had to be
    communicated with in an
    appropriate way.
    Key Benefits
    A multi-user set of tools that
    can guide an authority
    through the whole workflow
    project cycle.
    An actionable set of ideas
    that respond to the issues
    faced in a local authority.
    An accessible and usable
    product available in
    preferred formats.
    Key Facts
    The toolkit will be available
    in work/pdf and html
    formats, via the project
    website, by June 2004.
    It will also provide an
    interface onto the other
    outputs from the National
    Project, such as case studies
    and technical reports.
    IPF will be working with the
    Knowsley Programme Office
    to enhance the toolkit with
    interactive functionality,
    which will be available via
    the website by autumn
    2004.
    High-level preparation
    and context setting
    Executive Governance and
    decision-making
    Analysis, scoping, BPR, project
    management, technical design,
    implementation, integration and change
    management