When I graduated from my career, I was considering a professional future in everything from designing video game user experiences and interfaces, to gamifying apps and websites for higher purposes (social improvement, educational, etc.). Never once did the idea of becoming a Project Manager (PM) in a web development company form in my mind, and yet, a year after graduating I was doing precisely that.
Now, there are a couple of mistakes I only learned from by making them, so after 6 months it’s worth noting what I learned, and hope they’ll be helpful to anyone in my position so they don’t fall into the same holes. So here are a couple of basic tips:
1. Know when and when not to answer a client immediately
Being a total amateur at the whole project managing scene, and not wanting to ask “stupid questions” to my supervisor (this was my first mistake), I decided to take on client communications as I saw fit. And of course, ended up committing some serious PM crimes. First off, I would answer a client as soon as they sent an email, this could mean anywhere from Friday at 10pm to Sunday at 7am. BIG MISTAKE. By doing this, the client gained the confidence that they could email me for whatever reason at whatever time. So I had compromised myself and felt obligated to answer them each time, which usually meant sending work emails in my hours of leisure, which no sane person would like to do.
To give a happy ending to this anecdote, I did get a very nice review from the client who was happy with the constant communication, but this could probably have been achieved during actual work hours too, if I had managed it better from the beginning.
On the other hand, since I was so occupied answering some clients immediately, other clients with more pressing matters were being ignored, which of course resulted in frustrated clients and an even more frustrated supervisor. So, balance your time between clients and avoid answering outside of work hours, unless you want them to keep emailing you outside of work hours.
2. Show, don’t just tell.
Imagine you’re building a website and you tell a developer “Could you add a button in the header of the homepage?”. In your mind you know exactly where that button is located, how it will look, what the copy will say, and even what it will look like when moused over and clicked on. But the developer won’t, they may have their own ideas of where it’ll be and what it’ll look like. And believe me, no matter how specific you think your instructions were, the only full-proof way to get the exact results you want is to show them what it is they’re supposed to do. This could be by sending an example or even making a quick mock up yourself. Either way, the importance is in being visually explicit, since not everyone has the same idea of what makes something well-designed on a website.
This tip also goes for when you’re explaining an idea to a client, don’t just tell them what they’re website will look like, show them examples of similar websites or draw it up yourself. Visual representations of an idea are so much more powerful than any amount of pitching you can make to a client.
3. Check, and then check again.
Too many times did I trust that something would work on as website, or thought that something I had already checked would continue to work. Neither would ever be true. Now I’ve learned to check absolutely everything, no matter how trivial it may seem or if it’s a copy of something that works perfectly everywhere else. Whatever is it, check it, check it in different ways, on different devices, and make sure you do a follow up later on.
But this also rings true for teams. If a team member commits to doing something within a certain time frame, never trust it will happen. Always check in and make sure it’s actually being done as specified. Although this is intruding on the Scrum Master territory, sometimes you have to act as both when teams are small and just starting out. Either way, remembering to be thorough is always a good practice, no matter your role.