Categories
Digital Transformation Insights Organisational Change Uncategorized

7 Mistakes People Make When Facilitating a Workshop

To say we’re not a fan of meetings would be a mild understatement… People scrambling in late, half the people in the room not knowing why they are there and the ones that do wish they weren’t. Sound familiar?  We’ve been long-standing proponents of canning meetings altogether and replacing them with workshops.

To gain maximum value from a workshop, however, you’ll need a great facilitator. These arbiters of truth oversee proceedings to ensure the right people are in the room to have conversations that solve actual problems. 

 It can be a tricky business, but here are the top seven simple mistakes I’ve seen facilitators make and that you should avoid!

Workshop-7-tips-expert
Pretending to be an expert on the topic.

1) Pretending to be an expert on the topic.

The clue is in the title: ‘facilitator’. Unless you are an expert in the particular field or industry, don’t pretend to be!

Your job is to facilitate or guide the real experts in the room through the discovery process to generate conversations and ideas. Faking knowledge can ultimately reduce the trust people have in you and even lead outcomes in the wrong direction.

Workshop-7-tips-control
Letting people in the room run the session.

2) Letting people in the room run the session.

Too often I’ve seen facilitators lose control of the class, so to speak. Remember, you are there to guide the session to achieve the best possible outcomes for the participants. Upfront communication is key to make sure everybody knows why they are there. Make sure agendas, purpose statements and expected outcomes are shared before any session.

*If the conversation starts to wander, use a creative “car park” to capture ideas that can be discussed later.

Workshop-7-tips-process
Not sticking to the plan.

3) Not sticking to the plan.

There are so many different processes/ styles to facilitate a workshop and I’m not going to pretend to know them all. Whichever you choose, trust the process to get the outcome everybody wants. Don’t be tempted to chop and change on the fly otherwise the session can become confusing and ultimately less constructive. If it’s clear something has to change, take a break and reassess.

*I facilitate a lot of workshops and they can often feel like they’re not on the right track (particularly at the start), but each time I’ve trusted the process and there have been some incredible outcomes.

Workshop-7-tips-timer
Forgetting to keep time.

4) Forgetting to keep time.

Facilitation 101. Make sure you track the time for every step of the conversation. If you don’t, discussions will drag and before you know it your workshop has descended into another fruitless ‘meeting’. The imaginatively named Time Timer (https://www.timetimer.com/) is one of the best apps for timekeeping. 

Workshop-7-tips-writing
Illegible or tiny handwriting

5) Illegible or tiny handwriting.

How will people understand what’s going on if they can’t read your notes? Exactly. ALWAYS WRITE IN CAPITAL LETTERS ON POST-IT NOTES SO EVERYONE CAN SEE. Ideas will be flowing like fine wine so it’s important people can quickly refer back to notes. “What does that say?” is an awful waste of time. Once you become more experienced, you’ll quickly become more efficient at capturing what someone has said in just a few words.

Workshop-7-tips-comms
Lacking communication &/or preparation.

6) Lacking communication &/or preparation.

People should arrive energised and excited for a workshop. I love to share a short two-minute video with project summaries prior to the day so people know exactly what the purpose of the workshop is and what to expect. Arrive early on the day, set up tables, pens, paper, water… You’re the facilitator, everything should be in order so when people arrive the magic can begin.

Workshop 7 tips decision maker
Not inviting key decision-makers.

7) Not inviting key decision-makers.

The purpose of workshops is to get **** done! Decisions will often need to be made on the spot before pursuing certain ideas, particularly with design sprints. The last thing you want is for an idea to go all the way through to prototyping before a senior team member shoots the idea down. It’s a quick way to waste a week. ‘Decision-makers’ may be short of time, so just make sure they’re present for core decision touchpoints for a thumbs or down. If it’s down, you can quickly pivot. Pivot!

So there you have it, 7 simple mistakes to avoid when facilitating a workshop. If you enjoyed this, you might also find our 10 Tips To Workshoppin’ Like A Pro helpful.

For any further questions, or if you’d like me to facilitate one of your workshops, don’t hesitate to get in touch.


Book a free session today to explore how we can help you achieve better outcomes.

Categories
Insights Work Life Balance

Answering your most asked questions about Freelancing.

Freelancing has often been mooted as the future of work, with professionals seeking more control of their work and organisations benefitting from the greater flexibility of a transient, highly specialised workforce when reacting to evolving markets.

For many, it still remains a game of risk vs reward.

Having spent much of his career as a freelancer, Jason is here to answer your most searched questions about freelancing.

Categories
Insights Teams Uncategorized

“Hiring good developers is just like sexing chickens”

A memorable – if not a little disturbing – simile once used by an industry legend during his seminar.

Sensing the discomfort of the crowd, he frowned & bellowed, “Well, you know what I mean, right?” Not a clue, but you certainly have my attention… “It’s like being able to tell the gender of a baby chicken just by looking at it.”

Apparently it’s a subtle art (in the loosest sense of the word) developed with many years of experience, one you can attain to determine chicken gender, or, more usefully in our line of work, developer quality.

I don’t know about you, but I certainly don’t know anyone that has the ten thousand hours required to master that skill.

Anyway, we’d prefer to hire whole coops, sorry, teams of developers for a number of reasons.

  1. The developers already work together so have a quicker startup time.
  2. Cross-functional teams will be able to fulfil all the roles required for project delivery – UX, development, QA, DevOps & so on.
  3. They usually have a project project manager, scrum master or coach who’ll take responsibility for helping the team organise their efforts, report on progress & deliver the project.

Hiring teams is a completely different proposition to a single developer – we can’t make them all do whiteboard interviews. Here are some of the things we look for & ask at Digital Village when hiring great development teams.

Show us what you’ve done (please)

Stand & deliver. We’re technology agnostic & focus on the best processes for delivering reliable value in. In short, we spend less time looking at tech teams work & more looking at the projects they’ve completed.

Are the projects ‘significant’ & did they challenge the team’s ability? ‘Significant’ is of course subjective, but we’re looking for teams with strong capability & ambition.

Are the projects accompanied by glowing testimonials? Unfortunately self-assessment can be a little, let’s say, biased from time to time.

Now let’s talk about it

A curated brochure of past products is nice, but we aren’t window shopping here. We need to dig into things a little (lot) more. A good ol’ fashioned interview with some representatives from the team is a perfect way to find out:

  1. What challenges the team faced while building one of their showcased projects & how they resolved them.
  2. What they enjoyed about the project. Seriously, we’re all supposed to enjoy this or what’s the point?!
  3. Which projects they’re most proud of & why (forgetting pride is of course a Sin).

Abiding by the old proverb, “it’s not what you say, it’s how you say it,” & without dabbling in amateur psychoanalysis, there’s a lot more you can take away from the interview.

Are they excited to talk about the projects? Do their eyes light up when explaining technical triumphs. Perhaps an eye-roll when describing the challenge of containing scope with an ambitious client?

Honestly, the last thing we want to see is ambivalence. We want to see anything to show a deep engagement with all the challenges (technical & otherwise) that arise during a complex project.

If they pass both stages with flying colours, hire them & give them everything they want.

Ok, just kidding. I’d feel very hesitant to hire a team purely on this basis. So, I hear you ask, what are the key questions Digital Village asks before engaging with development teams..?

How do they know they’re building (whatever it may be) correctly?

A simple yet serious question. How do they know what they’re building works as it should? It’s an opportunity to understand their practices, processes & also attitude towards producing quality software.

The answer, of course, should involve a seven letter word that causes more headaches than most: ‘testing’. But what kind of testing? QA staff are great & will pick out errors like a sniper, but automated developer tests are also important.

The bravest programmer you’ll meet (& the one you want to meet) is running a gauntlet of unit, feature & integration tests. “Does my change break anything?”, is just an automated test run away.

Adopting such methods allow teams to stride quickly & ambitiously because the safety net of automated testing is always waiting to catch them after a misstep.

How do they know they’re building the right thing?

At least this one’s simple… “it’s what the client asked for”. Get out.

Every project is a big investment for a client, so how can we be sure the investment is going to pay off?

At Digital Village we have a huge range of clients: start-up to enterprise, tech wizards to non-tech founders. With each client, we assume full responsibility for helping them understand if the proposed project is going to make their business more successful.

If not, we can steer them in a better direction even if it means having difficult (but always positive) conversations. Clients come to us looking for guidance & it’s fundamental to our service that we find the right solution.

So our question for any team is, “how will the client know if what they’ve asked for is what they really need?”

If they reply, “the client agreed to the specification, if the code meets the spec then they’re getting what they want,” they’re not the kind of team we personally like to work with.

I’d love to hear how the team proactively validates work delivered to a client, their strategies for eliciting feedback & how they manage that moment when a client says, “wait a minute, this isn’t going to work”.

So, where is everyone?

Long gone are the days of expectation & necessity for singular locations. We’ve worked with all kinds of teams: onshore, offshore & a hybrid of both. So far, we’ve found each model brings its own benefits & challenges.

If a team has offshore members, great! Some of our current teams that contain offshore members produce incredible results at a fantastic price-point.

Traditionally, communication is seen as a potential pitfall for offshore teams, but our success is due to amazing team leads who are responsible for communicating with project stakeholders locally & team members offshore… a conduit, if you like.

So let’s hear about who is responsible for communicating the client’s needs to the team & relays the team’s questions, concerns & suggestions.

What’s the silent killer of projects?

To be clear, I’ve never asked anyone, “what’s the silent killer of projects?”. One, because it’s over dramatic, & two, there are always symptoms.

I would love to know, however, what the team thinks is most likely to derail a project. Although answers will vary, if this were a game of Family Feud I’d expect “communication problems” to be a top answer.

As Bernard Shaw, a man that revolutionised comedic drama, said, “The single biggest problem in communication is the illusion that it has taken place”.

So what are their individual thoughts regarding communication? How could they be sure a client has understood them (& vice versa)? Perhaps most importantly, will they be willing to take on the commitment to communication that Digital Village does?

Dev teams are often missing one vital piece of the puzzle. The client. Now we aren’t expecting 40hrs a week, but we always try to bring clients & users into the project team. Invite clients to join meetings & the same communication channels as the rest of the team.

The last word(s)

So, a case study & an interview. We’re hardly rattling the established pillars of HR & recruitment with this one, are we? But what it all boils down to is can we answer the following questions with a reasonable degree of certainty:

  1. Is the team proficient enough to produce technically sound work?
  2. Do they care enough about their client to provide them with results that make them more successful & do it in a way that makes the client feel empowered during the process?

I’d be happy to work with anyone who can do that.

Categories
Insights Organisational Change Work Life Balance

Canceling “Work-Life Balance”.

Millennials flooding the workforce has forced the redefinition of the much-loved buzzwords “work/life balance”. Instead, how about we cut the cr*p and do away with it altogether?

Perhaps this is a sign of resignation. Possibly calling for the term’s shelving altogether is the culmination of frustrations following years of trying to understand and articulate its current standing in the workplace fully. Perhaps it’s a touch of pedanticism.

Balance, fine, it’s the two words before it and dash or slash that irk me. We have a myriad of obligations and responsibilities to others and ourselves that we must prioritise and balance, not just two. Why are we making a distinction between ‘living’ and, ironically, ’making a living?’.

The assumption is that we tread a delicate (and often seemingly impossible) tightrope between two polarising worlds: what we “must do” and what we “want to do”. Work is bad; private life is good. The work/life paradigm implies we have two lives. We don’t, we have one, and if we aren’t in charge of it, then somebody else is.

I was once told, “life is our priority, but work is somebody else’s”.

Many adopt a somewhat dangerous position of defining our self-worth via our career, and I think that boils down to a particular view of “success” that we are taught. A “good job”, long hours, big money, promotions… And there’s nothing wrong if you are fulfilled, but the constant discussion over work/life balance would suggest not everybody is.

The traditional days of career trajectory are largely behind us. Long gone are the expectations of a single career – towing the line along a linear trajectory from bottom to the… well, somewhere that isn’t the bottom in return for a gold watch upon retirement. It’s a truly symbolic trading of time because let’s be clear, our finite amount of time is what we are trading.

We now live in a connected world of opportunity where people are having ten different careers (and less are treading the first rung on the corporate ladder). As people are becoming more conscious and aware of themselves, we’re beginning to question our relationship with work and how we spend our valuable time.

… idealistic?

Well, perhaps. For some necessity and obligation to others will, of course, take priority because unfortunately, we need money to survive (I’m sure I’ll write in further detail about the utopian bartering system I’m devising at a later date). The point I’m trying to make is that there has never been a more significant window of opportunity to find meaningful work that integrates with our chosen lifestyle.

We’re seeing more freelancers, gig workers, people continuously chopping and changing to find integration rather than separation of “work” and “life”. A healthy work-life balance requires reflection on what we truly value and prioritising your whole self instead of just the needs of your work.

Loosely translating to ‘reason for being’, Ikigai is a Japanese concept representing a cross-section of our work, responsibilities and interests. It incorporates what you love, what the world needs, what you’re good at amd what you can get paid for. To have Ikigai, and a healthy life because of it, means not being burdened by any one part of living. (and there are more than two parts to choose from).

It’s time to publicly ostracise or ‘cancel’ (a word I despise so much I now instead ‘annihilate’ my Amazon Prime membership) “work-life balance”. Banish it to the graveyard of annoying and useless business vernacular and make meaningful changes that allow us to integrate and prioritise our one life as we best choose.

Rant over… for now.

Categories
Agile Digital Transformation Insights Lean Startup Organisational Change

I Googled ‘Agile’ — and wish I hadn’t.

I Googled ‘Agile’ and discovered my worst fears. Confusion and mis-information about Agile software development, how it works, and how to make it effective as a method of digital solution delivery.

Following on from the short, rather poorly animated video, let me share a slightly more concise and coherent insight on how Agile should work and how it’s possible to make it a means of delivering exceptional outcomes. Spoiler alert: it’s probably not what you expect or want to hear, but please know I’m here to support you if you feel in the slightest bit unsure about what to do next.

The methods used to build solutions with software haven’t changed significantly for 30 years. And even though we’ve lived in the The Age of Agile for almost 20 of those years, the time it takes to deliver solutions, not to mention quality and efficacy, are still falling short of expectations.

Beyond Agile, examined why software development failed to meet the lofty aspirations of the Agile Manifesto founders. The book also explained how to avoid some of the classic mistakes of Agile software development.

A talk given by one of the creators of the Manifesto for Agile Software Development, Dave Thomas, underlines the dysfunction caused when the principles of the manifesto are misinterpreted or distorted to fit an enterprise IT agenda. He half-jokingly attributes the downfall as our tendency to turn adjectives into nouns; so instead of the title Manifesto for Agile Software Development, people turn it around a truncate it to — Agile Manifesto, thus losing its meaning and purpose.

Beyond Agile explores many of the noteworthy lightweight methodologies in use today, some of which pre-date Agile. This provides context and explains why software development often fails to meet expectations. Another founder of the Manifesto for Agile, Alistair Cockburn, puts it simply:

“The Agile Manifesto was the product of seventeen people from different schools and backgrounds. No one person is responsible for the words we came up with — it is clear that it was the product of all seventeen people. The addition or removal of any one person would have changed the outcome, something we recognised and discussed at the end of that meeting.

Whether you think ‘Agile’ saved the world or poisoned it, be sure always to recognise that it grew from a rich compost (joke intentional) of backgrounds. The next time you read a would-be history of the Agile movement, look for all those names. If you don’t see them, it is not a history; it is one person’s recounting of their journey, years after the event (as indeed, this one is).”

Cockburn’s statement gets to the heart of why Agile is such an enigma: few people bother to understand or respect it for what it is, choosing instead to follow second-hand interpretations of the manifesto or, worse still, adopt a consultant’s cheap imitation of it.

Agile often fails, not because it is inherently flawed or lacking in some respect, but how people interpret and apply the principles. The Agile Manifesto and its core principles are, in fact, quite logical and straightforward. The problem with Agile is it was released into the world and then distorted by people unwilling and unable to think about the true meaning and purpose of the method. Kent Beck, the creator of Extreme Programming and another of the creators of the Agile Manifesto, calls this the ‘staring dog problem.’

“If you try to point something out to a dog, it will look at your finger,” he explains. “If you explain an idea in terms of concrete practices — like test-driven development, pair programming, continuous integration — people will fixate on the practices and stop thinking.”

Kent is calling out that often we’re unable to make the cognitive leap between practice and application. Scrum and other so-called enablers of Agile fail precisely because they compensate for lack of intellectual integrity. They shroud important ideas like user-centricity and fast iteration in rituals and catchy names. The Agile manifesto left too much room for interpretation and not enough specific rules. It feels like we’re back where we started in the late twentieth century with powerful technology and tools but no idea how to make them relevant to the ever changing needs of our enterprise users and customers.

Beyond Agile, describes three outcomes Agile practised well delivers:

  1. Eliminates (or at least reduce) waste in software development;
  2. Creates software that people use; and
  3. Delivers projects on time and budget.

An analysis of fifty thousand software projects conducted by The Standish Group in 2015 found 29% of projects was successful (meaning they were delivered on time, on budget, and to a satisfactory standard). The remainder, 71% were either failures or failed to meet expectations. Just think about that for a moment: starting a large-scale technology project, there’s only a 1 in 3 chance of success. Not very good odds. The same report in 2018 showed the situation got worse, with only 23% of projects successful and 77% unsuccessful.

Other sources corroborate these stats. In a paper presented to the 7th International Conference on Knowledge Management in Organisations, Stanley and Uden proved that software projects typically overrun their budgets by two hundred per cent, and exceed their scheduled completion dates by fifty per cent.

But it’s the cost of project failures that’s the real issue here. It’s nothing short of tragic:

– The cost of re-worked and abandoned systems costs the US economy an estimated $75 billion per year;

– In Australia, $5.4 billion is wasted each year on IT projects that don’t deliver value or are abandoned completely;

– One project alone — the infamously abandoned National Health Service patient record system in the United Kingdom — cost taxpayers £10 billion.

To put those numbers into perspective, the United Nations estimates that a yearly investment of $267 billion would end world hunger by 2030. A meagre $175 billion per year would eliminate extreme poverty globally.

It’s been almost two decades since the Agile Manifesto was written, and even longer since Winston Royce published Managing the Development of Large Software Systems. But little has changed and no single methodology has improved software development; it’s still a hugely expensive and wasteful endeavour that rarely meets expectations. And that’s hard to accept, in any era.

It shouldn’t be beyond humans to come up with a better, more reliable way of developing software solutions. Just as garment makers and car manufacturers in past centuries industrialised their domains, so too software coders need to do the same. Digitisation begets automation.

Methods like Beyond Agile address some of the shortfalls, but it’s by no means a silver bullet. The method requires skilled people, disciplined practices, full engagement with users and problem owners.

When I Googled ‘Agile’ I was hoping for the answer to some of the more taxing questions surrounding the method. What I came away with was this: to make Agile software development successful, there are four areas that align closely to the original manifesto principles:

  1. Start by defining the challenge or problem to be fixed
  2. Define the project outcome in terms of a quantifiable measure
  3. Describe the first 6–12 features or functions the solution must have
  4. Identify the first half a dozen users you’ll engage at the outset and throughout.

Rinse and repeat.

Digital Village is a community of IT professionals dedicated to providing flexible IT project team solutions in an authentic Agile way to enterprises in Australia and New Zealand.

Categories
Insights Workshops

10 Tips To Workshoppin’ Like A Pro.

Along with words & the predictability of stupidity, never underestimate the power of a good workshop. In fact, I’m a firm advocate of replacing (often pointless & frankly irritating) meetings with them altogether. Why? I hear you say. Strap in for some truth bombs.

Why workshops are better than meetings:

  • Rather than a vague discussion, they have clear & defined goals/ objectives that you are trying to solve during the session & create clear actions.
  • They are structured in a way that benefits from each person’s skills & encourages ‘outside the box’ thinking.
  • If run correctly, they can solve problems in the shortest amount of time. Problem to tested prototype in just 5 days? Oh, go on then.
Design Sprint process on a wall

Running a good workshop, however, can be hard, & if you’re not careful can descend into the futile wasteland currently occupied by meetings. Following a process is simple enough but controlling the team, managing the content & ensuring you hit the goals/ objectives can be tricky. Here are some quick tips to have you running workshops like a pro.

1. The 6 Ps Of Success

Proper planning prevents piss poor performance. Some prefer ‘fail to prepare, prepare to fail’ but I’ve always been one for alliterative acrobatics. Prepare the agenda, practice (even into a mirror) & get advice from others you work with to agree a structure for the session.

  • Set a timeline
  • Set your clear focus objectives (remember, we’re here get sh@t done)

2. Think About The Logistics For The Meeting

Yes, this sounds bleeding obvious but you don’t want to be wasting valuable time scrambling around looking for things.

  • What do you need for the meeting (pens, white boards, post-it notes….)?
  • Do you have a room booked with the right number of chairs and enough space?
  • Do you understand your audience (names/positions)?
  • How will you get to the workshop if it’s offsite and you have a lot to carry?

3. Communication & Attendance

Almost as important as remembering to bring pens… The last thing you want is for the wrong people to turn up or, more realistically, key decision-makers not attending. Although everybody contributes, they get the final say.

Make sure you send out a confirmation email to everyone confirming:

  • Their attendance (provide the full list if appropriate)
  • The purpose of the workshop,
  • the goal of the day
  • and the agenda

4. Trust The Process

You’ve followed Rule 1 meticulously & are on course to prevent piss poor performance. You know what your goals & objectives are & you have chosen the right workshop process to match the outcome needs. Trust the process.

From the Workshopper Playbook by Jonathan Courtney

Don’t let people in the room make you deviate from the stages you need to go through to get the end result. If people challenge this, be open and honest about the needs of the process and inform how it will achieve the end result. Communication is key.

5. Use Ice-Breakers.

We’re embarking on a creative process so use ice-breakers to get the juices flowing. It helps to break down any barriers & encourage collaborative thinking within the group. Ice-breakers are also darn good at waking people up after a long morning or resurrecting people from a lunchtime food comma.

If the workshop is particularly long then use them intermittently to break up the day & keep everyone thinking. I’ll be releasing a free Ice-breakers eBook in the near future filled with jovial jaunts. Ninja, Tiger, Grandma, anyone?

6. Set The Rules From The Start

Anyone participating in a workshop should be just that, participating. We’re really on collaborative input to solve a problem quickly. Some rules I like to follow are:

  • No laptops or mobile phones (yes this is a tough one for people to accept)
  • Don’t talk over other people (common courtesy)
  • Never ever any name-calling (this ain’t the playground)
  • No question is a bad question (within reason
  • No one is wrong (the earth isn’t flat)

7. Utilise A Car Park

No, not to settle disputes. Sometimes conversations & ideas pop up that are not constructive to the process. Well, not this process. We don’t want to lose these ideas. Take note of them in a separate place on the wall and let the team know that you’ll come back to these ideas separately.

8. Focus On People & Don’t Make Things Up!

One of the best bits of advice I was given for managing a workshop was to remain mindful that it’s not all about you (the facilitator), it’s about the people in the room and how they feel.

Make people feel appreciated for their questions: “What I’m hearing is…..? Is this right?” & thank them. Never get defensive; appreciate what they say and table the question.

And be honest with the responses. If you don’t know the answer, don’t try and make it up. Trust me, the audience will see right through you & you’ll instantly lose all credibility (& look like a %@3*)

9. Dealing With The Trolls…

Ah, the troublemakers. Unfortunately you will have people occasionally have people that just don’t want to be there. They’re either not paying attention, talking too much or acting inappropriately. So how do you deal with these people? Straight to the car park, I jest.

Not Paying Attention: These people are annoyingly rude but are also the easiest to deal with. In these instances here are some things you can try:

  • The whole room is your stage (as the facilitator). Walk & talk. All eyes are on you as you present & will also be on the person *&@£ing around on their phone as you stand behind them. That usually does the trick.
  • Remind everyone (without calling out names) the rules about devices and attention.
  • Sometimes you just need an earlier break to keep attention.
  • Between breaks politely ask to have a private conversation with them & talk about how you can help them be more present in the room.
  • Go full highschool teacher & ask them to share what they’re doing with the room.

Loudest Person In The Room: This is very common when you have a room with potentially “junior” team members and a few “senior” members. Unsurprisingly it’s often the senior leadership that talks the most. So how do you deal with this?

  • As the facilitator, sometimes the easiest thing to do is to ask them to deliver their thoughts. So if someone isn’t saying much, give them the confidence & opportunity to speak.
  • You can utilise a talking stick. So only people with the stick are allowed to say anything. As the facilitator, make sure the stick is passed around the room.

Inappropriate Behaviour: Probably the hardest situation to deal with. You’re all adults & the expectation is that everyone behaves like one. Unfortunately there are some people that still struggle to do so. So how do you deal with these difficult situations?

  • Shift the process from conversations to quiet actions/note-taking.
  • Call a break & ask to speak with the person about their behaviour (politely).
  • End the meeting all together as it could be causing more issues than good.

10. Feedback! Always.

You never improve if you don’t learn from what you’ve done. Always ask for feedback at the end of the workshop. Every workshop you run is training for the next one you run. If it didn’t go as well as it could have, don’t take it to heart, explore why, & understand how you can do better next time.

7 Mistakes People Make When Facilitating a Workshop

  1. They try to be an expert on a topic
  2. Let people in the room take over the narrative
  3. They don’t trust the process
  4. Don’t time keep
  5. Write with small handwriting so no one can see
  6. Lacked any preparation or communication
  7. Didn’t invite the key decision maker
Categories
Agile Digital Transformation Insights Organisational Change Scalability

Excel: So useful it’s dangerous? Here’s the solution…

Excel is probably the closest thing we have to the perfect tool for analysing & reporting on data. It’s greatest downfall, however, is that it doesn’t really scale beyond a single user, and the result is organisations find their data and IP locked up in un-verifiable (but easily shareable) files.

James Diekman, who’s recently joined the Digital Village network as a Producer, sat down with DV co-founder Luke Fabish to share his solution.

[Luke Fabish] Hi James, we’re pumped to welcome you aboard as a DV Producer – could you tell us a little about yourself?

[James Diekman] Thanks! I’ve been in the IT industry my entire career, starting out in support to more recently becoming a Microsoft specialist consulting to government agencies and large enterprises which has been super exciting. I’ve got a passion for business applications and leveraging them to solve business problems and getting involved with the Power Platform community and also not for profits.

[LF] Hey, that’s great James. Recently we were talking about one of the technologies you work with, Microsoft Power Platform, and about how it has the potential to solve one of the biggest problems affecting IT in organisations… Excel is used for everything! What are your thoughts on that?

[JD] Completely agree! Use Excel for what it’s good at – analysing data. Don’t use it as a store of record, it simply wasn’t built for that and you’re missing out on turning your data into valuable insights. Also it’s not just Excel… We often see Word, OneNote and good old Microsoft Access heavily used because it’s all the users had at hand. These products have been around for eons.

[LF] So could someone who’d normally open up Excel to get a job done use Power Apps just as easily?

[JD] Absolutely. Organisations, however, need to look at PowerApps as a better way to capture data that can be stored in a common data service. From here organisations can start to automate processes they were never able to before because the data is stored in one place in a structured format. Start adding more applications and more data and you start to build up a valuable data estate that you can analyse and interpret by levering new technologies like artificial intelligence (AI).

[LF] That sounds amazing! So what you’re saying is we can solve some of the problems introduced by the pervasive use of Excel as a data store?

[JD] Yes… from simple problems such as versioning, multiple users, and data corruption to relating and querying large data sets. Thousands of disparate Excel files are of little value. Leveraging tools like PowerApps and the Power Platform allows you to turn data into business insights you previously didn’t have available to you before.

[LF] Thanks so much, James. For me, the big takeaway seems to be the ability to remove complexity and open up a way more collaborative approach to data than is possible in Excel on its own.

I know we’ve barely scratched the surface here… The Power Platform is at heart a powerful system for rapid digital transformation that can provide deep and integrated value across an organisation’s entire digital landscape.

Want to learn more? We have an upcoming live event with James where he’ll be highlighting the breadth of capability that Power Apps can bring to an organisation (plus he has some great tips for getting the I.T. department on board with it as well).

So to learn more about rapid innovation and digital transformation with Microsoft’s Power Platform, register for our upcoming event here.

Digital Village Live-Stream
Accelerating Digital Transformation
Categories
Customer Lifetime Value Insights meetups

How to Measure Customer Lifetime ROI

The busiest time of year is approaching and you’re running ads to increase acquisitions and revenue…

Let’s say you acquire two new customers at an acquisition cost of $20 each. Luke spends $50 & Jason just $25. Luke, therefore, represents a better ROI, right? Well, initially yes, but perhaps we’re thinking too short term as Jason returns at a later date and spends another $100.

Jason Hardie, Luke Fabish and Suraj Pabari talk about measuring customer lifetime value
Jason Hardie, Luke Fabish and Suraj Pabari talk about measuring customer lifetime value

Instead of focussing on short-term ROI, businesses should consider a customer’s lifetime value. Businesses need both Lukes & Jasons but by focusing on acquiring high-value customers revenues will increase, your business will grow and all shall be donning ear to ear grins.

If lifetime value does not exceed cost of acquisition, however… you get the picture.

So how do businesses identify, target and acquire high value customers while inspiring long-term loyalty? Well, we provide a tailored experience using RFM segmentation: Frequency, Recency & Monetary.

Imagine you’re the proprietor of a coffee shop (the kind that sells drinks prefixed with too many adjectives) & want to introduce a 50% discount voucher. Ok, great. Offering a discount to customers with a low frequency may be a great way of enticing them through the door.

Watch the full stream here now.

Now consider a customer that religiously purchases their dirty, skinny chai latte each day without fail. Their frequency is already high so a 50% discount is probably the wrong approach. Instead, you could give them a free hamper on their birthday; you already know what they like.

In DV STREAM: LIfetime ROI, Suraj Pabari discusses how you can develop a strategy to retain high-value customers and increase loyalty with low-value customers.

Categories
Customer Success Digital Transformation Insights library Payment Solutions

Are Payment Platforms in Australia on the Right Track?

by Paul Scott, Director and Board Advisor at Digital Village

Photo by Ronaldo de Oliveira on Unsplash

Payment Platforms are often referred to as the rails on which commerce transacts. It’s an interesting analogy, given the gauge of rails used today on most of the world’s train tracks were established by the Romans over 2,000 years ago, and has not changed significantly since in most parts of the world. Payments Platforms haven’t been around for the equivalent of seconds, but we have multiple incarnations, and none entirely seems to meet customer needs.

Technology can be tricky bedfellow. Take payment platforms for example. Before ‘digital’ was even a twinkle in John Vincent Atanasoff’s eye, banks were using multiple payment reconciliation methods — all paper-based of course. Records were kept in dusty ledgers scribed with ink pens by crusty men in starched shirts and voluminous morning coats.

Roll forward 90 years, and here in Australia, we have an abundance of digital payment platforms. Which is odd, because usually when technology replaces manual processes, you’d expect some degree of consolidation, streamlining and a leap forward — innovation perhaps.

Eftpos was born some ten years later and stands for electronic funds transfer at point of sale. It’s principally aimed at credit, debit and payment terminal transactions. Its also owned by the big four banks via a company called Cardlink.

BPAY was established in 1987 by the big four banks in Australia. It was the world’s first phone-based payment system. Nowadays its a full-blown digital bill payment platform.

The New Payments Platform is owned by 13 banks. It’s the new kid on the block, formed in 2013 and launched to the public in 2018. They were given an innovation mandate and launched an instant settlement process which uses phone numbers, email addresses as well as ABN’s.

Between them, each of the three principle payment platforms serves every business and consumer in Australia, but why three? Well, it’s a result of several factors, federal, industry institutions, regulators and the banks all had a hand to ensure the applecart remains upright.

Now there’s a move to seek consolidation, but just how long that will take and what the composition of the outcome could look like is anyone’s guess. There’s a bucket-load of vested interest and the glacial pace of change in banking to consider. In their wisdom, Australian Payments Council chair Robert Milliner has been appointed as the independent convener of a special industry committee examining NPP Australia’s proposed merger with BPay and Eftpos.

Robert Milliner

Not content with the existing complexity APC’s decided to have Milliner’s committee operate within a NPP-owned subsidiary, Industry Administration Committee Pty Ltd (ICA).

The purpose of ICA is to establish a governance framework for “making non-binding recommendations” on the merits of merging NPP Australia’s operations with the two domestic payments schemes.

The technology aspect of this is interesting. It’s a classic case legacy myopia. The core systems underpinning BPAY and Eftpos are 40 years old. Ask any digital solution builder what they’d recommend its likely to be ‘Reno’ versus ‘Doer-Upper’. In other words, it would be easier, quicker and better to build from scratch. Why? Because it takes 1/10 of the time to build the equivalent of 40 years ago and costs a fraction of what it takes to consolidate and build on top of existing computer code.

Speaking to people like Andrew Walker — the Impatient Futurist and you understand the logic. He’s spent a career showing retailers, banks, and insurance companies that building and consolidation on top of old systems is a waste of money and never delivers the desired outcome. Better to start with a blank screen, start solving one problem at a time and deliver outcomes users need.

Likewise, a senior executive in one of the three principal platforms explained it as follows: “Another industry insider concluded: “I feel the big four banks, in their current form, are not good for Australia, particularly over the longer term. They need to innovate, with a view to extending their business into a ‘platform’, with open support and collaboration for new entrants. An ecosystem if you will. Only this will deliver useful products and services to the Australian market and ensure the ongoing relevance of the big 4.” He concluded: “Otherwise, bring on the ‘asteroid’ for these dinosaurs.”

What happens next? Well, major shareholders in each of the platforms — the banks — will examine the landscape, sound out the regulators and oversight boards and decide what they can get away with. Sorry, I mean they will have an epiphany, recognise the extraordinary opportunity they have to leap forward with a new technology solution to payments people want and need. Maybe.

Categories
Agile Customer Success Digital Transformation Insights Lean Startup System Engineering

What Dev Teams Are Missing.

UX designers, check. QA designers, check. Developers, check. The list goes on… but most highly-trained dev teams are missing a vital piece of the puzzle.

Software development is an inherently technical activity but without solving a real human need a project has no purpose. So why are those with the most immediate needs, the arbiters of purpose in this instance, missing from the team?

Standard processes for software development demonstrate the issue (sometimes jovially).

@johncutlefish

Customers and end users, the foremost experts on the business and its goals, are the critical missing piece from software development.

Aren’t they included already?

Well, yes… but not enough.

Towards Customer-Centric Software Development: A Multiple-Case Study found that, even in organisations with a high level of customer focus, that customers were only present at the beginning and end of the development process.

The authors found four key challenges with this approach:

  • Indirect access to end-users led to a lack of understanding of the reasons behind customer requirements.
  • Feature prioritisation is done based on employees’ opinions and is not continuously validated with customers.
  • Testing is seen as an opportunity to identify defects but not to validate mismatches between customer needs and product offerings.
  • A lack of systematic ways to collect, analyse and incorporate customer data into the product development process.

What’s the real problem?

By omitting the customer and end-users from the delivery team you are working on hypothesis (and to some extent guess work).

Even projects undertaken with extensive and painstaking research are based on what a potential solution could look like. This hypothesis isn’t tested until the end of the development phase when complete features are presented to the users and customers.

And now for the grand reveal… The software has been built to the customer’s specifications, or has it been built to the team’s interpretation of the customer’s initial specifications? Without fully understanding the customer’s situation there is a high chance of building the wrong software.

This of course has a huge impact on budget, schedule and, worst of all, the trust between the client and team.

So how does putting the customer and users into the project team help?

Shortening feedback cycles is a central principle of Agile delivery. By embedding key stakeholders within the team, feedback cycles are reduced from weeks to days.

Developers can demonstrate early prototypes and benefit from the unique expertise and feedback that only customers and end users possess. Rather than thinking, “what would the customer want?” at key decision points they can be asked directly.

No grand reveals, no surprises. A product is developed in collaboration with the customer and ultimately the people that will be using it.

Customers and users are busy people – do they have two jobs now?

Obviously we can’t expect the customer to be turning in 40 hours a week, that would be slightly impractical (and rather unnecessary). Attending weekly team meetings and being able to respond to questions from the team is enough.

The point is to ensure the developer feels comfortable making a call to the customer or uses to clarify a requirement or gain feedback on an early version. Essentially, you remove the subjectivity and guesswork to ensure the right product is being built.

Sounds nice – does it really work?

Digital Village recently completed the first iteration of the Race Around Australia project and was rolled out for a successful pilot in NSW schools. Program manager Emily McLachlan was deeply involved in reviewing the work in progress and making critical feature decisions and prioritising application features.

Her involvement allowed the delivery team to frame technical decisions within the needs of the department, schools, teachers and students, which reduced uncertainty around the product to practically zero.

You can read about the project’s success here.

Next Steps

Convincing busy professionals to attend another meeting/ create time for the demands of a project team sounds, well, trick. In fact, the hardest part may be convincing people who feel somewhat out of their depth in a technical project to participate in delivering it.

With the right support, however, non-technical stakeholders like clients and end users can provide invaluable contributions to a project delivery team.

The first step, of course, is a conversation with project stakeholders. Luckily that conversation will be about how they can save money, reduce risk and enjoy the benefits of their new software as soon as possible. We have a suggestion…

Working closely with the customers means the team will share the customer’s disappointments and triumphs, and hopefully shifts the team’s mindset from focussing on feature delivery to customer success.