8 ways to drive software adoption in your team

In this episode of Workflow, Brian and Tom talk about 8 ways to drive software adoption in your team.

00:39  What's happening at Rindle (flip flops and more)
06:14  Our general thoughts on software adoption
09:07 #1 - Involve your team from the beginning
11:23  #2 - Choose software that is easy to use
14:19  #3 - Explain the key benefits for the software
17:01  #4 - Communicate at every stage of implementation
17:45  #5 - Don’t skip out on training
21:47 #6 - You lead, and they will follow
25:09 #7 - Be patient and nurture your team
27:11  #8 -  Collect feedback along the way
30:32  Tips for taking action!

Helpful Links

• Brian's favorite Croc flip flops

Brian: 00:00 This is Workflow, episode six.

Brian: 00:14 Workflow is the podcast that helps teams figure out the best way to work, collaborate, and get stuff done. Brought to you by Rindle.

Brian: 00:20 Hey everyone, I'm Brian.

Tom: 00:31 And I'm Tom.

Brian: 00:32 And we're the co-founders of Rindle, and this is our podcast, Workflow. Today we're talking about how to drive software adoption in your team.

Tom: 00:39 Should we start out with what's happened at Rindle?

Brian: 00:42 Yeah, besides the podcast being live, which we mentioned in the last episode, I think we're still working on V.3 of Rindle, which is exciting yet a large project. So, still working on testing all those little nuances and getting everything wrapped up and ready to get into production.

Tom: 01:02 Yeah, yeah. It's actually crazy how just complicated even simple software is. I think especially making software simple. Like we have had a lot of discussions this week about how different features should work and how the user experience should be. Like it seemed so simple on paper, but once you get in there and start fiddling around with it, it's really complicated.

Brian: 01:30 Yeah, I noticed one thing that keeps coming up as we're talking, which I think is a great thing, is not to put the burden of what we're doing onto the user. And so, I think that's been kind of an ongoing little blurb that keeps being brought up week to week.

Brian: 01:46 But I think some of the things we're dealing with are complicated, in the background. But how do we do that so we don't put the burden on the user, we put the burden on ourselves and make it a really great experience? So, I think some of those, as we test V. 3 and everything like that, that we're working on trying to get this out the door, some of these user experiences are coming up, and we need to make sure that those are solid before we kind of push it out.

Tom: 02:10 All right. Cool. So anything new or exciting going on in your life, Brian?

Brian: 02:15 Well, outside of Rindle, I have found the perfect pair of flip flops, which I have ... I'm a flip flop guy, so I wear flip flops pretty much as much as I can, even when I probably shouldn't, when it gets pretty cold out. I've always worn like Rainbows, which is a pretty popular flip flop out there, leather. I still like those. But I was struggling to find a really good rubber pair of flip flops, because when they get wet and stuff, you don't want to wear leather flip flops and all that stuff to like to the pool and things like that.

Brian: 02:49 So I had a really thin pair of flip flops that would slide off your feet. So I, through my sister, found this pair of Crocs flip flops that are absolutely amazing. I'll link them up in a show notes if anybody cares. But they're basically like wearing sneakers on your feet, but you're wearing flip flops, and super comfortable. Like it kind of wraps around your foot, so I'm really, really excited, if you can't tell, about my new pair of flip flops.

Tom: 03:16 You know, I'm really a Reef guy myself actually-

Brian: 03:19 Oh nice.

Tom: 03:20 ... in flip flops.

Brian: 03:20 I've owned Reefs in my life, yeah.

Tom: 03:22 The last pair of Reefs that I got actually had a bottle opener in the bottom of them, which has come in handy a number of times. It's been pretty awesome.

Brian: 03:31 Nice. I was actually looking at my grill spatula yesterday and noticed there's a bottle opener on the end of that and realized I'd never used it. So, even when I have like a barbecue or something, I always have bottle openers laying around, and I'd never used it. But that's nice that that's come in handy for you.

Tom: 03:46 Oh yeah. It's pretty awesome.

Brian: 03:48 The only thing I can complain about with the flip flops is that when I put like a really wet foot in that flip flop, that Croc flip flop, and I was a little squeaky. So when I was walking across the pool area, people could hear me coming. So, that's my only complaint. But I think that's a pretty small complaint.

Tom: 04:07 Yeah, I mean, for the comfort that it brings, I guess, it's a cross to bear.

Brian: 04:12 I'm telling you, it's a game changer. So, what's up on your personal side? What's going on?

Tom: 04:17 Not much. I'm just doing a lot of work. The wife was with the kids down in Delaware this weekend visiting her family. And I was at home doing work, and I got a little golf in, so that was exciting. I did have my first birdie ever, which was awesome. And then I shot terribly after that.

Brian: 04:40 Nice.

Tom: 04:41 That's golf for you.

Brian: 04:42 For those of us who don't play golf, and that's not me, but anybody listening, a birdie is one under par, right? So, if the hole is like a par three, and you get it in the hole in two strokes, then it's a birdie. So Tom, how long you been playing golf now?

Tom: 04:59 That was probably like my sixth time out playing golf, fifth or sixth time out.

Brian: 05:05 Yeah.

Tom: 05:05 So not that long.

Brian: 05:05 So, that's pretty awesome that you got a birdie that early on, and that's what keeps you coming back, man.

Tom: 05:11 Yeah, definitely, definitely.

Tom: 05:13 Before we get started, we just wanted to quickly mention that if you have any questions, topics, or team scenarios that you want us to tear down, our voicemail is (860)577-2293. Yeah, if you call that number, we'll definitely listen to your question, and maybe even incorporate it on the show. You can also email questions to workflow@rindle.com. That's workflow@rindle.com. You can also attach MP3s right to the email. MP3s or WAVs, or anything like that.

Brian: 05:51 You can leave us a review as well. That helps us reach more people through the different channels that we distribute the podcast through, like iTunes for example. So, the more reviews you get, the better chance we have reaching more people, which is great. Also motivates us that we're kind of doing a good job, you're liking what you're hearing and to keep going. So yeah, if you have it in you, take time to leave a review, we'd really appreciate it.

Tom: 06:14 All right, so let's get to the main topic. So, eight ways to drive software adoption in your team.

Brian: 06:21 Yeah, I think software in general has implementation challenges regardless of the software type that you might be rolling out into your team. So that could be a PM software, a CRM, a cloud-based file storage solution. Whatever it might be, user adoption in your team is a big challenge. It's not so easy to say, "Hey, we're going to use this software today," and tomorrow everybody's on it and using it and everybody's happy.

Tom: 06:45 Yeah, and I guess the challenges there are really around your team, right? Like that it's hard to get people to adopt new things just in general, right? If people already are using one thing and really like it, it's hard to get them to change. A lot of times, I guess, even though you have software at a company, like people tend to think that it's optional to use it, right?

Brian: 07:12 Yeah, I think people are used to whatever they're using today. So usually a software solution is going to replace a process or something that's going on today. That could be another piece of software, it could be a manual process that's happening. It could be something that multiple pieces of software are handling, that you're going to now bring something that's going to handle all of those things.

Brian: 07:34 So even in a project management software example where people are currently using email to track their tasks, right? 'Cause that's pretty popular still today. People are used to that. It's really hard to change their habits from, "Hey no, we're not going to use email anymore. And by the way, all of you are not going to use email anymore, and we're going to use this new thing."

Brian: 07:54 Same thing for like a cloud file storage system. You might be using a local file server, and that's what everybody's used to using. And now you're going to use something like Dropbox or Drive. And that change is really hard for people to kind of switch over to.

Tom: 08:08 Yeah, it's also on the opposite end of things. Like when you're developing software, right, like you constantly are asked, "Well, what are you replacing," right? "What software are you replacing?" And that's complicated, 'cause you can't actually come into a market and be like, "Oh, well we're not actually replacing anything, we're actually just going to be an additional piece of software." 'Cause no one wants to use an additional piece of software. They want to eliminate software, right, that they currently are using. So, getting people to adopt a new piece of software is very complicated, because people typically just don't want to do it, right? They don't want to have to learn something new and use something new.

Brian: 08:47 Yeah, so I think basically tons of challenges here. I think we're basically talking about eight today that we think are the biggest ones, that could really help you, you know, even through our own experiences that we've had in our career, but help you kind of roll out software or think about how you might roll out software in the future.

Tom: 09:07 So, let's hop right into it. Number one, involve your team from the beginning. So yeah, do you want to tackle this one?

Brian: 09:18 Yeah, I think this is a big one for me in general. I think whenever you do anything, you know, when you're rolling out a piece of software, a new process, whatever it might be, involving your team I have always found has been a lot easier. A lot of times people will kind of make a lot of decisions in a silo, in a private area where they're not involving everybody quite yet, 'cause they don't want to alarm anybody to what's going on. And then you hit them way later in the process with, "Hey, by the way, this change is happening, and it's happening in five days." And there's basically just panic.

Brian: 09:57 So, not only do you get people kind of engaged early on, but you also kind of alleviate kind of that panic syndrome. You also get input early on, so if anybody has concerns, they don't come when you've already made the decision, and you're already so far down the path that you can't change and you can't iterate. So I think that's really important to get your team involved early on. If you're considering multiple software platforms, whatever it might be that you're doing, get a team meeting together.

Tom: 10:25 Yeah, especially if it's like something that they're going to have to use on like a daily basis, right? You want their buy-in pretty early in that piece of software. Like you were saying, if they have a concern or they think that there might be a better solution out there, you should know upfront, right? Or they should have that say maybe upfront. You might ultimately still go with the software that you decided to roll out, but at least they had a chance to voice their opinion, right?

Brian: 10:54 Yeah, and you can address those specific concerns. So even if you decide to go with a different platform for whatever reasons, you can address those and explain that so everybody understands why the decision was made this way. I also think you avoid later people being frustrated because they didn't get to have their say. So if you give them the opportunity to kind of chime in, give any feedback, and if they don't and then they chime in later, you kind of say, "Well, I gave you the opportunity along with everybody else to kind of chime in with your feedback."

Brian: 11:23 Cool, so number two is choose software that's easy to use. I think this might be something that somebody said, "Well yeah, duh. That's obvious." But I think a lot of times, whoever is choosing the software is typically more of a power user. So, they tend to not consider the whole team when making a choice or considering themselves or how they might use it or how a specific thing they need to solve or job to be done, that they need done. You know, and they consider that only, not the masses. So I think that's kind of why it's not so obvious and really-

Brian: 12:01 ... kind of why it's not so obvious, and really, having software that's easy to learn, easy to teach and communicate to other team members how to use it and just generally intuitive across the board is going to be a better solution overall because in the end, having mass adoption is more important than having just a small percentage of user using the software imaging.

Tom: 12:22 Yeah, and it's not just that it's easy to learn, but it also has the resources available if you need to learn it. Whether it's documentation or webinars on a weekly basis that you can hop in and you can actually learn the software, right? The software itself doesn't necessarily have to just be simple, simple software, right? It can have complicated features. It just needs to have a path to learn it, right?

Brian: 12:52 Yeah.

Tom: 12:52 Where you can start off small and iterate on that and build that.

Brian: 12:56 I like, and we even build Rindle this way, something that's simple on the surface and easy for the masses to kind of wrap their head around, but then as you dig in you have the features and the flexibility for the power user stuff. In general, I think great software like that, really well-designed software makes that happen, where you're not presenting all these complicated things on the top level. It really comes down to how you source the software. That should be a decision point as far as, "Well, does it do everything I need it to do, but also, is it easy?" Right? A lot of times we just look at, "Does it do everything I do? Yes. Great. This is the solution," but it's really complicated to use. That's going to make your life 10 times harder.

Tom: 13:38 Yeah, I think it's like building off of the basic building blocks, right? If you think of a software like email, right? Email is pretty simple, right? You can view your email, read it, and you can send new emails or reply to that email, right? Those are the basic com steps, but if you take a look at a project like Gmail it allows you to then take that a lot further by there's advanced things that you can do with filtering, and sorting, and labels. Those are more for power users. You don't even need to necessarily do all that stuff. It does all the basic stuff and it does it really, really well, but then you can dive in further and do more as you learn the software more.

Tom: 14:19 All right, number three. Explain the key benefits. You need to explain to your team why you're picking this software and what the benefits will be to the team. If you're taking a file-sharing software, as an example a Dropbox or Box, or what are the other popular file-sharing softwares? Google Drive.

Tom: 14:41 Yeah. You need to explain to them, "Oh, it's important for everyone to use this instead of storing the files locally on your machine so that way everyone has access to them. If you go on vacation Bob can still see your files," or whatever. That's one of the benefits. The other benefit is for backup, right, We don't want all the files on your computer because what happens if your computer gets stolen or gets lost somewhere, right? At least it's in the cloud and it's backed up.

Brian: 15:11 Sometimes a reaction to a new software rollout is like, "Ugh. I'm going to have to learn another software." Taking the time to actually explain the benefits that will be given to the team by using this and all the reason will help the case because sometimes it's not as obvious as you might think. Your team members might shift directly into defensive mode like, "Oh, I don't want to use it. I don't even want to pay attention to this meeting. I don't even want to know what's going on." But if you really lay out the benefits you can convince them early on again that, "Hey, this is going to make our lives better. It's going to make it easier and these are the exact reasons why."

Tom: 15:45 Yeah. Another common probably complaint about when a new software's being rolled out is people are saying that, "Oh, it's big brother watching us." You should probably head that off with saying, "This is not a big brother tool. We're not trying to see how much work you're getting done right," if you're rolling out a task tool or project management tool. We're really just trying to get the team more organized and help you as an individual on the team rather than ... What am I looking for?

Brian: 16:17 Looking over your shoulder?

Tom: 16:18 Yeah, rather than look over your shoulder, right? Even if ultimately, yeah, maybe that tool is going to have additional reporting capabilities that will help the business, the individuals don't really necessarily need to be worried about that, right? This isn't going to affect their job. If they're hard workers and they're doing their job, using this tool is only going to benefit them and it's only going to benefit the company.

Brian: 16:41 Yeah, being big brother and having the kind of looking over your shoulder type thing is not the core use of the tool. It's not a benefit that a company or you as a manager or whoever might be rolling this out. It's really just kind of like you said, cut that off in the very beginning saying, "Nope. That's not the purpose. It's really just about improving communication and streamlining our teams, kind of how we work."

Brian: 17:01 Number four is communicate at every stage of implementation. I think that this is pretty common too that sometimes team members feel out of the loop as to kind of what's happening when and when things are rolling out. Whatever kind of rollout plan you have in place, and sometimes, my experience, it can take even up to six months to roll out a software and have everybody actually adopt it, onboard it, and using it every day. There probably should be stages that you're kind of rolling out touchpoints and things like that, but if you keep your team in the loop as you kind of rollout these stages, maybe even share the rollout plan with them ahead of time so they know what to expect, it will just make everything easier as far as rolling it out.

Tom: 17:45 That actually leads right into number five, actually, which is don't skip out on training, right? You're going to have this plan of [inaudible 00:17:51] and it could be several months, as you're saying, but one of the early stages of that is training for the product. You, as an individual on a team, you can't really skip that. Even if you think, "Oh, it's just a piece of software. I know how to use it," you should really get the actual formal training and you should ask questions. Do whatever you got to do in order to try to learn the software, even if it is easy to use, right? You'll benefit some way from the formal training.

Brian: 18:18 Yeah, I think it really comes down to due diligence of even though software might be easy to use, making sure that your team knows how to use it period. You don't make an assumption that, "Hey, this is easy to use. This is great," but you're kind of assuming that everybody will just know how to use it. Don't make that assumption. Team training's really important.

Brian: 18:39 I remember I rolled out a project management software in one of my previous companies and I actually had to do multiple training sessions. I had to different roles within the company even, because everybody kind of used the software a little bit differently. I had to do just the core creative team in one type of training and then the account managers as one training, and the project managers as another training, and then your management. Again, this was kind of planned out in, how should I roll this out? How do I communicate how to use this tool? Because it's not always as easy as just being like, "Oh, let me have this mass training session for the entire company," and you're really not taking into consideration how each group of people will be using it.

Brian: 19:21 Yeah, it's something to definitely consider and mapping out, it might take 30 minutes for quick trainings. It might take two hours depending on who you're training and what you're training on, but it should definitely be in the mix of your rollout plan. Overall it drives adoption. Again, we're talking about adoption here, right? Training on the software, getting people comfortable with it, answering questions, making sure they understand how you as a company are going to use it is just going to help adoption overall.

Tom: 19:51 I think that is really important too if you are setting up this training to actually do a first training session that's really the high-level view, the core functionality of the software, and then have either additional training sessions that maybe are optional or mandatory for maybe certain departments available, or also, just one-on-one type training tools available. Whether it's the help documents or videos of how to use different features that people can kind of learn at their own pace. Different people on the team are going to need different levels of handholding when it comes to using a new software. It's important, I think, when you're rolling out software to be aware of that in order to aid adoption because you also don't want to force someone into hours of training that they really don't need, right? Especially if they're not even going to be using all that functionality because that could be a turnoff.

Brian: 20:52 Yeah, I think in the end you need to provide the right resources to your team, and a lot of times the software that you're using will probably have a lot of out-of-the-box resources for you. Rindle has a help center, and some video tutorials, and other stuff. I'm sure you'll be able to put that stuff together, and sometimes you'll have internal process documents or things that you need to create to communicate how you're actually going to use it internally. Because the tool is just a tool, right? You still might have process or certain things that you want to happen within that tool or how you want your users to use it.

Brian: 21:24 I know, again, I had to create multiple documents even for the different groups of people of, "Hey, this is the process," or, "This is how we expect you to use the tool and this how we're customizing it specifically how to our company works." Make sure you outline those things and make sure they're clear and communicate it to your team so they have all the resources and tools they need to understand how you're going to use the software.

Tom: 21:47 All right, so number six. You lead and they follow. I really think that this essential. As long as the software is a piece of software that everyone in the company's using or large portions of the company are using and you actually are going to need to use it on a daily basis, you need to start with yourself using it on a daily basis. Then you need to start getting your team on it before you then worry about the rest of the company, right? It always starts with you needing to completely buy into the software and to start using it every day.

Tom: 22:27 Honestly, if you start using it from day one and you don't really use it all the time or after the first week you don't use it all the time, maybe you should look for a different piece of software because maybe it's not a good fit. If you can't even use it every single day, how can you expect your team to use it every single day?

Brian: 22:45 Yeah, I think a great example that I have of that is kind of even rolling out a PM software. One of the big things that I faced was people just getting tasks into the system because we were, at the time, communicating them in all different ways. Walking up to somebody's desk, emailing, chat. You name it, things were being communicated all over the place, as far as things that needed to get done. The first initiative was, "Well, we need to start actually getting the tasks into the PM system and assigning them out to whoever needs to do the work."

Brian: 23:15 A good example of this would be if I'm rolling out that software or I'm leading the initiative and day one I kind of walk up to somebody's desk and say, "I need you to do this for me." Right? That would be a direct contradiction to me not leading and expecting them to follow what I've laid out as far as [inaudible 00:23:31] software. It's really important and people notice that. I mean, they'll be kind of like, "Wow. Boy, he's on a high horse. He's walking over. He's not even following his own rules," so you really need to lead by example. A lot of times doing that people will see successes happening, so if you're using a tool and you're using it as planned, they will see that your life's easier, that you're starting to understand your work better, and all these things. Whatever it is you're rolling out, and they will want to get onboard with that.

Tom: 23:58 I can see this being especially important if you're rolling out a time management software.

Tom: 24:00 If you're rolling out like a time management software, which from previous episode, everyone knows our opinion on time management software and we don't really love them. But if you are rolling out a time management software to your company or time tracking software, if you will, you should probably use it yourself even if you are a higher level manager. Right? Because how can you expect your employees to really use that every single day if the software doesn't work well or if you aren't even able to use it yourself easily. Right?

Brian: 24:31 Yeah. That's a really good point actually that we made in that time tracking episode. I think it was episode two, about in the agency we worked at that all of the on the ground workers, if you will, the creative folks, the developers, designers, account managers, project managers, they all had to track time but really the managers and upper management didn't have to. It was a constant thing like, "Wow, we have to do this, but they don't." Right? It was a constant conversation almost every week. It is a great example of saying, "Hey, you kind of want everybody to do it from a top down approach. You should be doing it whether you're the leader of that team or you're the CEO of the company."

Tom: 25:08 Yeah. Definitely.

Brian: 25:09 Cool. Number seven is, "Be patient and nurture your team." I think this is probably again another obvious one or we think it's obvious, but your team's ... Everybody has work on their plate. People are doing whatever they're doing on their day to day basis, so you should expect them to have a level of frustration as you roll this out and as you're expecting to adopt these new habits. You have to be a little patient and understanding of what's going on and nurture them along the way. It's going to happen regardless. Again, it's not going to be perfect.

Brian: 25:42 It's really important because I think people tend to get frustrated like, "Oh, it's so easy. Just use it. I already explained it to you. You should just be using it. Just change the habits." But habits are hard to change. I think actually it takes 21 days roughly to change a habit. If you're expecting everybody to change their habits in week one, it's not going to happen most likely and you're going to have to kind of help them along the way.

Tom: 26:02 I think that another thing like ... You used be patient and nurture the team, but you also kind of going back to that number four, like communicating at every stage in the implementation. At some point, there should be a stage of implementation where you shut off that old way of doing things. Say you are rolling out a file storage software and previously you were using something else. Month three, everything should be cut off from that old way of doing it. That way, even if you were having some stragglers, hey, they had three months to figure out how to use the new system and start using it. Now they have to. You have to be patient but only up to a point, I think.

Brian: 26:44 Yeah. You don't want it to get out of hand where you're being too lenient and nurturing.

Tom: 26:49 Yeah.

Brian: 26:49 You have to have some guidelines as to well, this is happening by this point. I think that's a good suggestion, like cutting things off if you can and giving the heads up to that, saying, "Hey, you're going to have three months to do this." I think it's a great way to kind of implement urgency and understanding of you have this time, take advantage of it, don't wait three months from now because you're going to be confused and frustrated. Yeah. I think that's a great point.

Tom: 27:11 Awesome. The last point, number eight, is, "Collect feedback along the way." This is important with rolling out software. I think this is important with everything that you do that you should always be collecting feedback from your team about how something's going, is it not going well? What are the pain points? How can we improve this process in the future?

Brian: 27:32 Yeah. Similar to even being the baseline process that we talked about in episode four, being open to iteration and tweaking that as you go. Being open to feedback when you're rolling out new software, same principle. You might have thought you might use a software a certain way. Then when you're actually using it or the team's actually using it, it ended up not being quite right so tweaking that and the guidelines of how to use it should be able to iterate along the way. A lot of times we just worry about our internal team, but if you have external people as well in the mix, that's equally as important.

Tom: 28:08 Sure. Yeah. Also, passing features and pain points along to the people who developed whatever software you're using, I think, is really essential. Again, that's more of a management thing to do, but you're going to be getting that feedback from the individuals using the product, like your team members. Be sure to do that because I mean you'd be shocked with how many teams that are building products like really want to hear this feedback and implement changes, especially the onboarding or how people use the product. They really want to hear people in the wild, what their pain points are.

Brian: 28:45 Yeah. I mean we love feedback. A lot of what we do is driven off customer feedback. I think just getting that feedback from the team, if there is a frustration with how the software itself works or a missing feature or an enhancement or something like that, hopefully the provide is listening to your feedback and will implement some of the things potentially if it makes sense for that product. That's going to also get your team behind. If they see some of those changes happening down the road, that's going to make them happy, it's going to make the adoption even stickier. Making sure that you receive that feedback and communicate it to the provide is step one. If you ignore that feedback, then that will never really trickle up to the provider and those changes will never happen. Yeah, I think it's important to be open to those requests. Cool. To summarize, our eight ways to drive software adoption in your team. Involve your team from the very beginning. Choose software that is easy to use. Explain the key benefits to your team. Keep them in the loop into why you're choosing the software. Communicate with the team at every stage of implementation, so make sure they understand how it's rolling out and when. Don't skip out on training regardless of how easy the software is to use. Don't take that for granted and make sure you train different groups within your team. Lead by example. You have to use the software every day to expect your team members or anybody else to use that software. Be patient and nurture them along the way so it may not happen as quickly as you think, but don't let that get out of hand either. Set some guidelines and some restrictions as to when things will be cut off and other things like that. Collect feedback along the way, not only on your internal process of how you use that software, but also feedback on the software itself, feature enhancements, et cetera.

Tom: 30:32 Let's talk about some tips for taking action. I think we already just gave you eight tips, but do we have anything else, Brian?

Brian: 30:38 Great. So we're done. No, I'm just kidding. Yeah. I think one other thing that I wanted to mention, just empower your team to push back on each other. This is something I did with one of the roll outs I did on a PM software implementation. A lot of things were happening in email at that time, so empowering everybody to say, hey, if somebody emails you with something to do, push back on them, respond with, "Put it in the PM software." Empowering them to do that because a lot of times people are like, "Well, they asked me." Some people asked me, "Well, what if my boss asks me something to do, sent me an email." If your boss is supposed to be using that PM software and that's what the decision was and all the people were supposed to be using the software, then you're empowering them to push back even on them or yourself or whoever it might be. It really gave people confidence as to say, "Well, I can kind of get behind this. I'm using it so I'm going to do my part to help other people to use it."

Brian: 31:30 I think that really did a great deal for me just because it's not me just running around as the person who's rolling the software. Making sure people are using it empowered everybody to take ownership and kind of hold each other accountable.

Tom: 31:45 Yeah. I think that's a really good tip. I think that if you're at a company for a roll out of some piece of software and you don't see management using the software or there is no buy in, like they're telling you to use a piece of software, but there's no buy in from the people telling you to use that piece of software. I think that there potentially could be a cultural issue at the company, especially when it comes to project management software or ...

Brian: 32:18 Any collaborative software really.

Tom: 32:20 Any collaborative software.

Brian: 32:21 Yeah. When you're relying on multiple people to be in the tool and communicating.

Tom: 32:25 Yeah, absolutely.

Brian: 32:27 One parting thought is just that remember that software is a tool to help you solve a problem, not a solution in and of itself. You might find the software with all the features you need, it's easy to use, it has the right cost and the support and all the things you're looking for, but adoption is key to any software success. You can find the perfect tool that's going to help you solve your internal problems or whatever's going on, but having a proper roll out plan, things in place to get user adoption, is key to success. If you get a small percentage of people using it, it's going to fail. It's going to fall by the wayside. You're going to be in the same boat looking for another piece of software.

Brian: 33:06 Really take adoption seriously. The software, finding the right tool is one piece of the puzzle. It's not going to solve all your problems. You really need to worry about, how are we going to roll this out? How are we going to drive adoption? Hopefully these tips will help you do that.

Brian: 33:20 Well, I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 860-577-2293 or you can email it to us at workflow@rindle.com. Our theme music is an excerpt from Thunder Rock by Magic Studio used under Creative Commons. Subscribe to use on iTunes by searching for Workflow and visit rindle.com/workflow-podcast for a full transcript of each episode. Thanks for listening and we'll see you next time.