Our Blog

where we write about the things we love



The beauty of workshops

Workshops are my favourite part of the job. Yep I am serious, this is when I have the most fun. However, sometimes it can feel like I am the only one, at least at the first workshop or even before that when we try to explain to our client that we need them. This is perfectly understandable.

More often than not, our client would have just completed multiple sets of workshops to create an RFP, followed by more workshops to evaluate and rate all responses and then select the winner. As a consultant I have learned to expect that by the time I get to meet the client they are already completely workshopped out. More often than not, they are keen to get back to their day jobs which have been neglected for quite some time so they can start chipping away at that impressive mountain of a backlog they have gained as a “Thanks Mate” for all the hard work they put in to the procurement phase.

So, when Intergen ask for an analysis phase, it comes to no surprise that the usual reaction is one of despair – surely we have told you everything you could possibly want to know in our RFP? What else do you need to know?

I know how that feels, I have been there, hence my well-used mouse mat. 

Here is my attempt to explain why workshops are still needed… are essential even.

What’s the question?

Requirements, whether in an RFP or in a requirements document, are not always core requirements. They are rather a way to meet the core requirement, a solution. For example, a requirement can be that the solution has to force users to search for clients before they are allowed to create a new client record. In my opinion this kind of requirement warrants a discussion. Typically, I would use the “Five Whys” tool where I get to act somewhat immature and ask “Why” up to five times until I get to that all important root requirement. And admittedly I have a lot of fun digging for these root requirements as this is a very rewarding exercise.

Q. Why does the solution have to enforce the client search?
A. Because the users have to make sure the client does not exist before they create the client record.

Q. Why do they have to check that the client does not exist before creating a new record?
A. Because we cannot allow duplicate client records.

Q. Why can we not allow duplicate client records?
A. Because then we would not have a full 360-degree view on the customer, it would be fragmented.

In the above example, asking “Why” three times already brings us to the root requirement: The solution should provide a 360-degree view on the customer and therefore not allow duplicate client records. So, why is that so important to understand? 

Our solution experts are the best at finding the right answer to the right question, or maybe more accurately: finding the right solution to the right problem.

Again In the above example, instead of the enforced search, they could suggest deduplication rules which highlight the possible duplicate and allow the user to use the original client record instead of creating a new one. Using workshops to understand and agree the core requirements will allow our solution experts to come up with the best possible designs.

Without the workshops and simply using the stated requirement, the developer would have coded something to enforce users to search, resulting in a more complicated and expensive process than the deduplication rules which, in the case of MS Dynamics CRM actually comes out of the box… for free. That is bang for buck and that I like!

Working together to understand the problem we are trying to solve and come up with the best solution is an exciting process. If it is done well it will result in a happy client and a happy solution expert, both proud of the perfect solution to the right problem, which in turn provides the desired business value.

User interface design elements is another example of something that is commonly included in requirements, such as cancel buttons, tabs or calendar controls. I prefer to translate these into requirements that state what these elements are supposed to do and why.

This creates an opportunity to leverage one of our user experience experts to design an intuitive, effective and fit for purpose user interface, as well as check with the developer to confirm what is technically possible and doesn’t cost an arm and a leg. During this part of the process everyone’s creative juices are thoroughly flowing and the result is a better user experience than using the initial requirement.

To be able to identify and understand the core requirements we will need to understand the client’s business which brings me to my next point.

Face to face communication is the very best kind of communication

Understanding the client’s business and how the solution needs to support this business is valuable context when making design decisions. For example, are the users technology savvy people who would prefer a solution rich in functionality, or do they need the solution to be simple, intuitive and effective?

One of the main reasons I love workshops is that this is the time when clients are most willing to answer my avalanche of questions about their business and invariably there is so much more to it than anybody could possibly ever realise. Typically, RFP documents, or any other document for that matter, only provide a mile-high sneak peek on the client’s business and its challenges. To gain a thorough understanding simply requires a conversation, preferably with a whiteboard at hand. 

It is quite terrifying to walk into the first workshop, having no clue what is coming. The steep learning curve during the workshops is both exhausting and exciting at the same time. The moment when the client tells you that you get it is really satisfying for a consultant like me as that confirms that we can come up with the right solution, the one that will make all the difference.

As a bonus, during these workshops the consultant will learn to align their language to the client’s. For example, a few weeks back I learnt that calling a non-functional requirement an NFR in a health organisation is a bad idea as NFR in that environment means Not For Resuscitation… The term bug also has very different meanings in IT as opposed to the food or health sector. It’s a wonderful source of comedy to discover these things during workshops, again making them much more fun than clients initially realise. A shared language is important for a shared understanding of the requirements.

Having a conversation around requirements is a lot more informative, efficient and fun than reading and re-reading documents, followed by email conversations. 

When it comes to understanding written requirements, conversations allow any ambiguity to be discovered and removed and it allows confirmation of a mutual understanding of the requirements including all nuances. Conversations include body language which, when added to the mix, provides even more context, such as which requirements are on everybody’s minds, maybe because they represent a current big pain point or maybe because not everybody agrees on the requirement or it’s priority. 

A nice Segway to my next and final point.

An RFP is a snapshot of a wish list

Typically, RFPs include future requirements in addition to requirements that need to be met on Day One.  This ensures that the chosen solution is future proof. So when the RFP states that the requirement is a “Must Have”, what does that mean? Does it mean that the solution cannot go live when this requirement is not met, or does it mean that the solution must have this capability so that in the future this can be leveraged? Or does it mean that a key stakeholder felt at the time of writing the requirement that this is a very important requirement? 

It is crucial to understand which requirements are the show-stoppers, as that is what we should be delivering as a first cut in order to get an early start on the RoI.

That allows us to continue extending the solution to meet the next set of requirements while reaping some of the business benefits already. 

In addition to the challenge of understanding the priorities, there is that challenge of understanding the likelihood of the requirement changing during the project.

The origin of the requirement can be a good indicator of how stable this requirement is. Say the requirement is offered by a stakeholder who since has moved on and is no longer involved in the project, it may just disappear. If the requirement originates from the corporate strategy, then it may be around for the lifetime of that strategy. And then there are requirements that will be around for the lifetime of the client’s business as they are part of the fabric of their business.

For example, where would a manufacturer be if they did not have the ability to pay their suppliers or receive payments from their customers? Those are the only requirements that do not need to be reconfirmed on a regular basis. For all other requirements, understanding the origin allows us to pre-empt when the requirement needs to be reconfirmed due to changes in the organisation. If we hear that the client has a shiny new strategy, then we will know that all requirements originating from the previous strategy will need to be reconfirmed and aligned to the new strategy.  

Since change is the only constant it is prudent to check that all documented requirements are still up to date and stable for the duration of the project.

And what better way to do that than in an effective, efficient and fun workshop. I realise that using the words fun and workshop in the same sentence is probably raising some eyebrows. I could explain how workshops don’t need to be a sit-around-a-table-and-talk-lots-achieve-little type event… But that’s another blog.

Posted by: Ingrid Nabben, Senior Consultant, Modern Applications | 29 August 2016

Tags: Project Management, Workshops

Related blog posts

Blog archive

Stay up to date with all insights from the Intergen blog