You know the situation: you begin to make furtive glances over your shoulder because you think they are near; you wonder if they actually understand what it is you do at all, and the dread, moments before the monotonous weekly meeting, surpasses what even coffee can placate.
They are the project managers – the very whisper of whom incite fear in the most hardy of web veterans.
I’ve seen good and bad project managers (PMs): from the micro-managing control-freak prone to panic attacks, to the uninformed motormouth, who spurts buzz words faster than they can be created. I’ve also worked with some incredible people who can forge a mini-utopia from the chaos created by 30 programmers, designers and writers in one room. These folk can read a Gant chart like a conductor reads a musical score and churn out a dead-line driven symphony which, at the end, leaves all involved feeling euphoric and satisfied.
However it’s wrong to assume that we, in the creative output department, can sit back and do what we’re told by our PMs and leave them to tackle everything alone. The pressure is on them to deliver, but the attitude of “I just write the code – don’t blame me for being a scope creep” dodges our responsibility to contribute to the project’s smooth running. We are there because we have specialised knowledge and regardless of the personality of whoever is running the project, we should use it.
How we can help them and ourselves?
Contribute and participate
Why would you go to a mechanic if you were going to dictate to him or her how to perform an oil change? A PM shouldn’t do this to you either. You need to get in early to help define the scope of your own work to avoid nightmares later on. Identify the risks and ensure that the timelines are realistic. A PM might not know that you need four days for bug fixing, or that creating a Flash movie player needs more than one day’s preparation. He or she can’t be over all the minutiae of a task, and, if they don’t ask for your advice before they write technical or design requirements then, it’s up to you to stick your hand up.
Also, ask to have a look at the final requirements before they are signed off. You are not being self-important here – you’re just making sure that everyone, including yourself, understand what the expectations are.
If your PM is new or not up to speed on your area or expertise, tell them what you can do and demonstrate your knowledge through projects you’ve previously delivered. There’s no need to be a complete nerdy suckhole, but it does help to prove to them that you’re not just another monkey looking for a banana.
Depending on the intricacies of what you have to do, you should always provide proper documentation on what you have delivered. When working on the frontend, I try to provide a master document that contains all the CSS and markup rules to which those working on the site in the future have to adhere, along with examples. If they’re integrating your work into a backend application, programmers will love you for it and content managers won’t be able to complain later that they didn’t know that there was a class to style their images. As you can probably guess, this will facilitate everyone’s role and thus make the PM smile.
Meetings can be a bore, particularly when they focus on an area you’re not working on; large team meetings don’t usually provide an opportunity to go over everyone’s issues. But it’s not hard to email your PM when you discover something useful – such as an alternative solution to a problem that your team is experiencing. Many times they won’t care what technical solutions you offer then so long as you deliver whatever the functional specification says. But if you talk their language – budgets, timelines, making the client happy and so on – you will get through. For example, you may raise the risk that the groovy new AJAX application will not be accessible to everyone and argue that:
- you can raise the exposure of your client’s website by modifying the application to cater for screen readers and provide alternatives to AJAX-generated content for search engines
- the return on investment from the three days of extra work will come in the form of status (you’ll get a better solution) and money (it’s easier to implement a fix while the site is young rather than six months later)
Will they love us or hate us?
Anything you do to make the hectic life of a PM easier will reward you with positive vibes. Some won’t like what they perceive as ‘meddling’, and they’ll employ the old chestnut: “I don’t tell you how to do your job buddy, I have an MBA blah blah.” Although you can go too far, you’re just trying to do a good job and ultimately, at the project launch party you’ll get respect and beer instead of just being known as that guy who sat in the corner, coding and seething because no one listened to his advice.