Employee On boarding / Off boarding with SharePoint and InfoPath

There’s a few times with recent employers where I have been
asked to help streamline the on-boarding / off-boarding process. In fact, with
my most recent employer it has been priority number 1 for my manager. While the
theory of this is quite simple, in practice it is another beast entirely.

There’s a few key factors in my experience which tend to complicate this task. Primarily the issues lies with an ill-defined business process; most businesses know the ‘general idea’ of
hiring someone, however if you take 2 line managers, the chances are they go
about the process in completely different ways. A secondary concern is often
cost; businesses hate to spend money at the best of times, and processes like
employee on-boarding / off-boarding is often a very low budgetary priority (yet
remains a high priority for the people involved!). It’s very hard to demonstrate the value in improving
the process; tacitly it’s a no brainer, but try to
show that on paper.....

Get the requirements nailed!!

Regardless of which technology ends up being the answer (if
any!!), the process and requirements need to be absolutely set in stone up
front. This becomes especially important if the technology of choice happens to
be InfoPath / SharePoint Designer workflow, however the point remains valid no
matter what the solution. Avoid the temptation to allow a single person to
define the process, as almost universally, different people at different levels
all have different points of view. Additionally, you may get the situation
where an overzealous HR manager overdefines the
process.

My suggestion is to get a good BA involved. You’ll only need
a few hours of their time; however their ability to tease real requirements out of
the business and define wants vs. needs is invaluable. If
possible, get them to run a workshop and have them produce a flow diagram of
the business process too. This makes defining a workflow so much easier (obviously
you can do this yourself, but make sure you have a different ‘hat on’.
Technology should not drive the process)!

Technical specifications

Once the business process has been defined, it should be
fairly straight forward (but time consuming) to build technical specifications.
Regardless of the technology selected to provide the solution (this may not
even be a choice.), good technical specifications are vital. Focus on defining
upfront the entire collection of fields which will be required to be filled by
the user, as well as those that the system will automatically fill. Next, split
these fields out by ‘what should be filled when’ according to the flow diagram
defined by the BA. Avoid any assumptions at this point, if
you’re unclear on anything at all, however minute, have the process owner
define it in writing and ensure it makes sense in the context of the entire
process.

After this, define how the artefact (i.e. on-boarding form)
should be routed at each step. For example, the process may start with a PM
requesting a new resource. Upon request submission the status may automatically
be set to “New”. The resource manager may then process the request and set the
status to one of several choices – these may be something like “Rejected”, “Approved
– existing resource to be provided” and “Approved – new resource to be hired”.
Clearly the next step in the workflow is highly dependent on which status is
selected.

Functional specifications

The next step should focus on defining the process in the
context of the technology selected to deliver the solution. At this point, you
will need to start getting creative; you’ll need to think about the ‘view’ the
user will see at each step, and how you’re going to ensure they see that view
and only that view (Murphy’s law, give them options and someone will stuff it
up). This will get complicated because of the potential for back and forth
between the requester and the resource manager. There are a number of options
at this point, but fundamentally they’re all going to be driven off the value
on the “Request Status” field.

You can use conditional
formatting in InfoPath to define which fields are displayed depending on the
status, or you can use j-query to show/hide selected fields on the SharePoint
item form. Alternatively, you can use SharePoint designer and the data view web
part. Licensing arrangements may dictate your choice (Form Services requires
enterprise licensing), however if available, InfoPath is the most flexible

Develop you functional specs in a very technology specific
way and leave no ambiguity. Ensure you cater for all contingencies. Once
defined, have several independent people sanity check what you have proposed.

Build it

All of the above may seem excessive, however, regardless of
which technology is eventually selected and especially if it is a SPD/InfoPath
solution, changes mid way through can be highly disruptive. SPD workflow and
especially InfoPath forms, have a tendency to become
very unstable if significant changes are made to one or other. Always
develop your InfoPath form first and your SPD workflow second. This is what
makes all of the above so vital, if you do not plan effectively,
you cannot work in this order and as a consequence will end up doing and redoing
settings and configuration time and time again!