Collaboration or Contract: A Decision of Flow

Mint tea

Ask anyone who’s been involved in any significant implementation and they’ll have come across the waterfall approach. It typically leads to a contractual relationship between one team who are working on artefacts that are then handed over to a subsequent team. While the flaws of waterfall have been well-documented, this concept of contract versus collaboration extends to many areas of work.

Example

Coffee Shop
Coffee Shop

Let’s use a brief story as an analogy for the concepts of contract and collaboration. It’s an incredibly simple story, but even with the simplicity, we can see the complications that can arise from a contractual relationship.

My wife and I walked into a coffee shop. I was left to order the drinks at the counter. So I’d asked what drink did she want.

“Mint tea please”

She orders a lot more hot drinks than I do, so she’s more familiar with the script that we all follow in coffee shops. And she definitely knows I do not order as many drinks, so she’s aware that I’m not that familiar with the standard scripts. In fact, I order hot drinks (maybe once a year) so rarely that it’s almost a new experience every time.

So I’m at the till and I’ve asked for mint tea. I hear in the barista’s response that it’s blended mint tea. So I’m then thinking:

  1. Is blended mint tea acceptable?
  2. Are there are other teas in this coffee shop which are more acceptable?

I decide it’s acceptable.

I’m then asked what size. How would I know? I was just told mint tea. And I know for a fact that my wife chooses different size drinks, but mostly takes the larger options in general.

So I ask for big.

Not good enough, it’s one of those shops. They have small, large and grande (or some phrase like that). So which is it; big = large or big = grande?

And what happened to medium? (but that’s another story)

I choose large.

Then I’m asked take away or stay in. Thought I’d already asked for the tea to go, but no worries, it’s a busy shop with background noise, so I say to take away because I know the context.

I’m then asked if I want one teabag or two. Woah, where did that one come from? It’s a cup of tea, a bag goes in in order to flavour the hot water. The longer you leave the bag in, the stronger the tea. Mint tea works the same way, doesn’t it? So what would be the advantage of two? Rather than ask what that benefit would be, I chose one since I hadn’t seen many cups with two bags before.

Seeing the way the interaction was heading, I waited for the “do you want extra water with that?” question. Fortunately that didn’t come.

On being given the takeaway cup, I notice it’s hot to touch, but it doesn’t take a genius to realise that. So I look for the holders and place one around the cup.

Analysis

The wrong tea
The wrong tea

That coffee-shop interaction was a contractual one. It depicted a scenario where one person (my wife) stated her requirements, which were then interpreted and delivered by another person (me).

Although it’s a very simple scenario, it highlights how much needs to be known to be able to be fulfil the customer’s expectations.

There were numerous attributes that had to be chosen in order to complete the transaction and deliver the request:

  1. Feature/Product = Mint Tea
  2. Variety = Blended Mint Tea
  3. Size = Large
  4. Number of teabags = One
  5. In or out = Takeaway
  6. Temperature to hold = Need a holder

My wife only stated one of those. I, as the contracted partner, had to answer a variety of questions based on knowledge, size based on estimate, number of teabags based on memory, takeaway based on context and joint understanding, holder based on real-world experience.

That ratio isn’t uncommon with any set of requirements. No matter how well or how detailed you define your requirements, there will always be questions that need to be answered. If you’re not there to answer the questions, then it introduces a delay or it introduces a risk of diverging from your (unstated) requirements.

Collaborate

2 computers at one desk
2 computers at one desk

Now, imagine the same scene, but with my wife also involved. The barista would be able to ask her directly, or at worst, ask me to then ask her (e.g. if she’s had to sit at the table rather than stand at the counter). While the latter scenario introduces some back and forth, it’s still more timely and risk-reducing than me guessing and getting the order wrong.

That’s the situation that occurs in many organisations. An artefact is commissioned. It’s defined and passed onto another group. Who digest the documentation and then ask questions. And it takes time to progress through this rigmarole.

While I don’t think the people involved must be present in the same room all the time, they do have to be able to communicate in a way that doesn’t lead towards a waterfall approach.

So the default position could then become one of collaboration rather than contract, with those involved working together to define and review. Now while that concept is well-adopted in more agile organisations, those organisations that have remote development teams can struggle with some of the implementations.

However, it’s not just IT development. The concept of collaboration should be present for any change, any time that an organisation progresses, especially within the organisation itself. And that’s where a number of organisations fail.

 

Fundamentals of Process Mapping

I’ve written before about the elements involved in a process map. In this series of articles, I want to start at the basics and explain what a process map should contain. I’ve seen a fair few methodologies come and go. Fortunately, methodology seems to be settling down with a few interesting branches appearing. I’ve also seen and used a lot of different process mapping tools at different levels, some more like CASE tools, some more like business process management tools, some just diagramming tools.

The aims of this series
I want to work with better-written process descriptions. I want to pass on best-practice as I’ve seen it after working with a lot of process and business analysts. I’ll discuss why following the methodology is not enough on its own, nor is just creating process maps on their own.

I am not writing against any software lifecycle methodologies, any project frameworks nor am I saying one tool is better than another (although I may touch on that). What I will provide are tips for improving the process analyses that you create regardless of which tool, methodology or framework.

Why am I writing this series?
As part of my BPR activities, I’ve received a lot of process descriptions that are not detailed enough, not internally consistent, not wide enough in scope, have gaps in them…in short, not good enough. It doesn’t matter to me who did the analysis, what counts is that someone (maybe the same person) is going to have to do more work to get it up to scratch.

If the work isn’t improved, then it causes problems further down the line. Some examples of the problems caused:

  • increase in customer complaints because agents can’t handle their questions
  • having to hire in more people as process gaps are identified
  • having longer queuing times because the the time taken to complete the process was underestimated, based on too simple a view of the process.
  • delay to process implementation while the correct level of detail is captured
  • stakeholder conflict as the invalid process maps highlight distrust between the operational teams and the process improvement teams

I’d prefer it if the process descriptions were defined properly in the first place. So please, distribute this.

Issues with Process Mapping

I’ve been using process mapping for over a decade now. I’ve probably been the recipient of more process maps than I’ve created, as I’ve had to implement changes that have already been designed by others. I’ve also had to talk many business users through the intricacies of their redesigned processes, especially if they (wrongly) hadn’t been designed by them. The most common scenario for me is where I’m asked to review process maps and assess how easily they could be implemented, bringing together knowledge of people, processes and IT/ICT.

Over that time, I’ve seen many sides for and against process mapping. I’ll discuss some of the issues and some of the methods for mitigating the risks associated with mapping processes.

1. Takes too much time

Mapping a process takes a long time. If that’s the only method that’s being used, then it will take longer than you expect. The only exception is that if you’ve been through similar exercises before, then you should already have some idea of how long it can take. To get a high level map is easy, to get to sufficient detail that a reader can understand the process takes a lot more time. This is time is extended if there is interaction with IT systems and different locations.

2. No standards

Some people map processes for a living. Worth bearing that in mind if you’re new to it. You can generally tell how much relevant experience a person has by looking at their output and any comments they attach to it. Have they picked a standard notation? Do all the decision points have two or more outputs? Are decisions labelled differently to process steps? And so on. Whatever the standard, a process map should be internally consistent. If a decision is a shaped as a diamond in one part of a map, then all decisions should be diamonds.

3. Conflicting standards

Assuming that the process-map author used a standard, it often doesn’t conform to the standard that the rest of the team are meant to be working with. The level of rigour required – as driven by an evaluation of potential risk – determines how closely diagrams have to conform to the standard. Some deviation is often permissible, and may even introduce new ideas, just bear in mind that a process map is a communication tool. The more standards people have to learn, the less concise and the less effective the tool becomes in communicating.

4. Not enough detail

The most common issue I see is that I receive just a process map. There has to be more information. The process map is a diagram of the process, but it isn’t the process itself, nor is it a complete description of the process. It is one tool for communication, there are others and analysts should some of these should be used. For instance, there should be a process description supporting the process map. This would provide the detail of each process step, providing elements that couldn’t be included in the diagram. Remember that a process map is a diagram and you’ll often need words to describe the process more completely. Words or pictures alone are often not sufficient, the combination of the two together work really well.

5. Too much detail

Better too much detail than too little. I’m always curious if there’s such a thing as too much detail in process maps since the aim is to capture everything so that it can be understood, replicated, changed and/or implemented.

My current answer to this is “yes”. Once you’re into the realm of mapping something that’s rarely done, has very little associated risk and you know you’re going to change it, then you don’t need much detail.

You also don’t need much detail if you’re just trying to scope out the activities of an organisation.

Another indication of too much detail is when an analyst has focussed on one area more than another such that most maps are high level and one is too detailed in comparison. So unless there’s reason to concentrate on that one area such as you know you’re going to be doing that in the following stage, I’d start to think that there’s too much relative detail.

6. Users don’t understand them

Process maps should be easy for users to understand. If they’re not, then question the standard; are you using the most appropriate standard? For instance, I noticed that early versions of UML Activity Diagrams confused users due to the diagonal lines making the sequence of events unclear. Many of those Activity Diagrams still included horizontal and vertical lines, but the standard permitted diagonals. Compare that to later versions of the Activity Diagrams. Now, I’ve no idea if it’s the standard or just best practice that means that most lines are horizontal or vertical, but either way, I’ve seen a change towards that practice.

It is also worth taking a key or legend with you or at least explaining it in person. Mention what a process step is, what a terminator is, what a gateway is and how to read them. Especially talk through the difference between parallel and sequential processes.

7. Users aren’t involved with them

This is stake-holder management. By and large, people resist change. Not involving users in the process mapping exercise increases the risk of resistance and increases inaccuracy. The fewer users, the greater the risk. Fortunately, it’s rarer nowadays to see the creation of process maps not involving any users. But take it a step further, instead of a review process, move some of the ownership or responsibility onto the users. That doesn’t mean that they should be responsible for creating the maps, but that they should be happy with their content and happy that they represent what they do.

8. Don’t have the tools

You can’t do process maps well in MS Powerpoint. You can get so far and do a very high-level sketch, but you can capture detail that way. Trying to results in a mess, a divergence from standards and a confused user.

At worst, use MS Visio. This should be the lowest level of IT tool you should use. Better still, find a purpose-built tool. Make sure you can export into a format that your audience can open and read. Test the export and read process a few times. Visio used to be a bit unpredictable in its export output, but that seems to have settled down a lot. All depends what version you’re using and what the diagram includes.

If you’re a bit old-school and use post-its on brown-paper. Tape the post-its down once the process is agreed.

9. Use PowerPoint

In contradiction to the previous point, PowerPoint has a very useful feature in that its main deficiency as a drawing tool can be thought of as an advantage; i.e. it constrains the complexity of the diagram. I use it to show value chains and simple process maps. The diagrams usually have 6-10 steps and little branching. For this brief, overview type of process map, PowerPoint is ideal.

Use Case Diagrams for Documenting Scope

Use Cases

I embraced UML as a communication tool some years ago and have found it successful in being able to convey messages in a simple manner. I don’t use every type of diagram – some are too strange for the average business user. I do use Use Case diagrams. These are great and, with a small amount of education, are suitable for use with business users.

Use Case Diagrams for Scope

As a communication tool, Use Case diagrams are great at showing who does what at a very high level. They’re good at showing system solution scope, types of actors and ownership of integration points. In one diagram, I can show the scope of the system in a way that users will understand. Now that’s a powerful tool.

Depth of the Scoping Use Case

Ideally I like to have short Use Cases, perhaps 2 or 3 sentences at the highest level. Used like this, they don’t conform to the more common view of Use Cases, but they do give a good, brief overview of what happens in the solution. More detail is required in later stages, but you can’t beat a concise description to get the ball rolling.

Why use Use Case Diagrams for Change Management?

There’s a system involved. By system, I don’t necessarily mean an IT software application. There are people, teams, dependencies on other organisations, dependency on phone network being available and so on. Often the people in the change team, including the users themselves are not aware of all the interactions that they have with these external organisations (including teams in the same organisation). This is where a simple Use Case comes in. It can show, at a single glance, the main interactions between the team in question and their environment. I use them to gain a joint understanding of what the team does now, or what they’re trying to change to.

Multi-level Use Cases

Originally the concept was that a system had 10-20 Use Cases. If you had vastly more than that, then you were doing it wrong, it you had less than 5, you probably weren’t analysing far enough. Time’s moved on and real-world, practical experience has been added to this. What analysts and software methodologists/project methodologists came to realise was that the power of Use Cases was that they were readable and understandable by users but that to capture sufficient detail, they were becoming unwieldy and cumbersome. Alistair Cockburn has been influential in his work promoting Use Cases at different levels, some will be user and high-level, some more detailed. It does raise the risk of implementing a more traditional waterfall approach where one analysis has to follow on from another.

Use Case Diagrams for Developers

I know that there’s a strong argument for not using Use Case diagrams at all. This comes from developers and I can understand their perspective. That’s fine by me, I expect developers to know what works for them better than I do. In their case, the text of Use Cases counts for more. That doesn’t prevent analysts from using the tool.