Utilizing “Process” as a Crutch instead of CommunicationApril 2, 2020
As an agency based on reality and output of realistic outputs, we dive deep into the inner workings of projects, the minds that run them and the goals that are looking to be achieved. Going through this process has allowed us to find that many times information is gathered that automatically misaligns with the intended driver. One of these such “crutches” is the reliance on process to drive business decisions.
Why is it so important? It is important because clients and businesses that focus too heavily on a single process to provide insight into timing, value and progression are putting trust in something that is surely to lead astray. This is because while process is useful, focusing too heavily on what is being done, how it is being done and what timelines that structure outputs is too myopic for the ever evolving world of business operations.
Below we jump into the topic of how this is being used as a crutch and ways to think a bit differently about process in order to arrive at a successful project output.
Tony: Do you feel that clients or businesses, organizations, I should say, sometimes utilize the idea of process and having that process up front as a crutch for actually needing to communicate during the project? I can expand if it’s not making too much sense.
Austeja: I think I know where you’re going, but I just want to, I want to hear some more about it before I form an opinion.
Tony: I feel like, a lot of times, we’re asked for, “What’s your process? How do you get this done? What does this look like? How long does it take?” When in actuality, it’s less about what that’s going to take in isolation, in silo, but the client is relying on it to help make decisions and gauge resources, and almost this faulty idea that that is the process. It’s close to the process, but I feel it’s used as maybe an excuse for digging down deeper and actually communicating. And I just say that because I know what one of the things you really strive and are good at working with is, actually communicating with clients, with internal team members, with getting that going. Because, you know, you’ve said it in different ways, probably much more eloquently that I’m about to say, but it’s communication, what runs the projects. It’s how well we can communicate and learn how to communicate to each other. And I’m just asking, do you feel that there’s this facade around, “Well hello, LLT, what’s your process? Oh good, that’s going to solve it.”
Austeja: “Is there a process for that?” It can be a copout. Right? So, rules are good. In theory, it’s nice to have a structure. It’s good to have some sort of framework that we’re working with. But the framework isn’t the end-all, be-all. Right? So you’re still needing to communicate the points. You’re still needing to make sure that the client has heard and the project manager or the team in general on the account is able to translate the information to the client in a way that they can receive it. And it largely differs from team to team, client to client. PM to PM and so on. So the best thing we can do for each project is to make sure that in the beginning, we get a clear understanding of what kind of communication style the client has. Then match the accounting to that, right? And then from there, continue to evolve, right? I use that word a lot lately. But it is, it’s an evolution. So in the beginning, I might get it completely wrong, and communicate to you in a way that doesn’t clarify it to you. But with enough instances of that, we’ll get to the point where we’re being really efficient in what we’re saying to each other, and that’s the goal of every project. It really, every project, any project that’s ever gone haywire, it’s mostly because the client feels like they’ve either reached a lack of transparency on something, or they’re not being heard. But at the end of the day, when we’re talking to each other, all we want to know is that, hey, do you get what I’m saying? Yes. No. And then, from there, what do we do about it?