De-Risking Projects with Design

Thanks, Andy, for joining me today as we start to talk about de-risking your projects with design.

Yeah, happy Tuesday.

Yeah, it's like you're holding up well in quarantine and coming up with some great new content for our design services. Why don't you tell us a little bit about yourself and what de-risking design really means?

Sure. I'm Andy. I've been at BP3 I think almost four years now. I've worked in design for about 12, I think 15 years now. I can never remember. I can never keep it straight at this point. And then, specializing in user experience for the last four years. Any questions before we start?

Well, why don't we go ahead and get started.

All right, cool. I wanted to talk about de-risking projects and I think, in order to talk about that, first we have to talk about, well, what causes project risk? BP3 has a long history of helping clients develop solutions to enact some kind of progressive change within their business.

We've worked on solutions that range a whole bunch of industries like healthcare, insurance, banking, energy, cruise, pharma. We've just been all over the place. And now each of those industries requires a unique solution to be sure, but the blockers that we see... And sorry, there are a lot of blockers that we see from clients of all sorts and they span industries.

And that's because those blockers aren't specific to any one industry, but inherent in the way you typically get work done. Those take the form of what you see here, lack of stakeholder alignment and buy-in, unrealistic and unarticulated goals, incomplete and incorrect requirements, incorrect is the big one. And then, poor communication between stakeholders, IT and users.

And so, what that leads to, if you visualize it, might look something like this. And this is an image I took from Tim Brown, Change by Design, which is a great book. You should read it. And these barriers cause this misalignment that lead to solutions that basically don't need business [inaudible 00:02:32]. They solutions end up not improving outcomes for your users. Sometimes those users are your customers, and sometimes those are internal. And worse, sometimes the solutions just aren't feasible at all because of this misalignment.

So, what you end up with are blockers that compound the risk. And so, the risks are increasing costs and lengthening of time that it takes for you to realize the value you want from the right solution. And you can see that in the number of projects that are abandoned. You can see that in the amount of rework that is generated. And all of that halts innovation. And it basically maintains the status quo for the way you operate your business, ultimately making it harder for you to respond to market change.

What you really want, what everybody on your team is looking for, is good outcomes. Really, at the core of it, you know everybody wants that. Everybody at least wants a good outcome, but the starting place for that outcome typically might be different. Design strategies, design process helps you overcome the common risk factors to project failure through a structured approach. The design process brings everyone together. So, the stakeholders, the developers, IT.

The stakeholders might be from a multidisciplinary team, including marketing or accounting or the C-level. There's a lot of people that could be involved there, all of which have different goals. When you bring all those people together, you're working from the collective wisdom and intelligence of your team. Design process helps you build trust internally, overcome organizational politics.

One big one that we see is the loudest voice in the room syndrome where there's this one person who really can overpower a room in a traditional meeting discussion structure. And we don't want that. We want everybody be heard equally. So, getting everybody on the same page and working towards the same goal and being able to facilitate that.

Design process helps you surface the right data so you can make informed decisions rather than basing decisions on the strong opinion of a few people. We want to work based off fact. And also allows you to test ideas iteratively so you can course-correct before committing time and resources. So, before you go and you hire the developers and you throw something through the development cycle, you already know that your idea is going to work or it's not.

And when you have that alignment from business stakeholders, users, developers, you get solutions that make your business and your users successful, they help you further business goals and lead to business success. They help your users get their job done, they lower training costs with fewer errors, which basically leads to efficiency of your workforce and a more confident workforce. And you get adopted solutions faster. I think adopted solution is really the key phrase there. You get an adopted solution faster but at a lower cost because there's less rework for development b…