13 min read

Project workshops

A turning point for my agency was when we introduced a project workshop for all new projects. But before I get into that, let me tell you about the good old days...

In the early years I would do anything to impress a potential new client, I was very confident that technically we could hit their project out of the park - we just had to first navigate through this awkward sales dance first.

Back then I think my dance was pretty stock standard for a developer turned agency owner, I'd woo the client with examples of fantastic work we had done before, I would enlighten them to how cutting edge we were with our technology stack - and I'd ask lots of questions about the problems they needed help with.

Hopefully they had some type of written specification (or written anything!) that I could then reference when putting together a time and cost estimate for them (I mean let's be honest, that's why they were here), and then I would send it off to them along with a proposal basically saying "I love you, we can be fantastic together, please choose me".

I wasted a lot of time approaching sales like that.

It was a very small window of time, and ultimately I think we came off looking like one of a hundred agencies in my city... and I think it just gave the client 2 real data points to make a decision.

Did they get a good vibe from me
Was the cost estimate right for them

Whilst a lot of sales is based solely on those 2 points, I knew that wasn't the business I wanted to build. It was the sales I wanted to be doing, and if I was a client, I knew I wouldn't have been blown away.

But then a friend mentioned how they run a project workshop at their agency, and right away I knew that was the piece I had been missing.

A structured workshop that would not only give more time to dance the sales dance, but also allow us to get a lot more in depth with the client, and in turn provide more value. While other agencies would be throwing proposals and large project estimates at them - I would be honest, and say "Software is complex, and business is complex. For the best chance of success for your project I recommend that together we have a day-long workshop where we can really get to the crux of the problem, work together to identify the best technical solution to solve this, and provide us with deep knowledge in order to then provide an accurate estimate."

And as previously mention, this was a turning point. A very positive turning point, as we increased our lead conversion by around 10% (which is freaking huge).

So what's a project workshop? 🤔

It's not new, it's not ground-breaking, and I certainly didn't invent it. Others call it a project inception workshop, a roadmapping workshop, my agency called it a Kickoff workshop. The name doesn't matter, its purpose matters.

A project workshop is a session where you guide your potential client through a series of conversations around:

Understanding their individual and/or business history (the context)
Understanding their problem or the software they are looking to build
Discussing alternatives, showing that perhaps custom software is not always the answer (and that you are not just trying to weasel money out of them)
Working with them to articulate the requirements in language that is clearly understood by both them and you (or any other technical partner that wins this gig, no vendor lock in here)
Educating them on building software and what's involved (trade-offs, how you work)

It's structured, there is an agenda, you keep time, and you document everything. They walk out feeling more clear headed and excited about their project than when they walked in, and you have had time, a long time, to show your expertise.

What do they get out of it? ⚖️

Business problems are complex, software is complex, relationships are complex. Your potential client is looking for an expert. No matter how confident they appear, they want someone who makes them feel safe in this big decision, someone they can trust, and someone that really understands their problems - and can prove they can solve them.

That's what they really get out of it - but what they really want out of it is an accurate cost estimate.

We know that estimation is an art not a science... and a black art at that. A truly good effort and cost breakdown is not easy, and it's not quick. So the outcome of the workshop for them needs to be;

A detailed breakdown of all the features we identified, in a common language that any technical partner can understand.
A comprehensive time and cost breakdown based on those identified features, including all 'invisible' components of a great software system, including deployment and sever setup, automated testing, etc..
If applicable - some key high level user interface wireframes outlining the software.

And with that bundle, they can then take it to any software development company in the world, who would then agree that it's the best software specification they have ever worked with. Although, they would still probably try and sell them their own project workshop ;)

Length of the workshop 📏

The sweet spot is having three separate sized workshops

Half a day workshop for small projects
Full day workshop as the standard
Custom workshop for quite large projects or clients with specific needs

Once you get used to running these you'll find one day goes fast. The key is staying to the agenda, and knowing how to politely move things along.

Cost of the workshop 💰

The workshop should definitely not be free. I charged around $1000 for the one day workshop.

Your pricing should depend on your agency, I think for projects that are in the $50,0000 to $150,000 range - $1000 to $2000 is comparatively small amount to pay for some up front value.

As my agency got larger projects ($300,000+) a full-day workshop often wasn't enough, so we split it into two or three days - and charge between $3k and $6k depending on the project.

There is a magic psychological thing that takes place when a client first opens their wallet and gives you money. The real trust building begins. They still take a leap of faith, but it's a much smaller leap than the full project build, a much smaller leap for them to mentally justify spending, and a much smaller leap for the opportunity to spend a day with industry experts.

Charge half as much for the half day workshop, and a multiple of days for the large custom workshop. (The largest workshop I have ever run cost $50,000, which was many sessions with many client stakeholders, scoping an 18 month long project.

If you want to, feel free to offer a deduction of the workshop cost from the total project cost if they choose you to deliver the project. This can work well at the start, however after a while you may stop this if you end up running many workshops. After all, even though you don't need to make billions off these workshops - they are taking you away from other responsibilities.

Who should attend the workshop 👯‍♀️

In the workshop you need to,

Understand and empathise with the problem they need solved
Pitch your agency - give examples of great similar work you have done in the past, mention how fantastic your development practises are etc.
Think fast and on-the-spot - this is the time to get deep with problem solving
Switch between talking technical, business, UI etc. Wear many different hats.
Be confident giving advice, even if it's not what they want to hear

If thats all you, then you can do the workshop by yourself. The one thing I would recommend is you need to document it, so if it's just you you'll want a good quality voice recorder setup so your not scribbling notes for 7 hours.

Otherwise, if other members of your team add benefit and can come in at certain points (or the whole workshop) then that's fine. I would say don't have too many people from your team, keep it to 1, 2, or 3. And similarly from their side I would recommend no more than 1,2 or 3 people also. I have done workshops with 10 people, and it's.... hard. Too many people means A LOT of talking, and time is important here. It should be fast paced but not rushed.

I think the ideal is you (as the CEO, owner of the business, technologist, and business guy) - and their main project stakeholder. They should know exactly what they want, the reasons for that, and be able to make decisions on the spot. E.g, "Can feature X be delivered after go-live, or is it integral in the MVP?" etc.

Providing an estimate range 🔎

Your agency may vary, but personally I always provided time and cost estimates. The agile 'no estimates' thing may work for well for product development and internal projects - but in client services land they need something concrete to hang their decision off - other than just good vibes.

Back in the early days of my agency I would throw the big number out there in the initial proposal email, but when my recommendation turned to "let's spend more time together in a workshop to really figure this thing out with more accuracy" - it allowed me to offer an initial estimate range - e.g. somewhere around $XYZ and $ABC - and show them the benefit of the workshop is to get some more data points for a more accurate estimate.

Just for reference I did not quote fixed price estimate. It was made clear that changes will occur, and the price will go up (or down) depending on those changes. But estimates is a whole other article!

Selling the workshop 📢

Before I introduced project workshops I would personally spend a couple of days putting together a proposal and a detailed estimated (based on the data I had from calls and meetings), and then would compile it into an email and hope for the best..

To break the email down to its bare essentials it's something like:

Please see our proposal attached. Based on our estimation we feel this would cost <estimate /> to deliver, over a period of <months /> months.

Once I introduced project workshops, it changed the sales flow. First of all I would mention this to all new clients so they understood it's how we work. I would mention we can give some initial recommendations and ballpark estimate - but for anything more concrete we really need to speed some time getting deeper into the problem and solution.

The email turned into something more like...

Please see a summary of our initial recommendations. At a high level, we feel your project may cost around <low estimate /> to <high estimate /> to deliver, over a period of <low time estimate /> to <high time estimate /> months.

As previously discussed, we offer a structured Project Workshop process to help solidify a more accurate time and cost estimate - but also (often more importantly) get into the finer details of your project, and combined with our software development expertise come up with a detailed plan of attack.

For your project we recommend the standard 1 day workshop, which costs $<workshop cost />. Please note this price is deducted from the actual project cost if you choose us as your technical partner.

After the workshop we can then create a full project proposal going into detail of the features, costs, risks, and delivery phase - and can also provide an accurate time when this could fit into our schedule. An updated estimate will also be provided, which will be a single amount as opposed to a range.

You then mention the cost of the project workshop (and the size you recommend for them), the benefit plus when you can schedule it in for them. Make the workshop sooner rather than later), and obviously reiterate the benefits of choosing a workshop.

With this email we would include two attachments

A summary of our initial recommendations - essentially just a rehash of the information they have told us in our conversations so far, a quick overview of the technology we would use, plus a summary of this emails contents.
A brochure of the project workshop - detailing the sizes available, the costs, and an agenda of what the workshop will run through

Running the workshop 🏃‍♂️

The workshop is still a continuation of the sales dance, so keep dancing.

Before the workshop guests arrive, make sure everything is prepared in advance. Have fresh coffee, tea, and snacks for your guests. Have water in the workshops space, and if you cross over the middle of the day make sure you pre-order some lunch to be delivered (and confirm dietary requirements beforehand). This should be a great experience for your client, and another opportunity to show them you are an expert at this. So from the moment they arrive, make them feel comfortable, and show them you are excited about the workshop and reassure them of the value both parties will get out of it.

I ran my workshops in a large meeting room with full length whiteboards, many sticky notes for interactivity, and a large screen with a Google slides breakdown of the days agenda. I had a large table so people could sit comfortably and relaxed, and had lots of pens and paper on the table in case it's needed.

When everyone has arrived, been offered a beverage, and has been showing where the toilets etc.. you take them through the workshop agenda. Highlight how long each area will go for, and that there will be breaks throughout the day (besides lunch, also have a couple of 15 minute breaks).

Obviously the actual guts of the workshop is the discussion that you facilitate.

You should not be talking for the whole time, you need to be asking questions, probing for more information - and making your potential clients do the real 'workshopping' for you.

Tailor the workshop contents on the types of projects your agency handles, the niche you focus on - After 10 or so workshops, I'd created a general agenda that worked for 95% of all clients - and after you implement this you will undoubtedly do the same.

Example workshop agenda ✅

Below is the agenda I used for a 1 day workshop, but as mentioned your own workshop should be developed to suite your specific needs. For example, as I focused on custom software for existing businesses (often internal software), UI and UX was generally not a big component. If you were doing public facing software you would most likely need to spend more time on that area etc.

The agenda below is high level, but with each section you should teach the workshop guests about what you are running through, and make it known that it is a collaborative workshop. Everyone should get involved, ask questions, add comments. It's just your job to make sure everything gets done on time.

1. Welcome & Introduction

Welcome - Thanks people for coming etc.
Agenda - Running through the agenda (this) along with rough times
Outcomes - A re-hash of what will come out of today's workshop, and the deliverables you will provider afterwards (the proposal, a detailed estimate, perhaps wireframes etc).

2. About us

Our Values & Standards - A time to (quickly) talk about why your agency is awesome.
Our Team, Processes, & Tools - Intro to your team members (I used Google slides for this), and overview of how you work (e.g. Agile), and the tools you use (e.g. JIRA, Figma, whatever)

3. About you

How did we get here, and why now? - Why is the client here today, what is the history that lead them to this point. You may know some of this, but you can go deeper here.
Goals - What are their personal and professional goals related to this project, make sure they are clearly documented. They are important to refer back to.
Success Definitions - What does "success" look like for this project? How do we know if we had nailed it?
Current Solutions / Alternatives - Is there anything else besides custom software development that could solve this problem? If it's a product, what alternatives exist right now (and why are you better?)
What Keeps You Up At Night? - What is the worst case scenario about embarking on this project? What is the work possible thing that could go wrong?
Project Trade-Offs / Priorities (Time vs Scope vs Cost) - On time, fully featured, within budget - the triple constraint of the 'project management triangle'. They have to pick two, they cannot have all three. Teach them that there are trade-offs in software, and find out their highest priorities.

4. Users

User Types - Identify all the users involved in the system. Who will interact with it, what roles are required.
User Personas - Take each user type and identify a few user personas. This will help you relate more to the actual end users, and can always refer back to personas when thinking of the solution features

— Lunch break —

5. Solution

Current Understandings - You reiterate back your understanding of what they are looking for / what the solution needs (quick overview)
Feature Breakdown - This is the big one. For each user type identified, write down the specific features they can interact with in the system. I recommend using User Stories, and writing them on sticky notes (on a whiteboard) under each user type identified.

6. Project Phases

Overview - mention how all projects have phases, and even if they do not want to release without 'everything' you still break it into phased deliverables for testing.
MVP - What could the absolute bare-bones deliverable look like? Would they be willing to release an MVP without first building all the features identified.
Possible phases - organise features previously identified into phases. A good rule of thumb is always aim for a minimum of 3 phases, and I always prioritise the most important features in the earlier phases (this makes it easier to cull features if needed).

7. UI & UX Session

User Interface Discussion - Is there any specific UI inspiration? Or if not, what is the general 'mood' we are going for
User Experience Discussion - Discuss UX, and also make sure to refer back to the identified user personas to make sure you are taking all users into account.

8. Wrap up

Overview - mention how there was a tonne of information and it will be super valuable in putting together their thorough proposal and estimate.
Feedback - Always ask what people thought, which parts they found the most valuable etc.
Thanks - thank your guests for coming, remind them of the next steps that you will do from here.

When I first ran these with startups I added another section called "Product definition". It contained things like how they would pitch your service to their clients, their segments and channels they would acquire users, how much it could cost per user etc. The point is your workshops will evolve with you and as you gain more experience.

Multiple workshop offerings 💸

The one initial project workshop worked well for my agency, however I know some other agencies that have a series of paid workshops, treating these like a product that users can buy if needed.

I think the types of workshops you should offer should be around your agencies specific expertise.. Don't go offering a 'Pricing strategy' workshops for startups if you don't have real, valuable expertise in the area.

To be honest I never considered other workshop types because my agency was too busy, and I think you need to be careful about offering too many (feeling like you "do everything") but some other examples of niche paid workshops could include:

A dedicated user interface and user experience workshop
A startup workshop - going deep into the MVP, customer acquisition, pricing etc
A digital strategy workshop - long term digital strategy planning.

Workshops are a great way to show your expertise, gain more time with potential client's (or existing clients) - whilst creating value beyond just 'working software', value that is a key component to a long term partnership.

If you enjoyed this article please subscribe to the newsletter below.