How To Optimize Your Process With Workflow Management (with Marc Boscher from Unito)

Read The Transcript:

Ben Aston: So do waste a ton of time trying to find the information you need? I’m sure you do. And what’s more, as someone who is managing other people, seeing your team try and spend hours trying to find information is incredibly painful. So the reality is, though, there’s not a one size fits all workflow management system. Whilst your UX and strategy team might like using Trello or Asana when it comes to your developers, well, invariably they’re going to want to use JIRA. So how do you manage this madness? How do you decide who wins? Well, there was actually a McKinsey report that noted that actually, most employees spend about eight hours a week just trying to find information.

So the good news is there is a way to fix this problem and that fix is a workflow management system. So if you’re interested in saving yourself time, saving your team time and budget, keep listening to today’s podcast. When we’re going to talk about creating and optimizing a workflow management system, thanks for tuning in. My name is Ben Aston. I’m a digital project manager and founder of thedigitalprojectmanager.com. We’re on a mission to help digital project managers deliver better to help people who manage projects in a digital world succeed.

So if you want to get connected with our tribe, go to the digital project manager dot com and you’ll find there are plenty of resources where you can get skills, get confident, and start delivering better projects. So today I’m joined by Marc Boscher and Marc is a web developer turned product guy, and now he is the CEO and founder of Unito. And so, Marc, welcome to the podcast today.

Marc Boscher: Thanks for having me.

Ben Aston: So tell us a bit about this story. How do you go from being a web developer to a project manager to a product guy and then founding your own company? Tell us a bit about that evolution.

Marc Boscher: Well, it took some years, I guess but started in the Dotcom bubble, and things moving pretty fast. Been pulled in technology up to the product. And I’ve been doing basically products for 20 years. And when you’re in product, you get this really cool thing where you observe problems all the time and you keep on saying someone should solve this, someone should solve this, and you never really get to it. But I kept the list and basically, Unito came out of one of those problems that I observe all the time.

Ben Aston: And so in terms of I mean, you say you’ve been working product for 20 years as but Unito started as a relatively new product out there. So where did this kind of inspiration come from for developing specifically tackling that problem?

Marc Boscher: Well, product management and project management to an extent as well. You have to work with so many different teams and different groups and different skill sets, and you rarely have authority. You rarely have. You know, you’re not their bosses. You have to manage by influence. And that means you don’t get to decide what tools they’re going to use. And so you’re often at the receiving end of whatever mix of tools, each of the teams you have to work with have. And so kept on finding myself jumping around in between, you know, the Zendesk, the Asanas, the JIRAs, and the GitHub and all those tools and having to pay that price. And that’s one of those moments we.

Someone should solve this. And, you know, typically you solve this by forcing everyone the same tool. And the idea, as you know, API is evolved. It was, hey, can someone can we connect those tools together? Can we leave people in their tool and not have PMs waste all those times, all this time running around, just asking people if they’re done and where they’re at and then telling them, hey, this person’s late so this affects you here. And that’s really that for the idea grew as a typical scratch your own itch. And at some point, like it was always in the plans to start something you tried out and jump off the cliff and if it hits some traction. So we pursued it. And here we are today.

Ben Aston: Awesome. And so let me tell me a bit about your toolset that you integrate with it internally. So, I mean, I know you can connect project management tools and project management software like Trello and Asana and Asana and JIRA. But what’s your pick of tools that you tie together and how does that work?

Marc Boscher: I mean, personally, I’m a tool junkie, so I use pretty much all of them. And it’s really exciting when you discover some kind of design that fits with the way you think and is adapted to your role. You gain so much in terms of productivity, but often the real barriers convincing the others to switch that tool.

I think a lot of the barrier to the adoption technology these days, it’s less about technical, like installing the software, deploying it. It’s much more about getting people on it. So, you know, we have a dozen tools right now. We launched click up integration a couple of weeks ago. We’re launching another one next week and another one in three or four weeks or so. So we’re cranking out tools that certain the project work management space. So the Asana is the Wrike, the Trellos. And we also started with developer tools.

So the GitHub the BitBuckets to Gitlabs and the Jiras are really focusing on connecting PMs with technical teams or business users with technical teams that typically don’t speak the same language in the same tool language for sure. But we’ve added over the time, Zendesk, so supports systems, HubSpot on the sales and CRM side and Marketing side. So really, how do you start looking at work, not just something within a team, not just a processor, one team, but across the organization? And that that’s certainly is a much larger and more important problem where there’s a ton of time spent and wasted.

Ben Aston: Yeah. And say in terms of I mean, you said you’re a tools junkie. Are there any new tools that you have discovered or found recently that have got you excited and that you think every now should have?

Marc Boscher: I mean, all the tools we integrated are the best tools of the Market. But, you know, we’re we’d like to think that there is no one best tool for anyone. It really depends on what you’re trying to achieve, who you are, and the way you work.  And really, that’s a core belief. I don’t think I don’t recommend one over the other. It really depends. And that’s kind of the core thesis of the business, is that everyone’s got their tool, whatever makes them the most productive and super productive. And the challenge is that it’s never the same. So they’re their tools coming up every day. We tend to pick the ones that are the most popular up and coming in, growing. And of course, they need to have an API layer as well so that they can be integrated. But most of the tools today have that that component has the ecosystem view of the world.

Ben Aston: Cool. So, yeah, Marc has written a post which you can check out on thedigitalprojectmanager.com, and it’s called How to Build A With a Management System. And there are some examples there. But for those who haven’t read, can you kind of explain to us a bit more what you mean by work flight management? And I think, you know, as project managers, we understand what processes, you know, is how we get something from A to B, A being the start of our projects, B being the end of our projects and their steps along the way. That’s the process.

There are the steps we take to get our projects out the door. And the idea is. On that journey from A to B., we’re delivering value, creating value as we kind of make that journey. So help us understand what is a workflow management and where does it fit into that understanding and getting from A to B. While working within the constraints that we have on a project and said that we can create value at the end of that journey.

Marc Boscher: Yeah, I think it’s very similar to what we’re used to, to the same process. And people use workflows and process, often interchangeably. The way we like to think about as processes are fairly linear Step-By-Step sequencing and that’s how we think naturally. And when we plan projects, we often we’ll start with that: first you have to do this, and you have to do this, and then you have to do that. And then reality kicks in.

Right? Where once people start working, you discover things and you have to collaborate across a team and someone else needs to be involved in that very dynamic environment, especially today in digital work. It’s not as linear, it’s not as super-specific. And you have to give it’s a lot less predictable if you want. So when we think of the process, we like to think that there’s a software development process, there’s maybe a Marketing campaign management process or a product launch or launch process or a sales process. And each of those teams has to define and there’s lots of framework for that.

But once you start collaborating across those boundaries, there’s a lot less. It’s more about meetings. It’s more about Zoom calls. Now it’s more about chat and less about using the tools that allow us to manage that work and manage the execution delivery. So when we think of workflow management, we look at a layer that connects it all together across all those processes and crosses the T’s. That makes sense.

Ben Aston: Yeah. So if we said the Web management system takes into account like that, if this then that kind of scenario and I mean and I talked about practices being from how you get from A to B on a project. But the reality is that journey is not a straight line at all. It’s typically a series of loops and Segway ways going from one way to the other. And so we need some way of managing that, these things happening. We know that when maybe we present the UX to the clients, but also developing the style tiles.

And what happens when the UX gets approved? But the style tiles don’t get approved. How do we kind of loop? How do we keep the project moving forward and make sure the right people are connected and updated at the same time so that the development can start? That may be that the design iterations can’t proceed. So having a more complex and nuanced understanding can actually help us be more efficient in the way that we actually deliver projects because we didn’t. We no longer need to think of projects as this pure linear process, but it’s a series of small cycles that gradually become integrated with one another.

We’ve got these parallel work streams for UX design Dev QA. These things can begin to work and operate a bit more seamlessly and efficiently as we kind of linked them together a bit more tightly. Is that kind of the idea of workflow management?

Marc Boscher: Yeah, absolutely. It’s really taking a lot of the principles of agile that have told us, like, don’t try to control everything, just give people more freedom to collaborate together, remove obstacles to their collaboration, work in short cycles and in the tools today they’re getting in the way they’re getting the way again because everyone’s got a different one and everyone’s got a different process. So the first step to workflow management is going where the work happens— like accepting the fact that people are working in different places—and going there.

So integrating the tools where the work happens and the second step is really mapping out the workflow across this. So kind of shaping the flow. What are the rules? Are the guidelines as well? This is how Marketing works with self-development or when there is a feature, doesn’t need to involve the designers, and needs to involve the palms and the developers this way. Right. Without necessarily constraining them, but more like opening ways for them to collaborate from their tools without having to leave them.

So without having to run around for status updates. So a very simple example would be you’d have your project plan ina Gannt chart in a tool like Write or an Asana or some kind of timeline. And you’ve got one of those activities that are there has to be done by developers. Will that activity becomes automatically a Jitter issue, but it stays in sync with the Jitter issue so that the P.M. whatever happens as someone gets assigned to it or work starts it gets allocated to a sprint and work starts happening on and then it progresses through the development cycle, the PM knows to live what’s happening. That progress in their tool.

Marc Boscher: And they can see the dependencies with other departments or other teams or other activities without having to jump around wherever that work is happening. So start work recognizing where the work happens. Connected up together and then kind of define the rules, which is whenever something happens in this project, I want to see it in my project plan, for example, once to do that, then people have to lose their tools. All the information is accessible wherever you are. And suddenly it’s much richer and there’s less friction to collaboration. And that’s when you can start optimizing and improving.

Ben Aston: I mean, you talk about it. Yeah. Kind of an understanding that different teams are going to want to work in different tools. And I started with saying, hey, you know, it’s likely that your whole design is a new X team. Probably don’t want to work in Deira. I mean, because jurors can be very complex. And I think that the beauty of something like you need to have is that it enables people to work in whatever tool works best for them. And I think it’s an ongoing challenge with a tool rollout’s trying to. And everyone’s constantly, I think, really on the hunt for this kind of one tool to rule them all. That does everything in the way that they want to.

But the reality is each tool has a philosophy on, um, project management, on how projects should be managed and run. And depending on that philosophy, it makes it hard or easy for different teams within the organization to collaborate and work together in different ways. And, you know, I’ve had the experience of trying to design teams to work in JIRA, and it’s just a non-starter, really. It’s particularly like, yeah, when you build a complex workflow into JIRA.

So in terms of understanding, then kind of extracting that process and deciding how complex to make the workflow system. Talk us through that kind of workflow design process. How do you say, okay, we’re going from A to B? We know that you know, your UX and design is happening. Dev needs to begin. But how do you begin to put in the checks and balances and automate things without making this thing overly complex? And I think of one of my kind of pain points with JIRA is that you design and you design workflow and then you get stuck.

You know who you think, well, I want to move the cart here. It doesn’t need that step today or for whatever reason. So what I’m curious is when you’re building a workflow management system and you’re trying to automate some of these things so that, you know, when I create a and Trello, it automates it automatically creates that issue. How do you how complicated is too complicated and when do you start?

Marc Boscher: I think for us from the day from the first day, the goal was for business users to build to set it up. Right. For non-technical people. And that’s super key because you can’t go see if you want to connect two teams together. You can’t require technical skills or wait for a developer to set up that integration. So it’s all about visual design and being able to specify rules from in English if you want or in a natural language.

It says when this happens, make sure it ends up with the, you know, in the engineering side. But it also is all about mapping things was and it’s one process that may be much more detailed in the other. So, you know, in software development, you might have steps where, you know, you have QA and you have peer review and it’s going through staging. And there are all these individual steps that you might want to track in your software development process. If that team is organized that way.

But if you’re looking at it from them from a Marketing perspective and each one, the features ready to launch and how close is it to that? You don’t care about the level of granularity. So workflow management system to be able to say well, in Marketing. Here’s my process. Here’s my workflow or the steps. How do those map or map to those of engineering? And they don’t have to be one to one. Right. These, like 10 detailed steps of enduring could just be it’s under development for the Marketing team.

And it starts with a conversation of like, how do you work, how do we work and how do we bring those together? But it’s mostly then after giving the flexibility for the business users to set up that relationship and iterate over it. Now, you don’t have to figure it all one shot. You can start with some very simple rules. Whenever I assign it to Ben, it should show up in his tool, and or whenever I escalate a ticket to engineering from a support system, it should show up. And in this project, in Jira or whatnot. Right. There’s very simple. You can start in once you see that information flow and see how people are doing it. Then you can start really getting to the next level of sophistication and time-saving if you want.

Ben Aston: I mean, and I can see that what looks like a workflow behind you of some description. So like in terms of this, that conversation where you map how you’ll process it.

I mean, it looks like a process map behind you.

Marc Boscher: That’s actually kind of something that’s a relic from the past. That’s a customer journey mapped on a wall with leg posts and stuff. And this doesn’t exist anymore. It’s like wallpaper. It’s this. We’re all remote. It’s that.

Ben Aston: But in terms of, like, facilitating that conversation, where you were trying to bring together these different teams, SEO working in different tools, trying to understand who needs what, when and in what format. I mean, it’s kind of like developing a communications plan when we’re thinking about, OK, what do I need to tell you? In what format, when. I’m with what frequency is kind of thinking through that kind of conversation. But as you kind of building it out and facilitating that conversation, how do you do? Do you just design that straight into the tool or do you do try not whiteboard things out first and try to get this big picture understanding of what’s going on?

Marc Boscher: Well, we saw customers doing as they were. They would drawy it out. They would whiteboard. So we actually built a function right into the tool. So you can visually map out, whereas the work happened and then drive the flow of work, take basically shape that flow right. And shape how work should go from one team to another. In that discussion, you describing that’s the super Kiwi. We found that customers, they’re very good at their process in their team. They figured it out. There’s a ton of documentation out there for this stuff. But once we talk to them about collaborating across the boundaries of their team, that’s when they know nothing about whether other power, other people are working. And PMs know this firsthand because really they’re living at the boundaries and they’re crossing those boundaries all the time.

But instead of PMs spending their time translating and making that bridge and copying and pasting and repeating, what if the tools could just stop being an obstacle, and communication could flow directly and PMs could really do what they’re truly great at. And it’s just aligning people, keeping track of things of risks and de-risking things, and setting priorities without the grunt work of keeping everyone informed. That’s not where the value is. And that’s where we’re spending our time, unfortunately.

Ben Aston: Yeah. Yeah. I think so much of so much of budget management time can be making sure people know things that they should, they should know and making sure that people have read the ticket that landed in that box or that they’ve seen that something had been updated in Trello. And I think acknowledging the fact, everybody’s going to work differently and accommodating for that by saying, well, okay, if you want to end Trello, let’s get it in Trello. If you want this as a Jerrett issue, then let’s make that happen. So I think enabling and empowering people to work the way that suits them best is it is really the future.

But let’s talk about when it fails. What are the challenges of this system? Because in my mind, what the challenges are when you think the workflow becomes, you know, the solution to all your problems because you agreed on it. And, you know, we end up then with lots of things happening in lots of different places. But, you know, things still falling in between the cracks. So I’m guessing the challenges are a kind of blind reliance on the tools, but they have. What challenges have you seen with it with a workflow management system?

Marc Boscher: I mean, communication is always key arrives and that whether you have a system to help you integrate two teams or not. That doesn’t change. We found like once you remove like you make communication easier because then they can people can use their tools that you’re using every day to work to communicate and collaborate and update people that are not in their tool. That just becomes easier. Like that communication requirement just becomes easier. Think about it as an orchestra.

Right. You’ve got multiple musicians. They each have their own, you know, instrument or tool. The violins are in Trello in and the piano as it is in Jira or whatnot. Right. And there’s someone or some conductor. Typically the p.m. trying to keep them all in sync and orchestrated. But you’re not going to enforce them all switched to violins. All right. That’s their strength. The fact that they each have their own thing. And as a conductor, you’re not also trying to keep them perfect.

You’ve got limited tools. Right. You’ve got your boots on and you’re just trying to guide them through this process. But they’re each independent and they each have to get there on their own and they each have their way to play the instrument together. So I think, you know, modern digital project management is very close to this. And you’re conducting. Right. And you’re just guiding this group. That is all autonomous. And I’ve also learned to play their instrument their way and learn to really perform with an instrument.

And it’s more like bring them all together and keeping them in harmony. And the first thing is just can they all see the conductor and can they’ll see each other. And today, everybody’s in their little box. And in this remote world, it’s even worse. Right. It’s like suddenly the orchestra split out across the world and there’s lag and they’re like, you know, there are time differences and time zones and made it so much harder to stay in harmony. So you can imagine that workflow management solution as that as orchestrating all those people without having to change the way they work across the time zones. Across the tools.

Ben Aston: Yeah. And so how do you see this evolving? I’m kind of light when you look at the future of work, the future of projects that the future. You detail your tool. How do you see this evolving and how do you see the role of the project manager changes in that?

Marc Boscher: Well, hopefully, they spend less time with just grunt work and more time conducting. Right. And I think that we have a thesis that this trend towards more and more tools is just going to continue because it’s just so cheap to build software, so easy to distribute. And for people to adopt it, that it’s just going to continue. So we believe that you have to go where people work, where the work is, and embrace this reality instead of fighting it. And once you’ve let people and teams self organize, you still have to align them and keep in sync.

And I think once you’ve got a workflow management layer that that connects that that glue, suddenly you have a lot more visibility into what’s happening. And I think that’s the way it used. And you started the introduction saying that fight, who wins, right? Who wins. And like that implies that someone has to lose. Like someone has to jump on the other tool. I mean, we believe in a future where people don’t necessarily have to lose, and the tools all kind of worked seamlessly together. And we hope to be that platform or we believe that workflow management is the platform that was going to enable this.

Ben Aston: Awesome. So if I’m new to thinking about in a process at all workflow management at all, because I know there’s lots of agencies, studios out there, there are five to 10 person shop that just hustling to get stuff out the door. The CEOs, the business developer, he’s also the project manager in that kind of super-fast, loose Wild West of the digital world. Where do you start with, I guess, process design and then workflow optimization? What for someone who’s thinking, man, I didn’t even know I did. I didn’t even realize we kind of had a process.

We just do the work. Talk us through just what your first steps are in kind of understanding and designing the optimal process. How do you get to that point where you can even begin to automate things? Because I think that’s there’s some work that has to happen before we kind of get to that point of making, you know, keeping everyone on the site, getting everyone on the same page. Keeping them on the same page. How do we work that first step to kind of process design?

Marc Boscher: There’s always low hanging fruit in the bar. The barrier to entry is much lower than we expected. It’s not that complex, as you describe some agencies and studios. Every customer they have their own way to get organized. And often when it’s a smaller agency, they have to adapt to whatever the customer has. And that means that you have a ton of time to relearn whatever tool the customer is imposing on you. You have to adapt to their process. So next time projects show up.

Start with one project and then what’s that customer using? What’s your ideal tool? Where if you could use that same tool, then you can start, you know, repeat it. Having a process internally, if you could only just stick to one to one tool for delivering your agency’s projects next time you have a customer, the different tool trials on the workflow so that they try integration. Right. Take that approach. What if you could peer those two tools together? It’s so much less disruptive and there’s a very low barrier to entry to try these things.

It’s not that you can try one project, and that’s kind of the beauty about, look, going where the work happens is you don’t it’s not a rip and replace. It’s not doesn’t take a lot of upfront work. You can do it with one small team in your company. You could do with one project. You can do with one kind of workflow. It’s could be how do we get Marketing to make a request to change from engineering on the Web site? Just that one. How much time are you spending on it or support escalating a ticket to engineering? Start with that. You know that where you’re spending your time and you can just iterate from there. Yeah. Yeah.

Ben Aston: I think that a more agile mindset builds tests and learns. For example when we’re thinking about designing and optimizing the process. But the reality is, is we don’t get it right the first time. But finding low hanging fruit, finding opportunities to build process where it doesn’t exist. And a great way to do that is by looking at lessons learned from you from your last project. Where did it go wrong? Where did things fall apart? Why? Why was it that design that started two weeks later, the shed? Why was it the development started too early?

I’m beginning to identify from those lessons learned that can be a great place to begin to design some process. And then we build, we build the process, we map out, we test it, and then it’s right on it. We learn what was what, what doesn’t work. So that can be a great first step to designing, optimizing our process. But, Marc, thank you so much for joining us today. It’s been great having you with us.

Marc Boscher: Thank you, Ben.

Ben Aston: And if you want to learn more and get ahead in your project management process design, head to thedigitalprojectmanager.com. Well, you can find a whole ton of great resources that we have for you. You’ll find our membership now online training. But until next time. Thanks for listening.