<a title="Click Fraud Protection" href="http://clickguardian.co.uk"><img src="http://protection.clickguardian.co.uk/nojs.php?d=helastel.com&amp;k=N15i7ILUrfW3k" alt="Google Click Fraud">

Tales from the discovery workshop

Iouri Prokhorov
Blog Banners H Discovery.jpg

When you know you need a software project to kick-start a transformation in your business, the next step is to sit down with your chosen software development company for a first meeting to sort out what’s what.

This blog is all about taking a peek through the keyhole to see what goes on, how people interact and why it’s such an important springboard into the project proper. I asked around the office for input, which you can see highlighted in quote marks.

To be productive, these meetings have to have a solid structure and purpose to set everyone off on the right foot. It’s a process of discovery. And because time is money, we need to discover a lot as quickly and efficiently as possible.

“When we host a discovery workshop, we like our clients to let us know in advance what type of company they are and what format their existing meetings generally take. Basically, if you have a particular way of operating then we'd like to know about them. This provides clues as to how our clients think, for example being more visual or design-led in how the client receives information.” - Julian

Having said all that - we could maybe come up with a better name than Discovery Workshop.

Sitting on the other side of the meeting room table from the likes of us are business managers and owners who don’t typically ‘do’ software projects very often, if ever before. That can occasionally make some of them quite circumspect and ever so slightly defensive in the first meeting or ‘Discovery Workshop’. Even the term ‘Discovery Workshop’ can be a bit off-putting if you’re minded to keep your guard up. But if it sounds a tad wishy-washy to you, that actually could be a barrier to properly engaging with the process. Call the meeting whatever you want - it doesn’t matter. The big tip here is for everyone involved to check all their preconceptions and fears in at the door before we get underway.

“I remember one woman was visibly uncomfortable at the start of the meeting and took an hour or so to relax and participate fully. She told us later that she didn’t expect to be able to communicate with very technical software people like us (!!) and was just het up about saying things that would make her look stupid.” - Alex

The typical client participants in a Discovery Workshop would be:

  • The main people affected by the proposed changes who want to ensure the transformation is effective (Business Managers)
  • The people currently undertaking the business processes who have valuable insight to share (Users)
  • The people who need to understand the value of the project and how the business can get a tangible return on investment (Budget holders)

The biggest regret we hear is when people wish they’d prepared a bit better to talk in detail about their business.

Hold the front page: Software company in ‘talking more about the actual business than software stuff in first meeting with client’ shocker!”

The fact is that code and methodologies and sprints and versioning and all that other software jargon you might hear about is mostly irrelevant to establishing the need of a given business and melding that into a ready-to-go project. With respect, you are not the software expert. On the contrary, you are the oracle of knowledge about your business, how it operates, what you need to change, where you see it evolving towards. You need to own the vision of where you want this project to take your business. This is really important. Software development companies like Helastel can provide solutions, but we can't drive that passion and physically manifest it within your business. You have to take ownership for this.

Most of an initial discovery meeting will be taken up answering questions about your business, right from the high-level business plan down to individual processes. You might wonder what on earth your projected turnover in 2018/19 has got to do with a fairly narrow software project. The answer lies in the complete and universal understanding of your business that the software developer needs in order to work out the best way to deliver real, lasting change. We look through the cupboards; we pull up all the carpets. It’s not merely a case of bits and bytes.

“Good software can't be built without understanding business processes, and the initial meeting is a good opportunity to get to grips with these. Don’t worry too much about what restrictions are in place with current software solutions - a better objective is to find out what an ideal scenario would be; if we could make this the perfect system, what would it look like?   This is the creative bit - finding new solutions to legacy ways of working. But the client has to tell us where the pain is, or we can’t get the full picture and propose potential ways forward.” - Craig

Bringing users along can get you to the project startline faster

A strange feeling can sometimes descend upon a discovery workshop when one of the following becomes apparent:

  • The business hasn’t quite got a handle on the people or types of people who will be using the software when it’s complete
  • Nobody present has any direct experience of carrying out the existing processes that the new software is intended to improve

This feeling among the meeting group leads to the realisation that the people this software project is going to most intimately engage aren’t being adequately represented.

Users are usually either internal (employees encouraged to use the new software to undertake processes more productively/efficiently) or external (existing or potential new customers that you use software to sell to, or deliver a service).

It typically doesn’t occur to the business commissioning a project that users are - to put it bluntly - important enough to involve. For external users, there are understandable constraints. But for internal users, there is occasionally a presumption that managers who won’t end up using the software have a more valuable perspective that subordinates who will. If you think about it, that’s really rather crazy.

I’m not saying you actually need to bring users along to a discovery workshop, but it certainly wouldn’t hurt if you did. Sooner or later - maybe not at that initial meeting - they will be consulted extensively.

“Getting your hooks into a real user at the first meeting is really cool. There is always an interesting conversation between user and manager, as they begin to understand where the current shortfalls are. They’ve worked together every day for years, they travelled to the meeting in the same car - and yet they are learning loads from each other and how that affects their business. It all benefits the scope of the project, but they get more out of it than just that.” - Roopal

Software people like to think of themselves as a mixture of creative artisans and sleeves-rolled-up engineers, so I guess it follows that we’ve adopted the ‘workshop’ term to describe our 4-5 hour meeting room sessions, with added biscuits and a whiteboard.

Workshops used to be untidy, industrial places with springs and spanners lying about, populated with oil-stained old geezers in overalls. Today, they are still places where ideas are fashioned into actual stuff.

Creating software to make a real business transformation takes the right tools, and the skills to use them. But just as important is the raw material that goes into the finished product. We can’t get to grips with those unique qualities and characteristics without that first meeting.

Download your free ebook – The Business Guide to Preparing a Brief for  Software Development   With essential tips on how to prepare your RFP or briefing documentation, this  guide takes you through the research process all the way through to running  your software selection process. DOWNLOAD YOUR EBOOK NOW

Topics: Agile, Scoping, Project Management

Why not try these ones next?