Hi all

Workflows are big business in SharePoint land, despite the capability of SharePoint Designer Workflows being a fairly weak link in the overall SharePoint value proposition. If this wasn’t the case, then products like Nintex or K2 would not be so popular and workflow vendors wouldn’t have the biggest booths at the average SharePoint conference.

One of the serious strategic advantages of going with the SharePoint stack is the amazing 3rd party ecosystem that flourishes around the base product. No other platform in the space has the level of 3rd party support that SharePoint enjoys. But while its nice to be able to have great options for serious SharePoint workflow development, with each successive version of SharePoint that comes out, there is always that hope that one can use the base functionality without having to jump straight away to the 3rd party tools.  After all, it is quite common for organisations, having just gone to the time and expense of adopting SharePoint, to be dismayed that they have to part with yet more cash for 3rd party tools to address large functional gaps that were not apparent in the contrived product demos.

Another important trend being hidden by cloud hubris is the rise of the citizen developer. The CIO’s fountain of knowledge known as Gartner, stated that by 2014 25% of new business applications will be delivered by Citizen Developers.  They defined citizen developers as “a user operating outside of the scope of enterprise IT and its governance who creates new business applications for consumption by others either from scratch or by composition.” Elaborating, Gartner stated that

“Future citizen-developed applications will leverage IT investments below the surface, allowing IT to focus on deeper architectural concerns, while end users focus on wiring together services into business processes and workflows. Furthermore, citizen development introduces the opportunity for end users to address projects that IT has never had time to get to — a vast expanse of departmental and situational projects that have lain beneath the surface.”

So with SharePoint 2013, Microsoft has indeed changed things up a notch in the workflow world. Is it enough to enable and empower citizen developers?

That is what this series aims to find out… First up, lets take a quick look at the forces we are going to be meddling with…

What’s new with SharePoint 2013 and workflow…

Workflow in SharePoint 2013 is significantly different from SharePoint 2010. It fact, it is essentially a completely separate product called Workflow Manager. Technically, Workflow Manager is not part of SharePoint at all – there is no “workflow” service application or “service on a server” to be found. Instead, it is a separate process that works by communicating with SharePoint over the HTTP protocol in various ways.

This means that we have the option of deploying Workflow Manager onto its own server, or set of servers (although for you smaller sites, it happily installs onto your SharePoint servers and coexists with the rest of SharePoint too). This loosely coupled model has scalability benefits as workflow load can now be separated from the rest of SharePoint. It also means badly behaved workflows are less likely to affect SharePoint sites because they run in a separate process or separate servers. 3rd party applications (think about solutions built using the SharePoint 2013 apps model here) can also interact and communicate with workflow manager separately to SharePoint. It also helps Microsoft to realise their strategy of “encouraging” everyone to their vision of a cloud-based happy place.

Now new does not always equate to good – and Microsoft have a bit of a dubious history with V1 products and technology. So in this series, I’d like to show you an example of what the SharePoint 2013 new workflow regime can do. The example that I am going to use for this set of articles is useful for this purpose for several reasons:

• 1. It is a common use-case that many organisations would find familiar – particularly those with compliance regimes
• 2. It demonstrates a fairly typical SharePoint consulting “oh crap” moment, where you realise your masterpiece of a solution is completely undone by an untested assumption or a SharePoint caveat that you forgot about.
• 3. It demonstrates a path to redemption that is an excellent utilisation of the new capabilities of SharePoint 2013 and Workflow Manager
• 4. It gives you a great sense as to whether workflows are a real developer, information worker or citizen developer tool. In other words, after reading this, you should have a good idea what you are getting yourself into!

I have a lot to cover, so this series will be multi-part. This first post will outline the scenario that we are dealing with.

The scenario: Document Control at Megacorp

Many organisations operate in industries where they are required to manage documentation in a systematic way. Documents that are subject to any sort of quality or compliance regime are often referred to as “Controlled Documents”. Typically, a controlled document will have an assigned responsible party who is accountable for the management (i.e. approving the issuing of updates) of that document.

To illustrate, consider the document control requirements of Megacorp Inc – a mythical multinational conglomerate with a vide variety of businesses in many different industries and locations. Megacorp is your typical diversified multinational, making everything from Iron Man suits to hamburgers. A managed metadata term set illustrating the Megacorp conglomerate structure can be seen below. If you look closely, Megacorp Inc, actually consists of several companies and each is structured differently. For example: Megacorp Pharmaceutical divides itself based on country and state jurisdiction, whereas Megacorp GM foods divides itself up on the particular food it is generically modifying.

So let’s say that Megacorp is maintaining ISO9001 certification for assurance purposes and therefore has to control their documents as I have stated above. Let’s create a SharePoint site called ISO9001 to handle this requirement. We perform the following steps:

1. Build a term set (called Megacorp Inc)that stores all of the Megacorp businesses (you can see that in the image above)
2. Create a site based on the built-in Document Center template
3. Create a managed metadata site column called Organisation and associate it to the Megacorp term set
4. Add the organisation column to the document library (called Documents) in the Document Center site
5. Enable Metadata Navigation on the Documents library and add the Organisation column as a hierarchy field

For those of you who are new to SharePoint, below are screenshots from those steps to help you with the above steps… I am not going through this stuff in detail, so hopefully this suffices…

 

Now that the above plumbing is done, a few documents have been added to the Documents library and tagged to their organisation. With Metadata Navigation enabled, we now have the easy means to browse and filter documents to the specific organisation who owns them as shown below…

So let’s now think through a workflow scenario. Each organisation that makes up Megacorp has a process owner and when a document is ready for publishing, the process owner needs to approve it. Now we could do this by adding a “Person or Group” column to the document library and call it “process owner.” But Megacorp has some additional considerations that need to be pondered…

• 1. They have thousands of documents in the library
• 2. The process owner is a role, not an individual person. For audit purposes, Megacorp wants to have a record of when a person was in a particular process owner role.

The reason this complicates things is twofold. If we use a person’s user account in Active directory for tagging the process owner, we can easily track when a process owner changes because it will show up in the version history of the documents. But the downside is that we would have to update each document individually when that process owner changes to someone else. Not to mention that we may not want this change to be a version change in the document itself.

Now I know what your thinking – “Just use an Active Directory Group instead of an account”. Yes, it is a good and logical suggestion, since a SharePoint or Active Directory group allows us to easily manage changes in personnel between roles by changing group members. But the downside is that we have no easy way to see the history of who was in the process owner role at a given time because SharePoint would see and store the group, not the members of that group.

So let’s try an alternative approach. We will make a custom list called “Process Owners” and add two columns to it. We will add the Organisation site column that we created and used earlier, and we will add the “Assigned To” column that is built-into SharePoint and used in task lists. This will give us a list of process owners for a given Megacorp company or division. Even better – if we turn on version history on the Process Owners list, we now have a record of who was in the process owner role at any given time because it will show up in the changes in the “Assigned to” field over time.

The image below illustrates the Process Owners list.

So to summarise, we have a document library where all documents are tagged to the organisation that they belong to. We have a list of the process owners for each organisation. To better visualise this, I have drawn an xmind map to show you the Information Architecture of the Megacorp document control site

Now we turn our attention to the document approval workflow. It should be able to:

• Look at a document and determine the Organisation that a document belongs to
• Look in the process owners list for that organisation and then determine the process owner for the organisation by grabbing the information in the “Assigned To” field
• Create an Approval task for the Process owner to approve the release of a controlled document.

Now this all sounds straightforward enough in theory but as we will see as this series progresses, when it comes to SharePoint, theory and reality are two very different things. So in part 2, we will build out the workflow..

Thanks for reading

Paul Culmsee

www.heretisguidebooks.com

What does project management mean to me?

Well if you want me to give you the ‘glass half empty’ perspective, it’s easy. What project management means to me is a confused discipline where practitioners routinely do really dumb shit in its name.

Sermon over – go forth and spread the word…

Okay so that was fairly blunt, so I had better elaborate and perhaps take a more positively framed ‘glass half full’ approach to this sermon. To do that, I need to tell you about the legacy that Cleo magazine has left on society.

When I was younger, I used to skim through magazines like Cosmopolitan and Cleo while waiting in line at the checkout. Now you might think that I must really be in touch with my feminine side in admitting this, but no: the reality is that raw testosterone was the motivator. You see, Cleo would have headline articles like “10 great sex tips (in 50 words or less)” Or “The 10 things he doesn’t want in bed.” Titles like that dangled the possibility in front of me of finally understanding women, with the added bonus of developing Olympic class skills in the bedroom. Of course, each and every time the actual article never lived up to the catchy title. I rarely learnt anything new and in fact the “10 things” were usually pretty banal, self-evident and left me none the wiser.

So as our collective attention spans diminish via constant exposure to “5 steps to success with [insert buzzword here]” articles (articles designed more for search engine placement than actually informing an audience), the curse of Cleo-like catchy titles telling you stuff of little value is now so commonplace that it is hard to suss out the stuff that really makes a difference in outcomes.

So where does one go to find out the answers in project management? Should aspiring Project Managers master the dark arts of their craft by learning everything there is to learn from one or more of the bibles that contain the word “BoK” in them? On the surface it would seem so, given all of the past collective wisdom that is claimed to be codified therein – as well as shiny certification proving that one has passed the multi-choice exam on its contents.

But wait…which BoK is best? After all, we have multiple to choose from, with each making their own claims to the truth. Some BoKs even reject the key tenets of other BoKs, arguing that theirs offers a better answer. Of course, this leads to an endless stream of debate by their respective proponents as to which is really best and who is really the wisest. Not to mention that over time, new and updated BoKs emerge like phoenixes from the ashes of older BoKs. (Sometimes they are so cool that they don’t even claim to be a BoK at all).

It’s little wonder that Project Management is a confused discipline. No matter where you turn, someone is bound to tell you that you are doing it wrong.

While I am on the subject of doing it wrong, let’s poke a stick in one of the well-known project management hornets-nests: the “Waterfall vs. Scrum” argument. We all know that any self-respecting Scrum guy will not miss an opportunity to tell you about the evils of Waterfall – and for the most part they are right too, as Waterfall has a dubious history of which most people are not aware.

But that is not the reason I chose this particular topic, even though it is much loved by PMs who spend endless hours filling up the forums of various LinkedIn groups with discussion. I chose it simply because it’s fun to mess with Scrum guys – particularly the zealots. So if you have a “scrumdamentalist” in your midst, try this question on them:

Would Waterfall work if one could create an environment where all parties—as soon as they become aware of something that might affect a project materially—communicate it to all other parties involved in the project in a full, sincere and open way?

I have posed this question to many Scrum people. Most will think about it for some time, before answering a grudging “possibly” or “I don’t see why not.” Try it yourself… it’s fun pulling the rug out from under their firmly held convictions.

The best answer I have ever got to this question was from Chris Chapman – an Agile coach from Toronto. He gave me what I think is the perfect answer when he astutely observed that in the environment I described, Waterfall would actually not exist in the first place!

Therein lies the heart of my sermon. I contend that the endless debates over the efficacy of methods, tools and even BoKs are answering the wrong question! Don’t worry though, Project Management is not the first, nor the last discipline to lean their ladder against the wrong wall in this regard. To explain, let me introduce you to the work (and genius) of J Richard Hackman.

From the late sixties, Hackman spent his career researching and teaching about team performance, leadership effectiveness, and the design of self-managing teams and organizations. He died in 2013 and one of his last papers he published was called “From causes to conditions in group research.” In this swansong paper, Hackman explained how he spent years examining the factors that made teams work really well. He studied hundreds of teams (not just project teams mind you, but sporting teams, orchestras and flight crews), with the aim to distil the causes of success. Each time Hackman thought he had the causes figured out he would create a model, plug his model into a stats program, and work with real teams to see if the application of his model led to better performance.

On the surface, this approach seems like a logical thing to do. After all, if we can work out the magic levers that cause team success, then organisations would surely work better because they can start to pull those same levers. This is precisely the value proposition offered by the aforementioned BoKs as well.

When Hackman applied the models he lovingly researched and developed, he found they did not make a significant difference in outcomes. Being an academic, he did what most academics do: he spent years trying to refine his models and then re-tested them against real life teamwork situations. But this didn’t work either; his models got no closer to predicting or influencing outcomes in a reliable fashion. Reality it seemed, never fitted the models he developed.

At this point, Hackman began to question whether he was looking at the problem through the right lens. He wondered if trying to determine the causes of team efficacy by looking at successful teams retrospectively and then codifying these into causal models was the best approach. So he changed his focus and asked himself a very different question – a question that every project management practitioner (and project team member) should be asking themselves:

What are the enabling conditions that need to exist that give rise to great outcomes?

Now if, at this point, you think that this is the same question as “What are the causes of successful projects” you would be mistaken. Think about the BoKs and consider this: if you have ever argued with someone about whether a tool, methodology or some process is great or completely sucks, eventually someone will say something like “Well it can work for the right organisation.”

The implicit point here is that depending on the conditions, something that works for one organisation may completely suck for another (thereby invalidating the notion of a “best” practice). The genius of Hackman is that he challenges us to stop arguing about whether one methodology or model is better than the other and focus on what the enabling conditions are instead. Think about it – if project managers and developers did this, we would be able to avoid low value arguments like earned value management versus burndown charts.

In the case of Hackman, he re-examined all of his work on teams and boiled it down to six essential conditions, arguing that irrespective of what else you did or what methodology you used, having these conditions tended to lead to better results. Hackman did not rank any one condition over any other, instead arguing that all were needed for teams to have a greater chance of being high performing. The conditions are:

1. A real team: Interdependence among members, clear boundaries distinguishing members from non-members and moderate stability of membership over time
2. A compelling purpose: A purpose that is clear, challenging, and consequential. It energizes team members and fully engages their talents
3. Right people: People who had task expertise, self-organised and skill in working collaboratively with others
4. Clear norms of conduct: Team understands clearly what behaviours are, and are not, acceptable
5. A supportive organisational context: The team has the resources it needs and the reward system provides recognition and positive consequences for excellent team performance
6. Appropriate coaching: The right sort of coaching for the team was provided at the right time

There is more to that list than what I am covering here, and it is important to note that I’m not saying that Hackman’s conditions are *the* conditions. But I would contend that they are a pretty good start. Look at Hackman’s conditions for teams above and think about your projects and how you manage them. Did you have these conditions in place when you started? If you had them, would it have led to better outcomes?

I believe that it is a huge mistake to attribute success or failure of projects to methods, processes and models used to manage them rather than the conditions in which those processes operate. As long as this attribution error persists, people will continue to get suckered into B-grade verbal-slugfests about whether method X is better than method Y.

What exacerbates this “causes over conditions” problem is that enabling conditions rarely get codified in procedures, governance models, bodies of knowledge or certifications. As a result, the very factors that leads to success (the conditions) are entirely absent from the models that we use. My contention is that most organisations, when delivering projects, do not have the right enabling conditions in place to begin with. If your organisation has a blame culture, then chances are that any process, no matter how noble its design or intent, has the potential to become a blame apportionment mechanism or a responsibility avoidance mechanism.

So Hackman, despite looking at a different discipline of teamwork and leadership, gives us an important clue about what ails project management and how to we might improve it. Focus on enabling conditions rather than attributing causes!

Let’s get back to Chris Chapman’s answer to my Waterfall question. His assertion that Waterfall would not exist in the conditions I described holds a less obvious lesson. That is, the way project management tools or methods are used will affect conditions as well. So if you have ever said to yourself “I can’t believe that I am being forced to follow this wrong-headed process” chances are you have been on the receiving end of negative conditions created by application of a process. (So in this sense the agile dudes have it right.)

So what does project management mean to me? In short, focusing on creating the enabling conditions for great performance, and then getting out of the way!

 

Thanks for reading

Paul  Culmsee

 

Epilogue:

In this sermon I cannot hope to cover all of the things I would like to cover but never fear, Kailash Awati and I already piled some of our thoughts into 420 pages of goodness known as the book “The Heretics Guide to Best Practices” – so if you like what you read here, you will really like what is in there.

Acknowledgements:

As usual I have to thank Kailash for reviewing this post and making it suck much less than it did 🙂

Further reading:

1. My series on rethinking SharePoint maturity: Don’t let the title put you off – the material here further explores the conditions for great project performance: http://www.cleverworkarounds.com/2013/08/19/rethinking-sharepoint-maturity-part-1-conditions-over-causes/
2. Jon Whitty’s brilliant work on memeplexes and reconceptualising project management: http://espace.library.uq.edu.au/eserv/UQ:8801/sjw_ijpm_05.pdf
3. Pretty much anything on Kailash Awati’s blog, but in particular his sermon in this flashblog: http://eight2late.wordpress.com/2013/09/25/what-project-management-means-to-me-a-metalogue/
4. Stephen Duffield’s work on project knowledge management and risk: http://www.invictaprojects.com.au/pmlessonslearnedblog/?p=850

p.s: This post is published as part of a first ever project management related global blogging initiative to publish a post on a common theme at exactly the same time. Over seventy bloggers from Australia, Canada, Colombia, Denmark, France, Italy, Mexico, Poland, Portugal, Singapore, South Africa, Spain, UK and the USA have committed to make a blogging contribution and the fruit of their labor is now (literally NOW) available all over the web. The complete list of all participating blogs is found here so please go and check them out!

Hi all

Welcome to part five of my quest to improve people’s awareness and understanding of what SharePoint maturity is really all about. For those new to this series of articles, we have traversed a bit of territory to get here, and during the journey there has been not a single SharePoint site column, content type or site collection in sight. In fact, I have not touched any of the topics that many would traditionally view as a sign of SharePoint maturity. Instead, I have been taking readers on a fun-filled journey examining three nerdy, yet highly interesting areas of research in team development, collaboration and organisational learning. Along the way we defaced the Mona Lisa, looked at SharePoint through holes in slices of Swiss Cheese and channelled the number of the beast.

After all that, we ended part 4, by arriving at this odd looking diagram below…

What you are looking at is something called the CALL model, which stands for “Conditions to Actionable Lessons Learnt”. I originally developed the model with Dialogue Mapping and knowledge management in mind – essentially to help my clients do a better job of integrating double loop learning into their projects. However, it soon became apparent that it was valuable in various SharePoint contexts too.

Single vs. double loop learning

In the previous paragraph I made a reference to “double loop learning” without explaining what it was, so let’s quickly make amends because it is interesting stuff. The idea of single and double loop learning has been around for close to 40 years – it was in 1974 when Chris Argyris came up with the idea. To explain, let’s bring back our trusty SharePoint 2010 governance poster that I trash-talked in the first and fourth articles…

If you have not seen this poster before, it represents what Microsoft believe to be the focus areas for SharePoint 2010 governance. Many people – consultants in particular – will take the information in this poster for granted and create SharePoint governance plans that try to cover off the various areas it suggests to be covered. Everyone will feel good because they have ticked all the boxes of this authoritative fountain of SharePoint wisdom.

Then, if SharePoint then fails to live up to expectations, many will look at the poster and wonder which areas they did not adequately cover. They will study the poster, search Google or Wikipedia for better definitions of the terms listed and then make another reattempt, trying to do an even better job of implementing the wisdom contained therein.

This my friends, is a shining example of single loop learning. Single loop learning, as described in this article “seems to be present when goals, values, frameworks and, to a significant extent, strategies are taken for granted. The emphasis is on techniques and making techniques more efficient.” In single loop learning, the fundamental premise of a course of action remains unchanged. All of the energy of learning is directed to making sure “we get it right this time.” In short, in a single loop learning scenario, repeated attempts are made at solving the same issue, but no-one questions the underlying premise of the strategy.

Now in case you haven’t noticed, I spent the first three posts of this series “questioning the underlying premise” of the above SharePoint governance poster. So in effect I’ve been introducing you to the notion of double loop learning already. Double-loop learning involves taking a deeper look at what is going on. In double-loop learning, having attempted to achieve a goal on different occasions, the goal itself may be modified, re-framed or rejected in the light of the experience gained in trying to achieve it. Think about it – double loop learning actually happened in organisations people would never say things like “well that’s always how we have done it here.”

I see a lot of single loop learning in SharePoint land, and I want to help people break out of their existing framing of the issue – compassionately, of course

Enter the CALL Model

So getting back to my CALL model, I propose it as a multi-purpose tool that can be used for various SharePoint related stuff. It is based on the Swiss cheese risk management model; a metaphor which suggests most strategies have gaps that create risk. These gaps are analogous to holes in slices of Swiss cheese. In terms of the SharePoint governance poster, think of each of the areas it suggests to be covered as slices of cheese. This key to this model is that it assumes that no single defence layer is sufficient to mitigate risk. It also implies that if risk mitigation strategies are set up with all the holes lined up, there is a systematic flaw, since it would allow a problem to progress all the way through to adversely affect the organisation. Accordingly, the Swiss cheese model encourages a more balanced view of how risk is managed.

You can think of the CALL model as a SharePoint optimised Swiss cheese model. CALL extends the Swiss cheese model by incorporating cutting edge research in enabling team performance (Hackman), collaboration (Wilder) and knowledge management (Duffield). It outlines 8 actionable areas (Swiss cheese slices) that operate at the individual, team and organisation levels. These focus areas can be thought of as enabling conditions that mitigate risk, as well as focus areas for identification and application of lessons learnt. In other words, my contention is that for SharePoint maturity, you should strive to create these 8 conditions and then consider them when evaluating project performance.

The image above is another drawing of the model minus the pretty colours I used earlier. In this version, I am showing the path of a SharePoint project flows through these 8 areas. Note how the arrow from left to right deviates because we are seeking to use them to mitigate risk via defence in depth. But when it comes to applying learnings from a project (arrow now moves from right to left to close the loop), the flow is designed to be smooth and unencumbered to ensure that the opportunity for double loop learning takes place.

Here is a description of each of the 8 focus areas:

Skills and expertise

This focus area is concerned with ensuring individuals are selected with the right skills and task expertise to perform their role in delivery and operation of services. In SharePoint this is critical because of the technical depth and breadth of the product. Want to deploy SharePoint 2013 request routing in dedicated mode? Go see Spence so he can tell you not to. Want to learn how the new WOPI protocol works with Office Web Apps? Sign a cheque for Wictor to help you.

Skills is closely associated with high IQ. In other words, specialist skills require smart, dedicated people. Therefore this also incorporates ensuring staff have appropriate qualifications and certifications, that education, training and ongoing development practices are properly targeted, and that individuals are willing to learn new skills and be proactive in keeping themselves up-skilled. (In other words, all of the hallmarks of those brilliantly talented people who completed the now defunct Microsoft Certified Masters program).

Collaborative Maturity

Ever heard of the term “dumb smart guy”? Usually it is someone who is intellectually smart, but has all the emotional maturity (EQ) of a potato. Collaborative maturity is all about ensuring that individuals have skills in working collaboratively with others. It signifies a willingness to listen, empathy, mutual respect, understanding and trust. Collaboratively mature people have a tolerance for ambiguity and have the ability to engage in genuine dialogue to reach compromise. Collaboratively mature people also see collaboration in their self-interest and foster develop deep ties with colleagues in order to work interdependently.

Being in the IT industry, I’m not sure if this person actually exists, but hey – this description gives us all something to aspire to!

Role clarity

Role clarity is concerned that the role of each team member is understood by everyone within the team and it is clear how much authority is vested within each role. This in turn provides task clarity, fosters interdependency among a team and reduces process loss. (Process loss is difficulty in knowing who is doing what and how it is done). Where roles are clear and understood, team members are appropriately appointed to tasks according to their capacity (see “skills and expertise” above) and character (see “collaborative maturity” above).

Goal clarity

Goal clarity relates to purpose, direction and goal alignment between members of a team is essential for good team performance. A compelling purpose energizes team members, orients them toward their collective objective, fully engages their talents and motivates them to resolve conflicts. A compelling purpose should be underpinned by concrete, attainable goals and objectives, both short and long term. Knowing where you are heading focuses the team’s energy in directive meaningful activity. This also helps build team efficacy, which is the belief within teams of their ability to solve problems and deliver great solutions. On the other hand, lack of goal clarify is one of the classic symptoms of wicked problems.

Participation safety and decision influence

Ever been on a project that’s taking on water, but nobody seems to be willing to listen? Ever had any critically important topics not discussed because they are simply taboo and unmentionable? It is not fun – and little breakthrough thinking or innovation can exist without participation safety and decision influence. When a team has a high level of participation safety, members feel safe to share ideas, raise unpopular views or opinions, or speak their truth to one another. This reduces groupthink and social loafing, encourages breakthrough and can lead a collaborative team and a collaborative organisational culture. There are countless case studies of major disasters (such as the Deepwater Horizon Oil Spill), where a culture of “only tell me the good news” prevented critical information from being raised that could have averted the issue. In fact ‘communication’ (or lack of it) is probably the most commonly cited project failure factor.

Having said all that, while participation safety is critical, the ideas that team members put forward need to influence the direction and outcome of the team. A manager who says “my door is always open”, but then ignores feedback creates dissonance among team members because what is espoused is not practiced. The simple facts of the matter is that a key element for peak performance is to provide an environment safe enough for team members to speak their truths, to be rewarded for doing so and for truth telling to actually influence direction.

Enabling Technology

Technology underpins all aspects of organisational systems and projects and provides the means to generate leaps in performance and capabilities of users, as more broadly, team and organisational productivity. Technology at its best facilitates the delivery of timely, relevant information for decision making, co-ordination and collaboration. Thus it is critical that technology does not get in the way of delivering value. How often have you worked on a project when you have been forced to use technologies that stifle productivity, create frustration and reduce collaboration between team members? How often has that technology been SharePoint?

Enabling Process

How often have you said to yourself “I can’t believe I have to follow this braindead process.” Process is the glue that provides the rules of behaviour in delivering on goals and like technology, underpins all aspects of organisational systems and projects and is a key part of performance and productivity. It is critical that process, like technology, is always driven by purpose and that it does not get in the way of delivering value. Inappropriate process can make a huge difference in how team members interact with stakeholders and each-other.

Enabling Resources

Enabling resources is concerned with the financial, material and human input necessary to develop and sustain delivery of services. Put simply, even the best teams with the most compelling direction can falter if they are under-resourced. It is critical that sufficient funds, staff, materials and time are provided to get the job done.

Applications for the CALL model

The CALL model can be used in many ways, given its heritage of Hackman, Wilder and Duffield. Examples include:

• A model for performing SharePoint governance health check/assessment
• A model for assessing the makeup of a SharePoint team
• A model for assessing the complexity of a proposed SharePoint solution
• A model for assessing departmental readiness for SharePoint
• A model for developing SharePoint Business Continuity planning

It is worthwhile noting that Hackman developed a team performance instrument called a Team Diagnostic Survey based around his 6 enabling conditions. Since the CALL model is so closely aligned to Hackman, it should also be able to be used in a similar fashion. The same goes for the Wilder research on collaboration, that developed an instrument called the Collaboration Factors Inventory.

So given the source material, the CALL model also has applicability in the areas of:

• An set of enabling conditions to establish to develop high performing teams
• An set of enabling conditions to successful collaborative delivery of projects
• A focus area for the identification of risks (and opportunities) on organisational initiatives
• A framework for the systematic capture of project lessons learnt
• A framework for assessing change and other organisational initiatives
• A governance maturity model
• A knowledge management and organisational learning maturity model

Conclusion

The CALL model reflects a synthesis of three highly rigorous research efforts. All three seemed to gel really well when they were put into the melting pot and I was pleased with the result. In the next post, I will show you how I have used the CALL model when developing a SharePoint Business Continuity Strategy for a client. I’ll also talk about how I have used it in lessons learnt workshops.

Thanks for reading

 

Paul Culmsee

www.hereticsguidebooks.com

Hi all

Welcome to part 3 in this series about rethinking what SharePoint “maturity” looks like. In the first post, I introduced the work of JR Hackman and his notion of trying to create enabling conditions, rather than attribute cause and effect. Hackman, in his examination of leadership and the performance of teams, listed six conditions that he felt led to better results if they were in place. Those conditions were:

1. A real team: Interdependence among members, clear boundaries distinguishing members from non-members and moderate stability of membership over time
2. A compelling purpose: A purpose that is clear, challenging, and consequential. It energizes team members  and fully engages their talents
3. Right people: People who had task expertise, self organised and skill in working collaboratively with others
4. Clear norms of conduct: Team understands clearly what behaviours are, and are not, acceptable
5. A supportive organisational context: The team has the resources it needs and the reward system provides recognition and positive consequences for excellent team performance
6. Appropriate coaching: The right sort of coaching for the team was provided at the right time

I then got interested in how applicable these conditions were to SharePoint projects. The first question I asked myself was “I wonder if Hackman’s conditions apply to collaboration itself, as opposed to teams.” To find out, I utilised some really interesting work done by the Wilder Research Group, that produced a book called “Collaboration: What Makes It Work.” This book distilled the wisdom from 281 research studies on collaborative case studies and their success or failure. They distilled things down to six focus areas (they ended up with the same number as Hackman). Their six were:

1. Membership characteristics: (Skills, attributes and opinions of individuals as a collaborative group, as well as culture and capacity of orgs that form collaborative groups)
2. Purpose: (The reasons for the collaborative effort, the result or vision being sought)
3. Process and structure: (Management, decision making and operational systems of a collaborative context)
4. Communication: (The channels used by partners to exchange information, keep each-other informed and convey opinions to influence)
5. Environment: (Geo-location and social context where a collaborative group exists. While they can influence, they cannot control)
6. Resources: (The financial and human input necessary to develop and sustain a collaborative group)

If you want the fuller detail of Hackman and Wilder, check the first and second posts respectively. But it should be clear from even a cursory look at the above lists, that there is a lot of overlap and common themes between these two research efforts and we can learn from them in our SharePoint work. I strongly believe that this sort of material constitutes a critical gap in a lot of the material out there on what it takes to have a successful SharePoint deployment and offers some excellent ideas in further developing ideas around SharePoint maturity. I started to develop a fairly comprehensive Dialogue Map of both of these research efforts so I could synthesise them to create my own set of “conditions” in the way Hackman describes. While I was doing this, I met a fellow via LinkedIn who opened my mind to further possibilities. Everybody, meet Stephen Duffield…

Duffield’s SYLLK model for lessons learnt

I met Steve because we both shared a common interest in organisational knowledge management. In, fact Steve is working on his PhD in this area, focussing on addressing the pitiful record of organisations utilising lesson learnt practices on projects and then embedding them into organisational  culture and practices. If you have ever filled out a lessons learnt form, knowing full-well that it will disappear into a filing cabinet never to be seen again, Steve shares your frustration. For his PhD, he is tackling two research questions:

1. What are the significant factors that negatively influence the capture, dissemination and application of lessons learned from completed projects within project-based organisations?
2. Can a systemic knowledge model positively influence the capture, dissemination and application of project management lessons learned between project teams within the organisation?

Now if you think it was impressive that Wilder researched 281 studies on collaboration, Steve topped them by miles. His PhD literature review covered over 500+ papers on the topics of project lessons learned, knowledge management, risk management and the like. 500! Man, that’s crazy – all I can say to that is I am sure as hell glad he did it and I didn’t have to!

So what was the result of Duffield’s work? In a nutshell, he has developed a model called “Systemic Lessons Learned Knowledge” (SYLLK), which was influenced by the Swiss Cheese model for risk management, originally proposed by Dante Orlandella and James T. Reason.

Why SYLLK is important for SharePoint

Before I explain Duffield’s SYLLK model, it is important I briefly explain the Swiss Cheese model for risk management that inspired him. The Swiss Cheese Model (see the image to the left) for risk management is commonly used in aviation and healthcare safety. It is based on the notion that systems have potential for failure in many areas and these are analogous to a stack of slices of Swiss cheese, where the holes in each slice are opportunities for a process to fail. Each of the slices are “defensive layers” and while an error may allow a problem to pass through a hole in one layer, in the next layer the holes are in different places, allowing the problem to be caught before its impact becomes severe.

The key to the Swiss Cheese Model is that it assumes that no single defence layer is sufficient to mitigate risk. It also implies that if risk mitigation strategies exist, yet all of the holes are lined up, this is an inherently flawed system. Why? because it would allow a problem to progress through all controls and adversely affect the organisation. Therefore, its use encourages a more balanced view of how risks are identified and managed.

So think about that for a second… SharePoint projects to this day remain difficult to get right. If you are on your third attempt at SharePoint, then by definition you’ve had previous failed SharePoint projects. The inference when applying the Swiss cheese model is that your delivery approach is inherently flawed and you have not sufficiently learnt from it. In other words, you were – and maybe still are – missing some important slices of cheese from your arsenal. From a SharePoint maturity perspective, we need to know what those missing slices are if we wish to raise the bar.

So the challenge I have for you is this: If you have had a failed or semi-failed SharePoint project or two under your belt, did you or others on your team ever say to yourself “We’ll get it right this time” and then find that the results never met expectations? If you did, then Duffield’s (and my) contention is you might have failed to truly understand the factors that caused the failure.

Back to Duffield…

This is where Duffield’s work gets super interesting. He realised that the original Swiss cheese “slices” that resolved around safety were inappropriate for a typical organisation managing their projects. Like the Wilder work on collaboration, Steve reviewed tons of literature and synthesised from it, what he thinks are the key slices of cheese that are required to enable not only mitigation of project risks, but also focus people on the critical areas that need to be examined to capture the full gamut of lessons learnt on projects.

So how many slices of cheese do you think Steve came up with? If you read the previous two posts then you can already guess at the answer. Six!

There really seems to be something special about the number 6! We have Hackman coming up with 6 conditions for high performing teams, Wilder’s 6 factors that make a difference in successful collaboration and Duffield’s 6 areas that are critical to organisational learning from projects! For the record, here are Duffield’s six areas (the first three are labelled as people factors and the second three are system factors):

1. Learning: Whether individuals on the team are skilled, have the right skills for their role and whether they are kept up-skilled
2. Culture: What participants do, what role they fulfil, how an atmosphere of trust is developed in which people are encouraged, even rewarded for truth telling– but in which they are also clear about where the line must be drawn between acceptable and unacceptable behaviour”
3. Social: How people relate to each-other, their interdependence and how they operate as a team
4. Technology: Ensuring that technology and data supports outcomes and does not get in the way
5. Process: Ensuring the appropriate protocols drive people’s behaviour and inform what they do (gate, checklists, etc.)
6. Infrastructure: Environment (in terms of structure and facilities) that enable project outcomes

Duffield has a diagram that illustrates the SYLLK model, showing how his six identified organisational elements of learning, culture, social, technology, process and infrastructure align as Swiss cheese slices. I have pasted it (with permission), below (click to enlarge).

Duffield states that the SYLLK model represents “the various organisational systems that collectively form the overall behaviour of the organisation. The various modes of social and cultural learning, along with the organisational processes, infrastructure and technology that support them.” Notice in the above diagram how the holes in each slice are not lined up when the project arrow moves right to left. This makes sense because the whole point of the model is the idea of “defence in depth.” But then the holes are aligned when moving from left to right. This is because each slice of cheese need to be aligned to enable the feedback loop – the effective dissemination and application of the identified lessons.

Conclusion

The notion of the Swiss cheese model for mitigating risk makes a heck of a lot of sense for SharePoint projects, given that

• a) there is a myriad of technical and non technical factors that have to be aligned for sustained SharePoint success, and
• b) SharePoint success remains persistently illusive for many organisations.

What Duffield has done with the SYLLK model is to take the Swiss Cheese model out of the cloistered confines of safety management and into organisational learning through projects. This is huge in my opinion, and creates a platform for lots of innovative approaches around the capture and use of organisational learning, all the while framing it around the key project management task of identifying and mitigating risk. From a SharePoint maturity perspective, it gives us a very powerful approach to see various aspects of SharePoint project delivery in a whole new light, giving focus to aspects that are often not given due consideration.

Like the Wilder model, I love the fact that Duffield has done such a systematic and rigorous review of literature and I also love the fact that his area of research is quite distinct from Hackman (conditions that enable team efficacy) and the Wilder team (factors influencing successful collaboration). When you think about it, each of the three research efforts focuses on distinct areas of the life-cycle of a project. Hackman looks at the enabling conditions required before you commence a project and what needs to be maintained. Wilder appears to focus more on what is happening during a project, by examining what successful collaboration looks like. Duffield then looks at the result of a project in terms of the lessons learnt and how this can shape future projects (which brings us back to Hackman’s enabling conditions).

While all that is interesting and valuable, the honest truth is that I liked the fact that all three of these efforts all ended up with six “things”. It seemed preordained for me to “munge” them together to see what they collectively tell us about SharePoint maturity.

… and that’s precisely what I did. In the next post we will examine the results.

 

Thanks for reading

 

Paul Culmsee

www.hereticsguidebooks.com

Hi all

Welcome to part 2 about my research efforts that has led me to thinking a little differently in how we understand and measure SharePoint and organisational “maturity”. In the first post, I gave a glimpse into the work of JR Hackman, who had presented some really interesting ideas about what leads to outstanding team performance. In case you have not read the first post (damn you!), Hackman presented the notion that trying in vain to come up with the causes of team efficacy was a rather dumb idea and instead, looking at the conditions that enable great teams was a much more productive approach.

This notion of conditions over causes is really important to understand, because we all routinely get suckered into conversations about whether one process, approach or model is objectively “better” than another. This sort of discussion frustrates me and I usually find it all rather pointless because it all but ignores the underlying conditions that enabled or disabled things. As a result, we misattribute success or failure of SharePoint to how we used methods, processes and models, rather than focus on what really matters – the conditions under which those methods, processes and models operated.

Now Hackman was not looking at SharePoint projects when he came to this realisation. He was looking at leadership and the performance of teams in general. He synthesised his years of research work down to six conditions that he felt led to better results if they were in place. Those conditions are:

1. A real team: Interdependence among members, clear boundaries distinguishing members from non-members and moderate stability of membership over time
2. A compelling purpose: A purpose that is clear, challenging, and consequential. It energizes team members  and fully engages their talents
3. Right people: People who had task expertise, self organised and skill in working collaboratively with others
4. Clear norms of conduct: Team understands clearly what behaviours are, and are not, acceptable
5. A supportive organisational context: The team has the resources it needs and the reward system provides recognition and positive consequences for excellent team performance
6. Appropriate coaching: The right sort of coaching for the team was provided at the right time

So I very much bought into Hackman’s conditions over causes argument, but wasn’t sure whether his six conditions were directly applicable to SharePoint projects. To find out, I got lucky, coming across some really great work on the subject of collaboration by the Wilder Research Group.

Collaboration: What Makes it Work

Earlier this year, I  bought a crapload of books on the topic of collaboration. One of them had the rather long title of “Collaboration: What Makes It Work, 2nd Edition: A Review Of Research Literature On Factors Influencing Successful Collaboration” written by Paul W. Mattessich, Marta Murray-Close, Barbara R. Morrisey and published by the Wilder Research Group.

This book is quite short – just over 100 pages, but it packs a heavy punch nevertheless. The core question asked in this book was “What makes the difference between your collaboration’s failure or success?” and it sought to answer the question by providing an in-depth review of lots (and lots and lots) of academic research on collaboration. In all, the authors examined more than 281 research studies on collaborative initiatives (and their success or failure) and synthesised them. I love these sort of meta-analysis studies, because I am lazy and its terrific when someone else has done the rigorous hard work!

Why Wilder matters for SharePoint

The intent of the report is to help readers expand their thinking about ways to help projects succeed, gain background information before beginning a collaboration, compare their situation with others, determine collaboration strategy including necessary ingredients, uncover and resolve trouble spots. It also provides a tool called the “The Collaboration Factors Inventory” which allows you to self-assess how your collaboration is doing against the success factors they came up with. Examples are also provided of how organizations have used the inventory as well as a case study illustrating how one collaboration assessed itself and how it  used the results to take action to improve its success.

Thus, it should be fairly obvious why this particular work should be of interest to SharePoint practitioners. After all, improving collaboration in organisations and teams is one of the core value propositions that underpins SharePoint and has done so for years now. Under the guise of “governance”, we do lots of work and produce processes (and usually lots of documentation) in the hope that we have put in the necessary plumbing for collaboration to take root and blossom. So when someone has taken the time to distil the learnings from 281 research efforts into collaborative success, there is bound to be valuable takeaways to be had for us SharePoint peeps – especially if our organisations have bought heavily into “social” features of the product.

Now while that all sounds good, there is another less obvious, but cooler reason to be interested in this book – especially given my examination of Hackman in part 1. The Wilder team found a total of 20 factors that were identified as “ingredients” for successful collaboration and guess how many categories they distilled them down to?

Six! – precisely the same number of conditions that Hackman distilled for great team performance. So, wouldn’t it be interesting to see how much overlap there is between what Hackman says are the six conditions for great teams versus Wilder’s six “differences” between collaboration failure and success?

I thought so too…

Back to the Wilder team…

So what are the factors that make a difference in successful collaboration identified by Wilder? Below are their twenty ingredients, divided into the aforementioned six categories…

• 1. Membership characteristics: (Skills, attributes and opinions of individuals as a collaborative group, as well as culture and capacity of orgs that form collaborative groups)
  • – Mutual respect, understanding and trust: Members of the collaborative group share an understanding and respect for each other and their respective organizations: how they operate, their cultural norms and values, limitations, and expectations.
  • – Appropriate cross section of members: To the extent that they are needed, the collaborative group includes representatives from each segment of the community who will be affected by its activities.
  • – Members see collaboration as in their self interest: Collaborating partners believe that they will benefit from their involvement in the collaboration and that the advantages of membership will offset costs such as loss of autonomy and turf.
  • – Ability to compromise: Collaborating partners are able to compromise, since the many decisions within a collaborative effort cannot possibly fit the preferences of every member perfectly.
• 2. Purpose: (The reasons for the collaborative effort, the result or vision being sought)
  • – Concrete, attainable goals and objectives: Goals and objectives of the collaborative group are clear to all partners, and can realistically be attained.
  • – Shared vision: Collaborating partners have the same vision, with clearly agreed-upon mission, objectives, and strategy. The shared vision may exist at the outset of collaboration, or the partners may develop a vision as they work together.
  • – Unique purpose: The mission and goals or approach of the collaborative group differ, at least in part, from the mission and goals or approach of the member organizations.
• 3. Process and structure: (Management, decision making and operational systems of a collaborative context)
  • – Members that share a stake in both process and outcome: Members of a collaborative group feel “ownership” of both the way the group works and the results or product of its work.
  • – Multiple layers of participation: Every level (upper management, middle management, operations) within each partner organisation has at least some representation and ongoing involvement in the collaborative initiative
  • – Flexibility: The collaborative group remains open to varied ways of organising itself and accomplishing its work
  • – Development of clear roles and policy guidelines: The collaborating partners clearly understand their roles, rights, and responsibilities, and they understand how to carry out those responsibilities.
  • – Adaptability: The collaborative group has the ability to sustain itself in the midst of major changes, even if it needs to change some major goals, members, etc., in order to deal with changing conditions.
  • – Appropriate pace of development: The structure, resources, and activities of the collaborative group change over time to meet the needs of the group without overwhelming its capacity, at each point throughout the initiative.
• 4. Communication: (The channels used by partners to exchange information, keep each-other informed and convey opinions to influence)
  • – Open and frequent communication: Collaborative group members interact often, update one another, discuss issues openly, and convey all necessary information to one another and to people outside the group.
  • – Established informal relationships and communication links: In addition to formal channels of communication, members establish personal connections — producing a better, more informed, and cohesive group working on a common project.
• 5. Environment: (Geo-location and social context where a collaborative group exists. While they can influence, they cannot control)
  • – History of collaboration or cooperation in the community: A history of collaboration or cooperation exists in the community and offers the potential collaborative partners an understanding of the roles and expectations required in collaboration and enables them to trust the process
  • – Collaborative group seen as a legitimate leader in the community: The collaborative group (and by implication, the agencies in the group) is perceived within the community as reliable and competent—at least related to the goals and activities it intends to accomplish.
  • – Favourable political and social climate: Political leaders, opinion-makers, persons who control resources, and the general public support (or at least do not oppose) the mission of the collaborative group
• 6. Resources: (The financial and human input necessary to develop and sustain a collaborative group)
  • – Sufficient funds, staff, materials and time: The collaborative group has an adequate, consistent financial base, along with the staff and materials needed to support its operations. It allows sufficient time to achieve its goals and includes time to nurture the collaboration.
  • – Skilled leadership: The individual who provides leadership for the collaborative group has organizing and interpersonal skills, and carries out the role with fairness. Because of these characteristics (and others), the leader is granted respect or “legitimacy” by the collaborative partners.

Now that you have seen Wilders six factors that influence successful collaboration, think about where you focus on your SharePoint projects in the name or guide of “governance”. How many of these factors did you consider when you started on your quest to use SharePoint for improved collaboration? Which of these really scream out at you as something worth pursuing? Go back in time and with hindsight, imagine if you had considered these and acted on it… Would it had led to better outcomes?

Conclusion

I have previously stated that collaboration is a classic SharePoint platitude, and chasing goals like “improved collaboration” are a sure fire way to create elaborate SharePoint solutions that miss the mark. Thus, this work by Wilder is a crucial resource in helping organisations determine what collaboration means to them. Furthermore, anyone interested in assessing SharePoint “readiness” (whatever your interpretation of readiness), would be well served to think about how they can incorporate the Wilder work into their readiness or maturity models. After all, how many other meta analyses of 281 studies on the topic have been done, eh?

Consider also that the Wilder team asked themselves a different question than Hackman. While Hackman framed his question around “What are the enabling conditions?” the Wilder team asked “What makes the difference?” This more broader question posed by the Wilder team explains a lot about their results. Some of their collaboration success factors can be seen as potential enabling conditions as Hackman described, whereas others are a more retrospective look on what successful collaboration looks like during and after collaboration has taken place. Consider also Hackman and the Wilder team used very different areas of research to come up with their answers. Wilder examined 281 case studies on successful collaboration, whereas Hackman used decades of research in teamwork and leadership. While research on collaboration might seem related to teamwork and leadership, in the world of academic research, you are talking about completely different bodies of knowledge.

Nevertheless, if you compare Hackman’s six conditions to Wilder’s six collaboration factors, there are more overlaps than there are differences. This I find exciting because it tells me that these independent research efforts are coalescing around the same themes. But I am going to defer a detailed examination of them both in context till a future post, because as I started to synthesise Hackman and Wilder together, I came across a third area of research that also led to some important insights – perhaps the most important ones of all… the work of PhD candidate Stephen Duffield in the area of risk and organisational learning on projects.

That my friends, is the topic of the next post…

 

 

Thanks for reading

Paul Culmsee

www.hereticsguidebooks.com

Hi all

I have been hitting the books lately, doing various bits of research, all related to plans for a new book.  While most of that research would not be of too much interest to readers, some of it turned out to be quite profound and has significant implications for anybody interested in SharePoint governance/maturity/readiness, as well as risk management, organisational learning, knowledge management and team development. So if you are spending your days delving deep into the bowels of the SharePoint 2013 apps model, oAuth and Azure Service Busses, then maybe this article is not for you. However if you manage or are responsible for people or projects that delve deep into the bowels of the SharePoint in areas like the apps model, oAuth and Azure Service Busses, then I strongly suggest you read on. Continue reading “Rethinking SharePoint Maturity Part 1: Conditions Over Causes”

[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

Welcome to edition 7 of this seemingly never-ending tribute to the humble annual leave (vacation) form. This is getting to be like the “Friday the 13th” series of movies – they never stop!

First up, I want to categorically state that, as a heterosexual Australian male, I have a few stereotypical personality traits . I enjoy beer, kung-fu movies, Burger Rings, Vegemite and Tim-Tams, love the cricket (especially playing India) and most importantly of all, I do not read instructions. Period. I think that ignoring the RTFM rule is a characteristic of all of humanity but Australians in particular seem to celebrate this trait as something endearing.

Therefore, it pains me greatly to have to inform you that this seventh edition of the series is one of those posts where you have to put on the brakes and explain some really boring conceptual stuff to proceed with the rest of the series. Yeah, I know – theory is boring and sucky and you just wanna get into the nuts and bolts of it all. But, as Homer demonstrates below, sometimes we have to defy our genetic programming and actually read the instructions. The alternative is a SharePoint solution equivalent to that of Homers BBQ.

This post will deal with some of the mechanics of form submission and form publishing.

What has gone before…

The first few posts in this series are starting to get hazy – it seems so long ago now. To sum it all up in a nutshell, we introduced the leave form as a means to introduce a lot of key SharePoint features in an easy to understand and relevant way. We set several requirements that we had to achieve.

• 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

At the end of part 6 we were working on validation of dates. We added some validation rules to ensure that you could not return to work before you started your leave of absence. But at the end of that post, I showed how a published form did not obey our data validation rule, where the form was set to prohibit incorrect dates, yet I was able to click save and put the form straight into the document library. What the…?Why did this occur?

Saving vs Submitting – form confusion

Like everything else designed by nerdy engineers, InfoPath and Forms Services can be used in a few different ways. This offers flexibility of course, but has the disadvantage that if the flexibility is not well understood (i.e not reading the instructions ), it is easy to cause user confusion. Homer is a classic case of a person who, when faced with two choices, will always pick the wrong one.

You have to remember that InfoPath started out as a program installed onto your PC, along with other MSOffice applications. Thus, historically, an InfoPath form is just another type of document. In its simplest (and default) scenario, the form is very much like any other MSOffice document in that you create/open the form, edit it and then save it.

But hang on a second! Most of the time, the data collected in the form is part of a larger business process. Also most of the time, business process needs to do “stuff” with the information that the user has entered. In other words, the data usually doesn’t stay in the forms that users fill out.

So the InfoPath designers, wanting to please everybody, designed InfoPath in such a way that saving a form and submitting a form are two different things. Homer Simpson doesn’t care about this nor should he. He just wants to fill out the form so he can go back to dreaming about the land of chocolate.

Here is the key thing you need to know, though. Saving a form is, in effect, performed on the presumption that the form is still a work in progress. Saving the form should be thought about in the same way you would save a word document after performing some edits. Because the form is still a work in progress, data validation should not take place.

But at some point the form stops being a ‘document’ and becomes…well… a form! It is complete and no more edits should be made. This is when you actually submit the form!

Submitting a form triggers the data validation rules that were set up in part 6.

Big deal…When does this get hard, Paul?

Okay, so you may not think that there is really that much of a drama with the whole “save vs submit” thing. But when InfoPath is integrated with SharePoint via Forms Services, it can get complicated. You see, InfoPath allows you to create forms that submit their data to one or more locations. For example, the Springfield Nuclear Power Plant leave form could be set up so that when Homer submits his application, the data is sent to a database, and a copy of each completed form is also sent in an e-mail message to Waylon Smithers and Monty Burns.

For reference, here are the places that InfoPath can submit to;

• A Microsoft Access or Microsoft SQL Server database
• A Web service
• A server running Microsoft Windows SharePoint Services
• In an e-mail message
• An application on a Web server
• A custom application that hosts InfoPath

Now, given that this series of articles is about SharePoint, which option of the above list do you think we are interested in? You guessed it! The third option in the above list is SharePoint.

But here is the root cause of the confusion, when you publish an InfoPath form to SharePoint, all forms that you fill in end up being created in a document library. Back in part 4 of this series, we first published the form and as part of that process, created a form library called “Leave Forms”. Consider the screenshot below. We are about to create a new form in this library.

Below is a screenshot of the new form to fill out. Note the toolbar at the top with a “Save” and “Save As” options. If you then click ‘Save” on the form, it will prompt you to save into the above document library.

 

Therefore, if you use the “Save” option, the “In-progress” copies of the form are stored in the document library and no data validation has taken place. You really have not submitted the form at all.

Does the end user realise this? Some might – but come on! This is Homer J Simpson we are talking about here!

So clearly we need to submit this form because in part 6 we added validation rules that need to be checked. But, what the…? – How the hell do I submit?

Setting up form submission

Real programmer disclaimer: Yes I know there are other ways of doing all of this, but remember – this series of posts is for beginners.

Okay, for now the theory bit is over, and now we get to play with InfoPath again. We are going to add the form submission capability to our existing form so that we can actually submit the form. The thing is, I am also going to *remove* the “Save” and “Save As” options from that toolbar, so that the only action you can make is to submit.

Why would I do this? Several reasons.

• It is a simple form and really, you either fill it in and submit or you don’t. There really isn’t that much of an imperative to save this form, prior to submitting it.
• When you submit a form, and you are submitting to a SharePoint library, the submitted form is saved. Therefore, I don’t need a “work in progress” copy.
• The Homer factor. If you supply a “Submit” and a “Save” button, you know full well that Homer will go and click the “Save” button, when he should be clicking “Submit”. As soon as the save dialog pops up, he won’t know what to do. At this point he will lose interest and fall asleep.

Hiding save buttons

So, start InfoPath, open up the leave form in design mode, and choose “Form options” from the “Tools” menu.

From the list of options, choose “Open and Save” and uncheck the “Save and Save As” checkbox as shown below.

Click “OK” and republish this form to SharePoint using the steps described in part 4. Note the before and after screenshots below

 

Spot the difference? The “Save” and “Save As” buttons are missing, and with that I can confidently say that I have now made this form Homer proof because he can’t inadvertently click “Save” and think he has submitted the form. Of course, it is so Homer proof that he now has no way to submit the form, so now we have to enable the “Submit” button.

Enabling the submit button

Once again, open the leave form in design mode, and choose “Submit Options” from the “Tools” menu. InfoPath will dutifully display a fairly nondescript dialog box that, at first glance, seems rather simple. There is a checkbox that you need to tick to “enable form submission”. Sweet! How easy is that?

 

Upon checking that box, you now have to choose where you are going to send form data to. The default option is “Email”, but we want to send it to a SharePoint document library, as shown below. Choose SharePoint and then click OK.

Uh oh! Did I say this was going to be easy? Okay I lied .

So, what is this message telling us? “You must select a data connection for submitting to a SharePoint document library”. Hmmm…I hope that something about that message sounds vaguely familiar to you. That is because this is not the first time we have dealt with data connections.

Data Connections revisited

Way back in part 5, you earned your CCLFD certification by creating a data source that automatically identified Homer by talking to SharePoint web services. If you missed that post, then I suggest reading it, as it is a great example of utilising data connections to *receive* data into InfoPath.

In part 5, we set up a data connection to a webservice by following a wizard. To remind you of how it was done, I have copied the screenshots to this post.

Now, take a look at the second screenshot from the above three. It is asking you to create a connection to receive or submit data and at that time we were receiving data. Guess which one we are doing this time?

So, back to our “Submit Options” dialog box. We were not able to click “OK”, because we have not created a data connection to submit the data. Let’s now start this process by clicking the “Add” button. Given that you have already told SharePoint that you want to submit to a document library, InfoPath now wants to know the name of that document library and the name of the file that will be created by the submit.

 

Now, given that the entire staff of the nuclear power plant will be filling out this form, we don’t want to simply call the submitted form “Form” as suggested by default. If we did that, we would end up with a document library containing a single file called “FORM” due to the fact that all previous “FORM” files would have been overwritten and replaced by the current “FORM”.

Luckily the InfoPath team anticipated this and the filename can be dynamically generated using functions. (We looked at functions early in part 5).

First up though, I will specify the document library to submit completed forms to. It will be in the same document library that we was created when we first published the leave form in part 4,the imaginatively titled “Leave Forms”. Below is the library as it is inside the radiactivenet site. Note the URL is exactly what I entered into the “Document Library” field.

A unique filename

The final step for submission is to create an auto-generated filename that is unique. Although the principle is dead simple, this bit is actually tricky when you do it for the first time.

The file naming convention to be used will be as follows:

“Leave Form – ” + [EmployeeName field] + ” – “, [LeaveType field] + ” – ” + [todays date]

Here are some examples of this convention in action with various staff.

• “Leave Form – Homer Simpson – Sick – 2007-09-18″
• “Leave Form – Lenny Leonard – Annual – 2008-11-22″
• “Leave Form – Carl Carlson – Bereavement – 2008-12-25″

So, how do we achieve this? Let’s get back to the screen where we are prompted to add a file name for a submitted form.

Click the “Fx” button to the right of the “File name” textbox and you will be presented with the (far too small to be user friendly) “Insert Formula” dialog box. We are going to create a formula that constructs the desired file name.

The first thing to note is that we will be using a combination of fixed text, the data entered on the form and built in InfoPath functions. To join all these together in the manner we want is referred to as concatenation. Why do people call it concatenation? I have no idea but it’s obvious that an engineer thought up that name! .

We start by inserting the concatenation function called “concat”. Click “Insert Function” and in the leftmost window choose the “Text” category. The function called “concat” should be the first one listed. Select it and click “OK’ and you will see that a partially completed formula has been created.

 

The first part of our file name is the text “Leave Form – “. So single click the first occurrence of the “double click to insert field” hyperlink and it will be highlighted. From here, simply type in the string “Leave Form – ” (including the double quotes).

 

The next part of the file name is the name of the employee. We already have this, because in part 5 we set up a data connection to automagically grab first name and surname and store it in the textbox called “EmployeeName”.

Single click the next occurrence of the “double click to insert field” hyperlink and it will be highlighted. From here, click “Insert Field or Group” and choose “EmployeeName” from the list of fields.

 

Okay, so we have the “Leave Form – Homer Simpson” part done. Next we want a hyphen ” – ” and then the LeaveType field. By now you should be getting familiar editing the formula in the dialog box. Rather than bore you with even more screenshots, I’ll talk through the next 2 steps.

• Single click the next “double click to insert field” link.
• Type in (note the leading and trailing space) ” – “
• Type in a comma (minus quotes) “,”
• Click “Insert Field or Group” button
• Choose the “LeaveType” field and click OK.

If all has gone to the script, then you will see this in for formula box.

Note that you can use the mouse to place the cursor anywhere in the Formula textbox and modify what is there.

Finally, we need another hyphen and to insert another function. This time the function is called “time” and it returns the current date in a short locale based format.

• Referring to the above screenshot, place your cursor between the last letter of the underlined LeaveType (which is “e” ) and the closing bracket.
• Type in (including the quotes and note the leading and trailing space) ” – “
• Type in a comma (minus quotes) “,”
• Click “Insert Function” button
• Choose “Date and Time” from the Categories List in the “Insert Function” dialog box
• Choose “today” from the list of functions and click “OK”

We are done! The final formula looks like this. Click “OK” and you now should be back at the data connection wizard (the second screenshot below).

Click “NEXT” on the wizard, and we are prompted to give this data connection a name. Since this data connection has been created to submit leave forms to a document library called “Leave Forms”, I figured that a good name would be “Submit to Leave Form Library”. Click “Finish” and you are done!

To recap on what we have completed in this section, each time a form is submitted, its filename will be automatically specified and the end-user does not have to worry about it.

All rightie, then! Let’s republish this form to SharePoint and take a look at the effect.

Testing it out

Assuming everything worked, the effect of what we have done is immediately noticeable. We now have a “Submit” button on the form where the “Save” and “Save As” used to be. Sweet!

So let’s test the data validation rules that we created in part 6. If you recall, this form should not be submitted if the return date is before the start date. For that to really happen you would have to be Dr Who and use the Tardis to arrive before your departure…

Below is the form with deliberately incorrect data (click to enlarge).

If I now click the newly visible “Submit” button, what happens? Ecccccxcelent! It refuses to submit the form.

I don’t know about you, but this is one of those error messages that some people simply will not read. Homer will no doubt call technical support but the point is, crap data has not gotten past the form in the first place.

Now, when we correct the fault and resubmit the form, it accepts!

Click “Close” and we now see the newly submitted form in the document library, saved with our file naming convention! Woohoo!

Conclusion (Are we done yet?)

We now have achieved the goal of ensuring that our form is validated before being submitted. From a skills point of view, you now have created data connections to both send and receive data and you have integrated your form with web services, as well as some nice data validation logic.

Waylon Smithers is still pleased with progress thus far, and Homer hasn’t managed to completely derail things just yet.

But unfortunately for all of us, there is still much work to do. The next post will spend some time pimping up this whole validation and submission process, illustrating a pitfall or two along the way.

Thanks for reading

[Note: I never finished this series for various reasons. I hope that these 7 posts helps you nonetheless]

Paul Culmsee

[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 again

When I started this series of articles, I knew it would be quite a few parts and ambitious in its way. But after reading some of the other great articles on SharePoint Magazine, such as Bjørn Furuknap’s first article on customising the user experience, I’m now feeling like I picked the easiest topic of all!

Seriously, Bjørn, part 1 of your series is the closest experience I can imagine to any man giving birth! I bet you feel relieved getting that one out of your system!

So, do I feel guilty that my subject matter is easier? Am I suffering nerdiness envy?

Hell, no! I’ll stick to my fantasy world of user acceptance testing with Homer Simpson any day!

Previously…

Given that there are big time gaps in getting these articles out, I’d just like to reiterate that this series is pitched at a very wide audience, so hard-core nerds will probably find it waffly and frustrating. But then again, most regular people find hard core nerds waffly and frustrating .

I have been writing this series from the point of view of a frustrated implementation developer/engineer who has to deal with a clueless business development manager and a difficult customer. This, of course, is completely unfamiliar territory for all implementation developer/engineers because none of you reading this would have ever experienced such a situation, right? … hehe

Part one of this series introduced some background and provided the requirements for the leave application/approval process for the Springfield nuclear power plant. Those requirements were:

• 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 appropriate supervisor
• We have a central leave calendar to update

Parts two to four were really the “slick presales demo” parts of this series where the world is promised to the client and, hence, expectations were completely off the planet. Thus, we started out nice and easy in part two and three, where we introduced InfoPath 2007 and went through the exercise of importing the existing Springfield MSWord based form. We then added some data entry controls and tidied up the formatting. In part four, we published this form to SharePoint itself.

All in all, the first four articles covered some pretty straightforward stuff. Now, however, the salesman has moved on and our intrepid engineer is starting to get into the pointy end of things. In part five we delved into the scary world of web services and InfoPath data connections so satisfy the requirement of automatic identification of the requestor. That was a bit of a jump, wasn’t it?

This time around, let’s take care of the “reduce data entry” requirement, and leverage some of InfoPath’s useful features to make our form smarter. For those who found article 5 a bit heavy, this one is actually quite a bit easier (but it’s just a brief lull before we get to coding!). At the end of part 5 I said I’d deal with how to automagically handle the employee number – but I have decided to take care of that a little later.

Preventing a rift in the space-time continuum

Yeah, I know I was using the Simpsons theme for this series, but today I am dropping in a dash of Heroes.

First up, we need to add some logic to the form so that it doesn’t submit crap (that’s the technical term for “invalid”) information. For example, we want to make sure that you cannot return to work on a date *before* you leave – unless you’re Hiro Nakamura, of course.

Generally, for the rest of us who cannot bend time, you do actually come back to work at some point *after* you leave, so let’s make the necessary changes to ensure that our form does not destroy the world in some space-time vortex.

Today we are interested in the three date/time fields as shown below.

If you recall in part three where we created the form controls, we gave them the meaningful names of CommenceDate, CompletionDate, ReturnDate.

For reference, at any time, you can review your field names easily by clicking the “Data Source” link in the InfoPath design pane as shown below.

 

So, we have these three date fields and the rules are:

• The completion date cannot be *before* the commencement date.
• The return to work date cannot be *before* the completion date.

When you think about what we are doing here, we are validating data to make sure that it matches our business rules. Fortunately for us, InfoPath has some nice capabilities here to assist. Even better, they called it “Data Validation”. So, let’s take a closer look…

• Select the “Completion Date” control, right click and choose “Data Validation”

You are presented with a fairly unexciting text box asking you to add a condition that determines whether the value entered is valid. Clicking the “Add…” button displays the dialog box to add a condition. It is quite common to have multiple conditions that need to be satisfied in order for the data entered to be considered valid.

 

In our case, we wish to ensure that the CompletionDate field cannot contain a value that is less than the CommenceDate field. Create this condition by specifying “less than” from the middle drop down box, and then picking the “CommenceDate” field for the third dropdown box.

 

 

Clicking OK and we have our completed validation condition!

One final OK and we are back at our form and ready to test this. Rather than publish the form to SharePoint now, we can make use of InfoPath’s “Preview” button on the toolbar and test it out. Below I have an example preview where Homer has been identified as per the previous post. Additionally, I have used the date picker to specify the commencement date (October 25 2008) of leave.

What do you now see on the Completion Date field? What’s with that red asterix? Maybe I should hover my mouse over it and take a look, eh?

Aww… How sweet! A tooltip that matches the description I gave for this data validation condition. Well, what do you know? I spelt data instead of date (don’t worry I’ll fix it up later).

So, let’s try and defy time, then. I will enter October 24th as my return date. Doesn’t seem vary happy does it?

But if I change the date to the 25th of October (therefore validating the rule we set up), InfoPath happily accepts the value.

That it? That was easy!

Yeah, it was very easy so what are you complaining about? Easy is good and there should be more of it!

We now need to do the same thing for the “Return to Work” form field. Essentially, we perform the very same steps and thankfully for the both of us, I am not going to smother you with screenshots. This is where you try it yourself and instead I will simply list the steps and one screenshot.

1. Right click the ReturnDate field and choose Data Validation
2. Add a new validation condition where the ReturnDate is less than the CompletionDate
3. Add a tooltip text “Return date cannot be before the completion date”
4. Click OK twice and test using the preview button

The published experience

Now that we have successfully tested the validation rules for the date fields, let’s publish the form to SharePoint and see what it all looks like. I followed the exact publishing steps that I outlined in part 4, so please refer to that article if you need a recap.

I navigated to the forms library as described in part 4 and created a new form.

I then deliberately entered bad data into the form and sure enough, the data validation rules picked up on the issue. Excellent – Waylon Smithers is very pleased!

Reviewing our progress…

So, since we are about to see off part 6, our Project Manager wants to get a status update on how the Springfield leave form project is progressing. So, after 6 articles, what have we achieved? To remind you, the requirements were:

• 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 appropriate supervisor
• We have a central leave calendar to updateIdentification of Homer is now sorted, and we have taken steps both in the areas of reducing data entry and validating the dates (excluding days absent). So, we are tracking nicely and haven’t fallen behind schedule just yet .

  Before we continue with addressing all of these requirements, we will have to take a bit of a detour as I explain below.

  Too good to be true?

  Here’s a little experiment for you to try. On the above form, published in its current form with deliberately invalid dates (highlighted in red), you will see a toolbar that has a “Save”, “Save As”, “Close” and “Print View” on it. I clicked the Save As button and was dutifully prompted for a filename. I called the form “Homer’s Test Form” as shown below and clicked Save

  

  I then closed the form and checked out the form library on the http://radioactivenet site. What the…! It saved it! What’s the point of data validation if you can just save the form anyway?

  

  The answer to that question, my friends, is there is a difference between saving a form and submitting a form. But you will have to wait for part 7 of this series for that riveting discussion!

  Thanks for reading

  Paul Culmsee

[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.]

Welcome again students to part 5 of the CleverWorkArounds Institute Body of Knowledge (CIBOK). As you know, the highly prestigious industry certification, the CleverWorkarounds Certified Leave Form Developer (CCLFD) requires candidates to demonstrate proficiency in all aspects of vacation/leave forms. Parts 1-4 of this series covered the introductory material, and now we move into the more advanced topic areas.

Wondering what the hell I am talking about? Perhaps you’d better read part 4.

This post represents a change of tack. the first four articles were written from the point of view of demonstrating InfoPath in a pre-sales capacity. Your “business development managers”, which is a politically correct term for “steak-knife salesmen”, have promised the clients that InfoPath is so good that it can also make your coffee too. Essentially, anything to make the sale and earn their commission. Of course, they don’t have to stick around to actually implement it. They have moved off onto their next victim, and you are left to satisfy the lofty expectations.

Now, we switch into “implementation engineer” mode where a proof of concept trial has been agreed to. At this point we are dealing with three client stakeholders. Monty Burns (project sponsor), Waylon Smithers (process owner) and Homer Simpson (user reference group).

To remind you about parts one to four, we introduced the leave form requirements, and demonstrated how quick and easy it is to create a web based InfoPath form and publish it into SharePoint with no programming whatsoever. Was it a realistic demo? Of course not! But we have sold the client the dream and now we have to turn that dream into reality!

Here are the original requirements.

• 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 updateSo in this article, we will deal with the first requirement.

Automatic Identification of Homer

Now, some of the staff of the Springfield Nuclear Power aren’t the most computer literate. Technical support staff report that one employee in particular, Homer Simpson, is particularly bad. In between sleeping on the job and chronic body odour, he has been known to hunt in vain for the “any” key on the keyboard. So he was chosen to be the user acceptance test to ensure that the entire process is completely idiot-proof.

The way we will do this is to automatically fill in the full name of the current user, so Homer will not have to type his name in. It would just automagically appear as shown below.

So our process owner, Waylon Smithers, is excited and expectantly asks you, “This is easy to do, right”?

“Sure”, you answer confidently. “It’s built into InfoPath and I do it all the time”.

You then proceed into the properties of the above “Employee Name” textbox and locate the “Default Value” textbox. You then click the magical “fx” button that lets you pick from a bunch of built-in functions as shown below.

 

Now anybody who has used Excel will be used to the notion of using built-in functions to create dynamically created values. InfoPath provides similar cleverness. There are formulas for mathematical equations, string manipulation, date and time functions as well as a bunch of others.

While I won’t be discussing every built-in function in this article, I encourage you to check out what is available.

Now our intrepid consultant already knows what formula they want to use. The “Insert Function” button is clicked and from the list of functions available (conveniently categorised by type), we choose the function userName as shown below.

 

So we have now set the default value for the “Employee Name” field to be whatever the data the userName() function decides to give us. So let’s see what our favourite employee Homer Simpson now sees.

“Voila”, you think to yourself. “Homer, please test it.”

Homer: “Herrrrrr Simmmmmpson. Mmmmm. Who is hersimpson”?

Consultant: “Who”?

Homer: “Hersimpson. Is that… Lenny?”

Consultant: “…”

Homer: “Oh, wait! I know! I know! It’s that new sprinkled donut … mmmm donuts….”

Making it Homer Proof

So, it seems we have a problem at the user acceptance testing phase. Apart from drifting off into a donut induced daydream, it is clear that showing the username is not a good idea as Homer has not realised that his userid (hsimpson) represents himself. Clearly it would be more “Homer friendly” if his full name was displayed instead. At this point, we hit our first InfoPath challenge. How do we get the full name? We have no built in function called “fullName()”, so how can we do it?

Hmm, this is a little tougher than everything we have done so far. Perhaps we should get in some additional help from Professor Frink.

“Well it’s quite simple, really. We need to create a secondary data source to the SharePoint web service UserProfileService.asmx and call the GetuserprofileByName method, passing it a blank string parameter called AccountName, and then interrogate name value pairs in the response to grab the first and last name and concatenate them into a full name Mm-hai.”

Does anybody want the non-nerd (English) version of the above sentence?

Given that lots of interesting “stuff” lie buried in various applications, databases, files and other “systems”, the designers of InfoPath were well aware that they had to make InfoPath capable of accessing data in these systems. In doing so, electronic forms can reduce duplication, data entry and leverage already entered (and hopefully, sanitised and verified) data.

One of the many different methods of accessing “stuff” is via “web services”. The easiest way to think about web services is to think about Google. When you place a search on Google for say, “teenyboppers”, your browser is making a request to google servers to return “stuff” that relates to your input. In this case, people who actually like Brittany Spears’ songs.

Google is in effect providing a service to you and the protocol that drives the world wide web (HTTP) is the transport mechanism that both parties rely on.

So, a real-life web service is really just a more sophisticated version of this basic idea. One program can chat to another program by “talking” to its web services over HTTP. In this way, two systems can be on the other side of the world, yet be able to communicate with each-other and provide each-other with data and, well … services!

SharePoint is no exception, and happens to have a bunch of web services that allow programs to “talk” to it in many different ways. I am not going to list them all here, but it just so happens that one of those web services, gives us just what we need – the full details of the currently logged-in user. So we are going to get InfoPath to “call” this particular web service and return to us the data we need to make Homer happy.

Okay in theory but…

Now hopefully the basic idea of webservices now makes sense. Actually making the leap to using them does take some learning. Since this is all over HTTP, a web service is simply a website URL.

Real programmers – don’t start getting all anal with me about definitions here. This explanation is for people who speak human!

The URL of the SharePoint web service that we want is this:

http://<address of sharepoint site>/_vti_bin/UserProfileService.asmx

eg

http://radioactivenet/_vti_bin/UserProfileService.asmx

If you point your browser to this URL, you will get a response back, listing all of the various “methods” that this web service provides (click to enlarge). The screenshot below is not exhaustive, but the point is that one web service can actually provide many functions (generally known as methods) to perform all sorts of tasks.

Now, InfoPath likes to make things nice and wizard-based, and all of these above methods operate differently. Some take parameters (I.e. to create a new user account via web service you would have to supply details like name, password and the like). Some do not need parameters but return multiple values while some return a single value. Others still return different values based on parameters that you send to the method.

How can InfoPath possibly know in advance what it needs to send to/receive from our selected method? Fortunately the geeks thought of this and invented an extremely boring language called Web Services Definition Language (or WSDL for short). All you need to know about WSDL is that apart from being a fantastic cure for insomnia if you ever read it, it provides a way for applications, like InfoPath, to find out what it needs to do, to interact with a particular method.

So, using the above web service again, we will actually ask the web service to tell InfoPath all about itself using WSDL by slightly changing the URL as illustrated below

http://radioactivenet/_vti_bin/UserProfileService.asmx?WSDL

Now, if you try that in a browser you see all sorts of XML crap

But don’t worry, you will never have to actually look at it again – InfoPath digs it – and that’s all you need to know.

InfoPath Data Sources and Data Connections

Now, it is time to actually get InfoPath to talk to this “UserProfileService” web service as described above.

As I said, Web services is one several sources of data that InfoPath can access from. First up, we need to make a connection to a data source (imaginatively called Data Source connections).

From the tools menu, choose “Data Connections” and a dialog box asks you to some information about the sort of data connection that we want to use. We wish to receive Homer’s details from the web service, so we choose to receive data and choose “Web Service” as the source of our data.

We are next asked for the URL of the web service. We pass it the URL of http://radioactivenet/_vti_bin/UserProfileService.asmx?WSDL

Note: This really should be the exact sub-site where the InfoPath form was published to. So, if say, this form was to be published into a sub site called HR, then the URL would be http://radioactivenet/HR/_vti_bin/UserProfileService.asmx?WSDL.

Clicking NEXT and you are presented with the various methods that this web service provides. The method that we are going to use is “GetUserProfileByName”. We choose it and click “Next”.

At this point, we really start diving deep into talking to web services. InfoPath examines the details of this method by looking at the WSDL information. It determines that this particular method (GetUserProfileByName) expects a parameter to be passed to it called “AccountName”. We are prompted to supply a value for “AccountName”. Fortunately for us, if we do not supply a parameter here, then the web service will use the account name of the currently logged in user! This is exactly what we want. This method will automatically use the username of the current person without us having to manually specify it.

Thus, we can leave this screen as is and click NEXT. The final message asks if we wish to connect to the web service now to retrieve data, but in this case we do not.

 

We have now finished configuration. We are asked to save this connection and give it a name. (As you can see below the name defaults to the method name, so we will leave it unchanged. We also tick the box to connect to the data source as soon as the form is opened).

Using the data connection

We have an InfoPath data connection to this web service. Now what?

Well, let’s go back to our employee name text box and change the default value to something returned by the web service method GetUserProfileByName. As we did earlier, we click the function button, but this time we are not doing to add a function. We will instead use the “Insert Field or Group” button.

 

By default, InfoPath has a “main” Data source, which is the form itself. We now have to tell InfoPath that the default value for the employee name is going to come from a different data source. On the data source drop down, choose secondary data source called “GetUserProfileByName” from the drop down as shown below.

 

Notice that the fields available to choose for the GetUserProfileByName datasource looks very different to the main datasource. This is because the web service returns data in a particular format, and it is now up to us, to interrogate that format to get the information we want.

The GetUserProfileByName method returns a whole bunch of user profile values, way more than the stuff we specifically want. It returns these details in a name/value format as shown below:

Name	Value
FirstName	Homer
Lastname	Simpson
Office	Sector 7G
Title	Safety Inspector

… and another 42 more name/value pairs like the above!

So we will have to tell InfoPath to examine the full list of “Values”, and find the specific value for “FirstName”.

Note that firstname and lastname are separate items. There is no property called “FullName”. We will deal with this a little later.

Now although telling InfoPath to filter the user profile information is achieved using a wizard, it is not the most intuitive process. Once you have done it a few times, it becomes second nature. But be warned – you may be about to suffer death by screenshot…

Recall in the last screenshot we were looking at the data returned by the web service method called GetUserProfileByName. We need to filter the 46+ possible profile values to the specific one we need. Now you know what that “Filter Data…” button does

From the list of fields returned by this method, choose “Value” and click “Filter Data”.

We have now told InfoPath that we want one of the “value” fields, but we need to filter it to the specific value that we need. That value is “FirstName”. So in effect we are saying to InfoPath “give me the value for the property where the property called Name = “FirstName”. The sequence of screenshots below shows how I tell Infopath to use the Name field as the filter field.

 

Now we have to set name to equal the property name “FirstName”. The next two screenshots show this.

Click OK and you now have your formula as shown below.

Click a zillion other “OK” buttons and you will be back at your form in design mode. Clicking the “Preview” button and check the Employee name field. Wohoo! It says “Homer!”

But I said “full name” not “first name”…

So, that’s great. Although connecting to a web service and telling it to retrieve the correct data is tricky and requires some training, no custom programming code was written to do this. But alas, poor old Homer still get’s a little confused and we wish to see the full name of the person filling in the form.

Fortunately, this is actually quite easy. We just need to grab the FirstName and the LastName values from the web service and then join them together.

I demonstrate this below (with an adjusted formula – for the sake of article length I’ve not added the screenshots used to create this formula. I am hoping that I gave you enough to figure it out for yourself).

Application developers or Excel people will quickly see that I have retrieved the “LastName” value using the exact same method described in the last section for the “FirstName” value. I then used the built-in function concat (concatenate) to join FirstName and LastName together (with a space in between).

Let’s now preview the form… Wohoo!

So, just to be completely sure, we republish the form, following the steps in part 4 and examine the form in the browser to make sure that it works there as well.

Conclusion (and further notes)

So amazed at your ingenuity, you have managed to get InfoPath to retrieve the details it required so that the user did not have to fill in their name manually. There was certainly a lot more to it than using a built-in InfoPath function, and (for the first time anyway), probably took you a little while. But the main thing is, you have satisfied the first requirement and Waylon Smithers is now happy. He is a little bewildered in all the low-level web service stuff and concerned about how easy it would be for some of his staff to create forms, but regardless, everything was performed via the InfoPath graphical user interface.

So in the next post, we will look at two ways we can deal with the automatic retrieval of the employee number.

Thanks for reading

Paul Culmsee

P.S: Do not attempt to explain the low level details of pulling values from a web service in a presales demo .

[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 again. Welcome to part 4 of my tribute to the “leave form”. It’s probably time to just get straight into the article, as I think the whole leave form joke isn’t overly funny anymore

Crap, there is probably going to be a dozen or so articles and I’m running out of jokes already? But then I suddenly remembered that in this certification obsessed IT world we live in, I could make up my very own certification! I mean how hard can it be? Just add the word “institute” to your name and your legitimate right?

Therefore I am pleased to unveil the first of a series of certifications to be offered by the CleverWorkarounds Institute and its associated body of knowledge (CIBOK). The CCLFD or CleverWorkarounds Certified Leave Form Developer certification, which allows certified practitioners the opportunity to feel vastly superior to the mere mortals they work with. Additionally, it has waaaay more bragging rights than one of those weenie certifications like MSCE or CISSP. Of course, like all acronyms to add to your business card, you are certainly guaranteed a big, fat pay rise.

So what someone wants to validate your credentials, you just flash the badge below and they will all be like…”wow, this dude is a business process god!”

SharePoint Pre-Requisites

Right enough banter and back to business! Now remember, we are in “Business Development Manager” mode in this post and therefore we are trying to impress here. Selling the client the message that the you will solve all organisational process issues (and find the answer to world peace) in InfoPath and Forms Services. So far, we have fairly quickly produced a usable InfoPath form. All in all it has taken maybe 10-15 minutes of demo time. So in the interests of “impress the client at all costs”, we have done enough to publish it straight into SharePoint, so that it is usable via a web browser.

That CCLFD certification is looking good yes?

So first up, we need a SharePoint site to publish the site to. But not just *any* SharePoint server. It needs to be running the enterprise licence if you wish to use InfoPath Forms Services.  So sorry stingy people, WSS and Office SharePoint Server 2007 Standard Edition will not suffice.

Now if this were a demo, I would have already had this set-up in advance to make the client “ohhh”, “aaah”, “wooow” louder. But I think it is worth examining the prerequisites in more detail.

Assuming that the SharePoint farm been built and a web application has been created (called http://radioactivenet), it is time to create a brand new site collection to host this form. The SharePoint farm administrator performs this task in Central Administration -> Application Management. In this example, we are creating a completely blank SharePoint site.

Have we done enough to publish our form to SharePoint? Unfortunately, not quite. In fact if we tried to publish our leave form into the site as it is now, we would have a little warning message that easy to overlook and then cause you no end of wasted time.

But I am getting ahead of myself. Having created this new site collection above, we now need to enable the enterprise feature-set that includes the forms services component that we need. For the purposes of this post, I will not be explaining the SharePoint feature framework, but for the uninitiated, SharePoint is like a fisher-price toy with lots of buttons that have different effects when pushed. (We haven’t yet pushed the right button). Think about SharePoint site templates (e.g Document Workspace, Wiki Site) as automatically pressing the buttons for you.

To activate the enterprise featureset, we log into http://radioactivenet as an administrator or site collection administrator. Choose the “Site Actions” drop down menu below the search box. Choose “Site Settings” and you will be taken to the administrative back-end of a SharePoint site collection. I have highlighted the option to control site collection features. (Click to zoom)

 

This screen shows you all of the nice buttons to push. The one that we need for this demonstration is the “Office SharePoint Server Enterprise Site Collection Features”. Simply the click “Activate” and you are done!

Finally, let’s publish it already!

To remind you all of where we got to at part 3, we have a functional form looking like this. (Click to expand)

Publishing an InfoPath form into SharePoint is based on a Wizard. We want to impress here, so we will do a straightforward form publication. Start the wizard by choosing “Publish” from the “File menu”. The first wizard screen will ask you *where* you wish to publish to. Obviously we go with the default answer of SharePoint

 

Next we are asked to specify which SharePoint site we would like to deploy this new form to. We are using our newly created http://radioactivenet site.

Now we hit the first important step in the whole process. This is the step where InfoPath publishing wizard asks you to how to publish this form. While I am not going to explain each option in detail at this stage, I will warn you now that we are going to come back to this screen in subsequent posts.

Notice how “Enable this form to be filled out by using a browser” is checked? This is because this InfoPath form that we created has been set to be “browser compatible” way back in part 2 when we first created the form template.

The first and default choice is to create the form in a SharePoint Document Library. Thus in the SharePoint world, InfoPath forms are just another type of library storage. therefore you can can use version history, recycle bin and all of the other goodies that come with SharePoint document libraries. Now I should make it clear though, that SharePoint creates a special type of library called a “Form Library”, designed specifically for InfoPath forms. So we leave “Document Library” chosen as the default and click continue on.

Having chosen to use a document library we are now asked to create a new one or choose an existing library. In our case, we have not yet created the library to hold the leave form, so we choose to “Create a new document library” and then enter it’s name and description into the follow-up dialog box. This will create a form library called “Leave Forms” for us as part of the publishing process.

 

The next step is another important one. But in the interests of our “impress the client at all costs” focus, we are going to leave it until the next post. So we click Next to continue.

That’s it for the publishing process! Clicking the Publish button will commence the process. InfoPath will create the form library and when it finished provide us with a summary of what has been performed as shown below. You can see the name of the library where the form was published (”Leave Forms”), the URL of the SharePoint site (http://radioactivenet/leave forms) and the fast that Infopath Forms services is running on the server.

The new form library

So, are we ready to “wow” the client yet? Almost!

Looking at the http://radioactivenet site, we can now see that we have a new content item in the navigation. Well what do you know? It’s a leave form library!!

If you navigate to this document library, you will see that it pretty much looks like any other SharePoint document library. Clicking the New drop down in the document library though shows that something is subtly different with this library. The document type to create has the InfoPath symbol on it. This library knows that it is here to store InfoPath forms.

But there is one minor catch. By default, SharePoint assumes that if you have InfoPath installed on your PC, then you will always prefer to use InfoPath in preference to a more limited, somewhat “clunkier” web based version. In our case, we want the form to show up in a browser, irrespective or whether InfoPath is installed on you PC. So let’s do that now.

In the new Leave Forms library, we choose “Form Library Settings” from the “Settings” drop down menu as shown below.

Now remember how I said that a forms library is a document library geared especially to host InfoPath forms? Well, now you get to see why. One of the configuration options unique to a forms library is whether to display a form in a browser or using InfoPath. The option controlling this can be found in “Advanced Settings” as highlighted below. The third option under advanced settings controls the behaviour for “browser enabled” documents. Note that the default option is to “Open in the client application”.

 

So let’s change this to “Display as a web page” and click OK. Also note the second option, “Document Template”. We will be talking about this a subsequent post as well.

The big test!

So, all is now in place and it is time to demonstrate the functionality to your eager and excited clients. Go back to the home page of http://radioactivenet and choose “Leave Forms” from the navigation bar. In the document library view, choose “New Document” from the “New” drop down.

Wohoo! The form renders in the browser! (and the crowd goes wild! )

Conclusion

So there you go, in something like 20-25 minutes, you have created and published a web based form that started life as a MSWord template. Highlighting how long this world have taken to be custom developed, your client is already writing a cheque and wants you to do this with all of their internal forms right???

Whatsmore, we haven’t even gotten to the unbridled joy that is a workflow yet! Oh man if the client likes forms services, they aint seen nothin’ yet right???

Well, to be honest, this form really isn’t that smart yet is it? Before we even get to workflow considerations, the form still isn’t *that* friendly and we haven’t yet satisfied several of the requirements outlined in part 1. Remember that we had to provide:

• 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

So in the next post, we will make this form a little smarter and see if it is still within the realms of mere mortals (non developers) to do.

Thanks for reading

Paul