10 Tips for Managing Large, Enterprise Mobility Projects

INTRO  00:07
Welcome to the enterprise mobility roundup podcast. Brought to you by blue Fletch. We discuss technology topics related to Android and workforce devices, and how they intersect with business and mobility.

Brett Cooper  00:20
Hello, and welcome again to another episode of The Blue Fletch Enterprise Mobility roundup podcast. This week, we’re joined a Richard and I are joined by Lita Hines, who’s one of the principals here at Blue Fletch. And we had a recent conversation where we were talking through large projects of big, big enterprise projects. And when I think about that, it’s typically three or more months of building something big that’s gonna go out in the enterprise. And Lee, and myself and Richard are talking through some of the things we’ve learned in the last 20 years of doing all these big projects, and really came up with a list of 10 definitive pro tips or big lessons learned that we think are really important if you’re running big, big projects. So, Lee, thanks for joining us today. Thanks for having me. This is gonna be fun. Awesome. So the three of us have mentioned in the last 20 years have probably been on, I guess, over 100 of these large enterprise projects between us. And yeah, we’ve had a lot of lot of really successful ones. And we’ve also probably been on our share of projects that are that were on the losing end of the the big project successful scale. But um, you know, I think for, for me, there’s always like, red flags we see now. And, Richard, you’re the best economists out there, like, remember that project? And I’m like, Yes, I remember that. But uh, I think you know, for today, we want to talk through just some of those lessons learned and it’d be some negative ones and some positive ones. But in general, these are things that as you’re thinking about large projects, really to use them as as a barometer is no, there’s no one size fits all.  But and I guess to get started leave for for lesson one, we call this you can’t agile skyscraper. So tell me more about that. 

Lee  01:57
That’s right. So a lot of big enterprises and corporations now are tending towards more of this agile development, because it’s very in vogue in the software development world, which, for those of you aren’t familiar, agile typically means you have a development team that’s running in what we call sprints have anywhere from one week to two weeks to even up to a month, I’d say two weeks are probably the most common sprints. But what happens is, corporations have started to just go to Agile projects, and not actually do the planning on the front end. So the you can’t agile the skyscraper example would be if a bunch of people showed up at a construction site, and had a pile of iron next to them, and then just started working two weeks at a time to build a building, it’s not going to turn out very well, you need to have a set of blueprints to work from from the beginning. And so that means it’s okay to start off with waterfall. We often recall that like a requirements and design section of the sprint, so that URL of the project so that you can actually have an understanding of what you’re trying to build. At the end of the project, what your outcome is going to look like what you want it to look like. So that way you don’t end up just spending a lot of money burning through sprints, and not necessarily making progress.

Brett Cooper  03:15
Richard, any any thoughts come to mind for projects or where this hasn’t worked? You haven’t seen? I’ve seen people not do this?

Lee  03:21
Yeah, I think Lee was calling that out a bit where if you don’t have that plan up front, you could almost be that hamster on the wheel. So instead of progressing from A, B, C, D to get down the alphabet, you’re just bouncing on bee bee bee bee. And, you know, in a few months leadership comes in and says, you know, let me see what you guys have worked on and say this is what we have, you don’t have more. But when you do have the blueprint, you do that work up front, it’s okay to change. And, you know, once you get into that agile environment and you have a roadmap once you have defined goals and a shared vision, it’s okay to change along the way because you’re marching you’re moving in the same direction. So I think that’s the thing to keep in mind.

Brett Cooper  04:13
Got an awesome in. So lead number two lesson we talked about or jotted down was build a process for learning what what does that what does that mean? Like? What are the three key things that along the way in a big project you’re learning? I think this kind of falls along Richards point of changing, but what are the lessons you’ve learned along the way there?

Lee  04:32
Sure. I think it was several years ago, Brett, you and I were having a conversation and it was around the time the Move fast and break things. phrase was out there in the world and we decided maybe move fast and learn things was a little bit more gentle and less destructive for us. And so what we what we often try to do with customers is if they have a project that they want to watch work on with us, we try to focus on the core of the issue that they’re trying to solve, and then figure out a way to get to that answer as quickly as possible. So oftentimes, we’ll do things like a proof of concept, then moved to a pilot. And then from that pilot, once we learn things in the initial rollout, we’ll then go back, work a little bit more, and then go to a broader rollout. Multiple releases are super helpful, so that you can learn things. If you figure out very quickly something’s working or not working, you can do more or less of that thing. And also soft launches are helpful, meaning don’t try to go out everywhere at once go to one store, or one location or something like that.

Brett Cooper  05:45
He would give an example. This is a funny one of not doing a soft launch was a big restaurant chain we were working with do not sure who will say the name will protect the innocent. But yeah,

Lee  05:55
we had we’ve been doing bug testing on an application in in April of particular calendar year. And as soon as we had a bug free day of testing, the customer told us that Cinco Demayo, and this was a Mexican restaurant chain was going to be the launch day. So there was no soft launch whatsoever. And they just went out and went crazy on Cinco de mio with the application and just hammered it. And it was it was kind of a nightmare.

Brett Cooper  06:20
Ship it. Man, that’s terrible.

Lee  06:24
Like we got it to work once. And then that was it was good enough. Yeah. Richard,

Brett Cooper  06:29
for you any other pro tips on learning or building processes or learning, especially on the on the dev side

Lee  06:34
yet, so I feel like I’ve made my career on that early learning side. So doing proof of concepts, having conceptual vision getting out in front of the customer. But you know, don’t be afraid to release and get feedback, good or bad. We have a client here in Atlanta that we work with, we love them, we work really great with their team. But they, we have to really almost push them off the cliff to release hardware or to get people into the building to see it because they want to wait until it’s absolutely perfect. And a lot of that comes from a history of it, not delivering for the organization. So they don’t want to mess up. They don’t want to go back to this bad theme that they had across the organization. And we leave meeting sweating like it feels like a workout to get them to say like, it’s okay to have a soft lunch. It’s okay. If we missed the boat a little bit, at least we know, instead of, you know, waiting weeks or months before you release something thinking that it’s absolutely perfect. And the risk there too is if you wait and wait and iterate without getting feedback, you can get farther and farther away intended goal.

Brett Cooper  07:51
Yep. Yeah, that Lee, that takes us into a think number three a good segue into that, which is no nice stakeholders. When you when you think about stakeholders, and who is important in that, that chain of you think, Richard, you mentioned executives up here, and then end users down here, who else is involved in that, and what’s what’s important there?

Lee  08:12
Sure. So depending on the size of the organization, your stakeholders can be multiple can be a multitude and varied. You’ve got the security team, you’ve got finance, there’s operations. There’s also the IT team on the other side of the fence who can be sometimes your partners in programming or the gatekeeper as far as what sort of technologies you’re supposed to be choosing or using. So really getting in at the beginning of the project, understanding who the decision makers are, who can come in and at a certain point and change the direction of the project. And then also truly understanding what the end user needs and how to balance all of that. So it’s, it’s a nuanced dance, for sure. But the more you know about who you’re dealing with, and what’s motivating that particular constituent group is going to make a huge difference down the road. So it helps at the beginning of a project to ask, is there anyone here or not here that can come in at any point and change the direction of the way this project is going to go?

Brett Cooper  09:14
That guy, the seagull guy with a guy who flies in and craps or makes a lot of noise graphs and everything leaves? Richard on the on the stakeholders for actual users. And you touched on this in the last point but when you think about end users and finding pilot groups or POC users, what’s the big lessons you’ve learned there around you know going and finding a site or store or warehouse to engage with users how do you how do you have that process not go sideways?

Lee  09:39
Yeah, so I think Lee painted a really good picture but it’s kind of know your end users and know what you can get away with. You know, most of your organization’s you have a user or group of users that will try anything will give you feedback. They’re okay. Failing, they just like to contribute. They like to try new things, they should be your pilot group, they should be that group you go to first, then when you spread out, you know, there’s probably a larger store or site or location. That’s okay, trying new things like they get it, you probably have a manager there, they can run a team. And it can help facilitate, especially if you’re releasing on Cinco de mio, they might be able to know how that store could run, you know, sands technology, if you have to shut it down, you know, for that day. But then you also may have to come up with a plan. I know, we’ve ran into that with one of the big retailers who worked here in Atlanta, where there’s a store right across the street from headquarters. And you know, you can lean on the store pretty heavily, but sometimes you gotta mix it up. So we had to go across the city, to go to different stores to make sure we’re not wearing out that team. And they can actually get work done from day to day.

Brett Cooper  10:54
Yeah, I also like finding the the vocal doubter is, is a good guy to have in your pilot store. So find, I call it Carl and receiving, Carl, you know, you’re out there. But yeah, the guy that if you can win him over, he becomes and he doesn’t want to do it. But he becomes an advocate for the project long term and really helps you. You know, from an end user standpoint, I feel like a lot of times, there’s people who are in the stores or in warehouses that are overlooked by the executive team. And they, yeah, they complain, but they their feedback is valuable. They’ve been doing the job for 20 years. And like you said, they know how to run it without the technology. Yeah. And you know, your job is really to make their job better.

Lee  11:32
Yeah, there’s a change management thing. Usually Carl is a high performer has done things his or her way, and has their routine down to a tee and I don’t need you messing with, there’s a Quadrant for Carl, where he lives, for sure.

Brett Cooper  11:49
At least elite ever five was was, you know, ask, you know, or understand the value or ROI, or the I think we call it like the business case analysis for the for the projects and don’t know what that is? And what are the lessons you’ve seen around that? Or what are the pro tips you have there? Sure, a lot of

Lee  12:07
times we’ll talk to organizations where they have us come in and want us to do something for them. But maybe haven’t thought through a lot of the specifics. And you find this out when you start asking follow up questions around. Why are you doing this project? What is your end goal? Well, how do you think this is going to help your company overall, and sometimes you’re met with just sort of silence or a blank stare. And so it helps to an extent that doesn’t mean the project shouldn’t go on. But it’s part of our job to help someone understand the value of what they’re going to be hiring us to do, and how it can make a difference for the company. The lot of times, you’ll see people fall victim to fads where, you know, you’ve got machine learning with AR and craziness that you can do where maybe your website doesn’t even work. So, you know, don’t put VR on your website if the main app doesn’t work. Yeah, like start with the basics.

Brett Cooper  13:05
Yeah, like does my my favorite was the fad technology like, oh, somebody else was doing this, we need to do it. And then we we looked at it, and I think they got was less than 1000 downloads from the App Store. And they’d spent, you know, hundreds of 1000s dollars on an app and they didn’t have the feature I really love on a lot of retail websites is you might also like, like when I buy something, or when looking at something, give me 10 options for stuff that I might also want to buy just makes it so easy for me to buy more stuff. And yet I want to spend my money with you. And instead, people are looking at Crazy technology and really trying to push the envelope and they should be really thinking about what their users want to do. Rich rarely is anything for you. You’ve seen where people put fads over value or really think about they’re not, they’re not thinking about the ROI for their customers, their employees, as opposed to thinking about doing something flashy and neat.

Lee  13:57
Usually, I see that when that fat fat is taught to that individual at the organization, executive, they’re looking to make it, it could be an executive, it could be a manager, director, developer, but they’re trying to make a name for themselves. They’re trying to do something that pushes the envelope that’s outside the box, because if it works, it’s going to help them potentially get a promotion or get a larger project or more responsibility that they’re gunning for. So if they don’t feel like they can be taught off the ledge and they’re just really pushing for that. It’s usually a personal motive behind that that you need to uncover. Like if this is going to be the best thing if it works, but it’s the stupidest thing if it doesn’t work.

Brett Cooper  14:40
Sounds like a Simpsons episode. You stupid not to do this. Not not liking toads. Lesson Six was invest in tools that allow you to measure the before and after and this sort of align to that value one from before. That obviously you want to talk about some of the tools and how you’ve seen people use as tools to actually understand the value drivers and the impact.

Lee  15:04
Sure. So I think some of the examples that we want to talk about here we’ve seen that have worked is someone will look at, let’s say it’s varying stores and how they perform, and how their associates perform in the field from a sales perspective. And then if they did with us a pilot, for example, where one store was able to have a mobile point of sale system, out side, the store where they had a yard or a warehouse where they were also selling product, and they saw a lift in that one store, then maybe they should invest in a program that makes that more systemic. So I think, essentially, what the the gist of what would Brett you’re getting to is, try to understand how you can make technology serve your business better, and how you can measure for it before and after. So you’re not just putting something out there and hoping that it works.

Brett Cooper  16:01
For me, I think the that that example, you you sort of touched on this. And I think, Richard, you and I were in this, but we have we have a support agent included in the bluefish toolset, and one of our clients was piping sales data along with actual usage. So they could see when employees were using devices to sell on the floor, they think they got it was a double digit lift in sales, which to them justify the cost of spending $1,000 for these rugged mobile devices, they are expensive, and it’s expensive to put technology and software and employees hands, but they were able to go to the board and say, hey, look, these three stores where we put these devices, we’re getting double digit lift on all the employees, which is pretty meaningful, especially over multiple years. Absolutely.   Richard, this is the lesson seven is probably right up your alley, which is have a pragmatic technology selection approach. I know you’ve been on the receiving end a lot about technology, and how to make stuff work. And I know you’re in the team make a lot of magic happen. But um, I guess Can you talk a bit about that your your thoughts or your lessons when you think about how companies should be selecting technology upfront at the beginning of these large enterprise projects?

Lee  17:15
Yes, I think it encompasses probably all of the points that we talked about before. So do they have any data that is going to help make this technology selection? Selection? You know, what lessons learn? Do we have feedback out in the field? But yeah, I’ve been on the bad end of some technology selection. And in my career, I’ve made some selection that wasn’t the best. But, you know, it was the standard at the time, these big companies were using it, you know, the little did I know that something else was gonna come along and, you know, blow it away in two years, however, data at lessons learned not only from us, but other companies that look like us in our customer. So, you know, at the day, at the end of the day, we can live with it. But you know, how big of a risk are you taking? You know, is it supported by a big community? Can your developers get feedback? Can they get help online? Is it support it? How well is it supported out in the field? And then what else is coming along? Does it seem like, you know, big company like Google is supporting a library or a standard or a framework that could compete with it one day. And then it comes down to architecture, I think companies and architects are distinguished architects, whatever they’re called, and your organization’s are getting better at creating products that are slightly agnostic. Meaning that if another cloud provider or something different changes down the line, you don’t have to rewrite the entire thing. To make that adjustment. You could make small tweaks or make adjustments over time that can move you in the right direction. So there’s no one right answer. But it’s having the data to be able to defend your decision later on. But also architecting in such a way that you don’t box yourself in if you don’t have to

Brett Cooper  19:13
leave or any examples come to mind of you where you’ve seen this fail.

Lee  19:17
There’s been many that just like Rick, but you know, when you have a customer come to you and say we’re, we want to use a loyalty platform for our application from a deal management perspective. And then when you start looking at the loyalty program that they’ve selected and signed a contract with you realize that it doesn’t actually exist as an example vaporware. Exactly, yeah, so be aware, be aware of vaporware, but as the as the non architect non developer in the room. I think Rick hit the nail on the head and juicy enterprises learning this lesson now is trying to be as modular as possible so that you don’t have everything tied into one system that if one piece fails, the entire thing fails. As

Brett Cooper  20:00
we all built a flash app at some point in time, Ron Richards is disappointed about more of the buy versus build. Do you have any tips or guidance around that? So off the shelf, he’s an off the shelf pieces versus building something from scratch. I know we’ve seen it go both ways, good and bad.

Lee  20:22
Yes, it goes back to my point don’t box yourself in, right, there’s organizations that we work with that it’s almost a hard requirement that you build everything. They don’t want to buy anything, they don’t want to get stuck, they don’t want to be behind on an update or have to wait for an update to, quote unquote, innovate within the company. So it’s about balancing act, right. So if you don’t have a core set of engineering, or development talent that has a history of building things, and supporting things and not boxing yourself in, you really want to consider potentially buying and then it depends on what you want to buy to. So there are systems out there that support HR or CRM systems and ERPs that you probably should buy, unless you have a very deep focus, or you have a business process that is unique to yourself, you know, when you build things, you know, you want to build it because it’s bespoke to you. Like you have trade secrets, it’s a unique, unique way of doing things. So it’s really a balancing act. But I think, you know, if you’re going to build, you have to have some trade secrets, something that’s very unique, and you have to have a team or a vendor like blue Fletch, that you trust to support it. If it’s bigger systems that you know, is touching all the organization that encompass you know, like an entire department like HR, or sales, or even analytics, Bas.

Brett Cooper  22:05
Got it? In eleatic. This

Lee  22:07
is a go and build Splunk is what you’re saying? Oh

Brett Cooper  22:11
yeah. You had a little bit of segue lead to the next one, which is know when to replace legacy systems versus bolt on to them or use them. But yeah, I think this can go either way. I know you’ve seen we’ve seen some bad examples of people trying to put lipstick on a pig, but what um, you know, what are your lessons there?

Lee  22:35
Geron, you first thing you have to do, I think when you’re coming in as the outside vendor, like a like a blue flash, like we do is be sensitive to the historical investment that an organization has made in a product or something that maybe they made from scratch and the person you’re talking to across the table from you, it could be their baby. And so you don’t want to call that baby ugly to that person’s face. So I think understanding the sensitivities and why someone may feel that they need to hold on to something can help them release the grip on it a little bit. But making sure that you look at the cost of new development on top of an old system, and is it going to take that much more time and effort to make it work with something that maybe on its last legs versus investing a little bit more in a new system that you can update more easily long term might be painful, but having that conversation with the customer, and have having you get from them why they feel the way they do, I think is goes a long way we we are software developers, but empathy is a big part of our job. And, you know, an example of that is just where bad technology has an opportunity to be better, but just isn’t. We talked with someone recently, Richard and I did where they have a point of sale system in a restaurant. And they put the exact look and feel the point of sale system on a mobile device for the servers on the floor. And the person we were talking to even said, we know that the point of sale system is ugly, and no one likes it, but it’s what they’re used to. So I think there’s an opportunity there. That why wouldn’t you just try to make it a little bit better and easier for the server at that point?

Brett Cooper  24:24
Yeah, Richard, any thoughts on the? Yeah, the one for one point. I know, we’ve helped a lot of companies move from Windows C to Android. And we always get to ask, like, we want the exact same look and feel and all those exact same screens on, you know, on an Android device that we had from our Windows CE device. 2002. But like, what are there any examples come to mind there are things that people should really take a step back and take advantage of things,

Lee  24:47
a lot of examples but to go on a rant. So for example, you gave porting one to one so Windows CE applications that look like Windows CE applications or When modern Android work because they had almost half a million associates, they would have to retrain, we had a very tight timeline. And they were committed to rewriting all those applications. Not only that, transforming their whole IT process. So that was a bridge that had a, or I call it a skyscraper that had a very well defined blueprint, we knew exactly what we were doing. And I knew that, you know, I was falling. I knew I was falling on a grenade. So it wasn’t a surprise, I signed up for it. Until I was happy to do that. You know, a bad example of that was a company that we worked with that wanted a one on one port, because this is going to get retired, because we’re going to roll out SAP, and, you know, in a year, so I just need this to only work for a year. And, you know, that was a plan that was rigid, and we weren’t able to change, we weren’t able to influence the decision. Hence, four years later, they come back, and now they want to make updates to that thing that they were supposed to retire three years ago. And so because they were so rigid and didn’t have any changes, it’s a very rigid structure, because it was very complex, it’s gonna be very hard to change. And it was very hard to develop in support that. But then you have some companies that are in heavy, heavily regulated industries, where you know, they flip on a computer in the 70s 80s and 90s. And they haven’t turned it off ever. So you know, they are, are well suited, but also more open because of that constraint to integrate build technology that sits on top because it’s very hard and almost a traditional retirement when you retire a system because it’s been on for 3040 years. It literally retired.

Brett Cooper  27:05It’s crazy, but it makes me think of some of military computers. Have you ever seen, I think there was a Dateline where they did a walkthrough of a submarine, like a nuclear submarine was running. I think all the computers had windows 2000 on them still, just because it worked. And yeah, there, when it works, they stopped stopped doing updates, because they want it to work for the next one. Yeah,

Lee  27:22
there’s a perfect version, they had the perfect, probably processors that like didn’t die, they weren’t the fastest, they weren’t the best, but they’re probably the most efficient. They never break. And it just works.

Brett Cooper  27:34
Yeah, and so it’s pretty crazy. Um, in Lee, the next one that you called out in Lesson Nine was, Don’t be cheap, I think was how we said it. And I think the real point there is thinking about ROI and thinking about value as opposed to thinking about price. But you dive into that a bit. 

Lee  27:52
Sure, and we’ve danced around this quite a bit in some of the other things we’ve talked about. But it’s taking then analysis of what you’re trying to get to when the project is done versus where you are when you start. And if you aren’t willing to invest some money for what you know, is going to save you money down the road or even make you money down the road, then it can be very difficult to talk to customers in that situation. We’ve had good examples, though, where we did have a company that was losing, I think 8% of their mobile devices in their stores. And once they installed blue flash enterprise on their devices, that loss went down to I think, like 2%. And so that automatically paid for itself in the first year and continues to pay for itself. You know, year over year, even though it was inexpensive investment upfront. It the cost was covered. Another customer that we had, we worked with them on a project it was a messaging system, large enterprise global enterprise that has 10s of 1000s of associates using varied mobile devices and even desktops to talk to each other. And Brett and I kind of back of the napkin, talking through what their total investment from a development perspective was not even counting hardware, our services and everything else was probably $10 million. But they saved over a billion dollars. So it’s you have to look at the possibility of change in what your project is going to bring to the table and how it’s going to affect your organization. That’s what we mean by Don’t be cheap, don’t don’t look at that initial sticker price, and be scared off and not look at why it costs what it costs them what value can bring to at the end of the day.

Brett Cooper  29:41
Alright, so Lee, I skipped over whatever you had mentioned, but it was the big lesson for which was understand your constraints. Can you tell us more about when you think about constraints on large enterprise projects? What are they what are the things that people should be thinking about?

Lee  29:58
Sure, and you know, we talked Talk about this internally as an organization to when we are working on our own product and how to scale it. But nothing is impossible given the right resources and the right constraints. And so one thing to keep in mind when a customer comes to you and says, Can we do this? The answer is never know, the answer is always, yes, with a team of this many people and this much time and this much budget, this is what we can get you based on what you’re trying to do. And oftentimes, what happens is you end up somewhere in the middle, because the customer doesn’t necessarily want to dedicate an eight person team for 26 weeks. But what you can do is walk that back and say, here’s an initial release that we can focus on. Again, to go back to our first point, you can’t agile a skyscraper, but you can, you can learn a lot along the way you can point to you can learn a lot by building a model for learning. So I think that’s how you approach that is, know what you can do given the constraints around you and try to put the customer in a position where they can get the most information based on budget they have time they have and the amount of resources they can dedicate to it.

Brett Cooper  31:16
Yeah, Richard, on the technology or development side, are there certain constraints you see a lot or think about from resources or teams or technology,

Lee  31:25
and then one that comes up quite a bit is just know your organization, sometimes your organization can be the constraint. And let me take a step back. So broader organization, it could be because it’s regulated. So things that we do, could be regulated, because as a utility company or airline, we’re working in Europe, it could be GDPR. Oftentimes, if we’re doing something crazy innovative in a state like California, it could be privacy laws, because they differ per state, here in the US, but oftentimes, it could be the organization, there could be an Architectural Review Board or Security Board, or a deployment group, that is the constraint and requires a lot of overhead to manage, and sometimes almost requires as much investment in time to get them on board as it is to develop a solution. So you know, there’s been times where we’ve developed technology, and the technology selection in architecture, was driven by what we knew was going to come down in the organization and being constrained later on.

Brett Cooper  32:41
Yeah, for me, the big thing that comes to mind is the InfoSec teams, I feel like most projects want to avoid InfoSec. For me, I did this on a bunch of projects, I would try to get the InfoSec guys involved early on. And one of the, the CSOs say, you know, I love you guys, because you guys actually asked us at the beginning, as opposed to ask him right before you go to production. And it makes a big difference is getting that stakeholder buy in from those teams early on, they can, they can definitely shut a project down legal security, HR will definitely shut projects down. If if you haven’t involved them early on. So it goes back to that that stakeholder piece too as a constraint.

Lee  33:16
And oftentimes, you’ll find if you involve them early on, they will they’ll help you out and point things out to you that they probably wouldn’t to other people because they want you to succeed.

Brett Cooper  33:25
Yeah, give them a vault. Lee Lesson Nine, skipping back around a little bit, but lesson nine was was don’t be cheap. And I know it’s a little bit cheeky. But, you know, I think the real thing here is to think about value versus cost. You want to dive into that a bit are some examples there. Sure. 

Lee  33:44
So we run an organization that charges money, and we do it for profit. So when we put no dollar signs in front of people it can be, it can be something that takes them back. But what you have to focus on when you talk with your customers, the outcome of the project and looking at if you invest this, this is what you’re going to get on the back end of it. One of our customers on the booth enterprise side was losing I think between eight and 9% of their devices on an annual basis. Once they installed our launcher on their devices, they were able to track them more easily. And that loss rate went down to 2% annually. So that immediately paid for itself over the course of a year. So even though it’s an it’s a cost to the organization, you have to look at whether or not it can save you money or even in some cases make you money. We had another customer that has 10s of 1000s of employees talking to each other all over the world on a varied fleet of mobile devices. That and also desktop that the product that we put in front of them that they ended up using that we built for them, probably saves three to four minutes per me Need your interaction that they’re trying to deal with per day, per location around the world, and it’s probably saved them over a billion dollars for an initial investment. That was definitely under $10 million. So, I know a lot of that has to do with who your stakeholders are. And I know, Rick, you’ve had some thoughts on that in terms of how to get them involved in what how that helps. Yes, because I think some of our best projects came because executive buy in or buying at the top was there it was there early on. And they were okay invested in the money because they knew their ROI was going to be exponential. And it gave us the freedom to do what we wanted to do. But also remove some constraints that customers sometimes would put on us artificially, because they may be protecting themselves or wanting to stay on budget or making sure that they had cushion.

Brett Cooper  35:57
Yeah, I think this sort of goes back to the one of the early points we talked about, which is if you know, the problem you’re solving, you should be able to actualize what it’s going to cost. So they they knew, if you could save three or four minutes per outbound, that you would, you know, across a day, you’re gonna save this much cross, you’re gonna save this much over over four years, you’re gonna save this much. So it was definitely a billion dollars of savings for a tenant $20 million project. So it was very, very beneficial for him. In the last lesson Lee we talked about was the willingness to shelve a project, if it doesn’t work. And this is a, this is always painful, because especially when you work on something, it’s becomes your baby. And, and having to put it down down to the expert, like, what are the thoughts or experiences you have there?

Lee  36:45
Yeah, I definitely have a couple of projects that are in that Indiana Jones warehouse, you know, getting wheeled away as the credits go up the screen. But I think, you know, one of the reasons we talked about building the process for learning is so that you could don’t get into a situation where you work for 30 weeks on something, and it ends up not working. That’s why you do the POC. That’s why you set a hypothesis? And try to answer that question. It’s not focused on being right, it’s focused on learning the answer to that question, and then deciding whether or not you can go forward. So don’t get caught up in the initial, like sunk cost fallacy of building a POC, or doing that initial requirements and design and then POC because that’s going to be much cheaper than going away for six months, and then deploying something and figure out why it doesn’t work.

Brett Cooper  37:39
Yeah, and I have one example. I mean, it kind of goes back to the pile and POC or we had, it was pretty expensive, probably a quarter million dollar POC, we built, we put it in 10 stores, and tested it and looked at it and said, it’s not working. And, you know, if they rolled it to 1000, stores, it would have been millions and millions of dollars. And it just didn’t get the left we needed and the executive team had enough wherewithal to look at and say this didn’t get us the didn’t get us out left, let’s not let’s not do it. And the ability to walk away from that, it’s, it’s, it’s tough, because, you know, we, as developers, or technology are in it put a lot of work into it. And it’s hard to walk away from but, you know, the end goal for everybody is to really make our companies as successful as possible and the folks you’re working with or working for.

Lee  38:22
And sometimes those projects come back. So just because it’s on the shelf doesn’t mean that it’s never going to come back, sometimes you’re just two or three years too early. Maybe the technology is too new. We’re working on a project right now where the ROI is, you know, a mid to high nine figure number. And we’ve probably spent $2 million at this point. But because of the complexity of everyone involved, not necessarily the technology that it because it involves, you know, a tech team, a customer in their vendors to all work together, like sharing information, have these handshakes, make sure that when things go out that they go out properly. You know, the process for the customer vendor relationship, I don’t think is ready to support such a technology. But that technology, I think is ready, and I think it can help them you know, find that nine figure Live Tour money.

Brett Cooper  39:32
Yeah, $300 million a year in loss is a big one. So yeah,

Lee  39:36
opportunity. And so it’s 5050 right now, it may get shelved. It may go on but I think if it does get shelled, it’s going to come back and look a little bit different.

Brett Cooper  39:46
Yeah, I think you know, lately you and I talked about this and there’s a a 16 z equal around. Was it early and wrong. Are they the same? Yep. Which, yeah, we’ve had some of those a week. We’ve built stuff and then it didn’t work. Three years later, the client came back because the technology is finally ready for it. And yeah, I think that’s if you do the POCs if you be able to measure things, you’re gonna know whether you’re ready or not for it. So it’s, it’s definitely a get take a step back sometimes and look at it,

Lee  40:16
I think the key is focusing on the problem you’re trying to solve. And if the problem is still valid, then that project will find a way back.

Brett Cooper  40:24
Got it? So there’s the 10 lessons I’ll do I’ll do a quick recap here. But the lesson one was can’t agile skyscraper. So yeah, I know, the Empire State Building was built in 14 months, which is amazing, every time I go see it, but you they had a spectacular plan, and then move super fast. And I think that’s big projects got to think the same way. Second one was build a process for learning. And for us, it’s actually one of our core values that our company is learning and thinking through and building and growing. Number three is no stakeholders. So whether it’s whether it’s Carl and receiving or whether it’s the ops guys or HR folks, make sure you involve them early on, and get those stakeholders in there. Number four, was understand your constraints. So there’s certain certain hard constraints, whether it’s legal, whether it’s the speed of light, you know, there’s certain things you can’t overcome, but everything else is solvable with enough enough money, give me give me a long enough lever and we can move the earth, I think is the quote. Number five was understand the value of the project. So that’s just knowing the desired outcome, the pieces there, number six was invest in tools that allow you to measure before and after so whether it’s a polling data, your different different systems be able to measure things, it’s it’s really important to build that you can justify it, especially during POCs. And pilots. Number seven was the pragmatic technology solutions selection process. So whether it build versus by understanding what tools to go to what vendors to work with, have a process for that as opposed to just whatever first or whatever is coolest less than eight was understanding replacing technology, legacy technology, re skinning versus actually updating, like when to do that. And building and doing analysis around that is really important to the buy versus build. And then less than nine was was don’t be cheap, which thinks it’s probably a little bit too close to understand the value. But once you know the value, you know how much to go invest in things. So if it’s a quarter billion dollars a year savings, you can pretty easily know what you need to justify if it’s if it’s possible. And then number 10 was willingness to shovel projects. So if something doesn’t work along the way, have make it okay to actually step back and walk walk away from something if it’s not going to work, don’t don’t continue pouring good money after bad. So that was the 10 lessons. Lee, is there any like wrap up or key things I know, these are some of the bigger ones we saw. But something that wrap up as people think about these large enterprise projects and things that that you’ve seen, or lessons you’ve learned in the last 20 years.

Lee  43:03
I think as I’m looking through these 10 lessons, again, the main thing that comes up in all of them is really understanding what you’re doing before you start. And, you know, I’ve heard Rick say this to me, you know, countless times is, we’ve been doing this long enough that we know what works. And we know, we know what doesn’t work and what kind of smells funny. And so take some time on the front end of a project before you jump in and put code down and really understand what it is you’re trying to come out with at the end of the day and then start working on it, like have a plan before you start.

Brett Cooper  43:39
Yeah, richer for you. Anything that’s paramount in this list are the most important thing for you

Lee  43:44
think Know your value and ROI. One of the most frustrating things for me as a leader is to be brought in to solve a problem I’ve gotten really excited about I’ve motivated the team. And I don’t feel that that is I don’t feel the same energy coming back from the customer, whether it’s they’re playing Coy and realize that they’re solving a big problem, therefore, they’re trying to push me down on price or whatever and, and not be excited about it. Or, you know, they’re just being cheap and just trying to spend a little bit of money and hoping that they get lucky. You know, those that’s the difference between you know, a frustrating project that is okay and a successful versus having something that’s truly transformation, transformational for that organization and the people that it affects.

Brett Cooper  44:36
Awesome. Well, we thanks again for joining us. Appreciate it. And as always, if you enjoy the episode, give us a like or a star or follow and if you have any questions or follow up, reach out to us at info at Blue fledged.com Thank you everyone. Thanks.

INTRO  44:52
Thank you for listening to the enterprise mobility roundup podcast. If you enjoyed the discussion, please take a few moments to rate us if you’d like to listen to future episodes please subscribe. To learn more about mobility topics or submit any questions visit us at Blue fletch.com