88: Mobile App Project Management with Renae Livingston of Profile by SanfordPublished August 3, 2021
Run time: 01:10:17
Organizations that implement project management methodology see a 70% increase in success rates. Profile by Sanford’s Director of Project Management, Renae Livingston, joins the show to talk about how to effectively manage large technical projects, and how cost, bandwidth, and capabilities factor into hiring a development team.
In this episode, you will learn:
- Why project management is a great career path
- The difference between the roles of Product Owner versus Product Manager versus Project Manager
- A day in the life of a Project Management Director
- How cost, bandwidth, and capabilities factor into hiring a development team
- What goes into scoping out a large development project
- The role feasibility and sharing the “why” play in resolving conflict
- The communication process Project Managers use when it comes to navigating scope creep
- How to accept change
- When to trust data and when to trust your gut
- Why you should document your assumptions
This episode is brought to you by The Jed Mahonis Group, where we make sense of mobile app development with our non-technical approach to building custom mobile software solutions. Learn more at https://jmg.mn.
Recorded July 21, 2021 | Edited by Jordan Daoust | Produced by Jenny Karkowski
Email Renae | firstname.lastname@example.org
JMG Careers Page | https://jmg.mn/careers
Connect with Tim Bornholdt on LinkedIn | https://www.linkedin.com/in/timbornholdt/
Chat with The Jed Mahonis Group about your app dev questions | https://jmg.mn
Tim Bornholdt 0:00
Welcome to Constant Variables, a podcast where we take a non technical look at building and growing digital products. I'm Tim Bornholdt. Let's get nerdy.
A quick side note before getting going on today's episode. You probably hear a lot of podcasts mention rating and reviewing the show on Apple podcasts. Well, this is because getting people to discover new shows is tough. And one of the only levers we have to pull as podcasters is getting strong reviews and ratings. So if you enjoy our show, and you have 60 seconds of spare time, we would love it if you went to constantvariables.co/review. That's constantvariables.co/review. That will bounce you right into the apple podcast app where you can go ahead and leave a rating. Thank you so so much.
Today we are chatting with Renae Livingston, Director of Project Management at Profile by Sanford. This is the first time we've had a project manager on the show and I talk with Renae about how to effectively manage a large technical project. We cover everything from managing budget to meeting deadlines to facilitating communication. We even cover analysis paralysis. So without further ado, here is my interview with Renae Livingston.
Renae, welcome to the show.
Renae Livingston 1:27
Thank you. It's great to be here, Tim. Thanks for inviting me.
Tim Bornholdt 1:30
Oh, absolutely. It's been a long time coming to have you on the show. I'm really excited to have you on here. I'd love for you to take a chance to tell us about yourself and everything that's led you up to where you are today with Profile.
Renae Livingston 1:43
Yeah, so I am currently the Director of Project Management at Profile by Sanford, have been with Profile for a few years now and really enjoying it. It's a unique opportunity. We're kind of a small business with a large footprint. So it's an interesting concept but been working there and had the opportunity to work with you and your team on one of our projects. And that's kind of where we're at now and led us to me knowing you and meeting you. I don't know, Tim, do you want to know about my background? Or is it more just about Profile?
Tim Bornholdt 2:16
Yeah, just about you. I'd love to hear how you got, like, what made you say like, you know, I want to be a project manager. How did you get driven into that career path?
Renae Livingston 2:27
It kind of happened by accident. I am so old that when I started in information technology many years ago, there really wasn't a thing as a project manager in a normal sense of the word that we use today. We had people that ran projects, right, and we had people that ran work, and we never really referred to it formally as project management. When I was, you know, I started out in information technology and started working for an old computer company that's not around anymore. And they were so crazily insanely busy that you wouldn't be able to get through to support for weeks. You would get busy signals. And so they were kind of hiring anything and everything that walked in the door. And I remember my interview, my very first job interview with them was very interesting. It was two questions. It was, What would you do if you didn't know the answer to something? And I said, Well, I would look it up or ask somebody. And the second question was, Can you start Monday?
So, that was my introduction into technology. I honestly wasn't going to go into that field. I went originally to school for psychology. And it relates a little bit but I got into technology that way by interviewing for tech support for this computer company that really needed the help. And I kind of grew from there and moved around in the technology field, got into leadership, and then I was at a government agency as a contractor and a leader. And this government agency decided to implement matrix management. So they were going to separate the work and the resources. And with that, obviously, project management came into my life. And I honestly started in the resource side. I thought this is where I want to be. I want to manage people, lead people. I love working with people and and then after a few months of that I was seeing all the fun that the project managers were having. And so then I went over to project management. And so then I kind of bounced between the two roles for the last probably 20 years of my life between, you know, being a leader and a resource manager to being a project manager. The truth is, I love them both. And I love being able to manage people and I love being able to manage the work. So it's a really nice balance for me and that's kind of why I love it and why I stick with it.
Tim Bornholdt 4:50
It makes sense. It's nice too like there's so many people that I've talked to recently where when you ask them how they got into where they are, the answer is just, It's an accident. And I think some of the best, like, career paths where if you kind of start in one area and you gain kind of the soft skills, so to speak, of like managing people and getting projects done, communication, all those things that are kind of just necessary, but then when you find the right package for all of those traits, it's like the heavens open and you find like your true calling, and you can just really dive deep and get going on it.
Renae Livingston 5:24
Yeah, I get it. That is so true. I've looked back at my life, and I've seen all of these random things that have happened, and somehow they're not random anymore. And they've led me to where I'm at today. And project management is truly, in my opinion, by far the best career path anyone can choose. And today, thankfully, we have, you know, college degrees, and we have certification programs. We have, you know, mentors available out there. And so, if someone who wants to choose that career path, doesn't have to do it by accident. They can actually go to school for it and learn it in a formal sense. So it's kind of nice now.
But it is, by far, one of the best career paths there is. I've had so many amazing opportunities. When I look back, I mean, I've done everything from, you know, some of the boring stuff, you know, helping a marketing team release a new, you know, plan for a new product to, you know, implementing some, you know, new software to help with accounting, right. But I've also had the opportunity to learn, you know, genetics, and pharmacogenetics, and implementing DNA testing at the clinic level to help save lives. I've been able to impact that. I've been able to impact, you know, putting a satellite into space. I worked on a project for that. So, you know, not a lot of positions out there have that much variety in their life. And that's what's really cool about project management, because, you know, I've done those things. And today, I'm working with you, and developing apps that help our members be more engaged and lose weight and become healthier. And so I have an impact in that and in a way that no one else has, and in all of the projects I've done, have had some kind of a positive impact on the organization on people or whatever. So it's one of the most unique and challenging and fun career paths there can be.
Tim Bornholdt 7:20
How do you get caught up to speed so quickly? Cause I would imagine jumping around like you have from all those diverse problem sets that you're solving, with managing the projects within those, you know, diverse sets, it's like, how are you able to quickly go from like genetics to satellite launching to mobile apps? Is there like a quick ramp up to all of this or like, have you just kind of learned what you need to learn and then kind of just grown as you're in the job? Like, how does that work for you?
Renae Livingston 7:51
Well, I think there's a few things. The first of all, I depend heavily, heavily on the team. A project manager shouldn't be the expert in everything. And if I can sit down and do your job, right, or do your developer's job, then I'm in the wrong profession. I shouldn't know how to do their job. I should be able to speak, you know, speak the language. I should be able to generally understand what's happening. But I shouldn't be a technical expert or a developer or an expert in satellites or genetics. That's not my role. My role is to ask a lot of questions. And that's, I think, how I transition as quickly as I do. I am not afraid to look stupid. Let me just put it that way. I sit in front of the best PhDs and MDs in the world and say, How's that pronounced again? So I couldn't pronounce, I always joke with people I couldn't pronounce pharmacogenetics when I first started on the imagine edX project, or try to even spell it.
But, you ask a lot of questions, a ton of questions and try to understand, and that's really what a project manager does is, Okay, what do we need to do to get this done? How quickly can it get done? What has to happen before this gets done? And can you explain, you know, who else needs to be involved in this? And so you just ask a ton of questions, because you're not the expert. Your job is to pull it all together and have that strategic outlook with understanding some of those details. So you have to have the pit play in both fields a little bit and understand how to pull it all together. And for me, it's asking all the right questions.
And second, I would say it would be to really depend on your team and some of the some of the tougher projects I've had, I've been blessed to have some of the best business analysts in the world. I love that position when you get it at a company. If you can get a business analyst there, perfect. Their role is to help convert those business requirements into project requirements and help the project manager understand them. So that role is also a wonderful role to have and help but also just having a team that's willing to work with you and explain things and communicate is really helpful as well. Overcoming some of those learning curves up front especially, it's, you know, you learn a lot about everything, but it's not usually very deep. It's very broad. So yeah, but it's a lot of fun to learn. And that's one of the best parts is, you know, you get into so many things, so many things.
Tim Bornholdt 10:16
It's like, you know, that there's certain roles within, like, as an app developer, you know, there's this kind of love hate relationship with, for example, quality assurance, because there's these people that are like, you know, inquisitive and curious about what you've produced, and they're going to ask the questions and challenge you with, Hey, it doesn't work when you do this, or, you know, I found this issue. And so you kind of have this contentious relationship. And I would imagine, like, in your role, it's a lot of the same thing, like you're asking these questions to these people that are the professionals doing the work, they seem obvious and, you know, maybe simple. But at the end of the day, like, it's really, if you can understand it, then the world can understand it. And you can kind of piece things together and help assemble how the parts get put together at a time. So is there sometimes, do you feel like there's some of that, like, contentious relationships between you and the project participants that you're trying to manage?
Renae Livingston 11:11
Yeah, I think, you know, you do experience it. I've been blessed that I came up through it, right. So I understand that mindset. I used to be that mindset. I used to think this, I know this, this is what I do, you know, let me do my thing. Upfront, I try and set a relationship right upfront and say, Hey, I'm going to ask you a lot of questions. I need to understand this. But the reason I'm doing this is is so we can make it easier for you. I don't own the project schedule, you do. You're going to tell me what you need to do to get it done. I'm not going to tell you that. And I need your help doing that, right. So we can make sure that we're communicating and we're open. And I try and set that up front. And there are still cases today, where something happens, something goes down, and you're reaching out, and you're asking for help. And you know, you don't get a response right away. They're probably going oh my goodness, right. So it's really just being open to what their needs are as well as your customers' needs. And then explaining why you need it done the way it's done, instead of just saying, Hey, I need this work done, you know. Explaining this is the reason why we've decided to go this direction and here's the benefit that it's going to provide and kind of giving them some of that background so they feel a little bit of ownership in it as well and a little bit of accountability into the success, and letting them drive the schedule, drive the tasks, not not pushing too hard on them to, you know, to be as detailed as some people like them to be. But you also learn when you work with somebody over a little period of time how detailed you actually need to be. I have some folks that I have to go down to two week increments, right. I need to tell them every two weeks what they need to be focusing on. But then I have other folks that I don't worry about, you know. I put a high level task in there. I know that they're going to be able to figure out all the details that go in, and I can trust that they're going to get it done. So, especially when you're working with software developers who have done this a lot who know what they're doing, you don't have to micromanage them. You let them kind of go and they're gonna surprise you on how well they can do it. Especially if you don't try and control it, either. Project managers have no experience in doing any kind of mobile development. So me trying to tell your team how to do it and when to do it is not going to work well for them or me or the project or members or anybody. So I really have to depend on them to kind of just go with it. And we built that trust relationship over a little bit of time. Just they know, I'm going to communicate that honestly with them, and they're going to hopefully communicate back the same way. And we work well that way.
Tim Bornholdt 13:48
Yeah, it's all about having that mutual respect. And if you come at somebody that you don't understand their profession, and you dictate things and kind of, I always kind of say the, you know, Moses descending down Mount Sinai with the 10 Commandments, you know. It's like if you're going to give these edicts to people and say, This is how it's supposed to be done. Then you're going to be met with a lot of hostility, right back, you know, so coming at it with more of a friendly like, Hey, okay, here's, the facts, like we have these deadlines that we have to hit, what can we get done in those times? And how can we structure things to speed you along and make it this collaboration as opposed to just a heavy handed fist? I think that seems to be a better approach to project managing than the other way.
Renae Livingston 14:31
Definitely. Definitely. It's, you know, I think every time I've walked into a project, the somebody, the scope owner, the sponsor tells you a date they want it done. I mean, you expect that. That's how they identify, you know, a budget and get approval is they have to identify an estimated schedule or they have an expectation in mind, but it's really the project manager working with that technical team that defines that schedule. And so, you know, I tend to kind of move in that direction. And that I'm there to support the technical team in getting their work done. And my job is to communicate when things don't go well. And to kind of coordinate and ensure communication is happening at all levels. And so my job is to ask those questions, get things documented, and communicate as much as I can. And so my job is not to dictate. My job is not to tell people how to do their job. I may hold feet to the fire if things aren't going well, and ask them, What do we need to do to get it back on track? How do I need to get folks collaborating on this? Or what do we need to do to get this resolved in a timely manner? But everybody, almost everybody I've ever worked with has always wanted to get things done, right. They always want to do a great job. They always want to produce something that's valuable. And so it's rarely an issue with somebody just doesn't want to do it, or somebody is dictating too much, or anything like that. It's more about removing roadblocks, making sure things are clearly understood and that communication is happening.
Tim Bornholdt 15:58
I love that. So with project managing, I know like in the tech space, especially, I hear the terms project manager and product owner kind of used interchangeably. And even for me, like I'm in this space, and it's confusing to me as to like what the difference would be between those two roles. Do you know much about like product owners and product managers like what the difference between those two roles may be?
Renae Livingston 16:24
So Iwhen I hear the term product owner, my assumption there is they're more like the sponsor. They own the budget, they own the scope of the product that you're trying to produce. For the difference in my mind between a product manager and a project manager is very clear. I think a lot of organizations get those confused easily. In my opinion, a project manager is the one that gets you from zero to 100. They're the ones who gets the scope, they get the requirements, they get the project schedule, they get the implementation done, and they get you to 100% of quality and delivered an implementation. Once that implementation happens, the project managers off there, they step off the project. And then a Product Manager could take over depending on the size of the solution that you're implementing. The product manager's responsible for releases and updates and communication, those types of things once the product has been implemented and is live. And so project manager is temporary, they get the product from zero to 100% complete, and they deliver it and then the Product Manager takes over from there and kind of owns the product once it's there and ensures that the system gets updated, that new releases happen, those types of things.
Now, I've acted in both realms, especially on the app you guys developed for us. And, so it's been an interesting transition. And it's been honestly very good for me personally, because I tend to get a little more attached to projects than some project managers. So to be able to carry that forward and be able to support the long term release schedules and maintenance and updates that happened on the app that you guys developed for us has been really rewarding for me. And then I also act as a project manager for this app you've developed because we're doing major updates to it, like we're gonna implement this big piece of scope. And so we bring a project manager back in to do that update, right. So I've been able to do all kinds of aspects and roles with this app. And it's been a lot of fun, but normally a project manager's temporary. They're on until it gets implemented. And then a product manager will take over.
Tim Bornholdt 18:41
That makes sense. Thank you for clearing that up for me. You mentioned you're the director of project management. So that would, to me, infer that you do more than one project at a time. What is your typical day look like for project management? How many projects are you involved with at any given point?
Renae Livingston 19:00
Well, I think depending on the size and scope of the project, project managers can be on from one to 15, 20. That would be a little crazy and hard to manage. But it's not unheard of. But for example, when I was the project manager for Imaginetics, that's all I did, but there were 19 pieces of that, right. So almost 19 projects as part of that. But today at Profile as the director of project management, I am leading about, well, it averages somewhere between three to five projects at once. And so my day might be having a development meeting with a group of developers in the morning about a project that we're working on that we need some work done on and then it might be a scoping meeting in the afternoon for a new project that we just started. And then it might be meeting with a senior leader to talk about planning out the next big project they want to implement and talking through some of the initial phases and how do we scope this out, who needs to be involved type thing. So it's a little bit of everything, you know, and very rarely do you have the same, you know, project happen in the same pace as other ones. It never really happens that way. So usually you are in initiation in some projects and in execution in others. And so it's kind of all over the place. And you really focus your attention on where the priority is for that day.
Tim Bornholdt 20:21
Yeah, and I would imagine that priority gets set every day, depending on-
Renae Livingston 20:26
It changes every hour.
Tim Bornholdt 20:30
A lot of firefighting, I would imagine.
Renae Livingston 20:32
Yeah, yeah. Yeah. Yeah, this morning, I was focused on one project, and then had to quickly switch to another one because of an issue. So just, you know, today, I've been on three different projects in the first two hours of my day. So it just depends on what you're focusing on and where your needs are.
Tim Bornholdt 20:48
That sounds an awful lot like my days, just back whatever comes your way. But that keeps it exciting too, you know. It's never just though the one boring, mundane thing every day if you're kind of managing, you know, 10 projects or so on average, on any given day, you know. Sometimes those projects, it's like picturing somebody spinning 10 plates on their fingers, you know, like, sometimes those projects have inertia, and you don't have to worry about them. So those plates are going but then others are wobbling pretty hard. And you've got to get your eye on the ball a little bit.
Renae Livingston 21:19
Yeah, you need to learn where to focus your attention, that's for sure, and it changes throughout the day a bit, like we were talking about with, you know, some of the neat things about being a project manager is you get to check the box off a lot. And so being able to have that sense of accomplishment, even if it's just, Hey, we made this one decision we've been struggling with for the last six weeks. We finally made it today. I mean, it could be that to, Hey, I implemented this major piece of software. So it's, you know, you get to check the box off and have and feel really good about what you've done every day. You get to go home. Sometimes it's a struggle. Sometimes you're mitigating risks all day. But often you get to check things off more often than not.
Tim Bornholdt 22:03
And that's for certain people, that is like a really important, like, if you're Type A you have your lists, and you have to check the lists every day. It's like, for me, like I wish I was better at having the list. But I mean, that's why I work with project managers.
Renae Livingston 22:16
And that's why we're here. Keep people like you organized.
Tim Bornholdt 22:21
Exactly. I love it. So like we've alluded to several times in this conversation, you and I and our teams have been working together for, you know, at least a year, maybe two years now at this point.
Renae Livingston 22:33
Almost two years, yeah.
Tim Bornholdt 22:35
And we've been working on some customer facing apps for Profile. And I figured, you know, we can kind of use some of the lessons that we've kind of learned together doing this project, and maybe help some other people that are listening that are going to undergo similar things. So I'd love to hear from your perspective a little bit of the background as to, you know, why we even came on board in the first place, like what what pains were Profile trying to solve? And how did it come to be that custom apps were the solution for that problem?
Renae Livingston 23:04
Well, yeah, it's been interesting, right, because when I first started Profile, it was shortly after I started at Profile, was assigned to this project. And so at Profile, we have a large member base. These members work with coaches that are virtual or in their store in the store location. And we require a way for our members and our coaches to communicate. We have a need for our members to have the ability to track what they've eaten throughout the day, have a tool that provides support to them through providing knowledge and information and training. We also need a tool that, you know, tracks things like BMI and weight and those types of things. So they can kind of monitor their progress, as they work with our coaches and follow our plans.
And originally when I started, we had an older system that was in place. It was not mobile friendly. And it had not had any updates made to it in several years. And there had been a plan put in place before I started to replace that. And the original team that was hired to help us build that no longer worked with us when I started. And so this project had kind of kicked off. We had a lot of the scope defined. We had some development done. And then it sat on the shelf for probably over a year before I started and so when I came in as the project manager, the director of project management, they asked me to kind of take this and dust it off and see what we could do with it. And part of that was to find reliable and really skilled resources to help us bring this not only to the web, which is primarily how coaches access it, but also to mobile devices, Android and iOS, so we can deliver it in a way that our members expect us to.
And so we started the search, and your team came up, and we had some discussions with you. And what's wonderful about Jed Mahonis, you not only could help us with one platform, you could do both. So we could work with you on both iOS and Android, and a lot of the things that we needed to do with our Journey app, you had already done before, had skills in before. So it was a really good partnership and relationship. And then we're working with another partner, of course, to help us on the website. And so it's really been an interesting project. Because shortly after I started, and we started picking this up and running with it, our primary stakeholder or product owner left Profile. And so I suddenly became the person who knew most about the scope, not really the position a project manager wants to be in, is kind of the scope owner. So we had a lot of fun making sure that what we were delivering was what our members expected, and what our coaches in stores needed as well to maintain that relationship and manage that relationship with our members. So being new to Profile that was kind of a fun challenge, to have to, you know, not only learn about web development, app development, but also how our coaches and members interact, and how you know, what their needs are, and requirements are. So we overcame that altogether. And your team has done a fantastic job in helping us. And it's been an interesting journey for me, because this is my first project that I've done where it's been any kind of mobile development at all. So it's been very interesting working with your team and learning about how this works, and just overcoming obstacles, like how do we test this? How do, you know, do I need an Android phone and an iOS phone to test this? And how do we get past that? And how do we test that, you know, in a quality environment and not prod? You know, do I have to have multiple versions of it. In my mind, these were new challenges for me, since I had not developed it before in an iOS or Android environment. So your team was very helpful in explaining a lot of how that works, and how to overcome some of those challenges and made it very simple for us to get through that. So it's been a really good relationship. And you guys have some pretty outstanding developers, not only do they develop, but they can help us do some layout design work. And so when we have that, what if idea, Hey, can we do this, can we do this, your team can help us pull together some designs on what that can look like. They're willing to spend time and, you know, thought process like, Hey, is this possible to do it this way, instead of this way. And they're really good at working out some of those solutions with us and coming up with the right direction. We've honestly leveraged your team to help drive the development across the other, you know, across the web platform as well. So we might have your iOS developer develop it first, and then we'll move it to Android and then we'll move it to web. Because your team is so good at building those initial screens, and the initial designs and the requirements, you know, understanding what our requirements are, and working through those with us. So it's been, you know, a really, really good relationship, and I don't think we'd be where we're at if we didn't have you guys on.
Tim Bornholdt 28:29
Oh, geez, your check's in the mail for those kind words. That was very nice, thank you. It's really good to hear too, you know, because we felt the same way too, you know. Like when you're from our side of the bench, you get a lot of clients and a lot of different clients, and it's, you know, some clients don't work out as well as others, but then there's some times where you just get the feeling where it's like, you know, we're actually really firing on all cylinders. And that's where, as developers, it's really great when you can find a client that, you know, sees your value and appreciates it. And then you find ways to, you know, go above and beyond and make it so it's not just, we're not just there to, you know, type in some code and give you an app and leave. It's like, No, we were all really vested in the success of this product. And we want it to be the best possible app that it can be. And it's really great to be part of a team that also has the same drive, you know, like you pick up where we can't, with understanding all the, you know, business concerns and everything, you know, but you can communicate that to us, and we can go back and forth. And so yeah, it is a good partnership and one that we really, we really like having.
Renae Livingston 29:40
Yeah, with your team, especially, it's always been a team effort. So it's never, you know, here are your requirements, go do them. You know, it's never been that way. It's always like, you know, Hey, we're thinking about doing this. Here's the specific scope that we've outlined that we want to deliver. How do we do this best? And your team comes back and says, Hey, you know what, on Android, that's probably not the best solution, maybe we should think about this because the screens are different. And on iOS, we need to worry about this. And it's always been a collaborative effort where we come back and forth, and that's the best way, right? You don't come to the best decisions alone. You come to the best decisions as a team, because you've got that diversity of thought and process and knowledge. And so having that diverse group, and your team is so willing to come in and offer suggestions and offer solutions, especially if we're not completely sure what we want it to look like. We know what we want it to do. But we're not sure what it should look like. They're very good at working and collaborating and kind of talking through it with us and figuring out the right way of doing it. So it's been really good.
Tim Bornholdt 30:45
I love it. There's one thing with this, with the topic of, you know, getting us on board and everything. I know that you spoke with other shops, obviously, and had probably conversations about bringing in like full time people, just working on staff on it. Was there a reason like that you jumped over to us as opposed to hiring in full time or hiring, you know, a different team maybe? Just curious to hear from that perspective.
Renae Livingston 31:13
Well, I think there were two key aspects from a business perspective. I'll put it that way. The first one was cost. Well, let me say there were three. First one was cost. When we looked at, you know, doing a project of this size, we're still developing it today. And you guys are still writing stuff for us today. So we knew this was going to be a long term partnership. And so you know, cost obviously, is a factor is a consideration. And you were right where we needed you to be as far as what the cost expectations were.
I would say, second, you were one of the few shops that we found around that could provide us both Android and iOS development and had the bandwidth to expand and retract as far as capacity that we would need because we knew we would have a heavy development upfront, and then we're going to go into a maintenance mode, and then we're gonna have heavy development when we get the next release and then maintenance mode, you know. So you were willing to do that with us, is work with us on timing and on resource capacity and those types of things. And when we needed to expand you brought in the extra people to help us and and we've been able to stick with a lot of the same team members over the last few years and work with on the key resources.
And then I think the third thing is, is that you're pretty local to us. You're in Minneapolis, and that's really, you know, not too far away from where we're located. And so, you know, you were a known. You know, we knew about you, and we knew about Minneapolis and I think it was comforting to know that you were a local resource that we could leverage.
Tim Bornholdt 32:51
Excellent. That's great to hear. Because that's one thing we've been thinking about a lot lately is I would imagine in Sioux Falls, it's probably hard to find developers like, especially iOS and Android developers, you need that specific skill set. It's hard, I mean, even if you need just web developers or any kind of software developers. Everyone's in short demand, I guess no, that's not right. They're in high demand, and short supply. So yeah, I would think just going a little bit, you know, a little bit north and a little bit east to find us in Minneapolis, it's not too far away. It's not like you have to go overseas or go, you know, way out of the country. It's somebody a little bit closer, able to jump in. And you know, we haven't had to, but especially with COVID, we just straight up haven't been able to, but I'm sure at some point, you know, we're gonna have to make a drive down there and visit you guys in person, say hi.
Renae Livingston 33:46
Definitely, definitely. Well, and for us to do what you do, if we were going to hire internal resources, I'd have to hire at least two people, because it's very rare to find someone who does both iOS and Android. So we'd have to hire at least two people. And in some cases, we need more than that when we're doing heavy development and we have a hard release that we need to push out. And so you guys have been able to be flexible there. Sometimes we need heavier on iOS and Android, you know, or vice versa. And so you guys are flexible there where you can accommodate and be agile with us when we need more of this or less of this. And so, we're not having to hire full time resources to cover it up.
Tim Bornholdt 34:23
Good. Yeah, that makes sense. Yeah, it's nice. I think one of our biggest advantages is being able to do that scaling. And yeah, come in when you need us and not let us go, but just, you know, let us go when you don't need us. When maintenance mode is over and you've got some more features, we hop back in and that works perfect for us. So it is a great partnership in that regard.
Renae Livingston 34:43
I don't think in the two years there's been a time where we haven't needed you yet.
Tim Bornholdt 34:49
We're always here. You know, since you are the project manager for this project, you've kind of already alluded to some of your responsibilities. I mean, especially, losing the main stakeholder that had a lot of the scope in mind, but like, how did you go about with having lost that wealth of knowledge of what needed to go into it, you know, did you do a lot of relying on like users and getting feedback from coaches? Or like, how did you go about scoping things out and having that? Just what was your role really for project management in this case?
Renae Livingston 35:26
That's a great question. I think originally, what I did is, I decided that because we were dusting this off, a lot of the requirements that already been defined. But some things have changed. Because it had been sitting for a year, I mean, just some of our infrastructure had changed, too. So we had to redefine a lot of the requirements as well to fit into our current infrastructure. So I made the decision that I was going to reevaluate all the scope items. And so we had everything listed in DevOps. And so we were going to go through and I brought in folks from our operations team, our marketing team and our IT team, as well as our partners like you. And we sat down and honestly read through every single user story. And re estimated it, and we requalified it for any changes that needed to happen because of infrastructure, or any changes that needed to happen because of operational changes. And so we essentially just redid all of the scope, and I don't want to, redid is probably a strong word. We rewrote much of it, and we reused some of it. Some of it was still appropriate. So it was really, it wasn't as hard of an effort as starting from scratch, because we had somewhere to go to kind of leverage or get us kicked off. But it did take quite an effort to get through. It was, you know, when you build an app, we weren't starting from something. We were starting from nothing. And we were building iOS, Android and web app from nothing. And so it was quite an effort. And there was a lot of scope to get through. And so we spent a lot of time in those initial meetings reviewing all of that scope.
Tim Bornholdt 37:10
Do you have like an idea, just ballpark, like, how much time it actually did take from your end? Like, was it a week? Was it a month? Was it two months?
Renae Livingston 37:19
I think we spent over three months, three to four months.
Tim Bornholdt 37:23
Renae Livingston 37:23
And I would say it wasn't like solid meetings for three or four months. It was something we discussed every day. And often there were times where we'd read a scope item, and we wouldn't be sure what it was. And so you know, there was investigation that had to happen, and we had to reach outside resources to help us and just estimating some of the effort that required took a few weeks' time, you know. So we would have a piece of scope, like, we need to be able to create a meal plan for, you know, our 70 different meal option types, you know, because we customized meal plans for our members. How do we do that? And so, you know, just trying to talk through that was, you know, user stories. And so then we would have to estimate, Well, what's the impact to web? And what's the impact to Android? And what's the impact of iOS? And what changes need to happen here? And you know, what is the user flow to get through this and the user experience? And what's the coach experience? And so we had a lot of different user stories and a lot of different roles to cover. And so estimating alone took several weeks on some of these user stories to kind of break it down and understand it from our three different development platforms that we were building on. So it was quite the effort for at least three months of scoping, or re scoping.
Tim Bornholdt 38:41
Renae Livingston 38:42
Tim Bornholdt 38:45
Would you say that was three months well spent? Or do you think it could have been, like, protracted or expanded? I think a lot of times people underestimate how important that planning upfront could be, so just from your standpoint, was that time well spent?
Renae Livingston 39:01
Yeah, absolutely. We wouldn't have been able to start without doing that. There were just user stories that were out there that were not accurate at all because of changes that we've made in the last year, either operationally or technically, so we had to do it. There was no way we could have started without it. And all of the players that we were bringing in for this second go were new. None of them were on the original project. So we were all learning the scope ourselves, and trying to understand what this thing is we're building and what it was going to look like. So the effort had two-fold or, well, three. One, to validate what the scope items were. Two, to estimate it appropriately. And then three, for the team, the new team coming into this, to learn what it was about and get an understanding of the scope itself. So it was absolutely valuable. Could we have spent more time? Maybe. I think it was appropriate for what we needed to do. However, I mean, I think you revalidate your scope, especially in development projects, or agile projects. You're revalidating scope constantly. So this was a concerted effort just focused on scope validation. But throughout the lifecycle of any project, you're constantly asking, Is this how it needs to be? What can we adjust? What can we do to make it better? How do we make it more efficient? And so you're constantly re evaluating the project.
Tim Bornholdt 40:21
That makes sense. You mentioned everybody basically on the project was brand new to it. And there was a lot of new folks in the room. And anytime you get new people in a project, you know, communication can be quite a challenge. And I wonder, you know, you had an internal team and external development team, you had stakeholders, you had users, you had coaches. What did you do to manage all of that communication? And even maybe more importantly, like when conflicts arose, how did you deal with those conflicts?
Renae Livingston 40:55
We managed communication in a couple different ways. Obviously, there was a lot of verbal communication. We had a lot of meetings to review. I tend to break my scope up in chunks of relatable work, is what I call it. So maybe we'll focus on just meal planning on iOS today. And I only invited those folks to that meeting, that scoping meeting, who were relevant to that discussion. And that way, we get the right people in the room, and we document what the scope is together then. And then I validate that with the larger team, or the stakeholders, just to say, Here's what we're going to do. Here's what we're going to, you know, build. This is what we came out with. So that's my job as the project manager to ensure that whatever we define in those scoping meetings aligns with the original scope and the expectations of the sponsor and the owner. And if, at any time there's a conflict or a change, then we talk about that. And it's really just negotiating and working with it.
I'm trying to think of a good example where we had maybe a conflict. I think anytime we had any kind of a challenge in the scope, it was because maybe one stakeholder wanted to do something one way and another stakeholder thought it would be better to do it another way. And we honestly would just talk it through, and in some cases that the product owner wins, because they are the owner. And in other cases, we were able to justify a difference or a change. And I think that happens a lot especially when you can scope over to a developer. You know, feasibility is a big issue when you're developing something from scratch, and you say it's got to take, you know, it's got to get us to the moon and back, you know, so, is that even feasible to do? And so we do a lot of feasibility analysis reviews before we even bring the scope item up for estimate. So right now, when we have someone come through and request a change, and that change request can come from a member, it can come from a coach, it can come from someone in it. And that change comes through and says, Hey, we really want the Journey app to do this instead of this. We first evaluate feasibility. That's the first checkbox that it goes through. Is this even possible to do? And then we go through and we estimate it with a development team, with your team. We say, Here's what we want to do and here's why. And they provide us with an estimate. And it's not until we have that information do we bring it to our, essentially our change committee, to evaluate and say, Yes, we want to do this or not. And so that's kind of how I handled it through the project implementation and how we're handling it now that the project's been implemented.
Tim Bornholdt 43:34
I think I just heard the three sweetest words I've ever heard, which were, And here's why. Because when you were saying, you know, here's a change, but then here's why. I love that. That's music to a developer's ears, because a lot of times changes are just kind of, you know, thrown at you. And they're not actually thought through, like you said, with like, feasibility, and with all the different moving components, you know. Building software, it really is, you're building this like world in your own head, and the world has multiple planets in it. It's really just this big mess of things. And when you introduce a new variable into that world, there's so many knock on effects and things that could go wrong by introducing this new feature or changing a feature in a certain way. So I really like the, you know, here's the problem we have. Here's a proposed solution for it. Can we work together to see, you know, is this feasible? And then if it is, you know, what else needs to change? Or how? Like what does the process look like for getting us from where we are to where we need to be? And I think that's one big thing that I would say if you're listening to this, and you can take this away is, when you have an established set of rules already with your app and you have an established code base and everything coming, if you see something that needs to be changed, you know, come at it with not it shouldn't just be, Oh, we need this to be different because it would look better. So you know, have some intentionality behind it and explain that intentionality so that maybe if, you know, the proposed solution you have, maybe if we do it that way, it's going to take 300 hours, but if we tweaked it a little bit to the left, you know, that it would only take 100 hours. like that. Being on the same team, it's so important. That's why I like those communication, like the way that you just explained how you go about it. I was like, Oh, my goodness, like, that's so great.
Renae Livingston 45:37
Yeah, I think I completely agree. You know, as Simon Sinek has said, Share the why, right? So what's the reason behind it? And I don't imagine that I could ever be as knowledgeable about how to work with a member as our coaches are. They go through a lot of training certifications. They work with members all day long. And so if they come to me, and they say, I need to do something a little different. I want to understand why as well. So I can communicate it to our developers as well, because I wouldn't, you know, I don't know everything, and there's no way I could, and so they are able to come and say, you know, we need this button to be here, because our members are having a hard time finding it. They're going to know that first. And so we open up that line of communication from our team, to us as the project team. So they can share that information, user acceptance, testing, all of that stuff we went through as well. But then being able to share that with the developer as well. Because like you said, if I go to them and say, Hey, this button needs to be moved. You know, they may have a different option. Hey, why don't we make it a slider? Or, Hey, why don't we change the color? Because of their development experience. But now that they know the why, they're having trouble finding it, or they're having trouble seeing it, that's such a simple example. Sorry. It's probably one that we've done 15 times with your team, though, but, you know, they might have all the other alternatives, especially in the different environments, and between iOS and Android and web on, you know, Hey, this is the best way to lay this out. I think this will help them see it, and then being able to offer us different solutions, and maybe even different options in the testing environment that we can bring back to the coaches and say, Hey, how does this look? And let them play with it a little bit, which we've done a lot of, especially with your team, you know. Hey built this out, let us play with it for a little bit and see if that's really how it works and how we want it to work. And so we do that a lot as well.
Tim Bornholdt 47:30
Yeah, and it pays, you know, to have that. Because like you said, you know, nobody has all the answers. It really is a team effort to make something that will work for everybody. And sometimes when you spend time just talking about it, it sounds good in your head, then when you put, you know, pen to paper and actually design something out, you can clearly see like, Oh, okay, I don't like the way this goes here, this goes here, let's move things around. And then when you put it into code, it's another set of that of all, you know, this actually doesn't feel the right way. And so having that open line of communication around to everybody and getting things in their hands and actually playing with it is so valuable. And really, like it's a never ending, you know, story with building apps, right? You're just constantly iterating and trying to find ways to make it better for everybody.
Renae Livingston 48:22
Right. Yeah, yeah. And there's a very clear connection success when we allow our users, our end users, whether that be a coach or member to kind of check something out beforehand. We see a much higher significant rate of success in our app and in our usage, and in our customer success when they're allowed to be a part of that process. If we try and do it in a silo, by ourselves, and then we're going to deliver something that's not going to meet their needs, that's not going to help them deliver what they need to deliver.
Tim Bornholdt 48:55
Right. And at the end of the day, that's what we're all here for is to serve the user. So if you box them out of the process, what are you doing?
Renae Livingston 49:04
Right, right. That's what's so wonderful about that Agile process, especially in developing in software development. It's because it is interdependence. It's very close to the customer. So, it's been wonderful process to work with on this project, especially.
Tim Bornholdt 49:19
I love it. You know, as a project manager, it would be, I'm sure it'd be impossible to have a conversation about project management without talking about budget and deadlines. So, as you've alluded to many times in this conversation, you know, that the whole process is so fluid and things are rapidly changing, but at the end of the day, there's still you know, some hard truths that we need to live up to. So I'm curious, you know, specifically around things like scope creep and adding in, you know, making sure we get, Oh, just add one more little thing in or we have to have this before it launches. You know, how do you think about and handle those types of scope creep changes to the the original project?
Renae Livingston 50:06
I've managed project managers for many years. And this is one thing they get very touchy about. And they're constantly wanting change. They constantly want to add this and tweak this and change this, and you've spent so much time planning, and defining the scope and getting that schedule perfect, and the budget perfect and getting it all approved, and all of a sudden somebody comes in and just boom, right? And they get pretty upset over that. And one thing that I constantly remind my team is that we don't own the scope. It's not ours. It's theirs. It's the customers. And our job is not to say no, or definitely not to say no. It's not to get frustrated when they want change. They're requesting change for reasons, to find out what that reason is, understand it. And then our job is to come back and communicate, Well, here's what the impact of that change is going to be. And we communicate impact. And this is what we're good at. We communicate impact in terms of scope, schedule, and cost. So if you are going to, and when I say scope, if you're going to pull this resource off this project and put it over here, this is the impact it's going to have to scope and schedule. If you're going to add this piece of functionality that we didn't have in our original, then this is going to be the impact to schedule and cost. Nothing we do, there isn't a change out there that won't impact one of those three things at least. And so our response should be, a, provide them with all of the information they need to make a legitimate decision about whether they really want to do that or not. And so I might come back and say, That's a great idea. And, Give me a couple days to see what the impact is. I'll come back, sometimes called you guys up, here's what they want to do, what's it going to cost? Or I'll know what it's going to cost. But you know, what's it gonna, you know, what's the estimate gonna be? How many hours is it going to take. Honestly, your team and my team, we do that about once every two months. I have a list of change requests that come through, and your team and my team, we sit down, we go through those, and we estimate them. And then I go back to the project owner. And I say, Okay, well we can do that. It's feasible, it's possible. And here, it's going to cost you, you know, $12,000, and it's going to impact our go-lives by three weeks. Is that what you want to do? Yes or no. And now they have all the information they need to make a logical decision on whether or not they want to do that. And if it's worth it to them, right? How important is it now? And sometimes they'll say yes, and sometimes they say no, but if you don't have that process, that change process in your project management today, you need it, because that scope creep is going to happen no matter what, especially when they get their hands on it the first time and they start playing with it. They're gonna be like, what about this, what about this, and so having that formal methodology, it doesn't have to be formal. You don't have to have a set meeting and you don't have to, you know, have a set process and all of that. It can just be simply, hey, when you request these things, I'm going to go define what the, I'm going to take a day or two, figure out what the impact's going to be, come back to you so you can make a decision on whether or not you want to move forward with all the information in front of you. And they may say yes to everything, and great, you have job security for a lot longer than you thought you were gonna, you know, and so don't get upset when those things happen. Scope creep is going to happen, no matter what. Change is going to happen. No matter what. I have never in my life in the 25 years I've been doing this had a project end up the way we thought it was going to end up when we started. So never once. There's always been something we've tweaked, changed or modified. So just know that's gonna happen, and just be ready to respond when it does. And it's not your job as a project manager to say no. It's not. You don't own it. You're running it, you're accountable for it, but you don't own the original scope. And so going back, and letting them make an educated decision with the information you can provide is the best response.
Tim Bornholdt 54:13
That's really well said because I can tell you, you know, we've been doing this for 9, almost 10 years now. And at the beginning of when we started out, you know, we didn't, Rob and I didn't have any experience doing project management or you know, besides what you do in school and stuff. But it doesn't feel like the real world. When we were doing like real world building out apps, you know, you expect here's the project and here's what we say we're going to build and then that's what we're going to build. But then you quickly learn that nothing ever goes exactly according to plan because new variables come up or, you know, Apple or Google drops something new in your lap or just the world is ever changing. And you know, we would always get upset because we didn't really have a process for dealing with change. But we have evolved now, to the point where, yeah, change is good and accepting change as an inevitability and having those kind of parameters around how you deal with change and saying, okay, you know, you're changing the scope. So that means inherently, either the timeline is going to change or the budget or both are going to be affected, because we're going to need to do more work. You know, most of the time, that's how it works out anyway. So it's figuring out how to lay out those facts clearly, so that everybody is clear of you know, how this impacts time and budget and deliverables. And once you get buy in, then like you said, it's just added job security. I don't know why you would get upset about it. Because, you know, I guess if you're the one that has to add budget or timeline or something, then that's one thing, but at least you understand, like you made the change. So there you go.
Renae Livingston 55:52
Right, right. Exactly. Yeah, I think that, you know, that a lot of folks that I work with, they see, you know, the end in sight, and they worked really hard on whether you're a developer or an IT person or a trainer or a project manager, worked really hard on defining what it is, right? And you spent a lot of energy and effort and then somebody comes in and wants to change that wheel. We all know how fun change is for a lot of people. I live and breathe off that. But for some people, it's really hard. And so people struggle with that. And I have found when you can give them a process that says okay, well, it's okay, first of all, breathe. Second of all, let's define what's going to happen if we make this change. It gives them a little security around that. And so knowing that things just aren't going to willy nilly be thrown at them, that, hey, we're going to follow this process every time and it's not a bad process. It only takes a little time for us to figure out and then, you know, know what's going to happen in the long run. And we have something documented or confirmed on how we're going to move forward, you know, it's a lot better than just letting things happen.
Tim Bornholdt 56:56
I couldn't agree more. One final kind of topic I wanted to touch on was, I feel like you rely on lots of data to, you know, influence your decisions, coming from just different viewpoints and different stakeholders, different users of the software. Do you ever struggle with analysis paralysis, or like having to deal with just, you have so much stuff on your plate, like, what's the first next step?
Renae Livingston 57:23
Yeah, I think every day everyone has that problem. And do I make mistakes even after that? Yes, every day. I think over time, you learn to trust what you trust, right? And you learn to understand what your gut's telling you. And so the data is the data and it always will be and I am a data girl. I love my data, I love my facts, give me the numbers, but in sometimes you just got to move forward. And so I use the data as appropriately as I can, as long as it's not going to impact my decision making. I hate to say it that way, because it's so vague. But if I need to make a decision on, for example, which way to go with, you know, a development task, are we gonna go this way, and possibly impact user experience, or are we going to go this way and spend more time and money. You know, the facts helped me make that decision, because they provide the foundation on what I'm going to base the decision on, but it's really about the people that you trust, the people's, you know, their opinion, and doing what's right in the long run, you know, so sometimes you spend more money and time on something that you never even thought that you didn't think you had to, just because it's the right thing to do. And it's going to make that experience better. Even though the facts tell you that, you know, you're going to put the schedule off, or you're gonna spend more money than you thought. So you kind of learn to deal with those things.
And I do look at a lot of data, a lot, but I learned over the years where I should, what data is important to me and what's not. You know, I learned to trust what I trust, and I hate this. It's kind of weird how I put that but, you know, I know when I get an estimate from, this is kind of a bad example but when I get an estimate from Fred, I'm just going to make up a name, that I need to add a little buffer to that. And you learn to trust the numbers and you learn to understand the people and you learn to know what data is important and what data is accurate, just from experience in working with the same people and working on similar projects and then doing it over and over again and you learn to focus your attention on the data that's gonna really help you and make sense and help you make the best decision possible. But in project management, especially, you can look at cost 1000 different ways, you can look at budget 1000 different ways. And so you really just need to focus on what's helpful for you to lead, and to make good decisions and helpful for your customer to understand what's happening, and really those, if you're doing those two things, that's all you need.
Tim Bornholdt 1:00:18
It is really. I laughed when you said, there's like, you know, it's the classic Fred coming in with an estimate that's very generous for getting things done in a very quick time. And, you know Fred, that he's going to be, you know, 10 hours more than what he had projected. And so you start to, again, kind of put those buffers in, but yeah, I think a lot of times, going from 2000 to 2020, there's this kind of like worshipping at the altar of data, and just kind of taking data at face value, and not really humanizing it a whole lot. It's just like constant AV testing, and going to the median and all that stuff. And like you said, I think a lot of times it comes down to, you have to look at the numbers. And sometimes the numbers tell a very clear story. But as anyone that has ever taken statistics classes can attest to, you can make the numbers say whatever you want to make the numbers say. You know, you can tell whatever story you want to with whatever numbers you've got, and at the end of the day, you have to kind of just trust your gut and and trust the people that you have surrounding you to make those right decisions and push forward and know that you're gonna make mistakes from time to time. But as long as you have that team, and you've built up that trust, and you're trying to do the right things, then things kind of shake out the way they're supposed to.
Renae Livingston 1:01:42
Exactly. And I use assumptions a lot. So if I'm scoping out a project, I document assumptions. You know, this is why we made this decision. Here are the assumptions that supported it. Because you always have somebody say, Why didn't we do that? Why? Especially if something fails, like you go live with something and it just crashes, like, why did you make that decision? And then you go back and you say, well, the information we had at the time was this. Right? And here are the assumptions that we made and why we went that way. And that's a good learning experience. And, you know, I can't say enough about a lessons learned meeting. I know we're talking more about data, but I use lesson learn results on my projects so many times. And if you're not doing that you need to be, so at the end of every project, a few weeks after the projects over, give everybody a chance to grieve. And then you come back and you say, what did we do really well? And what did we not do so well? And then I always identify action items. Here's what I'm going to change next time, here's what we're going to do as an organization tomorrow, you know, this is what we're going to train somebody on before we do this project again. And lessons learned is one of the most valuable things you can do at the end of a project. You've learned so much and I've been in the last year, there's been two different projects where I pulled out lessons learned from a previous project and just read through it just to ensure I don't make those same mistakes again. And so you know, that's data that I hold valuable and you don't use everything from lessons learned. Sometimes it's just everybody coming together and venting, and that happens. But in other times, you can pull so much really good information off of their own things that you need to improve not only as a project team, but as an organization here, you know, we need to do a better job of ABC because you know, we always struggle here, right, and you start to see that pattern. You start to identify ways of continuous improvement for your projects for your methodologies and for your ultimately your organization on how to be better.
Tim Bornholdt 1:03:52
I can't agree with you more. The projects that we have done post mortems on or lessons learned on, it's invaluable and you do kind of go back, like sometimes you kind of hit yourself in the head when you pull out one from five years ago. And it's like, well, we literally did the same thing again, like you know, if you're not doing it consistently and and preaching those lessons and actually making changes, then you know, you're probably not growing much. But yeah, we've pulled, you know, we've moved our organization so many ways from these kinds of lessons learned meetings, and yeah, you're right. Sometimes they're just kind of ranting and getting some heat off of you from what has been built up over the course of a stressful project. But, you know, sometimes those stresses are the ones where it's like, well, do we want to feel that stress again? Do you want to feel that heat again? Well, then what do we need to do differently next time so that you're not feeling that heat and we're all happy and moving the project forward together in unison?
Renae Livingston 1:04:52
That's exactly right. The other thing that I look at, that I look at it data wise on a project is, I require all projects to define my sponsors, my project donors, before I start the project, before I do the kickoff, tell me success criteria. What does this successful implementation look like? Give me two or three key things you're expecting to see improvement on once this goes live. And it can be everything from, I'm expecting to see a 5% increase in revenue, or, you know, I'm expecting to see efficiency on my team go up by 10%, you know, whatever you can physically measure, it has to be measurable, you have to be able to report on it. You know, you can use your SMART goals here if you want. But I always make them define success criteria. Now, a lot of people do that, but then they don't do anything with it, and what I also make them do, then I set reminders of your SharePoint. I set reminders that, you know, I put all my success criteria for a project in a table, and I set reminders on it that are based off of the due date. But when it seems, you know, appropriate, so if we're going to increase revenue, so if your measure is we're going to increase revenue by 5% on this product, after six months of launch, right? It's something that's simple that six months after you go live, you're going to set a reminder out there, and you're going to say, Okay, I want you to go run these numbers and did we hit 5%? And then we pull together and we say, Why didn't we? What went wrong? And so that's another way of focusing on continuous improvement. How do we make our processes better? Did we just estimate inappropriately upfront? Do we need to improve? Was there something about the product that didn't go well, and we need to learn from that? Is there something we can do on the next product release that will help us know more about it? You know, those types of things are the types of questions we ask when we have those success criteria reviews.
Tim Bornholdt 1:06:52
Renae, I could talk to you for like a whole other hour because I feel like I am so lucky that I just got this hour to learn from you about good project management, how to be a good project manager and I mean, Profile is super lucky to have you, too. So I'm really grateful that you were able to hop on the show today and talk with us some more. Do you have any last pieces of advice for the audience or any ways that people can get in touch with you if they've got any questions?
Renae Livingston 1:07:18
If they have any questions, feel free to reach out. I love helping people. I would love to answer any questions. You can reach me at my personal email address if you'd like and it's email@example.com. And I'd love to help you out or answer any questions that you have. And I think just final thoughts for any of those organizations that are kind of doing project management or thinking about doing project management, I would tell you that it is absolutely valuable. It provides your organization with a repeatable, successful process that's custom for every project. And so I know that's kind of a counterintuitive way of saying that is that yeah, it's repeatable, but it's unique and custom. But essentially a methodology, project management methodology, and project managers are just that they create a, they define a process that's based on success. And that we can customize based on the unique needs of your project. And so if you're, if you're not doing it today, you should be. It only helps organizations become better and more efficient. There's so much waste out there. And in organizations today where they try and do a project and it fails for a variety of reasons, and project management helps you become much more successful, 70% increase in success rates in most industries when they implement project management methodologies. So that's one thing I would tell you on.
Second of all, partner with a team. If you can't do the development yourself, partner with a team that you can trust that you can rely on, that is willing to communicate back and forth with you and that is scalable, and will work with you on your specific needs for your organization, like Jed Mahonis's team knows. It's so important to work with somebody that you can trust and that will be willing to communicate and be a part partner with you in the development efforts that you have. That'd be my two closing thoughts.
Tim Bornholdt 1:09:19
Again, your check's in the mail for those kind words, and I really appreciate you again coming on today. Renae, thank you so much.
Renae Livingston 1:09:27
Yeah, thank you, Tim. I appreciate it.
Tim Bornholdt 1:09:30
Thanks to Renae Livingston for joining me on the podcast today. You can learn more about Profile by Sanford by visiting profileplan.com. And you can reach Renae directly at Renaeliving@gmail.com.
Show notes for this episode can be found at constantvariables.co. You can get in touch with us by emailing Hello@constantvariables.co. I'm @TimBornholdt on Twitter and the show is @CV_podcast. Today's episode was produced by Jenny Karkowski and edited by the kaleidoscopic Jordan Daoust. This episode was brought to you by The Jed Mahonis Group. If you're looking for a technical team who can help make sense of mobile software development, give us a shout at JMG.mn.