As a Delivery Lead with 9+ years of project management experience, Shannon Kubenez shows you how to successfully manage a software development project even when you think the cards are stacked against you.
Want to see more talks from LabsCon 2019? Check out our YouTube Playlist.
Welcome. Thank you for sticking around. I bet you didn’t know that you could leave at any point, so thank you for being here. No, but really thank you. I’m Shannon Kubenez, Delivery Lead at Detroit Labs and it’s been a full day of great talks, so much great information in different topics, so I appreciate you being here. My topic is To Succeed or Fail: A Labber’s Guide to Project Management Success.
So a little bit about me. I’ve been a Delivery Lead at Labs for nearly four and a half years. And I’ve held various positions in project management for almost nine years. I’m a flower enthusiast, hiker, nature lover. This is a photo from my vacation the summer at Waterton Lake. This was the last hike I went on. I swore the entire time, but then I got to see this beautiful view at the end.
But most importantly for the purpose of today’s talk, I’ve been in the midst of projects going wrong, so much so that over the past couple of years I’ve had a lot of labbers come up to me and say, “You always seem to get the hardest projects and you’re able to make them successful.” And that’s a big reason why I decided to create this talk. But it’s not the entire story because in each of those situations I had an entire team behind me doing the work.
The truth is that every single project has its own challenges. There are all sorts of things that can get in the way of project success. And honestly, I don’t know a single person who’s been on a project that hasn’t experienced an oh s* moment. And I’m going to refer to these as OSMs from here on out because I don’t want to keep swearing throughout this entire talk. Elyse is trying to get some good sound bites for marketing. So I don’t want to ruin that.
So it’s because of these OSMs I’ve experienced and what I’ve done in that moment and what I’ve done after that moment and what I’ve done when I’ve taken a lot of time to look back and reflect on that moment that have directly influenced the contents of this talk. This is not a delivery lead talk, just to be clear. This talk is for everybody and it’s regardless of your position within our company and your role on a project team. I believe you can take these core concepts and put them into everyday, your everyday work.
So before we begin, during this conference talk, we’re going to look at five key steps for project management success. But before we do that, I want to just take a little bit of time and I want you to think about a challenge that you faced and a project that you were on, like a seemingly insurmountable challenge. Think that Jira card was really hard to implement or it took longer than we thought. Think bigger than that. And this is going to be only for your knowledge. I’m not going to call on you and you don’t have to tell the person next to you, but we’re going to keep coming back to that moment. So I want you to identify a really good one. So we’re going to take 10 seconds and I want everyone to close your eyes and think about it starting right now. All right. Open your eyes and if by chance you don’t have one or couldn’t think of one, you can borrow one of mine that I’m going to share with you and you can think about what would you do in that moment.
All right. So the five key steps and I’m going to walk through today are be success oriented, have realistic project expectations, be a solution oriented, do the hard work and build great relationships.
Let’s begin. The first one, be success oriented. And what is success oriented exactly? Some people may call this the power of positive thinking or positive thinking and to be absolutely 100% clear, I’m not talking about a naive pseudo-optimism. I’m not talking about putting blinders on and pretending that everything’s okay. I’m not telling you to ignore the difficulties and challenges that you’re faced with. What I’m saying is that in spite of the challenges that you and I know are going to come up, we think success is still possible. And when we’re faced with the challenge, we can visualize a successful outcome at that moment. And it’s saying it’s going to be okay because we’re going to do X, Y, and Z. And even if we don’t know what X, Y, and Z are yet, we know we’re going to land there.
And sometimes this is not our immediate thinking. When you’re hitting like a big challenge, you may not think, oh yeah, it’s totally going to be cool. We’ve got this. It may take a few hours to process what’s happening on a project when that moment hits, it may take a day, but we have to land there.
So the problem with negative thinking is that you’ve already decided that you’re going to fail and your team is going to fail and the project is going to fail. And that’s going to come through in whatever way that looks like for you. So if you have a negative mindset, it’s going to impact how you interact with people on your team and how you talk to a client. It’s going to come through, whether that’s anxiety, withdrawal, sleeplessness, and it’s going to eat away at you.
So negativity also excuses us from doing the hard work. It’s like putting up a wall and saying, “We’re done.” If you say there’s no way this is going to work, it immediately shuts down the possibility that success is possible. Instead we need to be success oriented so that we can move towards doing the work. We need to move towards doing solutions. So this is the starting point for you and the entire team that you’re on.
So here’s a story about a real life situation. A few of us on the team went out to visit the client and at the end of our meeting, we met with a product owner and the CEO, and the CEO said, “Hey, our API vendor is going away and we don’t know which one we’re choosing yet, but it has to be completed by X date.” And we have every reason to say you’re out of your mind and we had a lot of reasons to say no. We could have said no, we could have pushed back.
But in our case failure was not an option. The fact is our team and teams before us at Labs had worked on such a quality product that it had four star reviews in the app store. And they went through, the first team on this project went through blood, sweat and tears to get it to where it was. So failure’s not an option for that reason alone. The other one is that the client would lose money, it would lose sales immediately. And the other one is users would essentially not be able to use the app at all.
So saying no and agreeing to failure was not an option. So the hard work became, I remember we had to… we took back this information and we got into the car and we’re like oh, some choice words. All right. I think we made some serious faces like oh my God. But then it wasn’t an hour or two later and on the drive the next day to the airport where we were starting to talk. How do we get this done? How do we get there? And we could not have done that without thinking for a second that it was going to be possible.
So we talked about the work we could start doing now. We started talking about which features can we remove that would not impact the user. So let’s start being proactive and getting that list out, because chances are we’re going to run out of time, so let’s get ahead of it. Another lever we could pull is can we add people to the team? Would that help at all?
So I want to think back to the challenge that you personally identified. And I want you to think about it and then ask yourself these questions. What was your mindset when the challenge became known? What was your immediate mindset and then what was your eventual mindset? And then how did you act?
There are three things you can do to be more success oriented. So if you’re not feeling very positive, say something, talk to your team about it. Allow it to be a discussion where these feelings can surface and if you’re not feeling positive, you can get insight from the people that are on your team. What are they seeing that you’re not seeing? What is the plan to get there? That’s the next step that follows that. And practice it. Practice being success oriented, because if you are negative in your day to day, when a challenge comes up, you’re not going to immediately be positive. So practice being positive and the small stuff.
Let’s say you have a really important client meeting and you’re worried about it and you’re like I’m not sure how we’re going to get them to buy into the solution we’re presenting. That could be a small moment where you can build on confidence. When challenges come up and they’re going to, visualize success for that challenge. What does it look like for the team to move beyond it and get to success?
Number two, have realistic expectations. So raise your hand if you’ve ever been on a client project at Labs, before Labs, in a former life. Keep your… okay. Keep your hands raised if there was never a production issue. All right, are we good? We’re good, okay. There’s a lot of stuff that’s going to happen on a project. The API we relied on was always stable and it never failed and it was built to spec. There was enough time to implement the features that we wanted or the client wanted.
Okay, perfect has never happened and it’s never going to happen. There are too many variables that exist, that will need to exist for us to have a perfect project and there are so many things outside of our control. So it took me a while to figure this out, but when I finally realized oh, this is just what a project is, is these series of challenges, I was in a better position to respond to those challenges. And I’m not saying we shouldn’t do whatever we can to prevent these things from happening, but I’m saying that it’s not uncommon for us to experience these challenges and have to work through them. So what you’re experiencing has happened before, has affected many people on every single project.
The truth is that even on a project, even a successful one, you can expect a ton of things to come up. The client not being in a product owner role before and not knowing what a product owner is supposed to do and have other responsibilities that take up their time beyond our project. The features that the will need to build are going to change over the course of the project. Expectations of what the team will deliver will change and we’re going to need to work with a client on modifying scope in order to hit a date. This is every single project that I’ve been on it Labs. There’s going to be API issues and dependency delays and even beyond that, we’re going to have to have uncomfortable conversations with the client. Just know it. And it’s not going to feel great, but we’re going to do it. And we’re going to have to have uncomfortable conversations with each other on a team. We’re going to have to give feedback.
And knowing these things are likely going to happen, should remind you that while annoying and frustrating, these are common problems we’re going to have to solve and they’re not specific problems to Detroit Labs either. This is everywhere where software is involved.
So you’re not alone. This means that you and your team are going to be able to pull from previous experience and apply similar solutions that worked in the past or fix and modify the solutions for your team. We’re going to be able to pull from each other.
So on one of my client projects. We had a kickoff and we all agreed the client agreed variable scope. And we left having a prioritize feature list. Two months later we get a call from the client saying, “Headquarters will not even look at the app unless that has this set of features.” Variable scope just went out the window. He essentially was saying my job is on the line. My reputation is on the line. The project was at risk. We wouldn’t continue working on this, if we didn’t get those features then by that date, that that project would be gone. So we got to work.
The team, we had an internal meeting. We talked about it wasn’t a oh God, how did this happen? I thought it was variable scope and now it’s fixed scope. It was, okay, how can we help our client be successful? So how can we look at these features in a different way to reduce that estimate and make them easier to implement? So we didn’t waste any time. We got to work and then we collaborated with our client. He came into our office and we said, “Okay, let’s talk about these features again. We need to get the scope down to a reasonable level in order to have a shot at this.”
So let’s go back to the key moment that you identified. Was it the first time you experienced this? What about people on your team, your challenge, did other people experience it before?
So there are three things you can do to have realistic expectations. Recognize when you’re experiencing the same challenges over and over and over. I read all of the retro notes and I’m like yep, I’ve been there. Yep, I’ve been there. Record common themes or experiences as you work from project to project so that you remember them. I remember I had to have a tough conversation with the client about scope. What did I do? How did it work out? What do I need to change in the future because it’s going to happen again. Consider sharing experiences with people on your team or that are in the same role is you, so we can learn from each other.
Step three, be solution oriented. So this is different than being success oriented because success oriented is a mindset or an attitude. Solution oriented takes us from that and moves us into action. It’s the how-to achieving success on a project. It’s how are we going to accomplish and get through this challenge.
So before we get to solutions, I have to say that one of the biggest things that stand in our way is not realizing there’s a problem at all or hoping it’s going to go away. Like oh what if I don’t talk to the client about scope and we just pretend we can hit this date, even though I know we’re not going to. Those are just going to morph into bigger and bigger and bigger issues. And that could ultimately result in the client losing trust in the team and the client losing trust in Detroit Labs. It could impact team morale and more.
So it’s very likely you’ve had at least one moment on a project where you’re like something in my gut is telling me something is not feeling right. So typically with these big challenges, the whole team needs to be involved in coming up with solutions versus one person doing it. And it’s a good thing too because we can leverage and pull from each other’s perspectives and lessons learned.
So in the last story we met with a client and collaborated with them on how to reduce the complexity of features in order to get the estimates down so we can have a shot at hitting the date. And we needed to do that first, before we even had a shot at hitting the deadline and getting the app reviewed by headquarters. It was also at this time we pulled another lever, another solution of let’s add more people to the team to build the watch app. Let’s pull all of these solutions and get this done.
So in the key moment you identified, I want to know, I want you to think about who is responsible for coming up with the solution. Was it the delivery lead, was it the delivery lead and one developer? What part did the team play? And what part did you play in it?
So there are three things you can do to be more solution oriented, like truly believe the problem can be solved. This goes back to the first step. That is your starting point and it’s coming back here. Brainstorm solutions as a team. That is one of the benefits of having teams at Detroit Labs is that we’re all working together and figuring it out. View the problem from a big picture perspective. So what would happen if the problem goes unresolved? Can you think about that? Can you see it from this view? Because in our view, in this scenario the client could have lost their job.
Step four, do the hard work. So you’ve identified a problem and you’ve come up with a solution, but all of that means nothing unless you’re actually willing to implement the solution. And then these OSMs or big challenges, I will tell you the solution is hard. It is hard work. It’s not just one fix and one call and we’re done. And doing the hard work is not just the job of one person. It’s the whole team doing this work. Because this is happened to me a lot in the past. What I’ve noticed is a gut instinct that will not go away. It tells me I need to take action and I need to do something now and it will not go away until I’ve done something. And it is the best and the worst feeling because I don’t want to do it a lot. Like it’s hard to do it. But it’s the best because I have a built in detector that tells me, “Hey Shannon, do something. Fire, fire.” And it’s the worst because I have to do the difficult stuff.
So here’s a story where I was on the client project and the API vendor that the client used was difficult to work with. And it was difficult because they never considered mobile in their design. And we started noticing… this is frustrating. We would complain about it. This is frustrating, what jerks, I can’t believe they would do this. What were they thinking? And I think we finally decided this can’t continue. We have to fix this.
In this situation, it was not a technology problem. It was a relationship problem. So the solution was how do we build a better relationship with that vendor? How do we build a collaborative relationship where they’re talking to us and we get to give them feedback on their API design. And so the hard work was first changing attitude. We cannot want a good relationship with somebody that we just talk about in a negative way all of the time. So we had to start thinking, okay, really what would they be thinking here? Why would they do that? And we’d go back to crucial conversations of like telling ourselves a story, let’s get rid of the story and start being curious about why do they do that, and then it became okay, maybe they’re not terrible people, maybe they’re actually good. And then it became okay, now we have to start our first step after we change our attitude is saying, “Hey, we want a collaborative relationship.”
But that is not it. This is a long game. This is not hey, we want you to collaborate with us and then we hang up and then it’s done. This is a long game. This is a now we’re being strategic, where okay, we have this feature coming up and we know they’re going to need to make changes. Hey, let’s say something on the demo like hey, this feature is coming up. Can we get on the call next week and talk about it? What would this look like? It was a hey, let’s give feedback. Hey, that issue that was caused, it was because of X, Y and Z. How can we prevent that from happening again? This relationship is a long game.
So it requires… in this situation the hard work was persistence and it was looking for areas of how can we fit into their process and it required work from the whole team. This was not Shannon, delivery lead, you do it all. This is the whole team looking for opportunities and figuring it out. And it really did require stepping outside of our comfort zones and doing what was easy to doing what was difficult. The easy thing would have been they’re never going to listen to us and we’re still going to have to have this terrible API and it’s going to take longer to implement. So in your own example, what was the hard work? Who took action and what was your part in it?
There are three things that you can do to accomplish the hard work. Explore what’s preventing you from doing it in the first place. If it’s a difficult client conversation, yeah, I’ve been there. That’s often what is the hard work. Understand the value of the outcome. In our situation, there’s a high value and having a better relationship with the vendor. It would benefit the client, project and team to have a collaborative relationship. Ask yourself what is good for the client, project and team. If you take away one thing from this talk, I want this to be it, because this is really the heart and soul of it all. It’s what matters most. It’s not about your ego or what’s good for you as a person. All roads lead here and so if you don’t know what to do on a client project, ask yourself what’s good for the client, project and team because it will help you really focus in on what matters.
Step five, build great relationships. And this could be a conference talk all on its own. There’s a lot to this. Relationships between team members and the client are crucial and relationships between team members on a team are important as well to the project’s success.
So project teams thrive when members are explicit in their expectations. We talked about this earlier where we’re using team agreements and project charters to really outline what we expect from one another. When we hold each other accountable, this came up earlier too, when we hold each other accountable to those expectations. Hey, we said we were going to do X, Y, and Z and you’re not doing it. Our teams can benefit from way more accountability.
Trusting relationships are built, and this is not a hey, the team just formed and now we all trust each other. We have to build it. We have to work at it, both between us and the client and us as individuals.
And really and truly caring about each other’s success. So I try to think about, I want people on my team to be successful on the team. I want them to be successful on the project and I want them to be successful at Labs. And this comes through by your actions and not just what you say.
Client relationships thrive when each person on the team contributes to the client relationship. So again, it’s not just the product owner and the delivery lead or the product owner and a lead developer. The whole team plays a part in our relationship with our clients.
When we build a collaborative solution. The best place you can possibly be in on a project is collaborating with our clients when they trust us, when we make recommendations, when we’re working together versus this us versus them mentality.
When we intentionally build trust and confidence, and this again, is not built overnight. This happens on a daily basis in the small things that we do. Every interaction we have either builds trust or takes trust away with each other and with the client.
So trust is not automatic, even at Detroit Labs. We have to work at it and just because the client signs an SOW with Detroit Labs does not mean the client explicitly trust us 100%. We’re spending all this money, we trust them blindly. No, we have to work at it.
So in your own key moment, what part did relationships play between you and other team members and between you and the client?
There are three things you can do to build great relationships. Build trust. Again, this is built every day. This means that you do what you say you’re going to do and you build a reputation all around that. I don’t know about you, but I’m more likely to trust somebody who shows a commitment to the project and doesn’t just say it, but I can see it. And when I know they… when I see and hear and can experience, they’re putting the team project client first.
It also means that you let go of all of your personal preferences when you’re on a team. Again, you consider the client project team in all of the decisions that you make and you incorporate Detroit Labs’ values into the things that you do every day. Really truly care, care about each other, care about our clients, care about the project. I sound like a broken record at this point.
All right. Developing a client mindset. So this is a mindset centered around the client’s goals. The value the team can provide to the client to hit those goals and building trust.
So in conclusion, every project and every project team will encounter things that will challenge them and can stand in the way of success. There’s all sorts of things that are going to come up. But there are things that each person can do to help achieve positive results. Be success oriented, have realistic expectations, be solution oriented, do the hard work and build great relationships. I hope you found this helpful and I would love to get your thoughts and feedback. I want to hear about, if you’re willing to share, I want to hear about your project challenge and what you did.
I also want to give a shout out to Sara who took my slides and beautified them in only the way Sara can do. Yeah. Go Sara. And I picked a lot of brains. I practice this with a bunch of people and I really appreciated their feedback. Stew, lent me his ears, not once but twice. Sorry, but you volunteered to do it. Jackie, Janani, Lauren and Erica. Thank you guys so much. I appreciate it. Thank you for listening and I want to thank everyone who was involved in planning and doing all this hard work. Thanks.