I’ve wrote a few articles on project management in general, including what I think makes a great digital PM here and as I handle more & more projects across different sectors in different types of organisation I wanted to recap some thoughts and learning over the last 12 months. Also, a question I’m often asked and am sometimes unsure how to answer myself (!!) is “what exactly do you do again!?” mirrored in this great article here by Sarah Rowlands of Creative Jar.

So what exactly do you do again?

Historically as I’ve worked in senior IT PM roles alongside digital, my ‘cute’ and rather candid answer was “PC World” as it was easier than trying to explain what I actually do without sounding dull. (no offence PC World people, you’re all champions in my book) but more recently I started thinking I should probably give that answer a bit more respect and thusly have worked it out to be something like

“a team resource co-ordinator. Someone that makes stuff ‘happen’ and checks to ensure it actually ‘happens’ and then reports on what ‘happened’ and plans what to do when what was planned to ‘happen’ didn’t ‘happen’ , as it (yep you guessed it) ‘happens’ “

No Value

I’m always quite open & honest about whether I feel the role I’m in is truly needed. Surely the pinnacle of your job is to in effect, do yourself out of it! (Either by streamlining or efficiency enhancement) Sometimes this is met with quite surprise and irritation if you’re in a Fortune 500 environment, but I’m still adamant it’s really important to constantly question “is the PM adding true value to this project” or in fact “am I adding value here at all” generally. When was the last time you assessed if you were adding true value?

I work for a lot of small to medium companies, with general acceptance that with agile teams and rapid output, a PM can sometimes slow things down. Take the following example;

The designer, (we’ll call him Fred) is creating wireframes for a client (we’ll call them XB Wotsits) and already has a working relationship over Basecamp (PM tool of choice for many) and *could* go rapidly backwards & forwards snagging & amending a core design. A PM at this stage, (with my argument) can get in the way of this small team. Funnelling what should be pretty fluid communication through a single-man bottleneck doesn’t make sense to me. Putting the onus on Fred to keep Basecamp up to date and maybe liaise with the client directly is much more efficient and does away the need for a PM, doesn’t it? Same for technical understanding, the best person to talk technical to a client is the technical stakeholder, as opposed to a diluted version offered up by the often non-understanding (not me) PM.

I’ve read (and only partly agree) that a good Project Manager should shield the developers & Creatives from the client allowing them to get on with what they do best. I agree in part, as this is only possible & therefor feasible in larger organisations. In smaller teams everyone has to roll their sleeves up and get their multi-discipline hat’s out. It’s the only way.

Real Value

I think real value of a good PM comes into larger or more complex multi-stage projects where there’s a range of stakeholders and a lot of administration which needs doing. Be that conf. calls (yeah, those!) meeting minutes or work schedule/phase schedule reporting and such like. I worked on a Microsoft Lync implementation project which had around seven stakeholders, and a couple of third party suppliers. By Prince2 guidelines, that sure needed ‘project managing’ but in the world of ever-smaller digital teams, a PM adds weight to an otherwise lean environment. Having said that, I’m not diluting the value of the PM role, I just think for smaller teams it’s often suggested a PM is needed where in actual fact, others stepping up and taking a little more ownership can avoid the need for another salary & another head-count.

Project Start-ups

As I start up a lot of digital projects, I thought it might be useful to document the things I find myself doing again & again. This post isn’t the space to discuss methodologies, and quite frankly, I’m not only sick of debating between Agile this, and Waterfall that, so I’ll just post up a couple of useful links about Agile Vs. Waterfall here  and Prince 2 (which I’m very fond of, when applied appropriately) here

Discovery – basically meeting with the ‘whoever wants whatever done’. Understanding requirements, the expectations, the why’s

Planning – Providing some loose leaf Scope of Work identifying specification, technology, defining any expected User Experience (UX) and any creative samples such as wireframes or mock-ups (typically referred to as Information Architecture)

Development – actually getting the product, be that a website or software app (the SDLC is a bit more complex and I’ll discuss in a later post) out the door and any (often forgotten about) testing.

Deployment – more testing and then launch

Maintenance – in my experience either forgot about until the last minute or never factored in, in the first place. Documentation helps here, also something rarely done well.

Building the Team

I always find until you fully understand the client requirements you can’t really build an effective team. I’ve worked for companies whom favour the approach of including the client within the project team and stages a collaborative effort, and I have to say I agree with that. It works well. With digital, the client enjoys and expects a lot of ‘touch’. Creative is subjective and the client is best served when they can ‘see’ what they are getting as often as possible. When building your team, you will want to ensure that you don’t overload your staff with too much responsibility. For instance, if you find that adding sales to someone’s role is too much then you could try Sales outsourcing so that you can still get the job done yet keep your staff happy and productive.

What does the client want

I often find myself having to explain (read battling) what the client needs versus how Creative & technical people like to work. Creative people (totally understandably) like to ponder, tweak, fettle & produce a masterpiece first time BEFORE showing a client the product. Much the same with technical people. They want to understand the requirements, code, test, code some more, and then present a fully working solution. The client on the other hand wants to see ‘something tangible’ straight away, and they don’t ever understand wireframes or mock-ups (unless you’ve gone to the effort to teach them about this) so whilst a valuable component in the project process armoury, wireframes & mock-ups are only as useful as the client understands them.

What does the PM Want

I take quite a lot of time and spend a lot of effort into understanding both the creative & technical process of delivering an online or software solution. In fact I do it myself. I’m more than able to code up a website or write an app, ok ok, maybe not with the svelteness or completeness of a industry specialist, but I *can* do it, and that puts me in a unique position amongst project managers, in that I understand the pain points of the Creatives & the technical folks. What PMs Like to see however is true understanding from the technical & the creative people into the commercial considerations of the projects they are working on.

There’s a great article I’ve read (but can’t quite find now, sorry) talking about how the age of sole-blinkered vision into your trade is no good now, and one has to be more of a generalist when it comes to being a turnkey solution for the company you work for. It’s a good point. A creative who Creatives beautiful designs is awesome. A creative who creates beautiful designs and understands the commercial requirements of the client is even more “awesomer” and thusly much more valuable to the team.

I’d really like to see Creatives & coders step up & understand and own stuff outside there realm. Should they *have* to do this, I don’t know. But I know I would. Why rely on a PM when you can do it yourself?

Some things often forgotten

Testing – a basic functional test within the realms of what is expected to happen is not a good test. User journeys & test cases need to be written, often by the client to give us all something to work with. Then the testing actually needs to happen and get documented. I find the testing facility in Team Foundation Server very good

Documentation – another often forgot about step. I’m not talking about project documentation, but more ‘product’ documentation. I’ve seen websites with complex e-commerce or other back end functionality go out the door, and then weeks are spent supporting the client due to them not having appropriate documentation to look at. This creates a false positive into the success of the project as the client flags up things they can’t do or don’t know how to do as bugs.

‘the wilderness’

The ‘wilderness’ is the bit of a project that looks like a dry arid desert with the occasional tumbleweed floating across it. It’s the bit of the project where the scope of work has been accepted, the deposit has been paid, and the initial mock up and design have been signed off. The coders are coding & the Creatives are creating with gusto and pluck, but what about the client? How do you show them progress without showing them something part finished or out-of-context? Will they understand a product selector on a blank webpage? Or a logo swatch outside of their website? They start to get worried, think deadlines won’t get hit, and then the relationship becomes de-stabilised. I’m not quite sure what the answer is to providing the client with timely chunks of progress demonstration whilst at the same time appeasing Creatives & coders who only want to show a finished project – answers on a post code.

In Summary

I guess it’s singly most important to know the biggest challenge for any project is keeping the time, cost, quality & Scope all on track & equal. Understanding that changing one impacts the others and it’s important to have a grip on this. A simple example would be changing the scope impacts the time & cost. It’s really difficult to juggle all these though & manage people’s expectations. We’re always learning though right