Placing more importance on the process than on the outcome.

I’d rather be called a “project delivery manager” – where the focus is more around ensuring the project gets delivered on time, on budget and to the appropriate level of quality for the customer than on producing a hefty report each week to explain why the project is late, exactly which line in the 1000 line project plan we are up to and how we are 67.56% complete against plan).

For me, successful project management is primarily about managing people and relationships in order to get the job done, not about managing detailed processes or creating loads of paperwork to show what we are doing. And about using your brain and judgement. About ensuring lots of good communication, managing conflicts, unclearing blockages and doing practical things to maintain project momentum.

Relationships

Build healthy relationships with both stakeholders and suppliers and ensure open, transparent and regular discussions from day one. Good, effective, open communication is absolutely crucial.

Build an atmosphere of trust – to the point where they both trust you and each other to do the right thing even when they aren’t clear themselves what it might be. Remember, all 3 have an interest in the project being delivered – work together, not against each other.

Be prepared for conflict as it will happen – but deal with it quickly and effectively and don’t let tensions build up across this important senior team.

Teamwork and empowerment

Have a clear vision and scope for the project, supported by a high level plan showing only the milestones and deliverables, and ensure the entire project team understands and buys into it all. The whole team has to understand the project vision and scope, and feel the project is achievable (“our project”). If anyone doesn’t, encourage discussion around it and work to gain their support.

Give team members responsibility for appropriate deliverables and milestones (or entire workstreams) and leave them to get on with doing it. Don’t micromanage – instead, empower these smart people to get the job done and get short, regular status updates from them on progress.

If things start to look like they are going off track or risks and issues start appearing, that’s the time to step in. If things are ticking along fine, leave them alone to get on with it.

If a milestone looks tight, suggest they produce a detailed plan to build up to it, and keep an eye on progress against it.

Encourage a team atmosphere where collaboration replaces directives, where trust replaces the need for back covering and where flexibility and teamwork replaces jobsworth behaviours.

Risk and Issue Management

As project delivery manager, this is the area I tend to focus on most. I am always looking ahead across the high level plan, checking for any potential bottlenecks or problems that may be looming and then working in advance to remove them.

If issues come up, bring the relevant people together quickly to sort them out. And don’t stop until you have an agreed way forward to resolve them. Time is critical where an issue is concerned or a decision needs to be made – otherwise, things quickly grind to a halt and team morale dives.

If risks are identified, quickly discuss and agree actions to mitigate. Never have an open risk on the risk register without an owner or mitigating actions for it.

And don’t just look for project risks and issues, also watch for dependencies with other projects or wider things going on (holidays, mandatory departmental meetings) that could affect the delivery of your project.

The key is speed – don’t sit back while time ticks on, identify issues and risks and deal with them quickly.

Communication

Its more than email. If the matter can’t wait and you think you might forget the point you wish to make, send an email. Otherwise, wait until a time when you can have a face to face conversation about it. Or even a phone call. Face to face / phone helps build relationships – misinterpreted emails often help destroy them.

Have weekly meetings with the team – what have you done since the last meeting, what are you planning to do before the next one, and what issues do you need to table. Add any new risks and issues to the risk and issues register.

Minimal project management documentation

The main ones I feel are beneficial to project delivery are as follows:

- project charter – in my view, the most important one for the project as it sets out the vision, scope, milestones, deliverables, key risks, dependencies, delivery approach, roles and responsibilities.

- high level project plan, showing deliverables, milestones and key tasks only. It doesn’t go into too much detail – if you need it, create separate detailed plans for the team to work against. The purpose of the high level plan is to provide a general guide on project progress and an indication of upcoming activities, not to specify in detail what tasks need doing and by when. ie. it’s not a workplan.

- project budget – keep it simple, summarised and up to date. But don’t overanalyse it.

- status reports – again, keep them short, simple and to the point. If you truly know the status of your project, if your high level plan is up to date and if everyone is in agreement on status, risks and issues, producing this should take less than ten minutes each time.

- risk and issue register – the things on here are those that can really derail your project so keep on top of them and follow through to resolution.

The most important thing is to focus on delivery, not process. Don’t document a failing project, deliver it effectively and hopefully it will never become one.

And then things became a little fancier and you could host a form on your site to allow people to send others links to your site. By email.

Plug-ins soon came along, and you could embed content from other sites in your site. And let visitors provide their own content (comments, etc) on your site.

All on your site. Or sent by email.

The great thing these days is that you can easily provide tools to allow visitors to share your content on other sites for you, and to follow your site on other sites. Its about moving the conversation.

Two tools which really illustrate this are Twitter and Add This. I’ve written before about Twitter and how I’ve integrated it into London for Free. I’ve already attracted quite a few followers – people who now don’t need to come back to my site to see info I’ve added about events. Instead, they will see my twitter post on either twitter itself or a twitter content aggregation site.

Add This is an excellent plug-in to allow visitors to London for Free to share it on other sites such as Facebook, delicious and more. And every time they do, it doesn’t just benefit them. It benefits my site. The more times my site can be linked to the likes of Facebook and other popular sites, the better. Though these links aren’t treated as proper inbound links by search engines, they help to advertise my site.

Two simple ways to promote your site on other sites and support conversations by visitors about it anywhere.

Specifically the idea of them building client side code which complies with standards such as XHTML 1.0 Transitional, CSS 2 (probably the two most commonly followed ones at the moment) and, dare I suggest, WCAG 1.0 (Accessibility).

Whereas most good books (such as Bulletproof Web Design and so on) not only recommend that standards are followed but also give lots of tips on how to do it, most developers I’ve ever worked with see standards compliance as another overhead, in the same bucket as doing their timesheets and attending team meetings. The code would work just fine without them, no one will notice if they didn’t do it and what value does it really add. Etc.

I can see why they might think this way.

There are loads of examples of high profile, hugely popular commercial sites that are clearly not standards compliant – even at the technical code level, as any simple check using the W3C Validator will show. It doesn’t appear to have harmed their search engine rankings or affected their ability to display correctly in various browsers. (Though the additional costs of making such “non-standard” compliant sites achieve this must be enormous.)

And almost all of them gets away with it. Though now and then, some site owners are prosecuted the cases are sadly few. Naturally, this therefore strengthens the case for the non-standards compliance school. If the big guys don’t comply and they don’t suffer as a result, why should anyone else bother.

Yet standards compliance is so simple to achieve and really doesn’t take much more time to do, so it shouldn’t be seen as such a burden. It basically amounts to producing clean, tidy and efficient code and using html properly – ie. semantically – which is what any good developer should surely be striving to do. I often use the analogy of a journalist complaining if they are asked to spellcheck their stories – surely it should be something that they do as a matter of course in the quest for quality.

Accessibility is a little different. Accessibility does require going that extra bit further, tagging up titles, using tabs and hot-keys to aid navigation, providing non-javascript versions of key content if you’ve also used javascript for it and so on. Being standards compliant takes you a long way to having an accessible site, but not completely.

But even then, it really doesn’t take too much more effort. And there are loads of tools to help check for compliance. I discovered a very good one recently – Total Validator. You can use it to check your code against the various html standards at the same time as you test for code-based (as opposed to content-based) accessibility compliance.

At the end of the day, whether its a legal requirement or not, it makes good sense to produce neat, clean standards-compliant code. It loads faster, works across more devices, is easier to maintain and ultimately better for users.

There’s really no excuse not to do it.

If you have good content to film, of course. And that’s the problem with user-generated content. The web is filled with rubbish – videos of pets (like my first VADO production), pointless blogs (er….. moving right along),  inane comments and so on.

Its not that the technology isn’t there to support the creation of great user-generated content – the current version of WordPress truly means anyone can create and manage their own stuff these days. And the changes proposed with the new HTML 5 standard will make it even easier for webmasters to enable it on commercial sites.

Its all about what’s published. And has been ever since the web really took hold in the late 90′s. Back then the mantra was CONTENT IS KING and its still the same today.

The big difference is that in these web 2.0 days, the “content” in question is far more likely to be user-generated.

USER-GENERATED CONTENT IS KING. I predict that will be the emerging message for 2009 and beyond.

And that presents interesting challenges but also opportunities for organisations that work to embrace user-generated content on their own sites.

Just how exactly to make money from it.

It requires innovative thinking – the idea of simply building your own community and hoping users will populate it and stick around has proven to be difficult for all but niche organisations. And adding ratings and reviews tools to sites is also now so commonplace as not to provide much advantage anymore.

There are some good examples of using user-generated content in non commercial organisations such as change.org. But I’ve not seen that many on commercial sites.

However, ideas such as inviting guest bloggers to post (Jamie Oliver perhaps, on a cookery site), and encouraging user collaboration around producing a film script (e.g. which a tv site could then fund the production of) might be worth exploring.

Basically targeting certain users as content creators or guiding users as a group through creating content that an organisation can then add the final touches to, to monetarise.

Just a thought. Right, better get on with publishing my next (bad) video to YouTube.

First, A/B Testing.

Put simply, A/B testing is where you test two complete pages in order to see which one has the greater conversion rate to your desired target page.

To try this out, I created a copy of my original London for Free homepage and simply removed some text and links, saving it as index2. Then, using google’s wizard, I added some javascript code to each version of the home page as well as to the target conversion page (which I chose to be my bus tour page).

The idea was to see which page was the best version when it came to encouraging people to click the link through to the bus tour page.

All well and good, except that the quality of the google code was awful. Even though it validated for google’s purposes (allowing my test to run), the W3C validator hated it. I managed to fix two elements of the code but everytime I edited the third part, the optimiser rejected it.

So I persevered with buggy code just to see how this test would work. After running it for a few days, it became clear that the page with less options encouraged greater conversion to the bus tour page. Probably fairly obvious, but it was an excellent way to get my head around how to set up and run A/B tests.

Multivariate Testing

This is where, instead of having two complete pages to test, you select only one page and indicate the sections or elements of that page that you want to vary and test. You still need a conversion target but you can test say several different images and see which one encourages greater click throughs to the conversion page.

I removed the A/B test code from the home page and decided to run a multivariate test on it, varying the text in one particular style element, the subfeatures section. I created two versions of the text, both aiming to encourage users to click through to the bus tour page.

Then, using the google wizard, I dropped some javascript code into both the home page and the target page, and copied my “variant code” directly into the google dashboard. The variant code is effectively a second version of the “subfeatures” ID code snippet.

(Yet another reason for using div IDs in page designs).

I’ve now been running this test for over a week and though the results are interesting, what has been of most value to me is to be able to understand how easy it is to use the google tool and how multivariant testing works.

I need to try and validate this google code and will probably also extend the tests to include multiple variants and see how it goes.

Google Optimiser is a good product, and best of all , its free to use. Give it a try.