All the work you’ve done on the definition of the project now bears fruit. Depending on what type of project you’re working on though determines what happens next.

I’m going to use the example of a website as it’ll be easy to follow, but frequently you’ll have a mix of deliverables, maybe an email campaign, banners and a website at the same time.

A common problem of web site builds is that the designer wants to create a site layout around content that you don’t have yet. It would make sense, then, to get the copy written to design around, but then your copywriter will tell you they need to know how much copy they’re going to need to write and how it fits in the site, needing the design first.

The way out of this chicken and egg situation is one that is often missed out of good web site design, even in large marketing agencies: Information Architecture.

A good Information Architect can help not only improve the way that your site works but also reduce the time your designer and copywriter need to spend adding their magic to the project.

Your Functional Specification is key to everything in the Design stage, but before your designer or copywriter gets their hands on their computers you will need to have all of these:

• Site map
• User journey
• Wireframes

These documents, the Information Architecture, will give the copywriter and designer everything they need to hang their work off of. The sitemap will show them how many pages there will be, the relationships between the pages work, and an indication of the kinds of pages needed. The user journey will inform them of the route the users will be able to take through the site, and in some cases document how specific tasks will be performed. Last and not least the wireframes will show the relationships of the navigation tools and content, and often the annotation of the wireframes will also define recommended copy lengths, either in  word or character counts.

The IA documents are the starting point for the site design, but that’s not to say that the Information Architect dictates the look and feel of the site.

N.B. It’s worth noting at this point that Information Architect and Information Architecture both abbreviate to IA. You’ll often get to a situation where you’ll need to be clear about which one you’re referring to, so when talking about the Architects output you talk about the specific item (wire frames, user journeys, etc.) or to refer to them collectively as User Experience (or UX).

In larger projects you may actually have an Information Architect and a User Experience Architect, an IA and UA, with the former being responsible for the structure of the safe navigation to the information and the UA specifying the user interface specifications. For most jobs, though, an IA will do both roles.

Once the IA has produced the first draft of their work it needs to be reviewed not only by the IA, PM and Client Services representative but also by the designer and developer (front and, back end and multimedia if that’s how your team is formed.).

The input of the whole team is really useful at this point as it allows ideas to be exchanged that could lead to innovation and over-delivery within the time and cost of the project.

This is also the time of which every individual commits to a common vision of the project deliverables; after all you don’t want your designers putting together something that the developers aren’t going to agree to build.

Within one or two rounds of review you should be able to not only agree how the site will work overall, but also details of the individual components that make up the page.

Once agreed internally the IAs work should be shared with the client. Often they won’t understand the diagrams they’re shown so clear annotation with reference to the Functional Specification are essential.

The client will have an opportunity to add their voice ideas and reinforce the requirements at this review stage, possibly triggering another round of amends before finally settling on the structure of the site and its layout.

Graphic Design now becomes the focus of the delivery effort, with your digital designer taking their lead from the wireframes to produce clear and attractive page designs. A good designer will take about half the time your IA took to define the UX documents, at least to a first draft, and a quick review of the design by the same review team as before should highlight any issues or shortfalls in the designer’s interpretation of the user experience.

There’ll almost definitely be a round of amends and another review before passing the designs on to the Client fro their review and the inevitable changes that they request.

Now here’s a bone of contention – the copy writing.

I’m a big fan of making sure the page wireframes are designed to accommodate long and short content, especially text, as it allows you to deliver standard page templates within which the copy can be flowed, however there are always occasions where the copy has to be written at the same time as the designer is committing pixels.

You’ll often here designers bemoaning the fact that they don’t know how far to go with the page designs as they don’t know how long the copy will be. This is absolute tosh. Using “greeked” text (lorem ipsum to the rest of us) they should be able to test their designs with both short and long copy amounts, even if the content doesn’t make sense. If they can’t be bothered to type this all out themselves then make sure they take advantage of Lipsum.org, a website that’ll generate as much “greeked” text as they want. However, with pages where the content is unlikely to change frequently, if at all, you might as well get the copy writer on the case, producing the words that will be so important to the success of the website.

Don’t forget they’re not just providing the body copy – they’ll also be responsible for the page titles, form field names, instructional copy for forms and navigation – basically any and all written content on the site.

Again the copy writer will take their lead from the IA’s work in terms of understanding how many words they should produce, however they’ll take their creative lead from the brief and may even use existing Client literature or web copy as the basis for the new text.

Where you have a designer and copy writer working in parallel there are obvious opportunities to try the whole package together – user experience, graphic design and the text. This is basically prototyping the design and is great if you have the time or budget.

Assuming this isn’t the case, as with a majority of web sites, your copy writer will generally start work after the first Client review of the design. This is so the copy writer understands the boundaries they’re working in and the visual context too.

They may recommend adding images into the content too, to illustrate the topic being covered. This is something you’ll need the designer’s input on, possibly getting them to find and select appropriate imagery from Client image libraries or stock photography.

You should reach the point where you have draft copy and a concept design that can be shared with the Client for feedback – the feedback which will let you move on to the Develop part of the project.

It requires a few components: a bar code, an iPhone or Android phone with the Stickybits free reader app, user generated content and the Stickybits website.

First you get your bar code. You can get randomly generated ones from the website over you’ve signed up for a free account. Alternatively you can buy bar code stickers made by Stickybits, although at the time of writing these are only available in the US (but you could probably order them on Amazon.com and get them shipped internationally). There’s another source that’s both surprising and exciting, but I’ll come back to that in a little while.

The bar codes you get from the website come as PNG files so you can include them in any creative you choose to use them on, from print brochures to t- shirts, magazine ads to coffee mugs, poster ads to … well that’s the whole point – you use them wherever and however YOU want. Stickybits have made no restrictions on how or where you use the bar codes. In fact they actually ask you to let them know if you do anything interesting with them, so the sky is the limit.

The stickers you can buy are just pre-printed versions of the bar codes. Generated uniquely and separately from those got from the website they allow you to add a bar code to anything that already exists – literally anything.

The next step is to scan the bar code with the app on your ‘phone. Once captured the app will check with the website as to whether its been registered, which it shouldn’t, and the chance to give the code “bits” of content: images, video or audio content, even add what they call a comment (essentially a free text entry in which you can write virtually anything you like, even adding URLs of the fancy takes you).

Once that content has been uploaded you effectively started a discussion thread on Stickybits around that bar code. As the first person to scan the bar code you’re also the moderator for the content thread, able to delete any bits that other users add.

The next person to scan the bar code can also add their own bits, enriching the content available, but they can also look at anything that’s been posted before. Add to that the fact that the app uses the geo-location data from the phone to record where and when the bar code was searched and you not only have a chain of content but you can see where the contributors come from.

Right now many of you are probably scratching your heads and thinking “so what?”, but there’ll be a bunch of you who all have figured out that here you have an opportunity to engage actively with an audience. You could put one bar code on multiple items in multiple locations, or one location that is experienced by multiple people, or even more and bending by, on something that charges location, even passes from person to person in a chain of ownership – anywhere.

You could be gathering feedback on a product, or disseminating information on a museum or gallery piece and getting comments back. In each case you’ll be able to finder out which Stickybits user said what about the bar coded item, when they said at and where. Truly the nirvana of any marketing or PR agency, right?

Now for the real bombshell-it works with bar codes that already exist.

Any product that has an existing bar code can be scanned and given “bits”. Brands are now posed an interesting problem-get in on the ground floor of this and they can take ownership of the “bits” that get added to their products. If they don’t someone else could, maybe a competitor.

You’re going to see land-grabs with this technology similar to the domain squatting of the dot com boom and Stickybits acknowledge that at the moment there’s nothing to stop it, either in their systems or their current business plan. That puts this firmly in the social content arena right now but you can bet your bottom dollar that, before long, you’ll find items in your shopping bag with supporting content, customer reviews, additional offers – who knows? And the data you’ll be able to gather on the scans gives marketers a whole new perspective on their audience. I can only begin to imagine how you might make content sensitive to time and location. Yet again the rules haven’t been written yet

I’m getting in on this on the ground floor with the rest of the geeks who are currently raving about this tool. To prove the point, here’s my bar code – why not get the app and scan it?

Like I said I’ve got Stickybits – how about you?

Related articles by Zemanta

• Stickybits is Google Sidewiki for the Real World (newcommbiz.com)
• Wearing your Stickybit on your sleeve, or elsewhere (news.cnet.com)
• StickyBits.com – Bridging The Digital & Physical Worlds (killerstartups.com)

You’re going to produce several documents in this stage, some (or even all) of which form part of the contractual side of the job (that is they are referred to in the contract and may even form its appendices):

• Statement of Works
• Functional Specification
• Project Timeline (or Project Schedule)
• Budget

There’s some debate as to whether the Project Manager is responsible for the Fucntional Specification. Many Information/User Experience Architects feel that this is a job for them, after all they’re responsible for detailing how the site will work.My personal belief is that the task can and should be a joint responsbility, with the top level specification coming from the Information/User Experience Architect and the Project Manager adding detail that would affect the technical build and at the same time consistency checking the previous input. At the end of the day this responsibility is owned by different people in different agencies – there’s no one way of doing it right (in fact in some cases you may even find the Client or Client Services writing the top level spec).

There may well be other documents produced at this point too but usually by, or in conjunction with, a specialist resource:

Again, depending on your organisation, you may be expected to produce all of these documents. You, as a Project Manager, should only do so if you are an expert in these areas. The chances are you’re not, and even if you are you should hand these tasks off anyway so that you’re not overloaded with too many things to do, a situation where you are likely to make omissions or mistakes that come back and bite you in the … well, you know where.

There are a few more documents you should consider creating at the start of the project too. They’re especially useful on larger projects as they help to control the job as it progresses, but on smaller projects they will either be over-kill or their content wouldbe agreed in a semiformal way (via email or in a meeting).

• Roles and Responsibilities - it defines who does what
• Communication Plan – who gets told what, and when
• Risk log – an ongoing record of present risks and their mitigations
• Change log – the way of recording spec changes after the sow, fs, Project TimeLine and budget have been agreed. You’ll also provide a summary of the impact predicted on the project for each change logged
• Issue log – this document is a record of the problems encountered in the project and their proposed or executed solutions of the associated costs to the budget and timeline

Back to your main documents, though.

The Statement of Work (or SoW) states clearly what is and is NOT included in the work to be performed during the project. As you can imagine defining what isn’t in the project can be more important than what is. It’s the nature of a Client to try to get as much as they can for their money, so this is the time to set the boundaries very clearly.

Where there is disagreement about the inclusions and exclusions of the SoW you’ll find either not enough questions and, almost certainly, not the right sorts of questions were asked. You now have the opportunity to ask the questions again, before you’re committed to the project in terms of resource, reputation and contract.

Once you have a clear SoW, you will now able to put together your next main document, the Functional Specification (or FS). There you describe how the end deliverable of the job will work. It often supplements the Information Architecture and User Journeys but if these are not present, for whatever reason, this document should clearly describe how every mouse click, every data capture or retrieval, every interaction should work, in detail whenever possible.

Again, any disagreement in the content of this document shows the gaps in the work done in the Discover phase. It yet again gives you the opportunity to work in amendments and corrections, and almost definitely will trigger the re-write of the SoW. Often the SoW and FS are presented to the client at the same time, allowing you to get any corrections to both done together.

Now you have these documents you should be able to define the resources you’ll need to get the job done, how often and for how long. More importantly you will be able to plan WHEN you’ll need them, creating your Project Timeline.

You’d probably use one of the many Project Management applications for this, like Microsoft Project or Project Kickstart.  Most of these have the function to allow you to enter the cost for using a resource into the software and, in many cases, calculate the price of the job as a result – your Budget.

Good software packages will highlight where you have project resource conflicts, specify task dependencies (or which tasks MUST happen in a specified order) and where you’ll need extra resources to achieve the project goal by any specific end date.

Some Project Managers will define their timelines in spreadsheet documents if they don’t have access to PM software, but whilst his is a perfectly fine way of doing the job, having PM software that is written to do the job will save the you a lot of time and effort.

As a final check and balance the Timeline and Budget offer the Project Manager one last opportunity to verify that the project has been properly defined. Any issues arising from delivery dates and/or costs will lead to conversations with the Client where the SoW and FS need to be redrafted, probably de-scoping deliverables either to a further, later project or even completely removing them.

This will lead to adjustments to the Timeline and Budget, and if necessary in several iterations, until the definition of the project is complete.

It’s normal, at the end of the Define stage, for the Client to be asked to ”sign off” the documents. This used to be a physical signature, hence the contractual nature of the products of the Define stage of the project. Nowadays an email confirming the Client’s agreement to the contents of the documentation is all that is required. Once you have that you ready for what most people see as the “fun” part of the project: Design.

• Discover
• Define
• Design
• Develop
• Deliver
• Debrief

Well this time wells look in some detail at the first of those steps: Discover

This stage of the job happens just after your Client Services team have learnt there’s a chance of some work from a Client. It may be an ongoing agreement to do work (a restored agency or retained work, for example) or it may be a pitch situation, but in any case you should have been called upon to start steering the work right from the off. Having a Project Manager, even at this early stage, is essential to make sure any digital marketing project starts off in a controlled way that will, ultimately, save time and money later on in the job.

Between you and Client Services you’ll be asking a lot of questions of the Client, such as these obvious ones:

• Is there a website to be built?
  • Will it be a micro-site or a brand web presence?
  • Is a content management system needed?
• Will a banner campaign be needed?
  • Will they be static, animated or rich media?
• Will there be any data capture?
• What about emails?
  • Are they generated dynamically or are they static?
  • Do you have a recipient list already or do you need to acquire one (and how)?
• Will you need exposure through social network tools and which ones?

In a perfect world your Client Services or Planning team will be asking all these questions but as the Project Manager you have to make sure they do – and not just those questions. You’ll also need to know:

• Who do you want to talk to?
• Why do you want to talk to them?
• What’s in it for them?
• What do you want them to do after you’ve talked to them?
• How much are you willing to spend to reach each person?
• When do you need to talk to them?
• What are the targets so that the project can be considered successful?
• How is your client perceived?
• How about their competitors?
• Why is your Client’s product or service better?

And don’t limit yourself to these questions – if you feel you need to know other things then ask.

Once you’ve gathered this information it’s a good idea to review it to see if what you’ve learnt has, in fact, generated more questions. Don’t be afraid to go back to the Client and ask for clarification and more detail – time well spent now will pay back many times over by helping you to eliminate misunderstandings, misconceptions and miscommunications early on. It should also gave you greater insight into how the Clients think and speak, exposing you to their processes and terminology from the very start of the project.

Now for the most important bit – you need to find out what the Client expects. It’s not just enough to have a list of deliverables; quite often the Client has an idea of a style or a key concept they feel should be incorporated into the creative. Less often asked about, but probably more vitally important, is what the Client doesn’t want the project to include. They may have seen another campaign, someone else’s website, any number of digital marketing assets and either been inspired or deterred by them, but you need to know what these things are to be able to feed that forward into the creative and technical teams when it comes to executing the project and steer the result more closely to a successful delivery.

When it comes to the creative or technical execution the project team may not agree with these expectations, but right now you’re trying to put together all of this information so you can write a totally comprehensive the brief for the project, the ultimate goal of this stage.

Yes, you will have to write the project brief.

A Client brief is usually just a top line summary of what they want to do, which is why you ask all of these questions now. This way you get to write the brief for the Client in terms you both understand and in enough detail as to be precise about what the project covers.

Once written you’ll get the Client to review it and feed back, either with amends or to sign off on the brief. It helps demonstrate that you understand the Client, their customers, their business and their problem (the one that created the need for the project in the first place). It saves the Client time as they don’t have to write the brief for you.

Best of all, though, it brings the Discover stage to an end and gets you ready for the next step – the Define stage.

Over the years I’ve been exposed to, trained in and qualified for a number of these methodologies. There are a bewildering number of techniques and names for the methodologies: waterfall, Agile, PRINCE2 … the list goes on. In my opinion, though, it’s all common sense (or it should be anyway).

Personally, I’ve found that any project has 6 distinct phases.

• Discover
• Define
• Design
• Develop
• Deliver
• Debrief

It seems pretty obvious to me what each phase represents but I’m often asked to explain them to clients and colleagues alike:

Discover

This is the shop where the need for a project is identified in the first place. As a service provider, such as a marketing agency, this is also where you should be asking all your questions; who, what, when, where, why, how, and so on.

After asking all these questions you should have not only a solid idea of what the project requirements are, but you should also be able to tell the equally important criteria of what the project requirements AREN’T. Added to this you should have also been able to gauge what the Client is expecting.

Define

This stage is where the solution starts to take shape, as does the make-up of the project team, the tools and skills needed, where they all come from, how long it’ll take and just what it’ll cost. It’s also where you figure out what success will look like and where you start planning to achieve it.

Design

Now you know what it is that needs to be done this is the stage where you start putting the detail into place. Whether it’s deciding on a look and feel, the materials to be used, what words will be needed. This is where the creative heart of the project lies. It’s not limited to just the pretty stuff either; this is the time that “how it works” is put together in detail.

Develop

This makes as much sense in a creative context as a technical one-at this stage you’re putting everything together in line with everything you’ve discovered, defined and designed.

It’s also the opportunity to over-deliver if you can, taking everything that little bit further than expected. If the previous stages have been done right you should be able to do this on every project

Deliver

Now you’re got your product ready it’s time to get it to your Client. In construction it’s the final snagging and acceptance, in web builds it’s deploying to the web server and going live.

Whatever your project is this is the point you’ve been aiming for.

Debrief

Not enough projects have this stage actually happen, but every single one should! It’s where your team, your suppliers and your Client should talk about what went wrong, what went well, whether you were on schedule, on budget, on quality.

It’s where you learn your lessons for future projects; what to do and what not to do, when you should and shouldn’t do it and what to expect when you do. It’s also where you take the opportunity to check if you achieved what you set out for a successful project

All project methodologies use variants of these stages. Some have additional ones, others not as many, a few have processes in parallel. At the core, though, you’ll find these steps.

Next time I’ll start describing how you use these steps in a digital marketing project.

This covers a multitude of sins as the project doesn’t have to meet all, or in fact any, of its goals. You can blow the budget, over-run the schedule, fail to meet the expected quality, but as long as it’s controlled whilst everything is going wrong it has been “project managed”.

Of course a Project Manager will strive to make sure few or none of the things that can go wrong do go wrong, but at the end of the day no project is ever perfect.

So what type of person makes a good Project Manager?

First and foremost a good communicator. Most of the important parts of the job involve the imparting and sharing of knowledge about what’s going on. That often means not only delivering good news but also coaxing the bad news out of your team members and then passing that along in a way others can appreciate and move on with.

The next most important trait is to be a problem solver. Bad news is a lot easier to deal with if it comes with a way to avoid or lessen the impact of the problem. As Mary Poppins says, “A spoonful of sugar helps the medicine go down”.

Now you may not know yourself how to solve the problem but as a Project Manager you should be able to identify where and how you can find a solution, and, if you’re lucky, who can give you that solution.

It’s also ideal of you know how to make lists. This basic organisational method is often overlooked as a core skill for a Project Manager but it lies at the heart of everything that controls a project, from the names and contact details of the team members, through to the tasks that have to be performed throughout the life of the project.

Oh it’ll be good to know how to use tools like Microsoft Project and to have formal training or even a qualification like PRINCE2 or PMP, but at the final reckoning they’re the icing on the cake; without the base ingredients there won’t even be a cake.

One last note: you probably already are a Project Manager. If you’re organise a house move, put together a birthday party you’ll have had to use these core skills, even if you ended up doing all of the work yourself too.

Welcome, fellow Project Manager