The Web Project Manager Interviews: Timothy Quinn
The Day Job
Tell me a little bit about the company you work for
I currently work for Transcontinental, a media company with interests in print, web, mobile, e-mail and social media. Transcontinental is the fourth largest printer in North America, and the largest in Canada.
I came to Transcontinental in a roundabout fashion. I used to oversee the production department at a Toronto-based mobile applications company called Vortex Mobile. In late 2010, we were acquired by Transcontinental and merged with a mobile group in Montreal which had been acquired earlier that same year.
I now manage both mobile production teams as part of Transcontinental’s digital solutions offerings, which involves working with a skilled group of project managers and mobile production staff on applications for iPhone, iPad, Android, and BlackBerry, among other platforms.
What is the ratio of web project managers to production staff at your company?
It’s roughly a 1:6 ratio, which is a bit low. I prefer a 1:4 or 1:5 ratio, because smaller teams tend to work more closely and identify risks earlier. With larger teams, you tend to see a ‘pecking order’ and that inhibits people speaking up when a project starts to slip off the rails.
There’s a real scalability issue as teams grow larger; it’s easy for decisions to bottleneck. To help mitigate the risk of issues bottlenecking with me, I recently split the production department in Toronto into four-person fireteams and gave my project managers direct management of those teams.
Do you use any particular project management methodologies? If so, why? If not, why?
Like most client-driven digital production environments these days, we use a hybrid methodology at Transcontinental that borrows from both Waterfall and Agile processes.
Once or twice a year, I sit down with my project management team and we review each of our existing processes to see what’s working and what isn’t – PM summits like these prevent processes accreting solely for process’ sake.
What online or offline tools do you tend to use for web project management?
I use a lot of cloud technologies. Our departmental resourcing is actually done in Google Docs. I built a production dashboard several years ago which I still use today because it gives us a good real-time bird’s eye view of everything happening in the department (currently available as open source, so feel free to use).
I rely on Basecamp for asset management, and MediaWiki for knowledge management. Estimation and tracking is still a challenge; we’ve experimented with a variety of tools at Transcontinental, but haven’t yet found anything to effectively replace Microsoft Project.
How on earth did you end up managing web projects? Few people start out with this aim. Tell me how you wound up being a full-time punch bag?
I started out a programmer at a small company in the early days of the web, and one of the best things about small companies is that they’re often so under-resourced and so deeply dysfunctional that you can pretty much pick up anything and improve it, and this is probably one of the faster ways of figuring out what you’re good at and what you’re not.
So from writing code, I moved into resource management, and from there into project management, and from there into managing project managers.
When I was younger, before I got interested in web development, I held a lot of short-term jobs that toughened me up for a career in technical project management. I filed claims for the Pacific Gas & Electric Company; I worked in the collections department of a Beverly Hills luxury car rental agency (never, ever rent a car to Billy Crystal); I ran the shipping dock at the Art Gallery of Ontario and I delivered pizza (never, ever deliver pizza to Billy Crystal).
What type of web projects do you typically work on?
Most of the projects I’ve overseen the past couple years have been mobile applications, mobile websites, desktop websites, social media campaigns or SMS campaigns.
It gets a fair bit trickier when you start integrating with external systems and data sources. As a project manager in a mobile production environment, resource utilization is the bane of your existence – you need to constantly juggle complementary skills to keep your team happy and well utilised. At Transcontinental, we’ve tried to tackle this problem strategically with infrastructure development, cross-training and selective outsourcing.
What percentage of a web project’s total budgeted hours would you typically spend on project management?
I tend to budget 15-25% during development, with some variability early on in the planning phase of the project and then post-beta.
Some projects inevitably spike higher, so you need to keep an eye on how hot you’re burning, ideally in near real-time. If you don’t have reliable time tracking in place and you’re not doing variance analysis, you’re driving without headlights.
What web projects are you working on right now, and what web project are you most proud of to date?
We worked on a campaign for Maynards a year or so ago that I think of as a high water mark because it allowed us to leverage a lot of different technologies. It was a Facebook sweepstakes – to enter the contest, you used a QR reader on your smartphone to tag barcodes from ads located around the city. Each QR code launched a URL that logged the specific capture on a Facebook leaderboard, which added a competitive social aspect to the scavenger hunt.
Actually, one of the lessons we learned from that campaign is that if you’re going to use subway ads, don’t print the QR codes so small that people feel compelled to lean out over the track during rush hour.
How would you describe your managerial style?
Two parts Columbo, one part junkyard dog.
Actually, a project manager really needs to have more than one managerial style – the way you manage your team ought to be very different than the way you manage a contractor, or a critical stakeholder, or a client.
What are the common things that crop up on a daily basis that destroy your planned activities for that day?
I try to leave my mornings free of scheduled tasks to handle anything unexpected; I manage this by keeping a recurring fake three-hour appointment in my calendar to discourage people from booking me into morning meetings.
That doesn’t mean every day is incident-free. Problems can still crop up at any time, and one of the downsides of a very collaborative production environment is that everyone tends to get pulled into crises, sometimes unnecessarily.
We’re getting better at solving urgent problems face-to-face or by telephone rather than by lengthy e-mail threads. When something does need to be communicated in writing, I encourage the team to use our ticketing system to make sure that what’s being documented is actionable, and that a single person is tasked at any given time with moving the issue forward.
How do you keep organised personally, given the hectic life that comes with managing web projects?
I used to really get hung up on task management, because when you’ve got a lot of work on your plate it’s easy to fall into the habit of treating everything with equal urgency. So a couple of years ago, I came up with a lightweight form of notation for assigning quantitative prioritisation which I called NUB (“non-urgency based”) notation.
I wrote a blog post about it: NUB Task Notation
At what point do you typically get involved with a web project you are to manage? Pre-sales and estimating or only post-sale?
I generally believe in moving project management as far upstream as possible to avoid being saddled with untenable scope and timelines, but this introduces a different risk: the further you inject delivery resources into pre-sales, the more time you spend chasing down leads that go nowhere.
I like to set the threshold at about 75%. If a project is less than 75% likely to close, the production team is only casually involved and the sales team avoids committing to hard costs or timelines.
What technique do you use to estimate web projects? Do you use different ones for small and large projects?
There are really only two ways of estimating a project, and each has its merits.
There’s the rigorous formal estimate, for which I’ll assign a project manager for a couple days to solicit team input and book resources, or there’s the back-of-the-envelope estimate, which can be anything from whiteboarding a function point analysis to totalling up interfaces and APIs in a spreadsheet.
As mentioned above, I like to use a 75% threshold for determining whether to commit time and resources to a formal estimate – anything shy of that gets an hour or so of ballparking on a whiteboard and no commitment on timing.
How do you handle unrealistic web project budgets and schedules?
Not well. Not well at all.
On those rare occasions when something slips in a side door without a proper plan for build, we stop and do the plan regardless.
It’s always better to have a realistic if unachievable plan than to have no plan at all, since it forces you to define the boundaries of the problem.
Once we know what needs to be done and have a good handle on our constraints, it’s relatively easy to start critically weighing options and risks.
Do we split our effort into simultaneous parallel work streams? What’s the risk of abandoning our progress gates? Do we outsource? Do we restructure QA to focus solely on primary delivery platforms? Actually, accommodating a higher level of risk is extremely liberating.
Do you manage all aspects of web projects, like design, front-end and back-end development, or do department leads manage production based on requirements you capture?
I’ve always been resistant to the departmental model because I think it blurs the lines of accountability and encourages us-versus-them thinking. I like cross-functional teams.
How do you tackle the art of monitoring web project budgets versus progress?
We do a short daily scrum for every project that’s big enough to warrant one, and one of the outputs of that meeting is a calculation of variance between where we are and where we ought to be.
We dashboard that variance both as a data point (for tracking purposes) and as a flag that’s either green, yellow or red (for escalation purposes). Yellows and reds get respectively higher attention from outside the team.
How do you manage the inevitable scope creep on web projects?
I think scope creep is unfairly maligned. It’s not creep that’s a problem, it’s undocumented creep. Why WOULDN’T a client tinker with requirements during a three-to nine-month build? As long as you’ve put a change control process in place, scope creep is really an opportunity for higher budget and iterative improvement.
What advice would you give for managing difficult clients?
There are difficult clients and there are toxic clients. Difficult clients can be managed: delayed approvals and ambiguous feedback can be avoided with the threat of domino delays and cost overruns; combative personalities can be handled with greater diplomacy or a reliance on passive documentation (paper trails rather than sign-offs).
Occasionally, you’ll deal with a client who insists on unreasonable turnaround times, or unexpectedly changes scope or withdraws prior approvals, or otherwise violates the terms or spirit of an agreement… and they do so with a spoken or unspoken threat: accommodate us or we walk away.
Let them walk. Cutting corners on behalf of a client virtually guarantees that you’ll be cutting corners for the duration of your relationship, and you’re better off pawning those sorts of clients off on your competition.
How do you ensure past mistakes on web projects never happen again?
At Transcontinental, we try to post-mortem as many projects as we can, and I push team members to pre-document their feedback so that the post-deployment analysis doesn’t end up being an hour of commiserating with no actionable steps or insights at the end.
Our group currently use Basecamp for centralizing our post-mortem process, but I’ve recently built a tool called Project Slicer that I think does this a bit better. Project Slicer handles invitations and follow-ups to team members, and then aggregates quantitative and qualitative feedback into a dashboard that can be sliced according to client, project manager or type of project.
The Big Questions
What websites, blogs and podcasts are you currently using regularly for inspiration?
I keep an eye on Glen Alleman’s project management blog, Herding Cats. John Carroll also has a good blog called The Tao of Project Management. To keep abreast of news in the mobile industry, I read Mobisheet, and for design and UX insight, I read 37 Signals’ Signal vs. Noise and Luke Wroblewski’s Functioning Form.
What do you think are the key personality attributes required to be a good web project manager?
I find the role of project manager toughest to recruit and hire. I look for technical expertise – familiarity with software architecture and object-oriented design, exposure to PMI and Agile methodology – but I also look for judgment, prudence, patience and thoughtfulness – and those are difficult traits to parse. There’s a level of leadership and self-reliance which you’ll find in good project managers regardless of how many years of experience they have.
I’ve worked with some great project managers over the years (particularly the team I have now), but I confess I’ve also hired some disastrous project managers who focused the bulk of their efforts on shunting emails and sitting in client meetings when they should have been helping their teams work through architectural or usability challenges, or strategising with other project managers on process improvements.
What are the biggest common misconceptions about web project management?
There’s a pervasive myth that project management has value in the abstract, and that you can move freely between software development and, I don’t know, automotive manufacturing or event planning or animal husbandry – the theory is that you can still be an effective project manager without knowing anything about the engine under the hood, which isn’t true.
Another misconception – I sometimes see product managers and project managers with interchangeable roles, especially in larger companies. You wouldn’t confuse your radiologist with your anesthesiologist, so why muddle product management with project management?
What, in your opinion, is the hardest part of web project management?
It can be tough to stay challenged. As a project manager, you learn how to tackle a certain type of problem and then, once you’ve mastered that skill, you find yourself looking for the next challenge, which isn’t always there in the sales pipeline. I see part of my job being to continually find challenging problem-sets and learning opportunities for everyone on the team.
In three words, how would you describe web project management?
Not product management.
Thanks Timothy, I think this interview is one that resonates with me perhaps more than others, in terms of ethos, experiences and what a project manager’s role should be.
If you’d like to get involved in The Web Project Manager Interviews then please leave a comment below or Tweet Me.
Read more Web Project Manager Interviews »