Saturday 5 January 2013

Rules of Thumb for a Publishing Environment, Part II

Following on from the first installment...
  • If your job title is 'Project Manager' it is not unreasonable for your staff or colleagues to expect you to know every aspect of the project. Consider the job title for a moment: does it not suggest that you are the manager of a project? Does it not follow, then, that when a new member of the team - or, heavens forfend, a Temp - asks you a question about the project, you should be able to give a more useful answer than "I don't know", and certainly something better than "I don't know, that's your job"? Perhaps I'm a hopeless romantic, but I would have thought that a Project Manager - the person who manages the project - should know that project backwards and forwards, inside out, from beginning to end, and be able to take direct control of any aspect of that project if and when the need arises. Having been a manager myself, that is how I work. One cannot support one's team and facilitate their work without knowing every aspect of it for oneself. That a Publishing company may be broken down into separate Sales, Editorial and Production Departments is no excuse. The Project Manager is the one who oversees the involvement of all departments, ensures smooth communication between them and keeps everything on track and on schedule. The Project Manager is the one who is present at all times while the project is ongoing. If that isn't you, kindly do your co-workers a favour, and don't call yourself any kind of manager, let alone a Project Manager.
The reason for the above tirade is the so-called Project Manager I've been working under for the last few weeks. Not only was she only in the office for a couple of days at the beginning and the end of the project in question, but literally every question I asked was met with a response somewhere along the "I don't know" spectrum, and on one occasion she did tell me "that's a Production job".

In the end, since I was training the newbie anyway, I ended up defining and documenting this project's procedures so that she doesn't have the same trouble I had when the next one rolls round later in the year. It's not as if it's a difficult project, or even time-consuming... The bits I gathered together were simple enough to collate, it's just that no-one told me until too late that they need to be collated in a particular way, so I ended up undoing and then redoing great swathes of my work.

But what really bugged me - because I can handle (dare I say manage?) so-called managers who aren't managing - was that, in my penultimate week, the Project Manager asked to play around with my last few days, shifting one day into the following week so that I'd be there for their press day... Sadly for them I already had other plans for next week and, even if I hadn't, I don't appreciate being dicked around like that, so I turned them down flat.

I mean, let's face it, if the project had been properly managed, my work would be done once I'd collated all the copy... and the only reason half of it wasn't sent to the Printers today was that - oh dear - the Project Manager hadn't managed the project in such a way that the Printers were set up to receive the files by my last day. And why's that? Because the print order is supposedly a Production task... and so the newbie had to be trained in the art of preparing this particular print order, but that only happened yesterday, because no-one had thought to sort it out before then.

That's a piss poor performance as far as I'm concerned. One should never rely on the availability of a Temp, even if that Temp is me. So much more could have been done with my last three days if only the project had been managed properly.

Thankfully their newbie is awesome... briefing her on the few bits and bobs that remain wasn't a problem, and she'll have no trouble finishing it all off.

No comments: