 I'm Janine, I am a project manager at Big Boom Design here in Asheville. I've been at Big Boom for about two years and it's my first project management gig. I'm really excited to be here with you guys today as a new-ish PM because I know we all struggle with the same things at pretty much every level. Project-based work is hard. Getting projects to be good and not bad is tough enough that my job exists. We are a small team of eight, all local, so most of us wear different hats. Some of us are remote or have different office schedules. So it's a fairly complex management predicament but easier in a lot of ways. We all have some sympathy for each other. I think a broader grasp of what everyone does and a better sense of what we each don't know, I think, because we've all had our hands on all these different problems at different times. And it's lucky for me because folks in other companies admit they don't see the value in what I do. My favorite project management podcast, the PM happy hour, recently recapped a survey conducted at the PMO symposium, which is this big conference for big companies talking like employees in the thousands that have like a dedicated project management department. Over half of respondents on the survey said that project management is a roadblock to getting work done or simply an administrative position. And given what they found, maybe there's some truth to that. Another question they asked on this survey was about dealing with fires. They wanted to see if there was a correlation between the maturity of a team and the number of fires they dealt with in their day-to-day project work. They expected to see this inverse relationship align, whereas a team gets more experienced this guy. So as a team gets more experienced, no, you're on the other side of this. So it starts here, goes that way. So they expected to see this inverse relationship between the experience of a team, the maturity of a set of processes and the number of fires going down, starting with the least experienced, the newest teams, the most experienced, the most developed processes, least fires. That's what they expected. But they didn't find a line. They found a curve. So the line started with the least experience and the least developed processes and dipped for a while. And then at the other end, where you would expect people to not have to deal with this, they found the line going way back up. So that ended the curve, obviously, as well out of my experience. You know, team of eight, like I said. But as I try to solve problems for my small team, I do try to keep in mind that statistic. It's a good reminder that it's really hard to assemble and work as a team with clients and deliver great projects on time for everyone. And it's the people we're really going to focus on while we're connecting these dots between them, the people, the work, and the tools we use for project management. I'm really convinced that you don't have to spend a lot of money on project management tools to deliver value. Because what happens when you choose bad tools? For us small teams, we are probably sharing tools that have to serve our entire team. You know, it's not like being at a big enterprise level company where your tools are your tools and everyone else's tools are their tools. So we're asking our teams to interact with our tools, like for time tracking or status reporting. So in another survey conducted by a professional research company, EG2, half of respondents said they were unhappy with the software that they felt forced to use at work. Another 25% admitted that they had left or considered leaving their jobs just because of those tools. So now we're not just talking about project fires or simple team inefficiencies. We're talking morale, productivity, and turnover, which are huge expenses for companies. So our choices here are critical to the success of more than just our projects. So where do we start? One of the first things I did as a brand new project manager was order some books. Because it's 1897 and I like books. One of the first books was the Project Manager's Book of Forms. I marked nearly every form on nearly every page as something we should do. My boss was so excited. I typed up voluminous documents based on those forms that nobody understood and that I didn't have time to maintain. I argued pointlessly in meetings for adherence to these processes that I had never actually tried. And what I didn't do, I didn't ask questions. I didn't talk to the team. I didn't try to find out how they work and think about work. And I didn't try to find out what tools they were interested in using and how those might solve some of what I saw as my problems. But I was referring to this heavily marked paper real life book to solve. Once I started taking this approach of actually talking to people, I started seeing progress. People were buying into good ideas, contributing good ideas. Projects still had problems, but not always the same problems. Once I started leaning on my strengths and thinking about project management as a design problem, a communication problem, a people problem, I was able to start establishing a system that could give me the information I need to do my job and a system that my team can really own and grow with me. And as you all know, stakeholder buy-in is key to project success. So here's another example. I want to tell you a few more stories about this point that I'm trying to make, right? So how about the time we signed up for a year of an SEO reporting dashboard before we realized we couldn't bring in analytics data? Only ad words. I remember using a lot of exclamation points when telling Boomer, my boss there in the back, we were good to pull the trigger. And instead of using this tool and having more time for higher-level work, planning strategy, providing recommendations, we chained ourselves to an expensive tool that only did half of what we needed and we had it for an entire year. I didn't push the team to really dig into this tool before we said go. I didn't take the time to understand the problems that the tool was supposed to solve and the nuances of our circumstances that affected what we needed the tool to do. And that's where we start to come into this design, this project thinking about what we do as project managers. Let me tell you another little story about the before time when I wasn't a project manager but managing at a small knitting shop that used to be outside of Salute in North Carolina. There we had a similar-ish set of tasks to what my Big Boom team does, if you can believe it. We were doing support, helping people with projects and teaching them new skills. We were conducting projects like mostly internal things like inventory, building displays, that kind of thing, and we were doing sales. Sometimes helping make selections and decisions but also literally running a register because it was a store. Usually one person helmed the entire operation from open to close. One of the least useful things we did over and over again every day was interpret product tags for customers. Meters converted to yardage, determining yarn thickness from its weight, fiber content, washing instructions. Yarn companies all have a different way of presenting this information and people don't want to stand there and take the time to figure it out. If they can't figure it out, they won't buy the yarn. But providing this information by me walking over to the shelf and reading it off a product tag wasn't actually helping sell product. And it was derailing the activities that actually did. But it's something that people needed. People needed that information to start making the decisions that actually led to those sales. It was my job to provide the information but not my only job. The tools that used to solve this problem weren't exotic and the idea isn't original. I just made shelf tags with big lettering that answered the five most commonly asked questions about each variety of yarn that we carried. I added some color to make them stand out and people quit asking those questions because they could answer them for themselves. They'd come to me with more complicated questions and actual ideas by communicating, by taking the time to talk to people, take note of the types of things we talked about and the context of those conversations. It was easy to identify basic needs that could be addressed with basic tools. But what do we do when problems and their solutions are bigger than what we can accomplish on our own? Because we're project managers. We're not just by ourselves every day. The point is to coordinate these groups of people and help them work together. And that's where we have to start talking as a group and understand how we interact as a team, what kind of team we're on. It was important for me to understand the distinction between my eight-person team that wore different hats every day and a team where maybe there are more or fewer people but the roles don't really get shared. Once we could start to talk about those things and understand them together, then the solutions we could come up with weren't just like sign up for this service or find this tool. We could solve our problems by using the things we already had. So that being said, you know, tools are cool. Man, they're out there. Let's talk about them. What makes a good tool? A good tool makes sense to your team. They use it as often as they need it. Not having it is more expensive than having it. It does the thing it's supposed to do. And a good tool usually gets better over time. Someone, whether it's your people or someone else's people, are working on it to make it better. So one of my favorite stories about tools is another story from outside of my life at Big Boom. And that's my husband over there looking embarrassed. So this is going to be fun. My husband and I have several different coffee makers. We have an arrow press, a French press, a pour-over carafe, and a couple of in-cup strainers. What we don't have is a drip coffee machine. We tried four years to have a normal 12-cup coffee maker. While we can keep a lot of things clean, like adults, a coffee maker isn't one. On paper, it's not that hard. I still have a strong feeling that any adult should be able to maintain one. And it's handy to be able to make a big pot of coffee for sharing or for storing. However, this coffee machine for us was always, always dirty. We would both avoid it until it reached science experiment status. We talked about it. Who should be responsible for what when assignments were made? In conversation, everything seemed doable. But in practice, it was a nightmare. And it was important to us to resolve this. We wanted to feel comfortable drinking our coffee and making it for other people. So finally, I bought the arrow press. The arrow press is almost impossible to not claim because it's a couple of tubes and like a rubber washer. And you push the grounds through one tube with the other tube. Everything gets cleared out just by using the thing for its purpose. And that's something that I feel like holds an important lesson for project managers. Consider the goal. Is it to do everything a PM should do and make your team go along with what that looks like? Because that's going to be a struggle, especially if you're at a small company or you're a new PM. If you can state your goal plainly in human terms and relate them to the needs of your team and your clients, then you'll be better able to pivot and find the tools that do what you need them to do that don't get in the way of achieving the actual goal. Oh, I do have a photograph for this section. Look at all those tools. But to get back to our PM tools, our work as project managers, lots of people use Google Drive and Google Docs, right? You probably already do. We use it for internal file sharing, collecting content from clients, and more and more for setting up and sharing essential project documentation. Since it records individual access and can save named versions and you could add your own templates in addition to all the other cool formatting and sharing stuff, it's a great option for important project documents. When we started doing this, I was fresh out of reading the project manager's book of forms. It was digital paper. I could use as much of it as I wanted. I tried to get all the way down to brass tacks and those scope docs. They were seven to ten pages long. Nobody read them. They didn't understand them if they read them. Even our team found them completely baffling. No problems were solved. Clients still wanted what they wanted. Questions and loopholes still existed. Assumptions were still made by all. Communication was not made easier or better. So now a project scope for most of our projects is a page. The first paragraph is a summary of the client, the project goals and the agreed approach. The rest of the page is a simple list of what users will and won't be able to do on the site divided by user groups or user roles. Design scope gets handled in the estimate and then through the project has change requests. There is a second page where I can keep running notes on the budget and on those change requests and clients can see this entire document anytime they want. But if I hadn't taken advantage of the tool I had that was already available to me and pushed it to provide this complicated solution and listened to the feedback that I heard and observed the human behavior around it, I wouldn't have known how and what to pair back if I had leapt into a complicated software solution instead of using the simple tool available. We might not have had the flexibility to change course when we needed to. Change would have been that much harder. You know, like that SEO dashboard we were, I was so excited about. Switching gears for a moment, still talking about tools. Who likes reminding people about things they're supposed to do every week or heaven forfend every day? Oh, boomer. That's why we love you. Does it make you feel like the office mommy or pop-up? Well, get you a robot and start automating some of those highly repetitive reminders. I started using a site called automate.io to handle basics like project monitoring since our task management software is kind of all or nothing on the notifications. When we started formalizing our client support system, we divided up the week into shifts and everybody, including myself, signed up for a couple of hours a day, right? So we're supposed to be handing off the shifts and communicating about, you know, tasks that are coming in and all that good stuff. The people are people. It was a new system. People get lost in their other work. Things happen. Shift came and went unremarked. But nobody wants to be the person walking around reminding people to take their turn answering email on the telephone. I didn't want to be that person. Heck, sometimes I need reminders, too, you guys. So I have a little automate.io bot that checks the calendar and slacks people right before and at the end of their shifts. People appreciate the reminders. Shifts are getting covered. Problems are handled. Work gets done. Automating this releases me from being the reminderer, so I can be a person, too. One of the effects of that kind of micromanagement is that people who seem to wield power get held up to the demands they make by keeping myself responsible to the same system as everyone else and using a tool to help keep the system moving. I didn't have to be or pretend to be perfect. When you're trying to solve these people problems, it's easier if you're a person, too. And now I'm going to have a long pause for a drink of water. How's everybody doing? Is that a good word count? Great. So much breathless excitement in the room. So speaking of automation and continuing our discussion of tools, excuse me, I can bang out a pretty good email. I'm not going to lie, but it's a pain to type and retype the same things over and over again. Remember all those details that need to be included, especially for important things like project milestones or team member handoffs for not already using canned email responses, email templates to, oh, man. I don't know what is living in the back of my throat now, but it's not good. Does anybody have any questions at the moment? Oh, that's fantastic, because it's got like... It's awesome. And the free, there's like a free level that's pretty good so you can get in there. Oh, yeah. Yeah, I kind of hate that beer. Oh, really? It just seems so much more straightforward. Yeah. Yeah. Yeah. That's an eternity on the Internet. So we're never going to do it again. Yep. I feel like it needs like 30 days to automatic, you know, capital exclamation points. Does that help? That so helps. I feel so much better now. You got it. Yeah, yeah. That's an excellent question. I will say I don't have a good tool just for that right now. Also, as a new PM, just everybody else just like show yours for a minute. Yeah, he was asking about utilization. So we're talking like workload and like resource management. It's interesting because our task management software, Asana has started broadcasting that they have workload planning now, but I haven't explored that yet. Good question now. Thank you. Maybe it's the wrong time to talk about how I'm a power user after admitting that. I don't know. I don't know. But I do like to really explore the things that we do use. I like to know at least a few keyboard shortcuts and all of my desktop apps. I click buttons. I look at menus. I investigate settings panels. And maybe you think that's a little ridiculous. Probably you don't because you're here. But tomorrow at the happiness bar, come find me. And I'll show you the pointless cap on keyboard shortcut in Asana. It's great. Harvest, our time tracking and invoicing software can also record expenses and automatically include them on invoices with dates and receipts and everything. You know who wasn't using Harvest to automatically invoice and expenses? Us. Perfect solution right there in a tool we were all already using. It is worth it to spend time with as many of the tools you and your team are using already as you can, especially if you're thinking about pursuing other tools. Also, keep an eye out for blog posts and go ahead and sign up for some email updates. They'll let you know when new features are rolling out and how to get or find them. If they don't, then you know you may outgrow that service or software eventually. But you'll have a better sense of how far you can push the thing that you're already using. This is going to be great WordCamp TV. OK. So we talked about Asana briefly. We've been using Asana for, I think, at least five years. It is task management software that's recently started evolving to be more of a project management solution. Several times, past big boom managers had tried to keep a master client list in Asana. Basically, a project set up just to list out each project or active client. There wasn't a way at the time to get that kind of information out of Asana without either doing this kind of hacky thing or building something outside that used the API and pulled information out of it. So this project of project never really worked, partly because it was not just active projects. It was all clients. And those two lists, projects and clients, they should do different things. They should be different things. The alternative to the project of projects was to prep a list for every update meeting, which takes time and multiple team members and turns those meetings into status reporting slogs instead of strategy or problem-solving sessions. Either way, I made my project status reports. They were time-consuming and siloed data away from the rest of the project information and the team. The only way for my boss to get this information was to schedule a meeting and get a list. So when our art director, Sarah, suggested setting up another project of projects in Asana, I was like, no, we've tried that. It didn't work. I don't think we should do it. But Asana changed since the last time a BBD project manager tried to do something like this. And our team had changed. So we tried it. And it's kind of working. We update project statuses and their individual Asana projects linked to the latest status in the current project list and only list actual projects. We use Asana's built-in custom fields to show things like budget status and priority. Boomer doesn't have to wait half a day for updates from all project leads to roll in and get compiled. It wouldn't have happened if we weren't willing to respond to change and take note of how the tools we do use evolve and update. Sometimes it's worth trying something again when you know that the paradigm has shifted. So I know I already talked a little bit about our support work, right? And we really are doing a lot to try to make that as easy and awesome as possible. So now that we have the system in place, we've started building some internal company tools based around WordPress sites or plugins. But I like our maintenance contract system because it was fast, easy to build, and solves more than one problem. All we did was build a gravity form on our site, add a plugin that can render submissions as PDFs, and attaches those PDFs to a notification email. Now clients read through our terms and sign and return agreements at their leisure without printing an, oh, my God, Boomer. Oh, is that smearing? Oh, man. Anyway, y'all were about to be real sad when I ran out of water. Now clients can read through the terms, sign and return the agreement at their leisure without any printing and scanning. We're not filing hard copies unless we want to. Our support coordinator, who's over there in the red shirt, doesn't have to mess around with, you know, word templates or, you know, all those other things. We've got a built-in list of who signed on and when. And it's not always a great idea to try to build your own tools. Anyone who's thought, I can make a CRM, I know how to WordPress, knows that it's a huge challenge. Sometimes there are reasons to let other experts make something and then keep on working on that. But you can use your expertise as a PM to think about the business case, right, for making a tool that you need if the right thing isn't available. And DIY it if it makes sense. But I think not to, I think my favorite project management tool, the thing that I come back to the most is communication. And I think that to become a good communicator, you need to practice, right, you need to talk to your team and listen. But also, you know, there are ways to learn about communication and get better at it by deliberately, you know, incorporating some new ideas and thinking about it differently. So making things happen is a great book if you're new to project management or if you want a refresher in the basics. And it is a project management book, right, but a great deal of it is spent talking about how to listen to your team, how to, you know, remember to walk around the office and see what people are doing. Because sometimes people don't tell you what problems they're having. And it puts those communication skills in that specific context, which is really helpful. In a more general sense, I really enjoy another book called The Crucial Conversations that has more, it's more, it seems a little like a relationshipy kind of self-helpy book. But since we are kind of in the middle, right, of these things that have great meaning and emotional importance and business, you know, importance to all these people, you know, our bosses, our clients, our team that's spending all this effort in making these things, we end up in charged conversations more than I think we realize. And when we step back from that and have some deliberate tools, like a framework for actually approaching that, we can better manage how we move through those conversations and get what we need out of them. So we've been talking about tools for a while now, right, and we talked about some specific, specifics, talked about Automate, talked about Asana, we talked about Harvest, we've talked about, you know, some learning resources, some learning tools. Basically, use the tools that are around where you're working, keep tools where you work. The tools are probably already where you're working. You probably just need to look at what you already have. And you are a tool. You are a resource for making things happen as much as any of these software tools that you are trying to employ. Sometimes data is bad. And sometimes it's bad because the projects were bad. It's, you know, it's objective judgment of performance, your performance, the team, the clients, because they're also performing. But sometimes historical project data, like the information that is left when a project is done, is bad because things are missing, or you realize that the way the data was structured doesn't actually tell you much about why a project went well or poorly and why. As project managers, we deal with both types of bad data. And one of our functions beyond managing active projects is interpreting information about past projects to make predictions about future ones. Lessons learned, you know, after a project is over, is really helpful. It can be much more informative to fail than to win. Bad projects ramp up skill sets really quickly because they make the gaps in your knowledge really obvious. But even these good, bad projects can still leave you with actually bad data. So what do you do when you realize you're dealing with bad data and not just good or bad projects? Well, you do the best you can with the information you have. Bad data is still a tool. It's a way to see where people problems have cropped up and a chance to change course. Forecasting project work is hugely problematic under the most ideal circumstances if you've gotten really good at proposals that accurately predict the work, the schedule, and the actions of the client, please let me touch the hem of your garment later and appeal for your blessing. So do the best you can with what you have. Then communicate with your team about the problems you're seeing in the data and the work. Use those conversations to make adjustments or changes. It sounds simple because it is. It's normal to realize that the way you thought something would work didn't. It's frustrating when it's coming from inside the house, but it's normal. Oh, I do have a picture. Yeah, he's got some bad data. It's easier to point to something that's clearly not working and convince people that something needs to change. It's really hard to pull up a good idea just out of the blue and get people on board. People don't like change. And as a new PM, you don't always have the street cred to get people on board with these strategies without that problem to point back to you and say this is why we're doing this thing that we're doing. But when you're dealing with bad data, what you can't do is be complacent or pin blame. It is what it is, is the death now unless it's paired with active plans for change. Don't mistake blame for accountability. Blame is finding a scapegoat and a reason why nothing needs to change because X, Y, Z is at fault. Accountability is stepping up and saying, this can be better. Here's what I think, what I can do, what I've already started doing, what I've asked the team to help with that will make it better next time. In that vein, we use Harvest for all our time tracking, right? In Harvest, there are projects which is a way to group track time together for a specific purpose. Sometimes maybe it's just an open project that's like for ongoing support. Sometimes it's a Harvest project that contains the work done on an actual project. And you can set up a collection of tasks and rates that get automatically added to all new projects. And this is a great way to get consistent visibility into the division of work across multiple similar clients or projects, right? If they all share these same places where time is being recorded, then you can go back, thank you, and look later at what you have done across more than one period of work or time. Our Harvest tasks were a hodgepodge of ideas that came from different people at different times over the company's history with this tool. What should have been the greatest source of historical project data was kind of useless for forecasting. When I had to produce my first sort of year overview of project performance, that was more or less doable. You can find budgets and see, literally, did we meet the budget, did we meet the schedule, all that good stuff. But I couldn't tell why projects were good or bad in that year. I couldn't give a narrative for how projects had played out. What I could do was use that opportunity to highlight in a tangible way how the data had failed us, the human problem underneath it, and propose a solution. Everything on this project build was clocks under the same category as design work because there wasn't a clear task set for development. No one ever asked for clarification or reviewed the entire project task outside of Asana. This was the kind of conversation we had to have during that meeting. It was not fun. But it highlighted the places in the process where tackling people problems could result in better data, better reports, and better proposals and forecasting. It took us some time to get a good set of harvest tasks, right? But eventually, being flexible, responding to results in a collaborative and thoughtful way, committing to seeking and making tangible changes rather than submitting to change by entropy, it was a project management tool. And I've got two minutes. So, what I'm going to do is say, I was actually pretty surprised by how much I enjoy project management. All my training up to two years ago was for making things and not managing anything. So, even though I'm up here, and normally this is the time when people say, I'll be at the happiness bar, if you have any questions, if you have a session, I want to turn that around. We don't have much time here today, but I'm checking into sickbait tomorrow morning. And I would so love it if anyone of the people in this room who have been doing this way longer than me just come and let me ask you about what you know. So, what I'm hoping, aside from, you know, helping me, please help me, is that you'll have some things to think about to make your own tools work for you without having to spend money on new things that maybe don't pay off. And that's it for me. I'm Janine. That's my cat. Have fun the rest of the afternoon and an awesome work camp.