A tribute to the humble “leave form” – Part 1

[Note: It appears that SharePoint magazine has bitten the dust and with it went my old series on the “tribute to the humble leave form”. I am still getting requests to a) finish it and b) republish it. So I am reposting it to here on cleverworkarounds. If you have not seen this before, bear in mind it was first published in 2008.]

Hi all. It’s a pleasure to be involved in the launch and first edition of SharePoint Magazine. My name is Paul Culmsee and I’ll be your host for this series of articles. If you have not read my stuff before, then I’ll say that I am an opinionated, underpaid and overworked SharePoint consultant based in Perth, Western Australia.

I had previously decided to write an educational series of articles to pay tribute to the humble, good old leave (vacation) form and I think it is perfect fodder for SharePoint Magazine’s wide variety of audience.

Where would SharePoint consultants worth their grain of salt be without the leave form, eh? When all else is lost, there it is to save your ass from the wrath of the CIO who is wondering where his two hundred grand of license fees, hardware and programming went.

Why the leave form?

From a demo perspective the leave form is pure gold. You can knock out an InfoPath form in minutes, publish it to a SharePoint site using Forms Services and top it off with an easy-to-understand SharePoint Designer workflow that creates some tasks for the boss to approve the request and to notify payroll of the approval. All within the space of a 1 hour demo session. Genius! No wonder Microsoft sell all of those licenses!

For a client who is still coming to grips with the possibilities what forms and workflow offer, the leave form is an excellent starting point. It is a simple process and almost universally understood. There really aren’t that many owners/stakeholders involved in the process, and thus even the most extreme anal-retentive “process nazi” can’t really make it too onerous. So turning this process into a “non-programmer” workflow is not that hard.

Being a simple process, you can use SharePoint Designer workflows. Now some developers reading this will probably start protesting, and believe me I know where you are coming from. But let’s face it – you guys are damn expensive!

Thus, SharePoint Designer based workflows are a great *prototyping* tool. Non programmers can develop them, and making modifications and changes do not require a lot of time or cost. For an organisation unused to workflows and the inevitable “process debates” that arise as a result, delving straight into Visual Studio and expensive developers I do not recommend. Workflows tend to evolve fairly quickly at first as people learn more about them. Additionally, whatever you *think* you want in the first phase has a very high likelihood of being ripped out or seriously modified once it starts to get real-world use.

So in using the leave form, we are using a process that is well suited to a SharePoint Designer based workflow. Once the process is mature and you have enough SharePoint experience to appreciate the governance costs, then you can rewrite it as a “proper” Visual Studio based workflow template.

Why not the leave form?

The leave form unfortunately is not representative of the sort of process where automation or improvement justifies a SharePoint investment. If your company is suffering a cash-flow bleed because you can’t get your leave forms done, then I can say with some confidence that you are *seriously* screwed and SharePoint isn’t going to solve your issues.

The point is, the leave form is not going to have too much real business relevance in terms of tangible return on investment. In fact the leave form is *too easy*. As a demo, it can mislead an organisation into thinking that the answer to life, the universe and everything is contained within the everyday world of mere mortals armed with nothing more than InfoPath and SharePoint Designer.

The real life of organisational process and workflow is completely different. Most workflows tend to be more complex because they involve more teams and team members. Because they involve more teams, they have a tendency to be unoptimised, undocumented, inconsistently followed and over-complex, due in part to to past screwups, lack of co-operation and organisational mistrust and politics. This is a reflection of much bigger issues than SharePoint of course, but to entertain the notion that SharePoint is going to miraculously change cultural issues is about as ludicrous as suggesting that Guns N’ Roses will actually ever release their “Chinese Democracy” album anytime soon.

Believe it or not, the image above is a real workflow. Check out this story behind it here – it’s funny in a very scary kind of way. Whilst this may be an extreme example, it should hopefully make it clear that despite best intentions, your first few attempts at trying to improve something like this via SharePoint aren’t likely to go all that well if your process is crappy to begin with

Why use the leave form an example then?

That’s easy! I actually want to finish this series of articles in a reasonable time!

Additionally, it still suffices to demonstrate fairly convincingly how it doesn’t take very long at all before we need to delve deeper into the potential no-mans-land of custom development. So the outcome of this series of articles is two-fold.

1. Readers will get a good understanding of the tools and SharePoint features that combine to produce an automated version of the leave form process
2. (But more importantly) They get a glimpse behind the virtual green door of InfoPath and SharePoint’s dirty little secrets.

Is it humanly possible to write a series articles for normal people *and* technical geeks? We shall soon find out!

A recent real-world engagement

The leave process that I have outlined here is going to have a little more depth to it than the sort that would be demonstrated in a pre-sales demo, but it is still not industrial strength. I’ve put enough in there to assist the reader to really understand just what it takes to implement a semi-real world case.

I hope that readers have watched the Simpsons!

Conveniently for all of us, my company Seven Sigma’s office in Springfield recently completed a SharePoint engagement for the local Nuclear Power Plant. After some initial requirements gathering, we ascertained that like most companies, the leave process for the plant was problematic. It was an MSWord file that employees have to open, print out, fill in and then hand to their boss. The boss (some old-dude named Burns) was an old-fashioned, unpredictable kind of guy and he tended to forget the names of particular employees. Thus sometimes applications went unprocessed, misfiled or inconsistently handled.

Below is the leave form in its original MSWord format.

After gathering requirements and running some workshops, we were able to determine what the client wanted with their automated leave form workflow…

The Requirements

Roles
Requestor	Approver	Payroll

The leave workflow steps to be implemented are as follows.

1. Hardworking and dedicated employee (Requestor) completes an online form to apply for hard earned leave. The form automatically identifies the requestor (a good thing because spelling your own name can be hard). Additionally, the type of leave (sick, annual, bereavement, etc), start date, end date and the return to work date are all entered into the form. Importantly, the number of days absent from work are automatically calculated to exclude weekends.
2. The evil overlord boss (Approver), receives a task notification to approve an application for leave. The approver reviews the leave details and approves or rejects the leave application. If the leave is approved, proceed to the next step, otherwise the leave is rejected and proceed to step 8
3. Evil overload boss curses industrial relations laws allowing employee leave in the first place, but belatedly marks the leave request as approved.
4. Requestor is emailed a confirmation that his application has been approved
5. The leave is added to the corporate leave calendar
6. Blatant brown nosing suck-ups (Payroll) are notified by email of the approved leave and adjusts leave remaining in the HR system
7. End of workflow
8. The evil overlord boss (Approver) has had a call from the Nuclear safety watchdog and all safety inspectors need to be on-hand to hide the evidence. Thus the approver rejects the leave application
9. Requestor is emailed a confirmation that his application has been rejected with the reason why
10. End of workflow

From the above process, a number of key requirements are apparent and some more were determined.

• Automatic identification of requestor
• Reduce data entry
• Validation of dates, specifically the automatic calculation of days absent (excluding weekends)
• Mr Burns is not the only approver, we will need the workflow to route the leave approval to the right supervisor
• We have a central leave calendar to update

Additionally, Mr Burns likes to keep an eye on things and has a large series of monitors in his office that he uses to watch what is going on around the plant. Thus, he requires a dashboard that shows him a birds-eye view of the leave process from end-to-end.

Next steps..

The first step is to convert the existing manual leave form into its InfoPath equivalent. So in the next exciting article, we will get to see just how easy (or not) InfoPath really is!

Thanks for reading

Paul Culmsee

www.cleverworkarounds.com