Tēnā koutou katoa, hello and welcome everyone. For some of you, this is your first time joining us, so you may not be familiar with Alan and Clark. We're an Australasian-based consultancy dedicated to making a positive impact on communities throughout Aotearoa, Australia and the Pacific.
Our areas of speciality include strategy, change management, programme delivery, policy, research and evaluation, just to name a few. I'm Sean Stack, Senior Consultant to Alan and Clark, specialising in system design and wrangling the various contributors to that type of work. Today we're discussing leveraging specialists, how to get the best out of your experts. And with me today is Priscillia.
Kia ora everyone, my name is Priscilla and I'm a Senior Consultant at Alan and Clark. I have been leading and contributing to various strategy, change management and business cases for governments and NGOs. I'm very excited to be here and joining Sean and share my experiences working with experts across different sectors. Cool, so firstly, Priscilla, what do we mean by experts? So, this might be someone with subject matter expertise. It could be a health clinician, climate change scientist, people with expertise in particular approaches or someone with a specific lift experience.
And why do we work with experts, Sean? Well, really it's because we can't know everything ourselves and so to do work you need to ensure that you have the right knowledge and skills on our teams to help us understand the issues that we're trying to address with a piece of work and how to solve them. So, for example, I'm working on an offender rehabilitation programme in a prison, I might need a forensic psychologist or if I have to do a complicated statistical analysis, that's certainly not me, so I'll need to get someone in who can do this. More broadly, there are benefits from working in multidisciplinary teams and bringing together different perspectives and knowledge systems.
Priscilla, can you give us a summary of why it can be challenging to work with experts? Yeah, so the most common reason I've encountered is the difference in understanding and expectations between people leading the project and the expert. So, for example, the expert providing depth on a topic but what you actually need is breadth. And then your expert providing independence rather than alignment with your organisation's strategy or programme goals.
And lastly, we have all fallen into the trap of using too many jargons and technical terminology. And today, we would like to share the challenges we've encountered, how we've overcome them, and share the lessons learned with you. Yeah, great.
Thank you. So, to help us work through the session today, we're going to use the structure that you can see on your screens now. We're going to talk through some fundamental challenges associated with three key stages of working with experts and share some tips for each stage so that by the end of the session, you'll almost always end up at success rather than failure.
So, what do we mean by each of these stages? So, defining. By this, we mean the process of figuring out what speciality or expertise you actually require, finding people with that expertise and figuring out who the right people are. Onboarding means the point at which you've picked your people and need to set them and your whole team up for success.
Delivering, this is the point at which you actually do whatever you've got to do. You're not just going to be hearing from us today, thankfully. Priscilla, who else are we going to hear from today? So, we're going to hear from a few experts we've worked with over the years and they're going to share what they like about being engaged as a specialist, what they wish always would happen and wonder what could happen.
We will hear from our own Jackie Ngawaka, a senior consultant who has specialist knowledge in Te Aumori as well as Dave Grimman, who's an independent economist specialising in various economic analysis and methods. Great. We're also going to hear from Dr. Jacinta Cording, who's at the University of Canterbury.
Jacinta's an expert in the rehabilitation of violent sexual offenders and is also a specialist in quasi experimental research approaches, which Alan and Clark use as an impact evaluations. And then finally, we'll hear from Dr. Pounamu Aikman from Mana Pounamu Consulting. Pounamu has expertise in Te Aumori, including in kaupapa Maori research methods and fluency in te reo Maori.
Cool. Let's hear what our experts have to say about the defining stage. I like it when organisations clearly communicate what they'll be expecting from me versus what they'll be dealing with internally, because it helps me understand what it is exactly that they're wanting from me.
I like to ask people what the pain points are, so sort of what's keeping them up at night, sort of the way I describe it, because it helps me to, and even if I'm asking that in a third person way about the client, think about that, to understand kind of the sorts of issues or challenges that they might be dealing with and how that might impact the work that I'm doing for them. What I wish for at that kind of stage of the process is that it's good to have a good conversation with the project leader or the team to get a clear, mutual understanding of the objective of the project, what each team member's role will be, what needs to be done to deliver what, to deliver the project, what inputs are required, like data and skills and meetings and stuff like that, and making sure that the project specs are realistic. What I don't like the project being is unclear, poorly written RFQs, requests for a quote.
What I find is if the client has not been able to write a clear request, then they usually don't have a clear idea about what they want out of the project, and to me that's a huge, usually a big warning signal to me that, hey, this is a project where things could go wrong. And this invariably does. A clear spec means that they've got a clear understanding of what they want and we can then design our project to deliver what they want.
What I really like in the identifying requirements phase, so that early aspect of the project, of developing projects, is working with people I've partnered with before, because that familiarity helps move quickly and responsibly to when there's a quick turnaround on a project. I appreciate that not everyone has that, but that is a really helpful aspect of being in this space where you're working alongside partners in some of the projects over time. One of the things, though, that is really important, and I wish we always had enough time to do, was really carefully think about the methodology in response to what is being asked by the client, because the heavy lifting in terms of thinking often needs to be done at that stage in terms of what is the product that we're actually offering to the commissioning agency, whoever that might be, in our response to, or our solution for their piece of work that they're asking to do.
The better we get that understood at this inception phase of the project proposal stage, the easier it is to actually both bid for it and then if we're successful, run the project itself. Cool. Hopefully you all found that interesting.
I think the first point that I want to make is that even though we're talking about defining onboarding and delivering work, this is equally applicable whether you're getting in external subject matter experts or whether you're onboarding existing team members onto a particular piece of work. That's the first thing I wanted to say. The second thing is that I really like what Dave said about needing to clearly define what you want from an engagement with an expert.
That goes a long way to ensuring you get the capability you need and the right people with that capability. Then I think Pounamu's point around thinking carefully about the methodology builds well on that. Be precise with what capability you require and then how you actually see that capability being used to deliver.
What do you reckon? Yeah, I think I really love what Jackie said about putting herself in the client's shoes as the person commissioning the work to an expert. Those are really good questions to ask ourselves and the question, what keeping me at night would definitely help tease out the outcomes I really want. I think all four of them talk about clarity, it's clear requirements, clear roles, clear expectation, but also remember to be realistic about it.
Yeah, awesome. Let's go through some of the key challenges associated with the defining stage. Priscilla, do you want to start us off? Yeah, sure.
For me, it's making sure that we take into account the experiences and capabilities our team already have so we all have our niche and at the defining stage, I normally do a small, mini gap analysis, which doesn't have to be onerous, but that maps our client's capabilities and we can find out what we're missing. This doesn't mean that we can't have duplicates, so there is benefit in having another perspective and a more independent view to a project. It's really important to do this before jumping ahead into thinking about the who you need.
Yeah, I agree. The obvious question then becomes once you've undertaken that process and you've defined your need, how do you find someone to fit that need? I know it sounds a bit simplistic, but in my experience, the best way to find the right person is to ask people in your networks whether they know anyone who'd be a good fit. If you've defined the capability you require well, then those people will probably be able to give people a pretty decent idea of what type of capability you need, and then the first people you talk to, they might only just give you a lead to follow up on, but then if you keep following those leads, you'll eventually find the right person.
My experience, having done this quite a lot, is that it's pretty unusual that it will take you more than five phone calls to get there. It definitely feels weird and awkward at first, but you get over it. There are of course other ways to do this, like Googling or searching on LinkedIn, but ultimately it will all come down to eventually starting to ring people and talk to them, which means you need to have the capability you need defined well if you want that process to go smoothly.
Yeah, and also when we start thinking about who to involve, it's really important to check their interests, not just assume because someone can do it, they will want to do it. I think it's particularly critical for people with lived experience, because it's so easy to assume that because this is their world, they will want to be involved in this, and once we have an initial conversation with the potential partners to check their expertise and interest, I usually create a shopping list, outlining the expertise and interest of each potential expert, and do like a matching exercise. I used this trick when I was leading a project to develop a campaign to encourage young Maori in Pacifica to study nursing, and it led me to find my unicorn, a young nurse specialising in Maori health with interest in creative marketing and has his own TikTok following.
It's really helpful to note though that sometimes we can't find that unicorn, like we can't find all the expertise we need in one person, so especially for a complex and really technical project. So it is okay to have two or more experts working together with us. Yeah, 100%.
I agree with your last point in particular, and sometimes it's even beneficial to have multiple experts, because people only have so many hours in the week, so that's another thing to think about. So one thing I would like to add is that if you are a company or an agency that's looking for a multidisciplinary team of experts to do a piece of work, then there are procurement approaches that you can use that will make it a lot easier for those teams to form and approach you. Some of those are things like open briefings, where experts can learn who else is interested in the work and who might have complementary skills, or some procurement panels maintain and provide access to lists of panel members' capabilities, which provides a useful shortcut to finding specialists.
Cool. So next we're going to talk about challenges in the onboarding stage, but first over to our panel of friendly experts. For the onboarding part of projects, what I like having is a proper inception hui at the very beginning.
This isn't just a formality, but sets the tone and expectation for the entire project from the perspective of the research team, who's doing the research, and then also the client, who is what they're expecting. From the beginning, I like to work sort of systematically through the resourcing needs. I do like to think about the detail of what I can see might be happening, whether it's in different stages, because it can sometimes save sort of last-minute organising or coordinating that can put extra stress on people if you haven't already thought about what might be coming.
And if something unexpected happens, you've already considered some of those things. I like it when I have a chance to have an informal meeting with the rest of the project team, because it helps me establish a collegial working relationship right from the beginning, and it also helps me to understand where my expertise fits in amongst others on the project team. I wonder if there's value in appointing a mentor or a point person within the organisation, especially if this is the first time that I'm working with them, so that I know that there's someone that I can go to to ask questions or ask for clarification about expectations without having to bug the project manager all the time.
What I wish for is a clear understanding about who the target audience is and who the client's key decision makers are, which can be quite different, because I guess the key thing there is that the key decision makers may not be in the room, and they can influence the project. Also, I think a clear understanding about who the ultimate client is, is important to maintain our integrity, that we're doing a project for the taxpayer, for the New Zealand citizen, or for the ratepayer, or whatever. They are the true client.
The people that we deal with often are the intermediary. I guess spending time ensuring that there's agreement about the objectives and mutual responsibilities at this stage is never wasted. It's really important.
Cool, and we're back. Before we get to sharing our reflections on that, we've had a question come through from Hillary. Please explain the term peak bodies.
Peak bodies are overarching organisations that represent members from within a certain profession or sector. I can't recall all of them off the top of my head now, but there'd be, for instance, there might be a peak body of psychologists. If you need a specific type of psychologist, you could approach the psychologist peak body and say this is what we need, having defined your capability.
Do you know anyone that you could put us in touch with from amongst your members? Cool. Please do feel free to send through more questions or reflections on what our experts are saying. I guess, Priscilla, what did you think about those comments? I'm hearing the experts mention formal and informal meetings in the same video.
I think there's room for both. It doesn't really matter if a project is short-term or long-term. Sometimes a short-term one means intense period of delivery, which means teamwork is super important and there is a lot of pressure to get things done quickly.
What is quite interesting is what Jacinta mentioned about having a mentor, because when we work with an expert, I never really thought about appointing a mentor for them, because they're the expert, right? But now having heard her point, I think it would be something we should consider in the future. I agree. Jacinta's comment about the mentor made me think about the value in organisations supporting their project managers or project leads by providing new experts with induction packs or something similar.
From experience, it can be a massive burden to be onboarding a new expert to our organisation as well as to a specific piece of work. Doing what an organisation can to free up project managers to focus on onboarding to the specific work is really worthwhile. We have had another question come through from Desi.
How do you manage unconscious bias of an expert? Priscilla, do you have any thoughts on that? Yeah, so I think it's always tricky to manage that, but again, I think really understanding what the project is going to deliver and having a sense check for all the things that the experts say to you as well. Yes, they are the expert but it doesn't mean that you shouldn't do the checking and also share the thoughts. I think it's always good when you get something from the expert to have some time to discuss it and ask the questions to try to avoid that bias if possible.
Do you have any other thoughts? No, I think I'd agree 100% with what you said. I think it's really around creating an environment where you and the relevant expert can have a sort of open conversation and figure out whether there is bias that's creeping in and then figure out either together or independently what do we need to do to manage that bias and that might involve bringing on another expert to provide a second independent lens. That was a really great question.
Thank you, Desi. Cool. Moving back to key challenges.
Priscilla, can you give us one of the key challenges and how you've overcome it with the onboarding phase? Yes. What's critical for me is making sure that we are acting and behaving like a team. At Elan & Clark, we have quite a big team.
When we start a new project, often we have people and partners who we have never worked before and we want to invest in that relationship up front and this can be done through different ways. My top three ways to do so are firstly, getting the team together, making sure there's an opportunity for whakafangatanga and building connections. Going back to that informal meeting point before and then secondly, ensuring your specialists come to the project kick-off meeting and hear directly from you, from the project sponsor, project manager or even better, hear from the decision maker.
Lastly, don't just use email. Use other communication platforms. It can be a WhatsApp group or other app and that can help the SPACE team stay connected and you can communicate things quickly.
Great tips. Thank you. From my experience, it can be challenging to ensure that experts are actively looking for ways that they can contribute to the piece of work right from the beginning of the piece of work.
The best way I've found to do this, to get them looking for ways to contribute actively, is to involve them in an initial goal-setting process with the rest of your team. Have a discussion about why you're doing a piece of work not what you're doing and then agree a set of goals that reflect the why. For example, a why goal might be, we will ensure that the organisation we're evaluating will understand what impact the service it is funding has.
Dave's point about being clear on the audience can also be really useful for the goal-setting process. With that evaluation example, you might get a big data set and just ask your friendly data scientist for a specific analysis to answer a question. With the why goal, the data scientist on your team is way more likely to come back to you and say, OK, we've got X and Y what if we also ask for Z and then we could do some quasi-experimental analysis to see if the service is more effective in certain circumstances, like are the impacts different with different populations or something like that.
That's adding real value to your project, potentially a quite low-time investment. Once you've got to the point that your experts are consistently saying what if, you know you're really making the most out of their knowledge, skills and experience. I think crucially you need to set the groundwork for what ifs before you actually start doing the work.
That's why I wanted to share this tip in the onboarding stage. I really like that groundwork that you do at the beginning because I think it's also important to cement the agreed ways of working. Once you've done all that groundwork, then you can put them in writing almost like creating a project rulebook.
From my experience, it's also helpful to create a RACI matrix at the beginning so your experts really understand their role and understand your role and other people in your team's role. It doesn't have to be super formal. I use collaboration tools like Miro or even a SharePoint document.
It's available in a visual way and can be reviewed at any time during the project. The last thing we want to do is to have done a good discussion and expectation setting that all that groundwork at the beginning, only to let it slip once we are really busy delivering the work. I absolutely love using Miro.
I highly recommend for working with experts but I don't know, what's a RACI? I don't actually know. It is a tool that we commonly use to identify roles and responsibilities for each project team, so that making it really clear who's responsible, accountable, supporting, consulted and informed for each task in a project. There we go.
We've all learnt something today. Sweet. Now we're going to hear from our experts about the delivery stage.
Over to them. I like it when my research partners provide clear feedback on my work quality and my working approach because that helps me adjust throughout the lifetime of the project rather than only getting the feedback right at the end. I like it when research partners are flexible around when I work because I'm often juggling multiple commitments and other priorities and so this makes sure that I can meaningfully contribute to the project within the time that I have available.
I wish that research partners would use regular check-in meetings more often rather than emails, because sometimes the volume and frequency of emails when working on a project can become overwhelming, especially if you're working on multiple projects at the same time. I like it when I'm given specific tasks by the project manager, including an estimate of how many hours they think it's going to take me, because this helps me both plan my upcoming week but also understand, based on the estimated hours, how in-depth they're expecting me to go for that particular task. In terms of the team, I like to check in with the team members fairly regularly, both individually and as a group because I think that's one of the best ways to build confidence and trust in people to do a good job and providing feedback but more so in encouraging that everybody understands what they need to do and has the freedom to do it.
What I wish for in a project is a data wonk. I like having good data to do my analysis with and if it's in the right form, then that means I waste less time putting the data into the right form. In a project, I think it's good to have a hierarchy of decision-making that avoids unnecessary re-litigation or even reversal of strategic decisions.
I make certain key big strategic decisions early and then stick to them through the project. Where projects come unstuck is often when there hasn't been clarity at the beginning about what is the objective of the project, who are we doing this for, what is a sign of success. Those things are the big strategic things.
You want to do those decisions early and then the other things should fall out. What don't I like about running a project? A lack of respect of consultants' time, I think, is one of the things. I get paid by the output, not by the input.
The more time I spend wasting it on meetings is a bit annoying. What I don't like to see in debrief is the blame game. This is about learning from the project.
It's not about saying this is someone's fault. I guess on the other side of it is the self-promotion, like I was responsible for this kind of thing. Wasn't I fantastic? Again, I don't like it.
This, again, is about a team and getting the team to work better. While we were listening to our experts, our friendly neighbourhood marketing manager Adam sent through a couple of questions from the pre-registration. We've got one here from Anna.
Challenge. Trying to get the information we need from experts without having to go back and forth a significant number of times. For me, that is a real challenge, but it is also one that's reasonably easy to resolve.
The approach that I take is to pose quite specific questions that you want the expert to answer. I find that particularly helpful with quantitative analysis, for example, where I know what the decision-maker needs to make their decision. Putting that on paper and saying, we need to understand X and Y. Then they're much more likely to say, that's actually what we need to know here and respond directly to that.
We also had a similar question from Tracy, which is how do you avoid knowledge dumps? I think the way to overcome that is the same, really. Pose specific questions that you want them to answer. Then that's not to take away from the suggestion that I made earlier about creating a space for people to give what-ifs, but they're just two separate things, really.
Priscilla, did you have anything to add to those? Yes. I think I totally agree with what you said, Sean. I think always creating that time for you to really think about the questions in the beginning rather than just trying to do it on the fly.
Always create yourself time to really think about the specific questions. Yes. Probably involve the experts in that process of writing down the questions as well.
Have a conversation about them. This is what I think we need to get an answer to. Can whatever information you have access to or whatever knowledge you have, can that provide us an answer to this question? Are we even asking the right question? I think that's a really ... Those were very, very helpful questions.
Thank you, Anna and Tracy. Anyway, back to our regularly scheduled programming. For me, the key takeaway from our experts' comments is that it's worth investing time in having regular meetings, but keep them short and focused.
I'll come back to this and share some tips around that later on, because that's something that I think is just super effective. Also, Dave's comment around making big decisions early and sticking to them really demonstrates how important the stuff you do during the defining and onboarding phases is for delivery. Priscilla, what do you reckon? I'm really glad to hear that feedback loop is important.
Sometimes we don't really think about it, often thinking, who am I to give feedback to an expert's work? They're definitely keen to hear from us, especially if their work has aligned with other outputs, if there's any improvements or any changes that could be done. I know they would really like to hear from someone who's not living in the technical world. I also really love Dave's point about the input, because good outputs can only be achieved with good inputs.
Really thinking about the context, the why, the so what, as well as what documents and data that you share with them so that they can do a good work. I'd just add that collaborating with them to figure out what a good input looks like for them can just save everyone so much hassle, especially if your expert isn't the main contact point with whoever's holding the relevant data or whoever's posing the problem that needs to be solved. Again, we're going to go through some of the key challenges that we experience at this stage.
Priscilla, you can go first again. Yeah, sure. I find it can be a really big challenge to maintain focus, especially when I'm working with experts that are very likely to be juggling at a work.
Some experts may not be exposed to quite a narrow scope that sometimes we have, or naturally as an expert they may already have strong, fixed views about something. They may not be very experienced in working within defined deliverables or timeframes, and that is generally how we work. There is a fine balancing act between sticking to our brief and not shutting down any potential for additional benefits.
This is where it can be helpful to identify specific benefits a project expects to achieve at the beginning, and then continually checking the progress against it throughout the project and acknowledging the wins as you go. This helps maintain the focus on delivering against the brief, but not losing sight of opportunities to deliver wider benefits. Yeah, 100%.
Then coming back to Anna and Tracy's questions, I think that the thing about defining the outcomes or benefits that can be a really important way of not getting information dumped on or not needing to go back and forth a significant number of times if everyone's got those in mind the whole time. Cool. For me, a key challenge is maintaining an expert's interest and involvement in a project.
I said I'd come back to this, particularly where their contributions are quite limited or occur at specific points in time. The only solution I've found, having tried a lot of different solutions, is to get everyone to commit to meeting for 15 minutes at the start of every week. In these meetings, I follow the structure of what did we do last week, what do we need to do this week, and who's going to do it.
Take notes against that structure and circulate them immediately after every meeting. This sort of process ensures that your experts have the opportunity to ask those what-if questions because they're hearing, okay, what did we do, which involves what sort of information did we get last week, what did we do with the information. They're hearing what do we need to do next, which is one person's view on where are we going, what are we actually going to do with that information.
Then the bit around who's going to do it, that can help keep them to be accountable where if they say, yep, I can do this piece of analysis or something like that, report it, circulate it. Cool. Then also this approach of just meeting also addresses the issue that one of our experts identified about being bombarded with emails.
Before we go on, we have had another question from Jutta, sorry if I didn't pronounce your name correctly. What is a good way to ask for honest feedback from a client after a project? Be mindful of the client's time slash busy schedules. Yeah, so it's always, it can be tricky to ask for honest feedback, but also I guess the way that we usually frame it is we have that kind of ongoing improvement mindset, so we would like to really learn from the feedback.
It's not about blaming anyone or by talking about what didn't go well. It's not for that, so it's kind of like what can we do differently in the future? I find that asking that question really helps to kind of tease out that honest feedback. It really depends on the relationship with the client as well, because sometimes when you've been working with them quite a while, then you've kind of built that relationship.
It's a bit easier to ask that question at the end, but I think framing it in kind of a more positive way is really helpful to get the honest feedback from them. Yeah, yeah, yeah, I think that's a great point. Cool, so right, Priscilla? Yeah, and I just want to mention one thing that is often overlooked, is that we always need to translate the outputs from the experts because sometimes we think about, oh, what if the stuff that they're giving us is a bit too technical? But we always think in our mind that we need to translate it anyway, because we want to make sure that that resonates to our target audience, speaks in their language and aligns with other outputs that we're doing.
So we want to make sure that we do that correctly and have enough time built in the project to do so. So I always take the time to sit down one-on-one with the expert and creating a safe space for myself to get them to explain their technical stuff and ask any silly questions to them. I recently worked with an economist who developed a bespoke wellbeing index for a business case, and I spent quite a bit of time to really understand his thinking behind it, the assumptions in how it could be used or not be used.
And because that way when I'm presenting it to in front of senior leaders or decision makers or the client, I can explain all the technical stuff in plain language and answer their questions and get the outcomes we need. Yeah, I reckon that's super insightful, like the creating space to have those one-on-one conversations like that creates value for you as the person working with the expert, not just for your organisation as the person that the output is going to sort of benefit. So yeah, just sort of some personal motivation there to do that type of thing.
Cool. Cool. Now on your screen you will see 12 success factors to leveraging experts.
Feel free to use it as your cheat sheet whenever you need it and we're going to share our three picks. Yeah, sweet. So my top pick is investing and building strong relationships is absolutely a key to success.
We've already discussed some of the ways you can do that, so the one-on-one conversations that we were just talking about there, where you're open and curious and it's mutual curiosity, those goal setting exercises, we shared lots of tips around that. And a strong relationship is a massive help if things start to go wrong. And even if it's wrong out of your control, like I've had experiences where someone has told me if we didn't invest all that time up front, we wouldn't have been able to overcome the challenge that we've arrived at.
And that strong relationship also means that you're actually able to collaborate with your experts rather than just sort of delegate tasks. And then in my view, that leads nicely to the next success factor, which is valuing the expert's wider expertise. So for me, I always want to get to a point where my experts are applying all of their experience, not just sort of what we've contracted them for to solving the issues that we're working on.
Yeah, not just making those task-based contributions. Yeah, I definitely agree. And I actually had a recent example that relate to that.
So I was finalising recommendations for a piece of work and I got the expert to sense-check them and found out that one of the recommendations has been trialled unsuccessfully in a similar setting. So that kind of wider knowledge from someone who has their ears within the broader sector was so valuable and kind of highlight the importance of not just limiting yourself to a narrow scope of the work. And lastly, my top pick is don't forget to celebrate the small wins and share reflections during the project.
So not just wait until the end, because that allows us to be agile and flexible so we can change our approach when things are not working as they should, and you're not scrambling at the last minute to trying to go back to the right course. Yeah, awesome. So we have had another question come through from Stephen.
The experts we work with volunteer their time, so it does become a bit harder to get them to respond within timeframes. Any tips? I guess the first thing is that that's not unique to people that are volunteering their time, but I can see how it does make it a little bit harder to potentially get them to respond within timeframes, and I think really if they are volunteering, then you need to account for that in the way you're designing your timeframes and communicate with them really clearly what sort of dependencies follow on from what you're asking them to do, so that they can say if I don't respond then, then that messes up this person's work, which messes up this person's work, and I imagine if it's voluntary, the outcomes that you're trying to seek are things that benefit a wider community or something like that, so linking what they do to that chain of things that lead to the community benefit I think would be really important. Do you have anything to add? Yeah, I think just kind of like because someone is volunteering their time, I would think that they will relate to the why a lot to the thing that you're doing, so kind of like speaking a bit more to the whys, why we're doing this and what kind of impact like you just mentioned, then it will help to kind of move them along.
Yeah. Cool, alright, so before we move to the sort of more questions, here's how we, meaning Priscilla and I, and Alan and Clark, can help you take the next step. So if you're considering how to implement some of the strategies that we've just discussed in your next project, if you're going to be working with SMEs, if you've already got SMEs that are in your team, Priscilla and I are available for focused discussions.
We'll explore what's possible in your specific context and help you navigate potential challenges. So you can click the button to arrange a brief conversation. I'm informed, completely free to have that conversation, so both of us would really enjoy actually talking to some of you about what your challenges are and how we think you could overcome them.
Alan and Clark also offer free strategy workshops for teams wanting to tackle specific challenges or generate fresh approaches. No strings attached, just practical problem solving with experienced practitioners. So you can go onto our website for details.
Cool, so now we're going to move on to answering some of the questions that people sent through in the registration, but please, I'm still getting the live questions, so please feel free to keep sending those through. Alright, so Priscilla, we've got a question here. How do you get the best out of experts slash SMEs when it's time pressured? Yeah, so I think we talked a little bit about the being really clear on time frame, so a talk about what is needed by when and by what time, and the trick that always works for me is to share the impact of not getting it done on time.
So for example, if something is not done, then one of our team can't really progress with something, or they need to stop their work, or we won't make it to the Ministry of Briefing, and that would be a disaster. So that normally kind of like gets to people and was like, oh, okay, I really need to do this. So, yeah.
Cool, and then another question that came through is commissioning advice that is technically robust, but also written in a way that is concise and accessible to lay audiences. Yes, so this is really a good question, because it is an art, and at Allen & Clark we normally get someone who hasn't been part of the project to sense check and then get them to play back to you what is their understanding of what you're trying to convey, and I sometimes use kind of like a persona as well. What does it look like for a university student reading this, or what does it look like for a general public, or for a minister that has got a lot of portfolios? And I always watch out for long sentences, because that's when sometimes people get like, oh, what message are you trying to say? And I normally speak them out loud, and if I'm out of breath, then they are too long, so make it shorter.
Yeah, and I think the thing about using a persona, I believe it was Dave in one of his answers sort of mentioned thinking about who your audience is, so it just shows that what you're doing right at the start of the project, set that groundwork well, by the time you get to the point they're actually reviewing deliverables you're thinking, okay, does this fit the need of my audience right through the project? Alright, so another question here, how do you get your experts to answer the phone, and or commit to helping, and how do you get good feedback, i.e. not oh yeah, looks all good? Yeah, so I think it's setting expectations at the beginning including modes of communication, so I'm not good with phones, and I'm one of those ones so it's really important to kind of talk at the beginning what kind of communication method you like, so it could be phone, it could be text, it could be an email, so ask them, and stick to it throughout, because when they're still not answering you can say, hey you actually really like to be called but you haven't been answering my phone, how can we manage that? So and I think to make sure that we get good feedback from experts, asking specific questions rather than just asking, hey can you give me feedback? Because that will help them create a good feedback for you so for example, asking is this the right level of detail for you, or does this align with your thinking, or what you've seen up there or does it align with a specific goal in your programme? So ask those really specific questions for them. Yeah, yeah, and on the feedback point I definitely agree and what I find quite helpful is sort of giving them plenty of warning in advance of what type of feedback you're going to be asking for, so say you know you're going to be sending them an evaluation report a month before you even send the report, say hey I'm really going to want your view on this, on a section about this, and a section about this and the reason why I want your view on these sections is to make sure that this is actually going to work in practise for example, and then that means that that's ticking away in the back of their head for free for about a month before they actually get to it. Cool, so another question, how to effectively lead a team of SMEs as a generalist? Brackets, if I am not an SME.
Yeah, so this is something that we encounter quite a bit, and I always say up front that I'm not an SME, and I normally ask for kind of like a one-on-one document so that I can read to have enough background to have a good discussion with them but also saying clearly what my role is, so for example I'm the project manager here, I don't have all the kind of like expertise, that's why we have you here, and my role is kind of like be the glue for the team, so it makes them think that oh yeah, okay these people are not experts, so maybe I can change the way that I talk about something so it's not too technical, and also I think it's just putting in your mind that remember that you always know something that others don't, even your experts probably don't know, so it can be you have a lot more context, you know what your audience is like, what they like to see, what format, or you just know your audience, and you just share them, and remember to do so throughout the project, because I think going back to what we talked about before, creating that safe space is important. Yep, yep, 100% agree. Cool, so I'll take turns and I'll ask some questions that you have pre sent to us, so getting assistance or information from SMEs when they see their work as more important than ours, how do we manage that? Yes, I think there are two ways that you can approach this, either think about how you can pose your work as a problem that they'll find so interesting that they'll reprioritise all their stuff to try and answer the problem, or demonstrate how your work will contribute to what they're working on.
That's awesome, yeah, so the next question I've got is we have a generalist working with lots of SMEs, and wanting to learn more on how to draw the best out of SMEs, and not get myself stuck down knowledge gap rabbit holes. Yeah, I think this is such a good question, so for me it's to be comfortable with not fully understanding what experts are doing or why, sometimes for quite long periods of time, but take every opportunity to ask them sort of targeted questions that are relevant to stuff they're doing, and it can be really uncomfortable to just feel like I have no idea what this person is doing, especially when you're responsible for this sort of delivering the work, but you'll eventually learn by osmosis if you build a good relationship. Such a good tip.
Now the next question we have is we have a range of specialities in our team, keen to know how to best share expertise to grow capability of team members in other areas. Yeah, so kind of links back to the answer that I gave previously, again, really great question, and to me it's just not to be afraid of spending time and money by having people join discussions who don't strictly need to be there, so that's really about providing your wider team opportunities for everyone to learn by osmosis, so if you're going to have a discussion with an SME about some super technical thing that you don't really understand, invite someone else from your team to just come in and sit in and contribute or just listen to that discussion. That I think is the best way of going about that.
Yeah, I can totally relate to that because the shadowing thing, I think I've learnt so much from that, and also not being on the spot, because you're there to kind of shadow other people, so yeah, that's a good one. Cool, so that's probably a good place to wrap up. Thank you so much for staying on and for all your thoughtful questions.
This is the kind of discussion that makes these sessions valuable for everyone. For those who are joining the team for Efficiency Unleashed, we hope that you enjoy the session. And remember, if any of today's discussion has sparked ideas for your own work, Priscilla and I are always happy to continue the conversation, like genuinely happy to do that, so please do reach out.
Yeah, thanks again for joining us. We really appreciate it. Have a great rest of your day, everyone.
Ka kite. We look forward to hearing your stories or questions about how you've used these tips and tricks in your work.
