Get a tech in the boardroom asap

Working in an agency that has a digital offering can be a strange experience sometimes. Often you’ll get web project proposals presented as one bullet point in a list of 15 advertising and marketing objectives in a client’s advertising brief. It’s very rare that you’d be talking to a marketing manager who has any sort of comprehensive IT knowledge. The website seems to have just been put on the list like it’s just another channel – which is your fault because that’s what you’ve been telling everyone it is! But it’s not is it. We just say that to win the business! So what do we do now that it’s on the agenda?

Next time you’re sitting with your client and they are going through their projected ad spend, and they mention a website, stop them there. Leave the room and go and get your Technical Director (or similar role – some sort of propellerhead anyway). I know they are usually cardigan-wearing Star Trek fans who kind of scare the client and ruin your whole company image of being cool, but it’s vital that you get the techies involved at the very start of any web project. The sooner the better. Even if they don’t say anything in the first instance (this is often preferable) it’s good to have them thinking about implications of the project right from the onset.

The reason I say this is because with the way business practices are being moved online, what used to be a brief for a simple brochure-ware site can now be developed/evolved into a powerful business tool. The client may not even realise the functionality available to them now. So although they might think they are asking for one thing, they might be actually touching on something a lot more powerful and functional than they realise. When sites come in as part of an ad spend they are often not as well thought out as a stand-alone project where you might be sent an rfp or tech spec. Cover your arse and get the geeks in from day one.

however, not all site briefs will need a techie sitting in on the meeting. A good rule of thumb is that the company website is more often that not a business tool, and a microsite is usually only required to be a branding tool. For a branding microsite I’d consider myself capable of taking a good enough brief for the boffins to get a good grasp on the requirements of the project. For a company site, I’d get the techie in, and also suggest that we just have a quick talk about it and come back to it when we have more time. Also, lately I’ve found myself writing creative briefs for sites for our clients, and presenting them back to make sure we’re all on the same page. It’s just been easier than trying to get the client to do it when often they are not capable of getting their head around what is required. I can then pass that onto the techies to do the tech spec and scope. Often it’s a lot better option than trying to make your client do it.

Stakeholders, goals, and covering your arse

I just got sent this brilliant little parody of the creative and development process involved in redesigning the Stop sign. It made me laugh, but it also rang so true that it made me a little uncomfortable. I think it does an excellent job at pointing out the dangers of not nailing down your project plan, and more to the point, your project goals, before you start your build.

I would stop at this?

A project is usually considered a success if the requirements of the stakeholders are fulfilled. It’s true. Who else is going to give you grief over it? When starting a new project, you need to determine who these stakeholders are before you do anything else. A stakeholder is anyone who has a vested interested in the end product. Along with the project sponsors, the project team, content contributors, end-users, managers, and financial controllers can all be stakeholders. Nothing derails a project like a stakeholder being included late in the piece – they almost always want to stick their oar in and bugger it all up.

It’s happened to me a few times, or should I say, I have let it happen to me a few times. I have worked on a stop sign! (…metaphorically speaking). People who for one reason or another weren’t originally considered important in terms of defining the goals of the site, are included into the mix at a later date, and understandably they usually try to make some impact on the project. And as your profit margin diminishes, you are left sitting there whimpering, “I am a good person – why is this happening to me?” Step one of any new project is to make a full list of the stakeholders, and get it signed off by the sponsor.

When you are making your project plan it is important to make sure your stakeholders have as much input as possible to get clear list of goals to form the basis of your plan.

Ensuring the goals of the stakeholders are defined, realistic, documented, and then managed, will help you avoid leaving yourself open to… scope creep (*shudder*). Also, in making this list you will have to resolve any conflicting goals amongst these stakeholders. Better to do it now that half way into your build. You’ll also gain a decent idea of what criteria will be used to judge the success of the project. Once these goals outlining what is expected at the end of the project have been finalised, then get that signed off too.

Now that you’ve got the goals for the project nailed down, you can push on and write your deliverables, and development timeline, sort out your project team, and all that other fun stuff, knowing that as far as requirements go, your arse is covered.