It’s hard to believe that a few short weeks from now, I’ll be saying goodbye to Oak City Labs and the technology industry as a whole. For the better part of nearly the last decade of my life, I’ve been a project manager in this industry. (To find out where I’m heading, visit my last post here.)
To close out this chapter, I thought I’d share ten things I’ve learned as a project manager during the past ten years. So, in no particular order…
- Iron Triangle: A project manager worth his or her salt is more than likely familiar with the iron triangle. The quality of any project is determined by a combination of three factors: scope, resources and time. Making a change to any of the three will always impact the other two. It’s important for both the internal team and client team to be mindful of this and have clear expectations going into a project. This visual from Atlassian does a great job at illustrating the iron triangle and how it differs depending on if the project is being managed with a waterfall or agile methodology.
Source: https://www.atlassian.com/agile/agile-at-scale/agile-iron-triangle
- Waterfall vs. Agile: Speaking of which, I’ve definitely learned the difference between these two methodologies during my tenure as a project manager. I started out in the waterfall world, but found a comfortable home in the agile world. Here at Oak City Labs, we manage projects using an agile methodology. To find out the difference between the two, visit this blog post we wrote last year which still holds true today.
- Relationships: In this role, it can’t be stressed enough that relationships are everything. The relationship a project manager has with all involved parties is often the difference between a successful project and a rocky project. A project manager is a liaison between the internal team and the clients – balancing the needs of both and the requirements of the project. Having a positive, productive relationship with all involved is crucial.
- Testing: At Oak City Labs, my role extends beyond the typical project manager role and involves handling a majority of the testing for our client projects. I’ve always thought the two roles compliment one another as testing requires keen attention to detail, significant level of thoroughness, and ability to effectively communicate with software developers and beta testers alike. I believe testing is vitally important and is one of the major factors that can influence client confidence in the product they are paying to build. Testing on multiple platforms, across multiple use cases, with multiple scenarios can’t be underscored enough.
- Flexibility: A project manager’s ability to balance the ups and downs of a project isn’t something they teach you in school. Sometimes unforeseen circumstances prevent a sprint from being completed. Sometimes content is late. Sometimes you have to pause and wait at the mercy of the powers that be at Apple for approval. Staying rigid is often more harm than good. As I reflect back over my years leading projects of all shapes and sizes, flexibility was always needed.
- Sense of Humor: I’ll keep this short and sweet. Sometimes projects get tense. Remember to have a sense of humor and send a Minion gif to break the tension.
- Big Picture: As a project is humming along, it’s easy for clients (and us!) to get bogged down in the details. But when a delay arises or additional work is required, remember to always help clients keep the big picture in perspective. Yes, it may take an additional week to work through an unexpected additional feature, but perhaps we can make up that time later on in the project by removing or delaying another less significant feature, expediting and working ahead on deployment, etc.
- Documentation: There is no such thing as too much documentation. Okay, maybe there is, but my point is that documented approvals are a project manager’s best friend. This isn’t so we can say “gotcha, haha!” later on when a client is adamant about something. No – it’s so we can all take pause and be thoughtful about the decisions we are making during a project’s strategy phase and be mindful of those decisions when changes are discussed.
- You Don’t Know it All: As a project manager, you are not responsible for knowing everything about everything – or even every detail about the project. You are responsible for knowing the limits of what you do know and for connecting with the right people who know the answers. It’s okay to tell a client, “I’m not sure, but I’ll check with Jay on that and get back to you.” It’s not okay to guess.
- People: At the end of the day, you’re really managing people – not projects. Never forget that.
