Warning: Controversial post alert

This may make your blood boil, but if it does, please feel free to add a venomous comment or two after reading.

PCs suck! Microsoft suck! Windows sucks! IE sucks!

Oh my, how often do those of us working in the web industry hear this from the community and colleagues? I would take a guess at daily, and they’re all probably right.

Although not a Mac user myself (cool points totally lost I know), I know enough people, whose opinions I respect highly, that say Apple and Macs are far superior in every way to PCs and Windows – I believe them.

I was a front-end developer and have spent days and nights (mostly nights) pulling my hair out, shouting and swearing at bugs in IE from what I know to be solid clean code – from this perspective I know how this browser can at times seem like a demon sent straight from hell to torment us all and make us doubt all that we know to be good.

The post isn’t about IE6 alone, but this made me ‘gigglesnort’

Image source: John Martz

But, as a Web Project Manager your perspective of this whole topic has to shift dramatically because guess what – as much as most who manage, design and build websites loathe to say or admit it…

THE WHOLE WORLD USES WINDOWS AND IE!

Ok, maybe not the whole world, but a bloody lot of people.

The Evidence

Now while I imagine pretty much everyone reading this article will know this to be a fact, I still think it’s important to show the figures to really ram it home, because it seems to me, the more the web industry production teams out there move closer and closer to an all Mac environment, the attitudes to catering for anything Microsoft become more negative, to the point of being damaging to a business commercially through decreased bug fixing competencies / speed and lowering team low-morale.

OS Usage in 2009, with Windows at about 90%

Popular browser usage in 2009 – hmm no Netscape ;-)

Source: W3Schools Browser Information Statistics

This last table says about 40% of people use IE with Firefox now the market leader at 46.6%, huzzah!

But wait, I would hazard a guess that if you take a look at the Operating System and Browser combination analytics for your client’s sites, not your own (unless you only make sites for cool kids only) these aren’t the figures you’ll see.

I’d bet Windows and IE combinations are way ahead of any other – on average the combo splits on client sites tend to lean overwhelmingly towards Windows and IE combos, usually around 70% and upwards of all traffic.

Please, take a look at your client’s analytics and tell me I’m wrong. I’m basing this statement on only stats I can see, which is a lot, but this is one instance where in a way I’d love to be wrong and look like a complete Muppet…

10 Reality Check Facts

Of course I completely understand, and empathise, that by pampering to the makers of IE it can feel like we’re possibly postponing the evolution of the product to what most would consider acceptable standards, but I’d like to point a few things out to web production teams that I believe to be perhaps uncomfortable truths:

1. We primarily design and develop websites for non-web industry people, not cool kids
2. Most clients do not give two hoots about, or even understand, the IE vs. Firefox vs. Safari debate, they just want a site the majority of their users see as the designs they paid for indicated
3. Most clients do not accept progressive enhancement as an acceptable solution when confronted with stats that tell them two thirds of their traffic is from IE
4. Testing and bug fixing in IE is just as much of an important part of a developer’s job as is cracking that awesome innovative piece of new code
5. It’s commercially pointless to be able front-end develop at warp speed for Firefox and Safari if subsequent fixing for IE takes an age due to lack of knowledge, experience or enthusiasm
6. No matter how much you scream, you will still have to fix those IE bugs so why not accept it and see it as an important part of your job rather than a chore – to deliver a solid product for the client and their customers
7. Leaving IE testing right to the end, after creating some really complex CSS and JavaScript, is asking for trouble. Maybe don’t fix till the end, but just have a few quick peeks during development to see just how broken things are so you can adjust your strategy early if need be
8. Saying client’s and their customers “Should use a better browser” is just not an acceptable or constructive response or attitude, despite it being completely true
9. Quality developers want their work to be perfect in all browsers, and despite resenting it, will work tirelessly to accommodate IE out of sheer pride and determination
10. And most importantly of all… Please try to realise and appreciate how lucky we are to work in such a cool industry and in jobs we love!

I’ll take full-time IE bug fixing over a dead end job I hate any day! How many people do you know who live THAT life…

Seriously guys we are SO lucky!

In My Defence…

Now let’s get one thing straight here, I’m not defending IE here, I would love as much as anyone to see it go away never to be seen again. It causes me, and anyone in Web Project Management, endless amounts of headaches, but, being on the front-line with clients and their KPIs means I just can’t ignore the reality right now.

This article is not meant as a rant at designers and developers, but really a plea on behalf of all Web Project Managers to the web designers and developers out there to just take a step back from the in-house, ‘in-industry’ red mist that surrounds this topic for a moment and appreciate the bigger commercial picture – the one Web Project Managers and web agency owners have to live in on a daily basis.

Let’s all keep trying to spread the word about using more standards compliant browsers, continue to educate clients we meet on the benefits of using Firefox over IE, inform everyone about the Google Chrome Frame, Progressive Enhancement and Graceful Degradation, but…

Please try to realise the commercial reality and support us in getting web projects finished on budget, on time, with minimal in-house stress and making client’s, and the large majority of their users, really freakin happy – which the for the time means accommodating IE in all its dominant form.

To a Web Project Manager, while it has such a large market share, getting it right in IE is just as important a part of the project as getting the designs signed off on time or making sure as much JavaScript as possible is un-obtrusive – we have to set personal feelings aside, be tenacious and get the job done.

Trust me, we Web Project Managers understand that Microsoft, Windows and IE completely suck when developing websites and applications, but as we openly empathise with you, please try to empathise with us, accept the amount of people that still use them and the position that puts us in when managing the delivery of websites and web applications.

So come on, quit with the un-constructive negativity and stop dragging your heels when it comes to getting it right in IE, it adds nothing positive to the atmosphere or morale of a web agency team – set your personal feelings aside, be tenacious and get the job done.

Ok, time for me to put my riot gear on…

In this final part I will discuss what I think good Digital Account Management is, the skill set you need and what it takes to distinguish yourself as a great Digital Account Manager.

What is good Digital Account Management?

Simply put, good Digital Account Management is… the ability to keep clients consistently happy, by being able to constantly identify ways to increase their business’s revenue using digital solutions, solutions that your web agency can implement at a cost that results in profit.

Although a job with a hundred other roles and responsibilities, they all ultimately are geared towards:

1. Winning new business from new clients
2. Winning repeat business from existing clients
3. Extending their agency’s reach into the client’s business

If a Digital Account Manager can consistently meet the monthly revenue targets set by their superior while keeping all their clients happy and losing none to competitors, then they have a done a good job and shown what good Digital Account Management is.

Ok, we now know what good Digital Account Management is, but what skill set does a Digital Account Manager need today in order to get employed and stay employed?

The Digital Account Manager basic skill set

Rather than immediately launch into what I believe makes a great Digital Account Manager I thought I’d take a look around some job boards to see what the general consensus currently is among digital agencies looking to hire Digital Account Managers, or put another way, what is the basic skill set required to be a Digital Account Manager today.

Client management

• Build and maintain client relationships as the primary contact point
• Responsible for day-to-day management of clients, requests and accounts

Tactical and strategic sales

• Identify new sales opportunities within existing accounts
• Achieve personal monthly new business / revenue targets set by the CEO
• Spearhead client meetings, presentations and account winning client pitches
• Provide sales and project documentation including proposals, quoting, contracts and budgeting
• Lead, write and present client account strategy development documents

Analysis and reporting

• In-depth analysis of web analytics to produce monthly reports with key recommendations for client
• Monitoring and understanding your clients markets; be aware of market issues and competitive activity

Consultancy

• Information Architecture, SEO, PPC, and Social Media consultancy

Internal and personal

• Proven digital creative and technical experience
• Manage production teams to ensure delivery of projects is on time and on budget
• Reporting monthly to the agency management team on your activities

As you can imagine, I’ve omitted the usual “great communicator” and “must be pro-active” attributes, I even came across the requirement “Mastery of MS Word” – mastery? … wow.

So we can see the skill set that an average Digital Account Manager should have in their arsenal, but what makes the great ones stand out? What do they have, what can they do that the bog standard ones can’t?

What makes a great Digital Account Manager?

From my experience, the difference between an average Digital Account Manager and a great one is the same thing that separates an average designer or developer from a great one – a burning passion for all things web. They live and breathe it, during the day and when they go home – they absolutely love it and can’t get enough.

Great Digital Account Managers crave input like Johnny 5

Although this isn’t the only difference, the others tend to be born out of this one alone.

Ok, so other than the burning passion thing, here’s what else I believe are the tell tale signs of a great Digital Account Manager, they tend to have:

• The ability to provide quality solutions to the client that they love because it helps achieve their business aims, but also aligns with their web agency’s business strategy – clever
• An honest addiction to the web that enables them to be able to know about and suggest new solutions to clients that are cutting edge and no competitors have started to adopt yet
• Enough web design and development knowledge that earns the respect of both production teams because they rarely sell solutions to clients that are unrealistic in terms of time or complexity
• Enough knowledge to handle the whole selling process mostly alone, right up until the production phase needs to begin
• The willingness to personally research any digital topic they need to in order to be able to speak to the client with complete confidence without relying too much on creative or technical production resource

Great Digital Account Managers are rare, if you find one, hold onto them for dear life because the unfortunate reality is that far too many Digital Account Managers simply act as a web agency’s face and voice, making out to the client they know what they’re talking about when in reality they’re completely relying on the creative and technical teams to cover their lack of knowledge, in some cases even asking them to write whole e-mails that they can send to the client as if they wrote it.

I believe this reality is unlikely to change simply because few people who work as a great web designer or web developer (and thus have the burning passion needed) want to make the leap from production into Digital Account Management, or Web Project Management for that matter, so you tend to find the space full of people who have minimal web experience.

However, maybe there is hope… looking at the Digital Account Management job descriptions it seems that to be a Digital Account Manager today you are now required to know much more about web design, development and trends than ever before – could it be we are heading towards an era where most Digital Account Managers are really and genuinely web savvy? I really hope so…

In summary

As a Web Project Manager working in a small web agency you will almost certainly be called upon to perform Digital Account Management tasks on a regular basis and they will usually come with no warning and need your immediate attention, throwing your web project schedules into bedlam.

Unless your agency adopts the approach of larger companies, by employing a dedicated Digital Account Manager, you will just have to get used to it because the client will probably know you a million times more than anyone else in the company and always approach you with requests – see this for the compliment it is if nothing else.

Try to make sure you’re in a position where you can justify any delays to your web projects due to account management to your boss and then start to embrace and enjoy it, you’re being paid to develop your own skill set that will never go out of date, something you wouldn’t get an opportunity to do in a larger company and something that even benefits your own agency – everyone’s a winner.

If it all gets too much and you simply can’t cope with the additional workload, seek help, find out if you can deal with it when you know you’ll have the time or work a little overtime and take one for the team – there are always options that mean the client stays happy and you don’t go insane.

Once you find the time to put your Digital Account Management hat on, do the best job you can. Remember the point of it, it’s not only to generate new revenue for your agency, but to do so while providing genuinely useful solutions to the client that help them achieve specific business goals.

As a Web Project Manager you probably already have enough knowledge and passion to temporarily pass as an average Digital Account Manager. But why not try to be a great one by keeping up to date with the latest web trends and technologies and putting in the extra work to keep the Digital Account Management work away from your production team, and retaining the Web Project Management ethos of trying to keep them doing what they should be and making their job as easy as possible – you will reap all of the rewards in the end – fact.

Related reading:

• Account Management for the Web Project Manager: Part 1
• Account Management for the Web Project Manager: Part 2

In this next part I would like to give you my thoughts on why Web Project Managers, despite the grief it causes, should actually embrace the opportunities they have and a few different ways to manage the additional workload as and when it arises.

Embrace Account Management

So this may be an alien concept to some Web Project Managers out there, almost as much as the concept of enjoying web development is to most Account Managers, but I’d like to explain why I feel Web Project Managers should actually try to embrace those times when you get an unexpected client request, just when you don’t need it, rather than spit fire.

In short, it’s a free crash course (in fact you’re paid to learn) in several new skill sets that are invaluable to you and your company and that will never become out of date, unlike web development techniques – everyone’s a winner.

This really is the only point and it should be a no brainer to everyone. Yes it’s tiring, yes it’s scary, yes it can be a right royal ball ache at times, but, I absolutely guarantee you, if you somehow manage to get through a few months of insanely manic times where you were juggling more projects than you know you should be, plus dealing with incoming requests and new business opportunities, you will look back at some point and realise just how much you learnt and it will blow you away.

I totally understand that when you’re right in the depths of hell in terms of your schedule, it’s practically impossible to sit back, relax and fully appreciate the experience you’re gaining, but go through the cycle enough times and slowly but surely, when things are getting really tough, you’re able to see the bigger picture and press the reset switch just before giving someone else an actual physical ball ache and being escorted from the building.

Irrelevant to the post but found searching for “ball ache” on Flickr. Check out the cow stool with udders.

Account management is a whole career path for some, as Web Project Managers we tend to act as Account Managers at least once a week, I honestly believe the better Web Project Manager you are the better Account Manager you are, and vice versa. Embrace the opportunity to be paid to learn, you will retain the skills no matter where you go.

*Note: You have no idea how happy I am that I managed to get the term ‘ball ache’ into a post, must use more.

Dealing with additional Digital Account Management work load

Now, as with most articles published about web project management, the advice given is very ‘ideal world’ and is not always easy to put into practice, as are job descriptions in small web agencies. The reality is, if you work in a small web agency as a Web Project Manager, you will have to perform Account Management duties, amongst many other roles, and they will generally come without any warning and need your immediate attention, superseding what you had planned to work on.

So now you know this, how can you go about dealing with the requests out of nowhere when you least need them? Well, there are some short-term, tactical techniques and long-term strategic techniques:

Short-term

1. Strike a deal with your Account Manager, or someone else, to help each other out
2. Postpone dealing with the request
3. Delay another project
4. Work overtime

Long-term

1. Cultivate a change in internal operations where an Account Manager is involved in the web project from the start and not post-launch

Strike a deal

When working in any company, be it small web agency or large corporate within a digital department, try to build a rapport with an Account Manager you like to work with and strike a deal whereby they help you out, and you them, when work load becomes intolerable.

This relationship can not only be a sanity saver in times of chaos, but it can also be used as a knowledge sharing exercise that will benefit both of you and the company you work for:

1. The Account Manager gets to learn a little about how you run web projects and web technology (something many seem to be short on)
2. The Web Project Manager gets a little insight and experience at what a dedicated Account Manager does
3. The company has more employees at their disposal that are developing their own skill sets

A key skill for any Web Project Manager is to negotiate win / win situations – this is a win / win for everyone.

Postpone dealing with a request

Sometimes even when you look around you for help, it’s just not there due to everyone else being insanely busy. In situations like this you can always consider putting off dealing with the request.

Now some Account Managers would physically vomit at the thought of telling a client that they don’t have the time to deal with this new request that is probably new revenue.

But I’m not saying you should tell the client you are too busy and can’t deal with their request, but simply enquire as to the urgency of it. You’d be surprised how many times I’ve taken a call out of the blue that is a client wanting to talk about new work only to discover it’s not something they need an answer on immediately. I’m equally surprised at how often the Web Project Manager or Account Manager doesn’t ask the client when they need a response, instead choosing to scramble around trying to react immediately.

Looking back, this is something I rarely used to ask because I very much had a “OMG a client is on the phone and I must answer them immediately in order to keep them liking us” – only as I became more experienced and realised client’s are just people with busy schedules too did I start to ask when they needed a response if I knew my schedule was mental at the time.

If a client says they need a response that day and you’re busy, tough, you’ll just have to deal with it somehow, perhaps by using some of the techniques described in this article. However, if the client says they’re happy to wait for a day or a week, this can be a life saver! Always ask, you have nothing to lose and everything to gain.

Delay another project

Occasionally you’ll get a request from a client out of the blue that will be a real opportunity for your web agency, more than occasionally you will have a completely full schedule.

It’s at times like these you have to think commercially about the new request versus the current web projects you’re running, in other words, does the new request have massive potential benefits that are worth delaying another project for…

This is a question that only you and your web agency can answer at the time, and only then on a case by case basis, but the option should always be considered.

Work overtime

Of course, the infamous ‘work overtime’ option. In order to deal with new client requests when your schedule is full you always have the choice to work overtime so you can fit it in.

Again, your decision can only be based on a case by case basis and can have many influencing factors e.g. massive opportunity for you or the agency, agency is not doing so well financially, you get paid for overtime and could do with the cash injection or brownie points etc.

Although it’s your decision, in most cases, I would give you one word of warning about working overtime, especially when working in a small company – it’s habit forming.

I could probably write a whole new article on the pros and cons of working overtime, but in short, working overtime once or twice to deal with new client requests when you have a busy schedule is ok, but there is a fine line between once or twice and it becoming a routine for you that can actually result in people expecting it and being annoyed when you say no.

This can then slowly become the culture of the entire agency and ultimately cause people to feel like it’s a mandatory rather than a choice – a sure fire way to cause team morale problems and burn out.

But ultimately, working overtime is always an option and there are just as many reasons to use it as there are not too.

Account Manager involvement from the start

This is an approach that’s adopted by larger organisations but something I feel smaller web agencies would also benefit from and should think about implementing as a long-term strategy – it’s where each project / client has both a dedicated Account Manager and Web Project Manager.

This person needs to be someone who will take the responsibility of looking after the client in terms of:

• New business opportunities
• Non-project related requests during the project
• Invoice sending and cash collection
• Post-project day-to-day account management and small work requests

The most important thing is that they’re included from the start of the web project and maintain an involvement throughout by attending kick-off meetings, being present on teleconferences and receiving weekly briefings from the Web Project Manager on project status and relationship development, thus enabling them to:

1. Build rapport and trust with the client
2. Deal with any non-project related requests a client may send through
3. Act as an understudy for the Web Project Manager in case of illness or holiday
4. Pro-actively spot opportunities, suggest and sell genuinely useful solutions to the client
5. Take on the client as a new account after the web project has been completed

…the very things that destroy Web Project Manager’s schedules and ultimately make them shy away from Account Management tasks.

Now, while the amount of work for one project or account may not be able to justify the hiring of a dedicated Account Manager in a small web agency, I’m of the belief that with multiple web projects and clients, there almost certainly is a full time role there, and that the role can be justified further by adding the standard measurable target to it that all Account Managers have to satisfy – monthly revenue targets.

Too often I see smaller agencies employ two or three Web Project Managers and then assign them each a project that has a client and that’s it – that Web Project Manager will not only plan and deliver the solution, but retain sole ownership of the client and account from that day forth. This tends to create a silo-type environment where only one person has client and account knowledge which is never a good thing.

I also feel this isolated multi-role approach is one of the many reasons Web Project Managers find their schedules obliterated on a weekly basis (thus affecting project schedules and quality) and why many small agencies are always playing catch-up and never make the transition to medium size – the people essentially responsible for growing the account tend to see it as a low priority task that isn’t their core skill and rarely have the chance to dedicate the time Account Management really needs in order to bear fruit.

I believe the aim should be exactly the same as it is when we try to keep web designers designing and web developers developing – to keep Web Project Managers managing projects and Account Managers handling the day-to-day tasks and growth of accounts.

I don’t think it’s a coincidence that medium to large sized agencies tend to have one person per role. By definition, the fact they are now medium or large means they have grown significantly, and in a stable manner, while others haven’t and I like to think smaller web agencies, if they want to grow to medium size, should always try to look at how the bigger fish operate in order to identify how they achieved this.

In Part 3 I’ll talk about what good Digital Account Management is, the skill set you’d ideally have and what it takes to be a great Digital Account Manager rather than just an average one.

Related reading:

• Account Management for the Web Project Manager: Part 1
• Account Management for the Web Project Manager: Part 3

This is one of the best, and worst, things about working for a small web company. You get to gain tonnes of experience in a variety of areas and develop a plethora of business skills, but, invariably it’s just these kinds of sub-roles that can crop up right when you don’t need them to, and often are responsible for wiping out an entire day that you had carefully planned out in order to stay on schedule.

At this point it should be noted that when I talk about Account Management in this article I mean Digital Account Management, and I’m talking about just a small part of the job, not the all encompassing one that includes wining and dining clients, permanent fake smiles and meeting revenue targets – just the day to day flavour a Web Project Manager tends to encounter e.g. new business sales and new work requests from clients outside of any projects being currently run.

In this series of articles I’d like to discuss the following:

• Why Web Project Managers end up performing Account Management duties
• Why we should all embrace the opportunity rather as opposed to shun it
• Ways to manage the extra unexpected work load
• What makes a great Digital Account Manager

And of course, include a few movie references kowabunga!

I’m a Web PM, not an Account Manager!

You see the job advert, it sounds tempting, you apply and charm the pants off the interviewer (not literally, that would be highly inappropriate) and you get offered the Web Project Manager position which you happily accept.

A few months in, with a couple of projects under your belt and good rapports built with clients, suddenly they’re asking you about small little pieces of website work, new mini-projects they have budget for and for advice on what they should do next with their website and overall digital business strategy.

Instinctively you begin to reply promptly and before you know it you’re getting sign-off on new work and new money… well done you, super duper shiny gold star!

But wait! What’s happened here? The sly subtle beast of Account Management has crept up and is about to devour you and your day – clever girl…

I’ve actually met several Account Managers who look a little like this, but, in this case it’s meant just as a metaphor

Yes that’s right; as sure as the cowboy hunter dude from Jurassic Park was eaten alive, you’ve slipped into an Account Manager role by accident; but why did this happen, and why does it always seem to happen to Web Project Managers?

Web Project Manager, a client’s best friend

Quite simply, you’ve become a Digital Account Manager because you’ve been the primary contact for the client for weeks or months and at this point they probably trust you more than anyone else in your team.

In the preceding weeks or months you have more than likely demonstrated a level of web industry expertise that gives the client a confidence that you are the person to ask about their online business strategy – what a compliment right!?

Web Project Managers love their ego’s being massaged as much as the next person (it’s not just web designers or web developers, we just hide it better), so why do some Web Project Managers dislike Account Management tasks so much when it is clearly evident the client is completely loving and respecting you?

Why Web PMs hate Account Management

I have come across many Web Project Managers who completely throw their toys out of the pram when Digital Account Management tasks land on their to do list, and do you know what, I have secretly done the same from time to time (just not shown it), but the reasons for the hissy fit may not be what you think…

Ok ok, in some cases the reason for the toy throwing is because a Web Project Manager just doesn’t want to do any Digial Account Management because they feel it isn’t their job, but you’ll generally only find this reaction in larger web organisations, where both dedicated Web Project Managers and Digital Account Managers are employed.

In larger organisations it’s not unusual to find the Digital Account Manager is the client’s primary point of contact and the Web Project Manager works more internally, managing the project team, something closer to a Production Manager in my opinion, but hey, I digress.

More often than not the reason Web Project Managers will try to avoid Digital Account Management duties is because it simply isn’t something they had planned to do in their already busy day and it can put multiple project schedules in jeopardy – that’s enough to rile even the most relaxed of Web Project Managers!

The 5 minute myth of Account Management

While it seems obvious at the time that if a Web Project Manager handles new client requests on a regular basis then something they had planned to get done that day won’t get done, it’s something that is surprisingly, and disappointingly, rarely accepted as a valid reason for a web project being late.

This is usually because the Digital Account Management duties performed come in dribs and drabs over a period of weeks or months, thus being hard to track. Sometimes it’s a 15 minute phone call, others its two or three mornings compiling new web project quotes, there’s the little quick e-mail or the new business meeting or two… you know the things I mean, the little bits n bobs that take “5 minutes”.

These “5 minute” things, as I’m sure you’re all aware, tend to take anything from 15 minutes to 2 hours and above because they’re very rarely events in isolation. Yes the initial task may take 5 minutes, but the subsequent actions and waiting for items that come as a result will also take time to process.

These “5 minute” things are usually quoted as such by a person who will not have to see the action through to the end, and over the course of a web project’s lifecycle, perhaps 3-6 months, they can all add up to days worth of lost time that can ultimately cause web projects to be delivered late.

A typical Digital Account Management scenario

For example, to take a request from a client to quote on a couple of small new pieces of work that are separate from the current web project and thus not a change request, assuming they are in some way bespoke, will take you a good deal of time because you will probably have to do the following:

• Talk to the client to see what they want / what they’re trying to achieve
• Talk to the web development team to see how it would be best to implement the request and how long they would estimate it to take
• Speak to the web design team to get an estimate for the work required
• Create a structured quote that also accounts for any other tasks that will need to be completed as a result of the new requests e.g.:
  • Create mini-Sitemap
  • Create mini-Functional Specification document to eliminate ambiguity and scope creep
  • Create crude design mock-ups
• You’ll then need to factor in the potential new work into the project’s existing schedule and your web agency’s resource availability, in order to let the client know how / if the new work would affect the current project milestone dates
• You’ll then need to write a mail, send the quote and be prepared to answer questions about your proposed solution
• There will no doubt be time needed to negotiate price
• Once agreed, you will have to send off the formal documentation and await sign-off
• Once signed off you will have to schedule the resource needed to complete the work, brief all team memebrs and send updated project schedules / milestone dates to the client

Then, and only then is the Digital Account Management duty over and as you can image, all of this takes time, time you had almost certainly had allocated for something else.

No doubt there are many out there who would just “throw together a quote” and say yes to the client immediately, but I’m a firm believer that if you’re not following a structured process for taking new client requests and producing quotes then you’re immediately running big risks of over selling, under quoting and / or missing critical requirements – and I guarantee this will invariably result in someone needing to spend more time to fix than you would have estimating, and leave the client peed off which all would agree is bad Digital Account Management!

Of course some will argue that this is the job of the Web Project Manager, and in most cases I would agree, after all, who best to understand the requirement, estimate time and adjust web project schedules than the Web Project Manager? Plus, how often have we whined about an Account Manager who has sold some new work to a client without taking into consideration the current schedule, resource allocation and fact that you can’t build “a mix of Facebook and YouTube” for £3k?

However, if it happens frequently enough, and isn’t a change request to the current web project, it can severely disrupt a Web Project Manager’s personal schedule to the point where projects are suffering significantly and thus it’s always best to have someone to delegate too if possible – the perfect person being a dedicated Digital Account Manager.

As the seasoned Web Project Managers out there will know all too well, one day lost can potentially cause days or weeks worth of delay to a web project. It could be that you’d scheduled designers or developers to start work the next day which was dependent on you finishing the creative brief or functional specification and getting sign off from the client that day, and they were only available to review and sign that day and won’t be again for four or five days – disaster.

When Account Management makes projects late

While it’s incredibly frustrating to be berated by your manager or client for a web project being late, if you know part of the reason is due to you dealing with unexpected Account Management duties, mention it.

But be aware, if you mention it, it’s best to be prepared and able to produce some kind of evidence or log, of not only the time spent on Digital Account Management tasks but also the new revenue earned for the company, just in case it’s a particularly sensitive project and you run the risk of being crucified, burnt, hung, drawn quartered and fed to the Sarlacc Monster in the Great Pit of Carkoon, rather than simply ’sighed’ at.

Pretty much how Web Project Managers feel when a project is late

Aside from keeping records of your work time to cover your arse when being thrown to the wolves, it’s also a good habit to get into so that you can begin to analyse your time and see just where it’s going and how long it tends to take you as a percentage to manage web projects – you can then use this information to assist you in identifying bottlenecks in your processes and estimating new web projects, as I discussed in my article Estimating Time for Web Projects More Accurately »

Hopefully this first article in the series explains why Web Project Managers always seem to end up performing Digital Account Management tasks and also why many dislike it. My counterparts out there will already know all of this, but perhaps it may offer a different perspective to others who work alongside Web Project Managers…

However, now the rant part of this series is complete, and I have all my fellow Web Project Managers agreeing in unison about how ridiculous it is to be expected to handle new work requests on top of their day job, in Part 2 I’m going to upset you all by talking about why Web Project Managers, despite it having the ability to seriously de-rail your projects, should actually embrace the opportunity rather than shun it and some techniques you can adopt so you can deal with the strain it puts on your workload.

• Account Management for the Web Project Manager: Part 2
• Account Management for the Web Project Manager: Part 3

About the Author

Michael Dlugosch works as a Senior Consultant at Kwantic Oy, a Web Analytics startup company in Helsinki/Finland.

In this final part of the Michael Dlugosch talks about Sloth, the last of the Web Project Management deadly sins. It deals specifically with the constant struggle Web Project Managers have when trying to allocate resource to their projects only to discover there is none available.

7. Sloth – “We don’t have more resources!”

As Sam Barnes comprehensively covered in his recent article “Web Projects: How to keep the peace when making decisions”, one of the saddest facts in a Web Project Manager’s life is indeed the multitude of expectations they to deal with, for example:

1. The client expects your organisation to be flexible enough to catch up with a five day delays in material preparation without any effect on the deadline
2. Your Accounting department expects that they can issue this phase’s invoice as planned before to ensure the cash flow
3. Your HR people are expecting you to make precise resource allocations for projects with an unknown scope, with a slipping deadline, and with a shrinking budget

But no matter what pressure you are under, please don’t ever give this article’s headline quote of “We don’t have the resources!” out to any of your clients! If you do, you will literally destroy the agency’s reputation that your Account Manager has built up over the years with his bare hands.

Here are two reasons why you should refrain from saying it:

1. You will ruin your reputation as you’re probably lying without even realising it!
2. One of your most important tasks is to keep your business away from the client

Of course your company has more resources! It will almost certainly be just a fraction of your agency’s workforce that you have allocated for your web project so far. As soon as more than one web project is handled at your company at one time there are more resources. The sad and brutal truth is that you probably do have the resource in-house, but just can’t access them or allocate them to your tasks – your organisation simply wouldn’t allow that to happen! So, admitting that you can’t get any more resources other than the ones you have assembled as workforce on their project is a bad thing to do. Just ask yourself the following question:

As for keeping your business away from the client, consider this example.

If you bring your car to a car repair shop – you don’t really expect the clerk to tell you intimate details about the workload of his staff, right? All you want to get is your car repaired. And thus you may accept the clerk saying: “Sorry. For this week we are already full. But you could bring in your car next Tuesday at 8 in the morning!” You really don’t expect any more information on the matter why you can’t get you car fixed before that.

The struggle for resources is one of the biggest challenges a Web Project Manager will face. It is however not the client’s concern how your web project staffing is addressed.

Dealing with resourcing issues

There are however a couple of techniques and replies which you can apply to situations where you are asked to stretch your project organisation beyond capability. They all boil down to the fact that it is essential for you to buy time, and to sequence the requests in a reasonable manner by constantly re-applying the distinction between urgent and important throughout a project.

If you have followed the advice assembled in this article so far you already have some good replies at hand to answer client requests about additional deliverables.

Several more re-usable Web Project Management snippets you may want to consider for any future resourcing situation include:

• “I would need to look into the implications on schedule and budget before I can give you confirmation on this matter.”
  • Remember, all the tasks and phases are deeply intertwined!
• “Upon initial thought it seems as if this request is enhancing the agreed functionality requirements. I’ll have this analysed by our technical experts first and get back to you.”
  • Remember, a significant scope enhancement will ruin one or more of the Assumptions and/or Prerequisites under which the Web Project Agreement has been issued originally and may result in filing a Change Request. Once clients see the price tag implied by their request, they may consider it “not that urgent / important”
• “I can only think of two people in my organisation that would have an instant answer to whether this is possible with the given system. Let me quickly see if I can contact any of them.”
  • Grab your phone while saying that. Remember, you are representing a team of experts, giving everything to satisfy client’s needs as they emerge!
• “The team for this week is completely allocated with coping for the unpredicted delay in the provision of material. We can have a look at this request next Tuesday at 8 in the morning!”
  • Remember to know where you and your team are with the tasks agreed and what is the most urgent thing, as opposed to important, to take care of is essential

For every additional task that ends up on your project team’s plate you have to consider one or two possible ways to deal with it. It depends a lot on the project team and the organisation you are working for and it also depends on how your organisation rates the importance of the project or client in question, but below is some general advice on how to try and squeeze in unexpected work into an already packed schedule if need be.

First, you could squeeze the task into the existing schedules, ordering your team to work overtime. You can promise compensation or certain gratifications for those who are volunteering for the extra work. Or simply assign the task to someone whom you consider fit for the job. This principle can be referred to as heroic management e.g. “It’s a shitty job – but somebody has to do it!”

Secondly, you could count on the advice and ingenuity of your project team. Make the task description as clear as you can and involve your project team in solving the matter. Discuss openly what other tasks can be shuffled around, postponed or distributed to more shoulders?

Is the new task truly a specialist’s task – or could anybody work on it? How would the team rate the chances to get the additional work equally distributed with only a couple of additional hours for everybody? This principle can be referred to as post-heroic management e.g. “It’s an inconvenience which forces us to re-shuffle already allocated tasks in a smart way!”

Last but not least, it largely depends on what kind of personality you are. If you are not able to contribute hands-on to the project (as you may not know how to operate a text editor, Adobe Photoshop, or a Content Management System) – you can always try to learn these things from your project team members and do the job yourself.

If you are not willing to contribute hands-on to the project because you do not consider this being a part of your responsibility – you can always try to get another job. The choice is yours.

In summary

Web Project Management, for which I sketched its shortcomings in the previous articles, will undoubtedly flop if it is carried out with the wrong focus and if it is aiming at the wrong goals.

The postulated deadly sins can, and shall be of course, all interpreted as examples of individual failure. In Web Projects, I have seen otherwise reasonable Web Project Managers being caught in selfish traps because they pig-headedly insisted on having the exclusively correct situation assessment and response for a particular question, issue, or project stage.

In the current economic climate it can prove deadly for a whole web agency if the management doesn’t see the wood for the trees – and each of the postulated deadly sins can easily obstruct the view on more important issues.

Web Project Management is far more a continuous business re-engineering strategy than simply the completion of pre-defined and well formulated task lists with known time, money, and competence allocations.

It requires, following one thought from the German sociologist Dirk Baecker, a type of management which sees its heroism no longer at the disposal of resources and the willingness to fight offending or unreasonable customer demands, but which requires serendipity for the factual and social dimensions of the organisation of work and the distribution of shared responsibility which comes along with that.

We are heading towards an age of post heroic management, for which two aspects seem essential to me:

1. The Web project Manager’s ability to let his personal motivations, goals and rewards fade into the background, and…
2. Each team member’s ability to re-think their own contribution beyond a structure of assessment, delivery and hierarchy

This concludes the Web Project Management: Seven Deadly Sins series. A big thank you to Michael for writing this incredibly extensive and enlightening article which has certainly taught me a thing a thing or two and I hope you feel the same too.

Related reading:

• Web Project Management: Seven Deadly Sins – Part 1 »
• Web Project Management: Seven Deadly Sins – Part 2 »
• Web Project Management: Seven Deadly Sins – Part 3 »
• 7 Deadly Sins of Beginning a Web Project »

About the Author

Michael Dlugosch works as a Senior Consultant at Kwantic Oy, a Web Analytics startup company in Helsinki/Finland. Follow Michael on Twitter »

In Part 1 and Part 2 of this series, Michael talked about the first four deadly sins of web project management. In this third instalment he focuses on dealing with delays in client feedback and controlling the scope of a project through thorough web project documentation – Anger and Covetousness.

5. Anger – “Dear client, as you failed to respond to my earlier emails…”

I come across many Web Project Managers who seem to personally suffer from the client’s inability to give feedback in good time. Though this is an annoying fact, in some situations it has to be attributed to a Web Project Manager’s inability to cater for this situation – beforehand, or as it emerges.

Trust me, even if you happen to inherit a web project where you are dealing with non-responsive client, not all is lost, yet. Countless intelligent people have devised Web Project Management documentation frameworks which would anticipate this situation, and prevent the worst case from happening.

However, I haven’t seen many web projects where all of this ideal world project documentation was in a grade A condition from the start (not even the ones I have started from scratch!), but then again, I’ve never worked with clients who wouldn’t have accepted a mode shift along the way, either.

But, if you have ever been forced to wait for client approval beyond the launch deadline you surely were caught between a rock and a hard place. As soon as this happens once, you are fully entitled to ask for a change in the mode of operation. In my experience, web projects tend to suffer from bottlenecks which are related to the allocation of time within the client’s organisation rather than your own.

Benefits of project communication logging

I had a client once who was managing a time-critical launch bound to an event where he had to participate in person and where he couldn’t be reached by email or phone for the whole afternoon while material was missing from God-knows-where.

We decided to go live with non-approved interim content. The client cried “Betrayal!” and refused to pay the bill.

I said “OK!” and stated I would simply send the project log (where all web project communication was recorded) via my boss to his boss to document the issue on behalf of our project team.

“You’re keeping a project log?” he said, with an amount of fear.

I replied, “Listen – do you really think that we, as a web project delivery organisation, wouldn’t organise and document our own web project delivery process? This is what we do for a living!”

Whether this project log exists or not is up for debate, but my advice is only ever be bitchy if you have evidence!

However, it is somewhat ironic how rarely the principles of Web Project Management are applied to the Web Project Management process itself. Managing the Web Project Management process is one of the most worthwhile tasks – and one of the most essential for complete confidence and stability on-going.

Web project delivery definition

In order to minimise situations like the above from ever happening, what I try to do from the start with any web project I am involved in, and if I fail, do as soon as I find the time or as the need emerges is:

1. I re-negotiate the prerequisites of delivery. Any web project which I have ever seen is based on assumptions e.g. “if we use framework XYZ, we’ll be fine” and “we’ll get all the materials in time”, and not forgetting the assumptions formulated out of pure madness like “we can do last changes on the materials in the two hours before we go live with it”
2. Whenever I read a web project briefing, or an RFP, I take a piece of paper and note down under which circumstances the stuff I read makes a reasonable request. And particularly, what are the likely points of failure?

As a result, my latest web projects had quite impressive sections in the Management Summary part of the web project agreement document.

One is labelled Assumptions and the other is labelled Prerequisites and they match the headlines on my auxiliary notes. One listing general delivery-related things and the other is listing items with regard to the project delivery schedule.

The first section states “Tool access is granted by the client” and the second states the deadline associated with it “Tool access is granted until 16.09.” which is exactly the start date for a project phase relying on the availability of certain things.

You’ll get the point here, I’m sure.

Needless to say that I, in some cases, failed to hand in the web project agreement document on time due to the extensive additions to the project agreement which was originally drafted. For times such as these it always becomes handy to formulate the essential “Three sentences why this document is late” for yourself, and for your Account Manager who will no doubt steal the formulated and re-usable excuse.

In one case the client went as far as to verbally convey their suspicion that I might be “not quite up to the task, maybe ‘incompetent’, or just a little inexperienced?” Thanks to the preparation, my Account Manager was prepared to extinguish this fire with a smile despite the fact they had asked for a simple task equivalent to order the following from your favourite bartender:

“One beer, but the foam on the bottom of the glass please!” – They got it and we got paid for it.

6. Covetousness – “Sure. This feature will cost you €10k”

As you may have guessed from what you’ve read before in this series or from experience, an unreasonable demand doesn’t get any better, regardless of how often you repeat it.

The key to make people pay for the things they are desperately asking for, which is beyond the agreed scope, is to comprehensively document the interdependencies between the parts of the puzzle for all to see from day one.

Working with a detailed Work Breakdown Structure (WBS) document makes this a much easier task. Everyone will have their own take on creating a WBS, but this is mine step-by-step:

Download WBS Template »

1. Transfer the different high-level stages of the project to pieces of paper – one phase goes on one piece of paper – or put it in an Excel file, if you want
2. Think about the competency contributions you will need for each of the phases and how they relate e.g. What do you need to get done by Web Designers in each phase? Is there anything that Software Architects or Web Developers can contribute, prepare, or review in a particular early phase of the project?
3. Add according lines to your paper, or add empty lines to your Excel. If the phases are in column A, put the tasks to be performed by particular competencies to column B. In both cases add marks to who is contributing in a separate column
4. Put all deliverables that you need as input for any of the phases in the upper left corner of every sheet. Making sure to note down which competency is contributing to which item in a separate column in the same place
5. Finally, try to envisage how the different contributions fall together into separate tasks. A Web Designer surely has to:
   1. Select the images for the web site
   2. Manipulate the images
   3. Finish them for web usage with sharpening, compression and naming them according to the defined naming conventions
6. Think about who uploads these images to the web site repository: the Web Developer? A Content Editor? The Project Manager? The Holy Ghost?
7. You will find both new tasks which are not covered in the basic project agreement new assignments which haven’t been thought of yet

What you will end up with, is complete knowledge you can present to your team, superiors and client on what action sequences need to happen in order to deliver e.g. There no point in uploading images which haven’t been selected and/or made ready for web usage, right? The dependency is created.

In the end, add the outcome of this examination to your sheets (preferably with a different colour).

Deliverables are marked with a right arrow (deliverable_X -> phase_Y), inputs to further phases are marked with a similar arrow on their left (phase_Y->input_X). Make sure every deliverable of one phase matches an input to another phase. Assign numbers with high-level phases get a single digit number “1″, subsequent packages get “1.1″; particular competence contributions get “1.1.1″ and so on…

And there you have it, a WBS document, matching both the output dimension of phase X and the input dimension for phase Y. Split by competencies, bound to web project phases and reflecting the actual deeds and work packages for everyone to see and track throughout the project’s lifecycle. Splendid!

Download WBS Template »

In the final part of this brilliant series, Part 4, Michael talks about Sloth, the last of the Web Project Management deadly sins. It deals specifically with the constant struggle Web Project Managers have when trying to allocate resource to their projects only to discover there is none available.

Related reading:

• Web Project Management: Seven Deadly Sins – Part 1 »
• Web Project Management: Seven Deadly Sins – Part 2 »
• Web Project Management: Seven Deadly Sins – Part 4 »
• 7 Deadly Sins of Beginning a Web Project »

^ Back to top

About the Author

Michael Dlugosch works as a Senior Consultant at Kwantic Oy, a Web Analytics startup company in Helsinki/Finland. Follow Michael on Twitter »

In Part 1 Michael discussed the sins of Vanity and Envy. In this instalment he goes on to talk about how Web Project Managers can keep web projects on budget, and perhaps even add more value than expected for the client and your agency, and what it means to lead from the front as a Web Project Manager.

3. Gluttony – “We need to increase the project budget by 2 million”

Gone are the days when clients seemed to have endless budgets allocated to an emerging digital medium and where they hoped to mark their claims on the Western frontier.

Today, more and more payments are tied to specific milestones, preliminary approvals by the steering group and successfully conducted functionality tests that are based on the use case descriptions, which may postpone a web project phase’s payment for six weeks.

It all depends on what kind of organisation you are working in and whether you’re paid by the efforts your team has put in, for meeting certain functionality criteria or for something else judged by some obscure stakeholders somewhere else in the world – big money spends on web projects have become scarce over the last few years, and you had better be fully aware that there is no more budget for your project – even if the customer has changed the scope countless times at will.

Either way, in these difficult times for the digital industry a Web Project Manager needs to find ways to keep delivering with reduced budgets and less margin for error that ultimately hit your already financially fragile web agency.

Here are two ways to deal with the constant problem of web project budget overrun:

1. Overspending
2. Shadow budgeting

Overspending

This is always a calculated bet on the future. It is the technique whereby a Web Project Manager or Account Manager justifies web project overspend by assuming that future projects for the same client will allow them to claw back the project overspend for the current one.

Shadow budgeting

Shadow budgeting is the art of working to lower budgets than you actually have in order to cater for the inevitable overrun – best case is you deliver under budget and achieve some internal process or skills development while being paid, worst case is you deliver on budget – not a bad worst case scenario, I think you’ll agree.

You start by taking the budget which you have for a given project phase or deliverable and you simply reduce this budget by 20% and consider the remaining 80 per cent from now on your available budget for this phase or deliverable.

Your team may mourn, but here’s how you can explain it so that they are more likely to follow your approach…

Most project deliverables follow Pareto’s 80/20 rule – 80% of the outcome of a project deliverable is realised with only 20% of the effort put in. It usually swallows all remaining budget to complete a deliverable – particularly due to long review cycles and more iterations than planned.

Plus, your client may indeed be happy with a preliminary 20% deliverable to collect instant feedback from within their own organisation even before your agency has put in all the efforts in to complete the whole stage.

In the end the client’s organisation may scrap it all anyway because your deliverable may not meet their high expectations – so why not give them sneak previews instead?

My best advice is to involve your team in this from the start! Let your team decide how to share the most laborious tasks. As a Web Project Manager, get your hands dirty in the practical preparations. Touch code, review copy texts, cut images – simply suck in as many practical issues as you can and familiarise yourself with the strains of fatigue and boring repetitive tasks.

Encourage your team to divide labour, to share what they learn and discover along the way, to focus on tasks which require a lot of concentration only for an hour at a time and to review and question each other’s work.

Allocate half of the shadowed budget for this stage (10%) to scrutinise and streamline the team efforts for getting the original deliverable out with more nifty tools, better material preparation, machine-based data enhancements and a smarter repository structure.

Make it a team effort to elaborate on solutions for the never ending need for further streamlining! Equip every piece of material with hooks and handles so that you can re-process and re-use it along the way.

As plenty of the original budget for phase conclusion is usually spent on implementing what was originally agreed in the first place, you need to free the team from the inability to revoke their original ideas, and because some of these efforts are spent on repetitive tasks, you may be lucky enough to pocket the famous learning curve effect which usually come along with repetitive tasks and may account for as much as 30% of the original 80% phase budget.

Any Euro, Pound, Dollar or Zloty spent on thinking about how to solve a problem can lead to totally new, and unpredicted, ways to get things done, and with considerably less effort and thus more cost effectively for future projects – think long-term.

With the other 10% of your shadowed budget – spend it on thinking through the consequences of the chosen setup. You may find that with only a relatively small additional effort, you can put time into those mythical documentation and show cases!

4. Lust – “Non serviam!”

I can’t help but notice the occasional unwillingness among Web Project Managers to serve.

By this, I don’t mean the feeling that one would have to stoop when the customer lets the proverbial soap slip – I mean the ability to let your own Web Project Manager personality evaporate into the background in favour of something else more honourable and geared towards getting things done together for the team.

It is a platitude that any kind of management only has two ways to get anything done – action and communication.

Communication without action is simply pretending, and action without communication will never lead anywhere. Big gestures, speeches, or any other kind of ‘pep talk’ are not really well suited for motivating people’s participation without follow through.

The inability or unwillingness to serve can be easily attributed to what psychologists call: narcism. However, it may lead further to take another angle and approach this topic through the back door.

We have, thanks to the genius of the sociologist Max Weber, a term for coining what might make the essential difference here – it’s called work ethics. At its core it can be surmised as “working hard will please…later”.

The distinction between hard work in the present and a gratification in the future is the core personality attribute that distinguishes an average Web Project Manager from an excellent Web Project Manager.

Contrasting this approach with the mentioned distinction between “action” (from Latin “agere” – to do) and “communication” (from Latin “communicare” – to share, to make common) indicates the direction of the reference inherent in both terms – towards oneself vs. towards something beyond oneself.

I believe the trouble with the stated “unwillingness to serve” is the coherence between one’s actual deeds and the expected or well deserved gratification structure behind the deeds. Or from the opposite perspective, it is the inability to classify one’s own deeds into coherence beyond the benefit for oneself.

If a Web Project Manager is primarily concerned about their own reputation (their lust for praise from others), status or comfort, it will undoubtedly have a negative effect on the team’s motivation to walk the extra mile with them.

Who has ever met a Web Project Manager that leaves the office during a laborious end phase of a website production on the evening before go-live with the reasoning “I have to attend my dance class”? If you have you have every right to scorn at their own perceived right to call themselves a Manger of any description.

To manage means to lead, and leading is located in the action domain, not in the communication domain.

In Part 3 of the series, Michael discusses how to resist getting angry with clients when the temptation is overwhelming, and how to control the scope of web projects by defining clear specifications and project scope from the outset – Anger and Covetousness

Related reading:

• Web Project Management: Seven Deadly Sins – Part 1 »
• Web Project Management: Seven Deadly Sins – Part 3 »
• Web Project Management: Seven Deadly Sins – Part 4 »
• 7 Deadly Sins of Beginning a Web Project »

^ Back to top

About the Author

Michael Dlugosch works as a Senior Consultant at Kwantic Oy, a Web Analytics startup company in Helsinki/Finland.

Equipped with true passion for the Internet since his first encounter with it in 1996, Michael has been jumping around in Digital Agencies since 2000, running web projects, web productions and teams, consulting as Usability Specialist and, lately, as Web Analytics Consultant.

While not working, Michael can be found taking photographs or preparing home-made pasta.

We’ve all been tempted, we’ve all been there…

Tiresome web projects without end, endless discussions with the client, never ending resourcing problems, budget cuts, technical systems not working and changing scopes all over the place – everything turning upside down faster than you can spell change request!

No doubt about it, Web Project Management is not an easy job.

However, during my own involvement with web projects I’ve had to witness particular things which were said by team members, in front of the client, and within the team itself, and these things did nothing else but add to the confusion and difficulties that all web projects already have too much of even at the best of times, making the job of the Web Project Manager that much more challenging.

I tend to call these things the “Seven Deadly Sins of Web Project Management” and within this series of four articles I will describe and illustrate them, with examples – along with my best practice advice on how to deal with the temptations we all face.

1. Vanity – “We know better than the client!”

Let’s assume you work for an agency which has a certain experience in the field and has been running web projects for several years now, think how many projects have you and your team been involved in? 20? 50? Maybe even 100…

An average client has run only a few and often has only one primary goal; he or she needs to satisfy the expectations that have been set by their superiors.

While it has become commonplace in web agencies to internally share the most outrageous briefings and the insane functionality requests for a good laugh with the project team, it should always be coupled with attempting to help your client by communicating with them better.

Of course you know more about web projects and web project management – so why don’t you start educating your clients accordingly? Take the following example of client feedback we’ve all heard and laughed at:

“Thank you for the screenshot of the HTML newsletter you sent. The layout looks ok, and the copy looks good. But not a single link works in the .jpg file you’ve sent me. You are going to fix that before sending the campaign, right?”

There is a wrong and a right response to this request. If you’re pressed for time, simply reply:

“Yep, we’ll take care of everything before we send it out.”

Don’t reply with:

“This is a screen shot, you stupid butthole! Of course the links don’t work in it!”

If you’re a patient person with nerves of steel, you could say:

“Hey, thanks for your feedback. We’ll take this as approval for the newsletter layout and content, and will make sure that all the links in the final version are functional and being tracked. Our technicians cannot yet exactly predict how long it takes to complete the newsletter batch delivery for all 3428 addresses, but we have scheduled to send the first campaign blast with 500 addresses at 2am tonight.

The file you’ve reviewed represents just an image version (jpg) of the final newsletter file (HTML) and thus doesn’t include any active link functionality. This is to ensure we do not inflate the click-through numbers during testing…”

See the difference? Embedding your sharp reply inside a plethora of “this will happen next in the process” information is serving two purposes:

1. It gives the client more information that they can hand over to their respective superiors
2. It educates the client about some tiny details in web technology

A colleague of mine once labelled this approach as “killing with kindness”.

Admittedly it takes time to write such lengthy replies. But by tying your reply to the next steps in the agreed process you do yourself and your client several favours:

1. You’re re-assuring your own understanding of the tasks that need completing
2. You give them the correct language to frame the project status and next steps to their superiors

This makes it easier to deal with upcoming requests from the client’s organisation as you easily can prove how deeply intertwined the single tasks are.

Also, at all times you are depending on your client’s political position within their own organisation and are literally casting silver bullets for them that they can fire from their corporate rifle. They may use the additional and contextual information that you give them to brag, fight back unreasonable requests or to claim as their own, but in all cases you can assist in making your client appear in a brighter light by filling them with web project specific information and terminology.

Remember, as a Web Project Manager one of your many roles is to make the client look fantastic to their superiors, do this and you’ll only improve your chances of repeat business.

But wait, isn’t that the job of the Account Manager?

2. Envy – “Account Management… I could do a better job myself!”

Many times I’ve witnessed Account Managers leave the office, much to the envy of the web project team and Web Project Manager as they are still clocking the hours up long into the night. As the leader of a web project team you are of course, more often than not, sharing cold pizza with your project team rather than seeing your friends and family in the evening.

But remember this distinct advantage of being a Web Project Manager over an Account Manager… by definition – A web project is a temporary endeavour with a fixed start and end date and so sooner or later it will be over – Account Management is never over.

Nothing prevents any client from calling up your fellow Account Manager at 10pm to discuss an article about how the latest web trends in viral marketing will influence the company’s performance on social media perception within the next twelve months from now on.

What looks so easy during daytime often proves to require an “always on” mentality for Account Managers, and trust me, wining and dining with clients is not as much fun as it sounds (although the food and drinks are on the house, mostly).

The only currency that an Account Manager has is trust. However, gaining, and keeping, the client’s trust is essential for both Web Project Managers and Account Managers.

But while Web Project Managers have very clear boundaries – delivering web projects – Account Manager’s success criteria are a little more blurry. While Web Project Managers may get adulation and praise for their constant supportive role (aka pulling rabbits out of hats – aka saving the client’s butt), Account Managers often find it more difficult to get famous for their deeds.

Maybe that is the reason why Account Managers are so often interfering and messing around with web projects, and the people involved in them, when it is not necessary – because it seems so much easier and more instantly rewarding when compared with what they normally do.

It occasionally seems to me that it’s the Account Manager’s secret job to promise what others have to deliver with no real clear idea if it is even possible, but the reality is a usually more brittle than that – thus putting the Account Manager in a difficult position.

While Web Project Managers have to deliver within a defined scope, Account Managers have to account for future scopes. At any time, a current client can approach a direct competitor of yours to begin talks about receiving the same service with improved quality and lower costs.

The Account Manager’s job is precisely this – to decrease the likelihood of this happening.

Operational, tactical and strategic are the names of the fictional stages of the continuum that both types of Web Managers have to tackle on a daily basis. While the operational side deals more with things that have already been agreed (projects and deliverables), the strategic level deals more with the ‘yet unknown things to come’, involving, for example, planned co-operations with institutions nobody has yet heard of and the instant need for ramping up your agency’s workforce by 385% within the next eight months.

The really tricky thing is that the Account Manager is held responsible for is the substantial monetary growth of the account through targets based on many unknowns.

So as a Web Project Manager, while continuing to attempt to keep the Account Manager away from the day to day running of your project, understand why Account Managers may insist on doing this before berating them.

In Part 2 Michael discusses his next two Deadly Sins of Web Project Management. How to keep web projects on budget without having to ask the client for an additional 2 million, and how the Web Project Manager should be willing to serve the project first and themselves second – Gluttony and Lust.

Related reading:

• Web Project Management: Seven Deadly Sins – Part 2 »
• Web Project Management: Seven Deadly Sins – Part 3 »
• Web Project Management: Seven Deadly Sins – Part 4 »
• 7 Deadly Sins of Beginning a Web Project »

^ Back to top

In my experience, by consistently displaying a high degree of honesty, trust and integrity to everyone throughout the web project’s entire lifecycle helps improve your chances of success, cements your position as a solid leader and earns you respect from both client and project team alike.

“A relationship that is based on honesty and trust with staff should create an environment of mutual respect. This environment should produce a more efficient production environment where staff are willing to go the extra mile to deliver a truly excellent product.”
Ed Richardson, Honesty is the best policy

Honesty and Trust in Web Projects

Of the many things you can be sure of when running any web project, one of them is that at some point you will have the choice to be honest or not so honest with either the client or your team. This choice is only ever one that takes more than a minute to debate in your Web Project Manager brain when the truth is likely to upset someone.

These choices come in all sorts of shapes and sizes but invariably include:

• Explaining to the client why a deliverable is late
• Telling a team member their work isn’t up to scratch
• Admitting you made a mistake yourself

In each instance the temptation for most Web Project Managers, in fact all human beings, is to at least consider taking the easy route and delivering a distorted version of the truth, or in non-corporate buzzword bingo professional terms – lying.

The fact of the matter is, often not being honest is the easiest option and will immediately make everyone feel great, however it’s pretty rare for this short-term easy option not to come back and bite you right on the backside and this is far more damaging to a relationship with the client or project team in the long run.

As a Web Project Manager, by cultivating a reputation as an honest straight talking person who will always tell you the truth, no matter how bad the truth is, eventually results in most trusting you when you speak – in business no one wants to have the wool pulled over their eyes and most can spot it a mile off.

So the next time a client demands to know why the deliverable is late when the reason will make you or your agency look less than great, tell them the truth… It will hurt, it will sting and it will be an awkward conversation that you’ll want to end, but, in most cases once the anger has faded away the client will almost always respect you for having the balls to be honest when other weaker web project managers would’ve lied.

The key lesson is that once a client knows you have the courage to be honest with them when it’s really bad news, they’ll completely trust you to always be honest from that point on and trust pretty much everything you say which, over the course of a project lasting months or years, is an invaluable position to be in as opposed to the oh so common vague feeling of mistrust that often exists between client and web agency.

Integrity in Web Project Management

Defined by the English dictionary as “Steadfast adherence to a strict moral or ethical code”, integrity is something a Web Project Manager needs time to develop and demonstrate, but once you have established yourself to the client and your web team as a leader with a great deal of integrity you will find all your working relationships improve dramatically.

Although inextricably linked with honesty and trust, integrity in web projects is all about acting in the most professional manner possible in front of your client or web team when faced with situations that require you to choose between standing by your principles, or, forgetting you have any for fear of appearing to be going against the grain.

“Sometimes telling the truth will not make people happy, or make you the winner of a popularity contest. In some cases you may suffer from “loss of grace” for telling the truth or for standing up for what is right.”
Thomas M. Cunningham, US Naval Academy Fire Department, Leadership 101: Integrity

Examples of displaying integrity in a web project management role include:

• Accepting responsibility for a mistake that you or one of your project team made
• Openly defending a project team member or client when the temptation is to keep quiet
• Insisting quality standards remain despite the temptation to cut corners

Preceding each of the above examples comes a situation where as a Web Project Manager you will have a choice between staying quiet and letting someone else take the fall or, as Thomas Cunningham puts it, standing up for what is right.

In these instances it is you that may be hurt and stung by the response, but as with honesty, over time your team and client will respect you for choosing to take this position as your default one.

As a Web Project Manager, failure to act with honesty and integrity will undoubtedly be your undoing. Both clients and your web project team will at some point become very wise to the fact you are keeping quiet, blaming others and treat you accordingly – with mistrust – and there is nothing more damaging to a project.

Having the strength to take a few hits for your web project team or from angry clients on the phone is not easy. It will often feel like you’re getting a load of flak and stress that you really don’t need and know full well you don’t deserve, but, the trust and respect you win from the people that matter is infinitely more valuable to your projects when compared to the reputation you pick up from acting inappropriately.

If you are in a web project management position, or any other leadership or management position for that matter, I cannot recommend reading the Leadership 101: Integrity article enough – it has absolutely nothing to do with web projects but everything to do with what it means to be a great leader. If you can manage to apply even one part of it in your day job, you will be a better leader and manager for it!

Honesty, trust and integrity – go on, try it, you just might like it…

^ Back to top

Add to that the nature of running a business where cash flow is critical, other projects can knock your carefully thought out plan sideways or a key client ring up with urgent requests that require resource you booked months in advance, and you have a delicate situation indeed.

While web trends and technologies evolve around us at a rapid rate and business requirements can often change on a week by week basis, a Web Project Manger will have to make constant decisions on what solutions to ultimately deliver to the client and often these decisions will not please everyone involved in the agency or project.

So who are these people and why may they not be happy bunnies?

Who you may annoy as a Web PM

In short, as a Web Project Manager, making final decisions about which solutions to implement, the chances are at some point you will annoy absolutely everyone who is involved in projects… not an appealing part of the job, but sometimes a necessary and unavoidable one.

“The Project Manager can’t ensure that they’ll be loved by everyone – nor do they want to be. They aspire to be well respected by the customer, but even that can’t always be guaranteed no matter how well they perform and manage the project. But, the Project Manager can ensure that everything that is expected of them is being performed well and if that doesn’t always do it for the customer at least it should be noticed by the delivery organization.”
Brad Egeland, Reputation is a Fragile Thing

But before you get scared and begin to re-think that career move into web project management, let’s look briefly at what each team member generally wants from all projects.

Empathise and understanding

Empathy and an understanding of the business forces driving different people’s motives are key skills required by any Web Project Manager as it enables you to appreciate other perspectives when making project decisions.

Let’s take a look at the usual suspects, who they are and what they want from web projects and your web project management. *Stereotype disclaimer included afterwards.

Web agency directors

A web agency director wants the project completed on time, on budget, to a quality level that is fitting to the web agency and with the client feeling happy, wanting more work and willing to give referrals to potential clients.

Finance directors

A finance director wants the project milestones split up in such a way that cash flow/collection is maintained for the business and thus that the project is completed to schedule, on time and on budget.

Web designers

Web designers want to push the boundaries with each design, creating designs that make the client happy, are worthy of the web agency’s portfolio and any web design showcase site.

Web developers

Web Developers want to use the latest technologies in order to implement the most efficient solution possible and keep the web agency on the cutting edge of the industry.

Web project clients

Clients want to receive a website that is as future proof as possible and facilitates them being able to achieve their short and long-term business aims. Unless otherwise informed, they will assume the website has been built to excellent standards but probably won’t care what doctype has been used so long as it looks and works perfectly for their users.

Web project managers

In the middle of everyone is the Web Project Manager, and he or she will want, and often be expected, to meet ALL of the expectations above. But if you work with other Web Project Managers they will want your project to run on time so that their own projects can also be on schedule.

Web Project Managers: In the middle of everyone

Cool, that’s everyone nice and neatly packaged and stereotyped, so why is it not always possible to please everyone, and as a Web Project Manager, how can you try to make sure everyone’s as happy as possible?

Consider, analyse and communicate

It is vitally important to understand that, in most cases, everyone’s intentions are good! They are always geared towards delivering a great project and growing their companies!

Understanding this first fact is crucial when you’re being pulled in every direction trying to keep people happy. Failure to understand this results in a very defensive posture when challenged and that usually leads to bad things.

When you have to make a web project decision the key is to always:

1. Consider everyone’s perspective, goals and motives
2. Analyse and make a decision
3. Communicate why you made the decision

This sounds simple and thus you would think it easy to articulate in a paragraph, but after trying to do just that and failing quite dramatically, in much the same way as Greedo tried to apprehend Han Solo, it seems best to illustrate the point using a few scenarios Web Project Managers face every day.

Greedo apprehending Han Solo #fail

Developer: “Let’s use a new technology”

You have the client requirements, you communicate this to the development team and you hear the phrase you know both excites and scares you…

“We could use [insert_new_web_technology_here] for that feature.” – It’s time to and make a decision.

The first step is to consider why the developer is suggesting to use a new technology as opposed to the one the agency has experience using – it will generally be for one of the following reasons:

1. The new technology has the potential to be far more performance efficient than the current one
2. Using the new technology will mean less repetitive work in the future
3. The developer fancies trying out (playing with) the new technology

Next a Web Project Manager should analyse if using the new technology is a decision that will improve the project, web agency and/or client’s chances of meeting their business aims.

To do this it is important to make sure you fully understand the technology in question so you can assess the potential benefits and risks.

In order to make a decision a Web Project Manager needs one or all of the following because ultimately you are 100% responsible for the project’s outcome:

• Experience in the technology being put forward as a possible solution
• The aptitude and willingness to research the proposed solution
• Absolute trust in team members to make the right decision

Once you understand the technology, assess it against the project and decide if the long-term benefits justify going for it and then communicate your decision and reasons why to your team.

If you choose to go for it then you should communicate the possible benefits of using it to your boss and add the caveat that it is adding a certain risk to the project and thus could cause some overrun. Of course you may be overruled, but if you think it’s worth it, put your case forward and do everything you can to make sure the benefits are clearly visible.

If you choose to reject the idea you should do more than just say “no” to the development team, instead communicate to them the reasons why you are making this decision, which could include:

• Using the new technology brings too much risk to what is already a fragile client relationship that needs complete stability right now
• You feel the advantages of the new technology are not strong enough when compared to the current stable one you use
• The new technology is not mature enough to be used on a high-profile site
• The cross browser compatibility is not broad enough to warrant use
• The project budget is already extremely tight

It’s quite possible that, even after explaining your reasons, team members will still be unhappy and you will get the shaking heads and sighs that translate as “This Web Project Manager is really stuck in his ways and is holding this agency back technically!” It’s at times like this you just need to have a thick skin and have absolute conviction in your decision.

As I’ve said before, as a Web Project Manager you are responsible for the entire outcome of the project and thus the client satisfaction, deadlines, budgets, agency cash flow, reputation and whole host of other business critical factors – the technical solutions provided are the complete focus of the developers, but in the grand scheme of things only one part of many and you are the one with the complete overview.

Communicating this to the development team regularly will hopefully raise their awareness to this fact and make them more commercially aware, and that can only be a good thing for any web agency.

Always playing safe

As a little side note however, making the ’safest’ decision is not always the best move, sometimes it’s best to just go for it even if you think the chances of success are smaller than you’d like…

This is how web agencies move forward, by occasionally throwing caution to the wind, taking risks and pushing the boundaries! If it works, you and your team are great, if it doesn’t, blame will be laid squarely with you – but hey, as a Web Project Manager you should be used to this situation right ;-) and better to have given it a go than always play safe!

MD: “Why are we going over budget?”

Oh the words any Web Project Manager fears… it inherently is coupled with the assumption the project has been managed poorly and thus you should be hung, drawn and quartered. On some occasions this is exactly the case and it’s best to just admit it, learn from it and try to make sure the same mistakes aren’t made again – it happens to us all, its how we become better.

However, on the odd occasion a Web Project Manager has consciously made decisions that they knew would cause the project to overrun, but in doing so have achieved, or gone part way to achieve, a web agency’s business goal that aligns with the long-term strategy.

Examples of this include using web project tasks or phases to:

1. Train a team member in a new skill and/or give them experience
2. Develop new web project management processes
3. Create a stunning agency portfolio site
4. Develop a new re-usable plug-in for a CMS
5. Make a very important client very happy

Of course an agency would ideally be able to satisfy all of these requirements on a regular basis within project timelines and budgets, but let’s face it this isn’t always possible so you have to grab any opportunity you can and go for it – remember, over budget doesn’t always mean zero profit.

The important things are to consider if this is the right task, project, client account or time in the business’s life to go over budget by using your knowledge of all four to analyse the best course of action.

If your analysis leads you to the conclusion it is worth it, then communicate to the big boss man (or lady), preferably before you announce the decision to the team, that this is why you went, or are heading, over budget on this particular project, but, the agency now has a:

1. Trained up team member who has a new skill that can be utilised on future projects
2. Happy team member who feels they are growing in experience and skill
3. More refined and efficient web project management process
4. Website or web application that will ‘wow’ potential clients and makes the whole agency proud
5. New, or vastly improved, CMS feature plug-in that can be deployed in minutes rather than hours
6. Great chance for repeat account business and glowing referrals

If you can communicate the reasons you made a decision that meant your project overran and demonstrate that it will provide a potential viable amount of return on investment, more than the over budget time spent, you should get the thumbs up and it’s full steam ahead.

Even Stormtroopers had to demonstrate ROI

Client: “I want to add a new feature”

Words from a web project client you could almost bet your life savings on hearing at least once per project and after all functionality has been agreed upon and budgeted for in terms of money and resource allocation.

However, in order to shy slightly away from the traditional Waterfall project management methodology, a Web Project Manager’s response to requests like these should never be an instant “no” because a specification has been signed off for several reasons:

• They could have additional budget and be willing to extend the project’s timeline in order to fit the new feature in
• Other parts of the project may be ahead of schedule and under budget, leaving room for additional work
• They may be willing to sacrifice a previously agreed feature to get the new one in
• There may be an alternative and quick to implement solution that will see the same aims achieved
• The feature in question may be one your web agency have been thinking about developing before to sell to other clients
• “No” should only ever be the words you use if after analysing the request it is deemed in no way possible

Before making any decisions a Web Project Manager should first consider why the client is asking for this feature and why now.

The common response to these requests is to huff and puff about how typical of a client this is, assume they are being cheeky and trying to squeeze the web agency as much as possible etc. But, for the most part, clients are savvy business people who know their industry, market and target audience better than you and thus the late feature request could well be a reaction to something happening in their field that makes a seemingly daft request quite a sensible one.

Start by having a discussion with the client about why they want this new feature, more importantly what business reason or web project KPI they feel it will help to satisfy.

Once you have fully considered why the client has made the request, the next step should be to analyse if the new feature:

1. Will help the client’s business or project aims
2. Can be completed under the current budget, timelines and required resources are available
3. Would require additional budget or timeline extension
4. Could be re-sold to other clients

Once you have analysed the information and made a decision, you should then communicate it to the client.

If you decide to allow the feature in the client will be over the moon and they’ll love you to bits, sweet.

If you decide that the feature should/will not be allowed in, then you will get a mixed bag of reactions depending on the client, but how you communicate this decision can influence the reaction immensely!

Take the client through your decision making process step by step, explain to them the hours you estimate the new feature would take just cannot be accommodated unless they agree to provide further funding or sacrifice another project deliverable, or how the feature would probably not in fact achieve what they would hope it too – the more transparent you are about your decision making process when communicating the decision, the more understanding you’ll generally find the client to be.

Learning how to say “no” to a client is an art form for most Web Project Managers.

Guaranteed happiness for one and all?

Web Project Managers are constantly pulled in every direction by everyone – they are always in the middle of everyone and their priorities. It requires a great deal of strength, understanding and negotiation skills to be able to deal with these pressures and end the project with all parties feeling positive – remember Web Project Managers’ motives are also always focussed on delivering value, not only for the client, but their web agency as well.

By following the consider, analyse and communicate decision making process during web projects will not always result in happiness for everyone involved, but being honest and transparent about how you reached the decision and why you believe it is the right one for the project, web agency and client should go some way to reducing any friction that could be caused otherwise.

What tips do you have for keeping everyone as happy as possible when making web project management decisions?

I don’t know about you, but I’m always fascinated what other Web Project Mangers’ are up to when they’re not putting the world to rights on Twitter or in blog comments.

Important things I have learnt

1. McDonalds coffee is now drinkable
2. I am the last PC user in the world
3. Jack Bauer could probably bruise Chuck Norris
4. Tropical punch should be a controlled substance
5. A Bruce Lee/Stormtrooper wallpaper makes me happy

iBruce Wallpaper – Gold Dust

Image source: iDesign for iPhone

Ok, onto the more relevant content…

Smashing Magazine article published

Due to the popularity of my Estimating Time for Web Projects series I decided to re-write the two articles into one and submit to Smashing Magazine for publication. To my humble surprise and child-like joy, it was accepted and published last month by Vitaly Friedman, Chief Editor (a genuinely nice and down to earth guy).

The article received really positive feedback and with front-page love on Digg and Delicious meant my server ground to a halt once again – joy.

Effective Strategy To Estimate Time For Your Design Projects »

New sites launched

Project managing the new sites below are a big reason my posts have been almost non-existent, with another two launching soon, as you can imagine, I’ve been pretty beat in the evenings (please submit sympathy via comments), so much so, Rawnet are looking to hire a new Web Project Manager, get in touch if you’re interested.

View Rawnet’s Web Project Manager vacancy »

HHIC

Central Heating.co.uk – Rated 80/100 by NMA

Recently rated 80/100 by New Media Age (NMA to you and me) in their Site Inspection section, this was my first public sector outing as a Web Project Manager. It was one of those projects that just went well from the beginning, was a pleasure to work on, the results blew the client away and made everyone at Rawnet proud little soldiers.

View the HHIC website »

Neocol

Neocol.com – A web project with all the trimmings

This project had it all; design, front-end, back-end, animated elevator presentation, SEO, copywriting and print marketing material design! This one took real tenacity to manage and a long time to get live, but finally managed it this week and the client is over the moon as it really does blow competitor sites out of the water.

View the Neocol website »

BaxterStorey

BaxterStorey.com – Birth of the Flowerpot Functionality

Rawnet were commissioned to provide web development for BaxterStorey’s new website. The branding and design had been finalised before we came on board which meant working with not only the client but also another agency, which, as those who have had to be the lynchpin between multiple agencies will know, brings about a whole new set of challenges.

As with most projects I had to write the functional specification for this one, and will always remember, from this day forward, having to define the “flowerpot functionality”.

On time and on budget makes Jack a happy boy.

View the BaxterStorey website »

Delicious feed updated

Ok, so hardly exciting, but over the last month I had built up a ridiculous amount of bookmarks, RSS feeds and Twitter favourites that I’d deemed worth a read when I got some time. Well I found that time recently and read everyone, adding the best of the bunch to my Delicious feed. Some of my personal favourites include:

• Brad Egeland: Characteristics of a Project Manager
• Rob Borley: Under Sell, Over Deliver
• Drew McClellan: Cost Effective Development Techniques
• Karl Staib: Stay Happy During Stressful Projects

The Vendor Client relationship – In Real World Situations

If you like these articles, you may want to subscribe to my Delicious RSS feed as I will be keeping this up to date from now on in a true GTD style – Operation BookmarkZero begins!

View my Delicious links »

ScrnShots: Web design inspiration

ScrnShots: Start building your inspiration library

For those diehard fans out there, you will have noticed a new call to action in the sidebar, underneath my shallow and desperate plea for Twitter followers – ScrnShots. This is where I upload all of the websites and website design elements I happen to chance upon, and make me go “phwooar nice!”, as I cybersurf the beautiful waves of the digital super information highway.

I recommend everyone involved in the industry, not just designers, should keep some kind of inspiration record that they can draw upon when embarking on new and fantastic projects. From a web project management perspective, you can use it to brief designers, developers and even present examples to clients to communicate solution ideas.

*Note: I don’t believe I have diehard fans, just fans of Die Hard. Yippee-ki-yay!

View my ScrnShots collection »

More articles coming soon…

I have a bit of time off work at the moment so intend to get disciplined and write a few original articles – I’m hoping this public statement will force me into delivering the goods, if I fail, I will make up a very good excuse thus shifting all responsibility to something out of my control.

What Web Project Management topics would you like to see covered next?

^ Back to top

In this final part we’ll look at a pragmatic approach to web project planning for those of us working in a small busy environment and who often find it difficult to make time for a toilet break.

Example small website brief

Let’s take the following common brief to a small agency or freelancer as our example scenario.

“Hey web nerdy geek person, I own a one man band catering business. I want a small website so people can find me, view my menus and book my services online. I want to be able to update the website content myself, edit my menus, upload images to the menu gallery and receive orders via e-mail. I’d like to launch in 4 weeks and have a £3000 budget.”

Notice I omitted the requirement to be number one on Google for the keyword “food”. This would clearly cost at least another £1000.

Planning? Pah, no need, no time – boring!

Ah (I hear you say), a small simple website, could probably get started on designing the homepage straight away, let’s get it on!!!

The truth is, yes, you could dive straight into your sketchbook or Photoshop and get designing, but what will go on the homepage exactly? At this point you could guess based on, what is usually, a slightly woolly set of initial meeting notes. But the reality is you just don’t know and the chances are you will spend time on several revisions of the homepage and it’s widgets until you get the client’s approval.

If you get it right first time then you got lucky or you’re a psychic web designer (If psychic please contact me for immediate employment opportunity).

By diving in and getting the homepage approved by the client you will have used a certain amount of project time, but how much did you have allocated for the homepage design and what date should it have been signed off by in order to remain on track for launch?

If you don’t know the exact answers to these questions your project is already out of control.

Despite this, you press on and get approval for all design, hooray! You begin to start the functional phase of the project only to discover the client wants a rotating banner on the homepage and wants to be able to do a whole host of other things dynamically that when designing you had envisaged being static elements – oh the pain of re-opening the design phase of the project after ‘approval’.

But, what about if you choose to hold off from the production side of things and start with some project planning…

Pragmatic web project planning

Ok, so the above scenario is a little exaggerated to illustrate the point, but I challenge anyone, and I include myself, to deny they’ve ever found themselves in a similar situation with a web project, I know I have and no doubt will again!

The web project planning processes described below are not intended to the be a definitive set of web project management techniques that align with the classic project management methodologies, but a stripped down version that I personally find practical on a day to day basis when trying to juggle the realistic amount of work and lack of time we all have.

For the freelancer this may seem all a bit too much to consider doing, but I can assure you, once you get to grips with it you can knock out all of the processes in a solid day or two for projects ranging from small to medium and it will inevitably save you a lot more days in the long run!

Defining scope, identifying risks and granular project tasks

If you estimated the web project using a method similar to the one I described in my Estimating Time for Web Projects more accurately series you already have a head start as you have a complete breakdown of all the design and functional requirements, along with timescales. If not, don’t panic, you can retro fit the method based on the budget and deadline as follows:

• Speak at length with the client and break the project down into all design and functional requirements, getting as granular as possible for both
• Document any assumptions you have to make about the project due to lack of information e.g. the client will perform all content entry and provide all images
• Estimate times for all tasks and see how the totals match with the budget and deadline.
• If your estimates put you over on both, begin to work with the client to agree on dropping or simplifying design and features until you are both happy
• Enter the agreed tasks and times into your time tracking tool

By going through this initial exercise with the client you have immediately gained a great deal of control over your project before you’ve even thought about starting that all important homepage design by:

• Defining the project scope, at a high-level, allowing you to manage any scope creep throughout by being able to identify any feature requests as ‘new’ by it not being present in the task list
• Identified some of the project risks in terms of features that are complex
• Broken the project down into granular tasks, knowing how long you have to complete each one

Now you have all of this defined information you can continue with the web project planning process, starting with the project schedule.

Producing a project schedule

Using the agreed estimated times and deadline you can now produce a project schedule. Using a simple, free and open-source tool like Planner; define your web project start date, enter all of the project tasks you have identified, with the exact amount of time allowed for each. PM tools like Planner will automatically assign each task with a start and end date.

Planner: Create a project schedule & even export as HTML

One of the advantages of using a tool that allows you to produce a GANTT chart, with start and end dates for phases and tasks, is that you can add:

• Client tasks
• Revision time
• Dependencies
• Lag
• Resource allocation
• Project milestones

Dependencies? Lag? Ewww, web project management waffle! But even if you don’t plan your web projects thoroughly you will need to deal with all the above during the project – being prepared for these in advance is the magic!

Client tasks and revision time

One thing your granular project breakdown will often not include, because it’s not something you need to estimate on in order to produce a quote, is the tasks the client must complete throughout the project and the revision mini-stages you have to expect to go through before sign-off of any phase or task. At this stage you need to include them, not only for your sake but also the clients’.

This means adding tasks such as:

• Client homepage design review
• Homepage design revisions
• Client homepage design sign-off
• Client copywriting

Despite these tasks being either encapsulated in your quote as ‘Homepage design’, or not at all (client copywriting), when producing a project schedule it is crucial to consider them all as they impact the overall project timeline. For example, if you have determined you only have 3 days to complete the homepage design phase, by adding in review and revision times you can communicate to the client that, in order to hit the deadline and keep the project on schedule, they must be available to review, provide feedback, sign-off and deliver website copy on/by certain dates.

Often a client seeing the turnaround time required from them, when comparing with their busy schedule, can illustrate the realism of hitting their go-live date and open up an adult dialogue that will see an extension allowed.

Note that this is still before you have put pen to paper and started a sitemap or designing the homepage – this is hardcore client expectation setting right at the beginning of the project and in the right way, as opposed to 2 weeks before go live when print campaigns have been booked!

Dependencies

Dependencies are simply rules that state Phase / Task A cannot begin until Phase / Task B is complete. Typical examples being:

• Sub-page design task cannot start until the homepage design task has been completed
• Back-end development phase cannot begin until the Solution Design phase has been signed off by the client

Dependencies are a great way to adjust project schedules and set client expectation when the inevitable delays happen because, taking the functional specification / back-end development example, if a delay occurred either yours or the client’s side and the functional specification overran, you could update the expected end date and the tasks / phases that are dependent on the specification being signed off will automatically shift along the calendar thus producing new milestone and go-live dates.

Of course, shifting milestone and go-live dates is never ideal, but if you can consistently explain to a client why the dates have moved, or at least communicate, when delivering the project schedule, that if you don’t get sign-off or receive content by this date, then the dependent tasks will be shifted to later dates, they will generally be more receptive to any changed timelines.

Lag

Lag is the term associated with the amount of time expected between tasks. For example, although you may have an allocated time of 8 hours for the homepage design, it is unrealistic to schedule in 8 hours or 1 day for this task. Instead you would schedule:

• 3.5 hours for a first version that you send to the client
• A lag of perhaps 1 day that the client will need in order to review and submit feedback
• 2 hours revision time before re-sending to the client for review
• Another 1 day of lag to allow the client time to provide feedback
• The remaining 2.5 hours for final amends before sending for sign-off, and finally
• 1 day to allow for the client final review and actually getting around to formally signing off the design

As you can see, this 8 hour task could actually take up to 6 days to complete. It still surprises me how often I see an 8 hour task scheduled in for 1 or even 2 days and the constant shock when it actually takes a week or longer.

Then again, although I may have developed an aptitude for this lesson, I still regularly find myself in the McDonalds drive through and then gasp in disbelief as my jelly belly expands…

Resource allocation

This is a huge topic in its own right. GANTT chart tools allow you to assign each project task to a team member. However, this being an article about pragmatic web project management in a small web agency or as a freelancer I will not go much further on this topic. I find simply assigning tasks to the appropriate internal team and client an adequate solution. It tells me what resource I need and when, and also rubber stamps the client’s initials against any tasks they need to complete e.g. reviews, providing content and sign-off.

Milestones

Milestones can be assigned to any project phase, but are generally used to define the beginning or end of a high-level project phase e.g. Design complete, Back-end development begins etc. These are the big dates to watch out for as hitting them all means you’re on track to complete the project on time.

Creating a GANNT chart that breaks down the project into as much detail as possible, adding time estimates, dependencies and lag, results in clear start and end dates for each task and phase, and ultimately produces definitive dates for the project milestones.

Why GANTT charts work for me

GANTT charts are the subject of much debate in the project management world, some people love them and some hate them. You will find endless conversations online arguing how they are old fashioned and enforce a Waterfall methodology.

I am by no means saying they are the ultimate solution and you should never move away from them, all I am saying here is that at this moment in time they work for me on the kinds of projects I work on currently.

They allow me to:

• Explain the web project lifecycle to the client
• Schedule a realistic timeline with milestones that are visible to everyone
• Communicate to the client their level of involvement and when they need to be available
• Track the project’s progress at a low-level
• Quickly adjust the project schedule and produce new milestone dates if anything overruns
• Highlight the fact I need to secure more resource in order to meet the original dates

Need I sell it more? This stuff sells itself…

The rewards of web project planning

So you’ve gone through this, sometimes painfully slow and methodical, web project planning process – how does it help you?

Cast your mind back to the advantages of planning defined in Part 1 of this article and see how this approach has satisfied each point:

• Define and manage the project scope
  • Completed and possible through granular project breakdown
• Identify and minimise risks to the project
  • Completed through granular project breakdown, assumption listing and scheduling
• Break the allocated project time into manageable phases and tasks
  • Completed through granular project breakdown
• Determine realistic milestones and client-side deadlines
  • Completed through project scheduling
• Track progress and control the project
  • Possible with an easily updatable project schedule and consistent time tracking tasks
• Secure the necessary resource
  • Easy to identify using an easily updateable schedule

Being able to manage these fundamental web project management factors greatly increases your chances of delivering on budget and on time without having to compromise on quality which equals happy you and happy client!

In summary

When working in a busy environment, as either a web agency team member or as a freelancer, where delivery is what gets you paid, justifying a non-production / non-billable day or two to plan the project is pretty hard to do. Some people know it should be done and just can’t carve out the time, others don’t really believe planning in that much detail is necessary.

Those that can’t find the time should probably try to track the time they spend during their projects working on tasks that they wouldn’t have to if they had planned first – usually this time is much greater than the time it would’ve taken to plan.

Those that don’t believe planning in detail is necessary have probably had a few successes where a project was bought in on time and on budget without a planning stage, or are just avoiding admitting the fact that they don’t enjoy planning. Admitting you don’t enjoy planning is fine, not everyone does, but while admitting this, please try to also admit how many projects have not been delivered on time or budget that perhaps could’ve been if only you’d planned thoroughly.

Always skipping web project planning is a hit and miss affair where success is more dependent on the project and client rather than your ability as a web project manager.

Consistent and thorough web project planning generally results in a more consistent success rate with web projects because, before production begins, you are able to identify, define, and thus manage the critical parts of any project; phases, tasks, resource, timelines, milestones and risks and communicate these to the client.

Thorough web project planning does not ensure a project will come in on time or on budget, but it does increase the chances, and if over budget and late, it will also limit the extent the project overruns because while you may have missed or underestimated a few tasks or risks at the planning stage, you will have identified many more that you have managed to successfully control – and anything you missed this time, you can easily make sure you don’t the next time.

To the web project managers out there, some of the advantages and methods described in this article will be nothing new, but, to web agency and freelance guys and girls with little web project management and planning experience, I hope it explains why planning web projects is so important, to both supplier and client.

But primarily I hope it shows that planning a web project is not a dark art that should only be tackled by dedicated web project managers, it’s something anyone can do as long as you can mentally envisage the project from start to finish…

The real dark art is actually being able to determine the appropriate level of planning that should be undertaken for each project and then managing the project to that plan once in full swing!

So, I open up the floor to you guys…

• How do you go about planning web projects when the workload is stacked up?
• What mistakes do you commonly see made when planning a web project?
• What are your tips and tricks for pragmatic web project planning?

Look forward to your comments :)

^ Back to top

I often come across both web agencies and freelancers who consistently do not plan their web projects, and no matter how many times the same mistakes are made, they continue to push ahead using the same techniques. Once upon a time I put this down to sheer naivety, but I’ve come to realise it’s not naivety at all, it’s just that people responsible for running web projects and web project management are very different (not sure it should have taken me so long to realise this!)

A really good, if somewhat angry, article, posted by Karine, entitled “Project management and fire fighting” on Ace Project helped inspire this part of the article in the series. It summarises the two different types of web project planning personalities I talk about here; Fire Fighters and Forest Rangers.

Fire Fighters and Forest Rangers

To further back up Karine’s summary I also heard a quote the other day that I found fascinating, it stated you get two types of people when it comes to planning:

1. Someone who doesn’t enjoy planning and just dives straight into production. These people will get started quickly and will reach the finishing line after solving many challenges as and when they arise in an ad hoc fashion (The Fire Fighter)
2. Someone who will start slowly, meticulously planning every step from start to finish and although will gain momentum more slowly, will usually complete the task correctly first time round (The Forest Ranger)

Two planning personalities; Fire Fighters & Forest Rangers

(Ok, I realise these images show neither a Fire Fighter or Forest Ranger, but you get the meaning behind them no?)

The two web project planning personalities

This planning personality quote fascinated me so much because my initial reaction was that the person who just dives in is clearly a little mental if they think they can successfully bring a project in on time, on budget and to a high quality by taking this approach.

But soon after hearing this quote it dawned on me that, web project management ideals aside, and speaking from the reality of running web projects in a small web agency or as a freelancer, I’ve seen it done, and not just once but on several projects at several companies.

So what does this mean? That you can plan and run web projects using either approach? Using quotes from Karine’s article, let’s take a closer look at the reasons why both web project management personalities/approaches are adopted when put in context of the frantic pace and environment we all work in today…

The Fire Fighter

“Fire fighting is a management style not only used by project managers. When someone spends all their time putting out fires, they look very busy, and they have a great sense of purpose.”

Although this summary has some truth, I do feel perhaps the article was perhaps written on the back of a bad experience! I say this because although I have met many Fire Fighters, I don’t believe they run web projects in this way in order to look busy or have a sense of purpose.

I believe the reasons some web project managers adopt the fire fighting approach are because they:

• Have no time to plan or run a web project due to all sorts of everyday pressures such as cash flow or a large client with un-realistic and inflexible deadlines
• Are suffering from web project overload – responsible for too many projects at a given time
• Have a lack of web project management/planning skills and experience and don’t know any other way
• Enjoy the adrenaline buzz of the unknown during projects
• Don’t enjoy web project planning
• Just want to get on with the production
• Have had successes with the approach before

The Forest Ranger

“While fire fighters are very visible and have a high-risk, dangerous job, forest rangers are just as important: they keep fires from starting in the first place. It’s not as glamorous as fire fighting, but it causes less damage.”

I find this quote to also be mostly true, but would emphasise that I believe Forest Rangers have an equally high-risk and dangerous job given they are ultimately just as responsible for web projects as Fire Fighters.

The reasons for taking the Forest Ranger approach are mostly the exact opposite of the reasons for adopting the Fire Fighting role. A Forest Ranger will typically:

• Have allocated time per project to plan web projects in detail
• Be responsible for an acceptable amount of web projects at any one time thus not falling victim to project overload
• Come armed with web project planning skills and experience
• Have a strong dislike of project fires and emergencies and a love of predicting and avoiding them in advance
• Enjoy web project planning
• Believe beginning web project production work before planning is a large risk
• Have had successes with the approach before

So what’s the best personality for web project planning?

Well first of all it should be said that although I have discussed two different web project planning personality types, it doesn’t necessarily mean one person can only adopt one personality throughout the many projects they plan.

As a web project manager in a small agency, or as a freelancer, working to tight deadlines and on too many projects at once will inevitably lead to you at some stage having to skip the detailed planning phase. You know it’s wrong, you know it is bound to cause problems and lost time and money down the road but the reality is the project must start now! Other times you will be lucky enough, or choose to spend an evening or weekend, to have the time to plan a project in detail.

So what happens when you have to be, or are by default, a Fire Fighter? Why do those projects sometimes go well?

Why Fire Fighting sometimes works

As I mentioned previously, despite going against all I know to be good and true on this earth, occasionally I will see a Fire Fighter bring a project in on time and on budget and I always ask myself, how? From what I’ve seen the answer is more often by luck, with a hint of experience of running projects this way.

If you get the right project, with the right budget, right team, a good client and have many years experience of diving in and just starting on design or development, you could very well bring that project home with a gold star – it happens.

However, if even one of those variables isn’t present, you could really get caught out the minute something goes wrong and cause yourself and your team a whole load of stress… this is when the methodical and thorough planning of a Forest Ranger really proves valuable.

Consistency is key

Although Fire Fighters can bring some projects in on time and on budget, others will spiral horribly out of control, and when it does, reeling it back in to a controlled state can be a nightmare because usually there has been little documentation, ambiguous or non-existent scope definition and unclear phase sign-offs.

Being a Forest Ranger by no means guarantees project success, but over time it tends to prove more stress free and consistent because many of the problems encountered along the way, and there will always be several, can be addressed quickly, comprehensively and with complete confidence.

If a Fire Fighter’s project is going over budget or running late and there has been no defined scope sign-off or project schedule, the client is well within their rights to question why and become rather unpleasant. If the same thing begins to happen in a Forest Ranger’s project, he or she, can point to how, who, what, why and when with absolute conviction – in most cases, with the full facts presented to them, a client will generally accept the situation and either compromise or provide additional funding.

Over time, a Forest Ranger’s consistent form of web project planning and management will produce consistent results when compared to that of a Fire Fighter.

“There’s no way to completely guarantee success on a project. There are always issues that arise and sometimes even the tightest control and the best communication, management and resources can’t ensure success. But the probability of success is exponentially higher with well-documented and utilized Project Management processes in place.”
Brad Egeland, What if.. There was No Project Management? – Revisited

The planning personality hierarchal truth

Perhaps some Fire Fighters out there are reading this article and thinking “Oh be quiet thesambarnes you little midget, I don’t bother with the kind of planning you mention and I’m still in business!”

To this I say well done, you’ve been very lucky and long may you prosper, but I would offer the following response to you as the final piece of evidence that the Fire Fighting approach is always the second choice and thus by definition the most vulnerable…

I can absolutely guarantee each and every person that considers themselves a Forest Ranger at heart, and works in a small web agency or as a freelancer, has adopted the Fire Fighter approach on several projects during their career.

What’s interesting about this is I think the number of Fire Fighters who could honestly say they’ve adopted, and stuck to for a whole project, the Forest Ranger approach for even one project is significantly smaller – thus the following hierarchy is formed with regards to web project planning and management:

• If you have the skills, experience and time to implement, the most effective, efficient and solid web project management approach is that of the Forest Ranger
• If you do not have the skills, experience or time available to implement the Forest Ranger approach, the fall back is to adopt the Fire Fighter role and just get the job done as best you can

I would be open to hear any challenges on this, and change my opinion accordingly, but without a convincing challenge I think this role reversal comparison, and truth that Fire Fighting, although occasionally successful, happens when a crucial skill or variable is lacking from a web project manger’s toolkit, ultimately places the two approaches in a hierarchal order rather than on a level footing.

In Part 3 of this article I discuss how to actually conduct pragmatic web project planning.

Pragmatic Web Project Planning: Part 3 »

^ Back to top

You have all no doubt read countless articles on how best to plan a web project. They all go into varying amounts of detail about the steps you should take and how if you don’t follow them the whole world will fall from underneath your feet. I happen to agree with this general philosophy and can often be found preaching the same in my day job.

However, the trouble with many of these articles is they’re often written by authors who work for a large corporate and are planning a multi-million pound enterprise web projects that must use the PRINCE2 methodology and assumes you have weeks of time allocated to plan your project.

For those of us working in small web agencies, or as super funky freelancers, the reality of the web project planning process is a little different…

In this three part article I hope to fill this gap a little with my humble ramblings on pragmatic web project management, addressing why it is often skipped, what the advantages are, the two different type of planning personalities that exist and a little insight into the processes and tools I use to help me retain what sanity I have left.

Why plan at all?

Before talking about why it’s often skipped or how to plan, it’s important to discuss why planning is needed at all for web projects. Simply put, planning a web project allows you to:

• Define and manage the project scope
• Identify and minimise risks to the project
• Break the allocated project time into manageable phases and tasks
• Determine realistic milestones and client-side deadlines
• Track progress and control the project
• Secure the necessary resource

Although these points sound very much like the corporate web project management waffle I mention in the opening part of this article, they apply to web projects of all shapes and sizes. Not being able to satisfy these points at all stages of any sized project can often spell disaster.

Project planning, or lack of, can lead to very different end results

Image source: Action Figure Insider – Star Wars products rejected a long time ago

Why web project planning is often skipped

It sounds obvious on paper that planning is a necessary and valuable stage of any web project, but the reality of day to day web project management in a small business, or as a freelancer, often makes it difficult to remain disciplined enough to ensure thorough planning is always conducted.

There are many reasons why planning a website project in a small agency, or as a freelancer, is quite different, they include the usual suspects:

• Lack of time
• Lack of web project planning skills
• Lack of resource available to plan
• Lack of budget
• The belief planning over complicates
• Web project planning is not fun

Lack of time

It takes time to plan a web project, there’s no getting around it. When feeling the time and cash flow pressures, an agency or freelancer does on a daily basis, it can often feel like stalling design and development work in order to plan is just slowing things down too much, adding unnecessary time and cost to the budgets, stopping the project being completed and that essential last 50% payment coming in hitting your bank. The only real questions to ask are: Does it actually slow the project delivery down and add to the budget?

The default answers to these questions are:

“Don’t be silly, of course it doesn’t slow delivery down or add budget, it speeds it up and saves you and the client a load of cash.”

However, at the risk of undermining my own article, I’m going to say it depends… It really does depend on the web project, the web project manager, the web team and the client. In my experience planning has no negative effects but to say you will never bring a project in on budget and on time without planning is a falsehood and I discuss this in the Part 2 of this article (coming soon).

Lack of web project planning skills

Project planning is not as easy as it looks, I personally didn’t realise this until I had to do it, and despite planning many projects still don’t feel I’m a Jedi-level web project planner. Sure I’d read some books and a whole heap of articles and tutorials, but the reality is like anything, you learn on the job and from your mistakes. Likewise, as with anything else, experience is the most valuable commodity with refining any skill.

The truth is many small agencies and freelancers do not yet possess the skills to confidently plan a web project in its entirety. While I can only implore both to start learning, I do however feel this reason is often used as an excuse to dismiss web project planning as a “waste of time” (I really have heard this said with my own, rather large, ears. I swear I almost fainted).

But I can empathise with this attitude… let’s use an obvious analogy to explain – homemade curry.

I like a curry as much as the next person, I also like to cook. I’m told making a curry from scratch is ten times better than a takeaway or using a bottled sauce. Every part of me knows this must be true and yet I don’t make one from scratch myself, why? Because it’s just not worth it… the bottled sauce is fine and tastes good – at least that’s what I tell myself and others. The truth is, to me, making a curry from scratch requires a lot of fiddling takes ages and looks really complex regardless of the rewards of a homemade one.

To the uninitiated used to not planning web projects, yet happily making a living, it can seem a little daunting to contemplate starting to plan using any processes given the stigma processes carry of being slow. Like with my curry, any new skill being used for the first few times will add a significant amount of time to the process you’re used to, you will make mistakes, perhaps a few horrific ones, but once you’ve mastered it, you’ll be quick, you’ll reap the rewards, see the benefits and wonder why you ever had such a problem with it.

Damn, now I actually want a curry.

Lack of resource available to plan

As I said before, planning takes time and that is something few of us can say we have in abundance. Even dedicated web project managers are all too often stacked with too many projects and too little time to plan effectively.

The only advice I can offer here is to try and shut yourself away from the world for a day or two, resist the temptation to deal with e-mail and phone calls, and plan that project. This is easier said than done, but I always try to remind myself that it’s quite possible I could’ve been ill for those two days and if I had been would have probably not moved any projects forward, dealt with e-mail or taken phone calls – what’s the difference?

Lack of budget

This is often a contentious issue because a salesman will not want to add a row in their project estimate to the client that ups their final quote price for something that isn’t a production task – however this really isn’t necessary. If you charge for web project management time, and have been a good boy or girl and been tracking project management time from previous projects in order to identify trends like web project management tends to take between 10% -20% of the total project time, you should always be able to allocate an adequate amount of time to a project timescale or estimate in order to cater for the time required to manage the project, including the planning phase.

Sorry folks, lack of project budget is just not a justifiable reason for not planning your project. If you have to, do it for free, you will undoubtedly recoup any time spent on fewer design and functionality revisions in the long-run due to the planning you did.

The belief planning over complicates

Although you will often hear this line from the ‘dive in and get started’ planning personality mentioned in Part 2 of this article, and despite it not being a popular answer amongst the web project managers out there, the truth is they can sometimes be right.

When you’re up against the clock and the pressure is on in a small agency or freelance role, and instead choose to update your GANTT chart each time a task is delayed by 3 hours, or insist on wireframing the 404 error page, chances are you are focussing too much on the planning when you should be focussing on the doing.

That said, you also have to know when to stop to update your schedule or perform the most crucial web project management tasks so that you can maintain a level of control over your project. Not planning when you know you should is a dangerous habit to get into and trust me, before you know you have several projects all going tits up and in ten different directions and all because you chose to do when you should have planned.

Being a good web project manager in a busy small business environment means you have to be wise and flexible enough to know when to plan and when to just get on and ‘do’!

Web project planning is not fun

This heading is slightly misleading, I enjoy web project planning for two reasons:

• It’s just what I happen to enjoy doing these days
• It feels like a lovely warm fuzzy blanket at the beginning of a project to know you have identified the risks, broken down the project and can visualise every step, including the end

As with so many of the most critical parts of web project management, like producing detailed estimates, to most it’s just not exciting or sexy and there is only one cure – try planning your next few web projects that warrant planning before starting production and see if it seems to help or hinder.

If you do it right, remain disciplined and consistent I would wager ownership of my cat Spiderpig that you won’t look back – if I’m wrong I will personally cook you a curry from scratch…

Why small web agencies and freelancers should plan thoroughly

Major reasons small web agencies and freelancers should get into the habit of planning web projects thoroughly is so they can begin to develop some repeatable processes that they can rely on for every project, or even apply the skills and techniques to parts of their projects if full planning is just not possible.

If anything, I believe web project planning, in some respects, is more important to a small agency or freelancer because there is less room for mistakes given most are in a constant state of survival mode. Yes a corporate web project needs planning, but a mistake is less likely to put them out of business! In our world, and as I’ve said in previous articles, one or two whoppers of mistakes can mean the end of a business…

Melodrama aside, I believe it’s time for small web agencies and freelancers to up their game on the web project management side of things.

We are maturing as an industry at a rapid rate and I believe the days of fumbling our way through projects in our small offices or bedrooms are coming to an end.

We live in an age where clients are becoming more web savvy and quick to spot a disorganised supplier, and where they are more likely to hire, or work with again with, an agency or freelancer who can demonstrate a certain level of professionalism, competence and consistency when it comes to planning and running their projects.

In Part 2 of this article I will describe the two types of people that plan/manage web projects and the advantages and disadvantages of both, and in Part 3 I will go into more detail about the techniques and tools I use when planning web projects… stay tuned.

^ Back to top

Estimating projects and the occult

After reading Alyssa Gregory’s recent article on Sitepoint.com, How to Estimate Time for a Project, I couldn’t help but feel that it was a good introduction but lacked a little when compared with the realities and complexities of estimating/quoting for a website or web application.

“The Devil is in the detail: When people say that the devil is in the detail, they mean that small things in plans and schemes that are often overlooked can cause serious problems later on.”
Using English.com

I may not believe in the Devil, but I do believe this statement to be as true as it gets when it comes to estimating time for web projects.

Estimating web projects accurately

Some would say this is an oxymoron, and to some extent I would agree, but I do believe by applying a few techniques it’s possible to drastically increase the accuracy of most web project estimates and avoid the feeling of wanting to curl up in the foetal position and whimper helplessly under your duvet.

Confirm a ball park figure

Before you embark on any detailed estimate exercise it’s crucial to immediately confirm with the client a rough budget, or budget range, they feel would be acceptable for an estimate. After all, if you get a new business lead, spend three days estimating and deliver a proposal worth £30,000 only to hear that the client ‘appreciates your response’ but only has £3000 to spend, you probably deserve to be struck with reasonable force in the baby-making department.

When you receive a project brief, throw some figures out there for the client to comment on, only one of a possible few things will happen:

• They will laugh and hang up when they hear your daily rate
• You will laugh and hang up when you hear they want Facebook for £4000
• They will say you’re in the right area but probably need to come down or go up a little bit
• They will refuse to feedback and say “We are open to suggestions”

For these possibilities what the next steps are need little explanation, but the “we are open to suggestions” answer is always the trickiest. In these cases it really is down to you to make a decision if the project is worth the risk of spending time writing a proposal and estimating for. It could be that the potential for new work is huge, or the client is extremely high profile and thus often it’s worth it, however, if you feel none of these are true, you should probably ask yourself what this statement says about the client and if you want to work with them.

It’s understandable a client wants to get their website or web application at the lowest cost, but the best clients are the most professional, experienced and ethical ones and simply know that not providing a rough budget range could waste theirs and your time.

Assuming you have made the decision to pursue the lead, you can now begin the detailed estimating exercise.

Consistent project phase breakdowns

Most web projects can be broken down into the following high-level categories:

• Research and planning
• Solution design
• Functional specification
• Web design
• Front-end development
• Back-end development
• Content entry

Each individual project will contain unique tasks, but most can be encapsulated in the above phases.

The first step to increasing accuracy of web project estimates is to make sure you always begin with a consistent set of categories and then add as many sub-categories and tasks as you like.

Get granular, then get more granular

Now your consistent high-level project phases are defined, it’s time to get granular and add sub-phases and tasks e.g.:

• Research and planning
  • Requirements gathering
  • Project planning
• Solution design
  • Sitemap
  • Wireframes
  • User workflows
  • Functional specification
• Design
  • Initial homepage look and feel
  • Content page
  • Master content page template
  • News main page
  • News item
• Front-end development
  • Template x5 XHTML/CSS
  • Cross-browser fixes
• Back-end development
  • CMS Setup and configuration
  • News feature
  • Contact us form
• Content entry

This full list of required project tasks can be created based on the pre-sales research you have conducted with the client. It is imperative to nail down, in as much detail as possible, what exactly the client wants before you submit an estimate or begin work.

The more granular you can get, the more you are forced at this early stage to think through each part of the project, literally designing and building the website or application from beginning to end in your head.

By going through the project step-by-step, putting yourself in the shoes of the information architect, the designer and all developers, will often immediately result in many issues rearing their head that you need to clarify before putting in an estimate, take the News feature for example. Ideally you could break each feature down as much as you can, so the News feature may actually end up looking like the following:

• News feature
  • Add/edit/delete new item
  • Upload image
  • Attach PDF
  • Auto-archiving
  • RSS

By resisting the temptation to just think “News… ummm… 5 hours” and breaking it down to this level means you’re mentally building the feature step-by-step and raising questions as you go.

So the client needs to be able to upload images to their news items, ok, but do they need:

• Auto-resize capability?
• Auto-thumbnail generation?
• Full-screen viewing?
• Caption addition facility?

I’m sure you can think of many more questions that could be associated with a simple upload image for a news item requirement. This demonstrates the possible scope variations that are contained within even the smallest of features and that could impact your estimates / risk of underestimating.

By getting granular and mentally trying to build the solution you are able to identify and address these issues early on, making sure to cater for them in your final estimate.

“A Web Project Manager knows how to design and develop most of the project on his own, even if with poorer results compared to his team. This allows him to estimate projects with good approximation and to understand his team’s problems and difficulties”
Introduction to Web Project Management: Fucina Web

Granularity: Good for the client and good for you

Don’t forget, by getting this granular not only increases your estimations accuracy, but it also gives you the instant ability to remove proposed features quickly if your estimate exceeds the client’s maximum budget! Need to shave 10 hours off the budget? Well, rather than removing the News feature entirely, how about remove the thumbnail and caption adding functionality from News, and a few other small niceties from other features and still allow the client to have the basic versions of all the features they need? Simply remove the lines and hey presto, a new estimate at warp speed and with full visibility to the client of what functionality they’re sacrificing for budget.

Roughly guessing the News feature will take 5 hours is one thing, but what about when the client comes to you after seeing the initial functional specification and asks where the archive section is or how they attach PDFs simply because they assumed the News section they would be getting is like the News section on another website they’d seen?

Getting granular will not always allow you to breakout a required feature in full because it is client industry specific. If you are ever in any doubts about what the client needs, ASK THEM! Take the time to understand their business so that you can fully understand why they want the feature and how it needs to work.

Few clients mind you asking questions, if anything it tends to give them more confidence that you will continue to be as diligent and thorough if they hire you.

Best of all, if you win the work, by getting granular you have:

• An instant statement of work
• A defined project scope
• The timings you need to put together an accurate project schedule with milestones
• Set your client’s expectations very early
• Demonstrated your thoroughness and understanding of their business to the client

By being methodical, transparent and getting granular from the very start means your client is well informed and you’re seriously reducing the chances of friction later down the line.

You won the work w00t! Time to start tracking time

The more projects you complete that are categorised with a consistent set of phases and tasks, the more useful data you can collect on how long you estimated versus how long each phase or task actually took.

Consistency here is the key again. By this stage you should have the final project estimate that was approved by the client, and this estimate should be broken down first into the same high-level phases as your previous projects, and then at a granular level by task and sub-task.

Simply replicate this structure and the time estimates for each in your time tracking tool of choice so that you can:

• See how long you have to complete each phase
• View how long you have for each task and sub-task
• At the end, report on how long everything took

Not only is this a perfect way to track the progress of the project you are working on, but the data you collect over multiple projects, using a consistent pattern, will become more and more valuable when it comes to estimating future projects and also allow you to identify bottlenecks in your project processes.

Analyse project estimates vs. actual time spent

Once you have defined a consistent set of high-level project phases to use when estimating all web projects, and committed to setting up your time tracking tool each time to match, you are ready to reap the rewards.

By tracking all the estimated and actual times of all past projects, using a consistent framework, will give you an average percentage that each phase and task took, and you can use these averages as a good guide for starting a new estimate.

For example, by collecting data for your past five projects you are able to identify trends like:

• Solution design took around 10% of the total project time to complete and get approved
• Web design 30%
• Front-end development 15%
• Back-end development 30%

And so on…

Using these averages, and with a client’s preferred budget, you can begin to immediately allocate a rough amount of time to each phase and then break out each in more detail, but with the roughly allowed hours available known beforehand.

With this initial capped time limit in place, you can estimate not only your times but also the most cost-efficient solution you can deliver based on the budget rather than going in with a blind quote that may be way to small or too high.

Of course, this is dependent on knowing the client’s budget beforehand, not always possible, but more possible than most seem to think if you just explain you want to deliver the best solution for the budget given that you could potentially offer a News feature that costs £750 or £7,500.

Get granular with features, again!

Aside from being able to determine the average percentage of time each high-level phase usually takes of each project, you can take this tracking and analysis one step further.

How many websites or web applications tend to need a feature you’ve implemented before? Small to medium business websites invariably demand the following functionalities:

• News
• Press Releases
• Case Studies
• Events
• FAQ
• Contact us form

At the estimating stage you will have identified these requirements and broken them down as much as you can. Not only can you re-use these common breakdowns in multiple quotes, if you track the time for each one over multiple projects you will also begin to have average times it takes to implement or migrate each feature – now that’s useful.

In summary

The approach for estimating time for web projects I have described to you in this article works for me. It’s something I’ve developed over several years through trial and error by having to estimate web projects of all shapes and sizes in a small web agency environment, combined with a lot of good old fashioned hours of research.

Its methodical, it’s laborious, isn’t a guarantee that a project will not go over budget and I’ve no doubt is something I will continue to develop and evolve as time goes by. But as any web project manager will tell you, the more you plan, the more chance there is your project will be successful and the same goes for estimating times.

When possible, resisting the temptation to throw some figures onto a proposal and send it off and instead splitting the project requirements into as granular detail as possible can really be a life saver. It not only identifies possible grey areas early on but forces you to think through everything you’re planning on offering the client and to what extent/scope.

It also presents you to the client as someone, or as an agency, who are very meticulous, diligent and thorough in how they approach things and this is often taken as a signifier of how you will approach the rest of the project and this always gives the client confidence.

Finally, by creating and maintaining a consistent pattern of high-level phases and tasks between your web project time estimates and time tracking means you can collect and analyse reliable data from multiple projects that can help you further increase the accuracy of, and cut the time needed to create, estimates for web projects.

If you want to read why underestimating web projects is such a common occurrence, please check out Part 1 of this article »

^ Back to top

After reading Alyssa Gregory’s recent article on Sitepoint.com, How to Estimate Time for a Project, I couldn’t help but feel that it was a good introduction but lacked a little when compared with the realities and complexities of estimating/quoting for a website or web application.

But before we look at how to create more accurate estimates for web projects, it’s important to look at the reasons why this area is such a difficult one and why web project management forums aren’t exactly littered with posts entitled “How can I stop completing web projects on budget?”

Why underestimating is so common

There are many common reasons why web projects are often underestimated by freelancers and web agencies alike, they include the following:

• The technologies required have never been used before
• Large parts of the project are grey areas at the time of estimating
• The features needed are very specific to the client’s industry and thus bespoke
• To break the project down into the detail it would require almost as much as work as the paid for requirements gathering phase

While almost all web folk will admit to these points being common reasons why it’s difficult to estimate time for web projects, there are a few that will admit to the following that are just as true:

• No previous project ‘estimated vs. actual’ analysis has been conducted to draw on
• The client needs an estimate for their large project tomorrow
• The revenue needs for immediate cash flow now outweigh the effects of no new business now
• Estimating time for a project is not fun

I am no different. At one point or the other I have cited the valid public reasons but also fallen foul of the not so public ones; this is the reality of working as an insanely busy freelancer, or in an equally busy web agency, just trying to keep your head above the water financially.

However, there are few worse feelings in this industry than getting to any point in a project and realising you’ve grossly underestimated the time, it’s a bitter taste you don’t forget in a hurry and should strive to avoid again.

So why does it happen time and time again?

The day-to-day reality

The approaches to creating more accurate estimates for web projects that I will describe in Part 2 of this article explain how to combat several of the common reasons for underestimating. I personally use them to track time on all projects and use the data gathered when estimating new ones – the results are very positive indeed.

However, as you can see below, it doesn’t resolve them all:

• The technologies required have never been used before
• Large parts of the project are grey areas at the time of estimating
• The features needed are very specific to the client’s industry and thus bespoke
• To break the project down into the detail it would require almost as much as work as the paid for requirements gathering phase
• No previous project ‘estimated vs. actual’ analysis has been conducted to draw on
• The client needs an estimate for their large project tomorrow
• The revenue needs for immediate cash flow now outweigh the effects of no new business now
• Estimating time for a project is not fun

So what can you do to combat each of these realities?

Technologies have never been used before

If you are estimating time needed to implement a solution using a technology you have little or no experience of, you will have to conduct some basic research and then just guess! Alternatively, try to negotiate a smaller fee with which you can conduct the first stages of the project in terms of research and putting together some kind of high-level specification for the project.

At best, you learn a new technology, build a rapport with the client and win the remaining work. At worst, you’ve learnt a new technology, you’ve generated revenue and the client has a good specification to update its project tender with.

Detailed estimation exercises take too long

My personal approach takes time, much more than the traditional method of providing an estimate purely based on both experience and instinct. What if you spend hours or days putting together this detailed quote, breaking the project down perfectly, and then don’t win the work. Is that a loss of opportunity on another potential sale? Does the client now have a free detailed breakdown for free?

Well yes, but this is just how it goes in any sales situation. Is it wasted work? Possibly, but it’s also possible you have researched a new technology or broken down a feature you haven’t used before. What’s to stop you trying to sell this to existing or new clients if it aligns with their long-term business aims?

Client needs estimate for large project tomorrow

If a client needs an estimate for a large project tomorrow, please refer to the ball park figure section in Part 2 of this article. Try to confirm a ball park figure and then assess the potential gains to your business versus the possibility of underestimating this one project. Always bear in mind, the larger the project, the greater the likelihood you will underestimate and the potential loss you could incur by submitting a low estimate.

Business revenue needs

Revenue needs of a freelancer or small businesses for cash flow is an ever present issue. A typical dilemma faced is:

• We need £20k in revenue this month to sustain the business
• Client is offering us a maximum of £10k now and we don’t have many other leads
• We feel their project will cost a minimum of £15k
• We can walk away now and not lose £7k, but also not make £10k
• We can take the project on and try and do it for £10k
• We can take the project on; accept the £5k loss, break even and live to fight another day

This quandary is the reality of running a business and just one of the daily tough decisions a freelancer or Managing Director has to make, I don’t envy them. What to do in this situation is entirely the business owners decision, all you can do is get accurate information to them so that they can make as informed a decision as possible.

Estimating time for a project is not fun

Well never has a truer word been spoken. Despite taking so much pride in it, and also testing new ways to improve accuracy, it’s not often a person will love the process of compiling and delivering a project estimate (if you find one, grab hold of them and lock them in your office!).

Let us speak plainly my friends; the following facts are true when it comes to estimating web projects:

• It’s hard work and takes you outside your comfort zone
• Forces you to predict the future
• Usually has to be completed alongside your plans for your already fully booked week
• Makes you largely responsible for the:
  • Sales success
  • Solution offered
  • Eventual profitability of the project
  • Growth/survival of your business

With all of the above being truisms that I believe most people who have to estimate web project feel, the scary truth of the matter is getting it wrong just a few times can leave a freelancer or small web agency in real turmoil.

Identify then fix

For all of the reasons stated above, getting people who are primarily from a creative or technical background and more passionate in actually creating something, to really spend time on developing a solid and reliable web project time estimating process is quite difficult and understandably so, it’s just not sexy work.

But, especially in these turbulent times, being able to identify any gaps in your entire web project management workflow that (incoming buzzword bingo phrases) minimise project risk and maximise project profit should take a front seat, and the web project estimation phase is the most crucial in achieving these aims.

In Part 2 of this article I will go into detail of how I personally go about estimating time for web projects, both on an individual project and long-term multiple project basis, that combats the remaining common reasons for underestimating.

^ Back to top

A KPI, or Key Performance Indicator, is simply a measurable metric by which a project can be judged as a success or not in accordance with the client’s primary aims for the project. For each KPI a pre-launch metric is recorded and post-launch the same metric is recorded, thus providing the data for an objective comparison.

KPIs can be defined as financial or non-financial targets, examples of typical KPIs for web projects are as follows:

• Increase the amount of leads via the website by 10%
• Increase online conversions by 5%
• Reduce the time Customer Services team spend dealing with telephone queries
• Increase newsletter subscriptions
• Generate 10% more traffic
• Get higher competitive key phrase search engine rankings

Often KPIs that are more difficult to measure will often be put forward by a client, such as:

• Increase brand awareness
• Improve usability
• Increase time spent on the website

Although more difficult to measure, it is possible to use some KPIs like those above as long as the necessary metrics can be collected but the time required to do so should be made clear to the client upfront. For example, usability could be measured on the current site, and then measured again on the new site, but it would require the same controlled conditions and user groups for both – possible, but possibly time consuming and difficult to replicate.

The key ingredients to a KPI are the ‘before and after’ metrics that allow for an equal comparison of numbers to determine success levels.

But wait, so if I define some KPIs with the client it means at the end it could be proven the project wasn’t a fantastic success? Correct, but KPIs are good for both client and web agency.

Why KPIs are good for web agencies

Aside from the obvious client benefits of being able to set, and hopefully achieve, their desired business aims with the web project, KPIs also keep web agencies focussed on what they’re really being hired to do – add value to the client’s business. After all, if a web agency delivers a website or web application that looks beautiful, is coded beautifully and accessible to all but fails to satisfy the aims of the client’s business and facilitate growth, quite simply, the web agency has not done their job.

Not only will the web agency have not done their job, but the client will inevitably be unhappy with the results and this damages the chance of possible repeat business, testimonials, case studies and referrals, and as a web agency, sales as a result of these are the true keys to stability and expansion.

But sales aside, KPIs are good for web agencies because they ensure all teams remain focussed on the business problems that need solving as opposed to the latest techniques or technologies. Yes a web agency must keep up to date with all of the latest trends to remain competitive, but cultivating an entire team to become primarily business focussed is by far more valuable to an agency in the long-run than any use of cutting edge technologies as that team will consistently be delivering business value to clients and this only ever increases agency team morale.

KPIs can also serve as a boundary to client requests for features that are out of scope. In this instance, with KPIs defined, a web project manager can, with all sincerity, ask which KPI this relates too. More often than not, the answer will be none and in one swift move you have not only protected the project’s scope but kept the client focussed on their business’s primary aims and saved them money.

When failing is valuable

Even failing to deliver on one or all KPIs is extremely valuable to a web agency because it allows the team to fully analyse why this was the case and take the appropriate steps to improve on the next project. In some instances, by being completely transparent with a client about the KPIs and failure to reach them results in a relationship based on respect and trust and this puts an agency in a great position to propose further work in order to turn the failure into success based on statistics captured post-launch – if you can identify what the project failed to achieve but also why, you can fix it rapidly.

Who should define KPIs

It is important to specify who should create the web project’s KPIs? Usually the client will give you the KPIs but it is the web agency’s role to analyse and challenge these where necessary to ensure they are realistic, measurable and placed in the correct context e.g. if a KPI is given to as “appear on page one of Google” without the context of which keywords to appear on page one for, the KPI could be achieved by getting the client to number one for their domain name, brilliant.

Obviously this is not brilliant, but illustrates the importance of defining the right kind of KPIs.

Factors to consider when capturing and measuring KPIs

Another factor to take into consideration when defining and capturing KPIs is what the client’s business activity is that time that could impact any of the metrics collected both before and after launch.

For example, if a KPI was to increase traffic by 5%, a ‘before’ figure would be collected that gave the current traffic over a defined period, let’s say three months. Post-launch, the ‘after’ figure would be collected for the same time duration and the comparison made. But using just this one example could possibly result in skewed results if any of the following are true:

• When the ‘before’ metric was taken the client had just implemented a print marketing campaign
• PPC/SEM was being conducted and now is not
• The ‘after’ metric is taken over a period of time when several national holidays occur
• A new competitor arises on the scene before project completion

There are many factors that should be taken into considering when capturing and measuring web project KPIs. It is impossible to predict the future, but by conducting research into any external factors increases the chance of being able to produce the most equally weighted comparative metrics and thus the purest measurement for a KPI and the project’s success.

Staying focussed on KPIs

Once defined with the client at the start of the project, the KPIs should be documented and circulated amongst all parties that will be involved throughout the project’s lifecycle. In doing so you are immediately focussing everyone on the aims of the project. Too often in web projects the aims of the project are specified in finite detail by the client in the tender document, backed up by agency proposals and then swiftly forgotten by both sides. While this seems a little crazy, in reality, the pace and complexity of most projects, both large and small, make it difficult to focus on anything other than completion – it’s the job of the web project manager to ensure these aims are at the forefront of everyone’s mind at all times.

The most effective ways to keep KPI focus throughout a project are to:

• Document them at the start of the project
• Present back to the client, and any stakeholders, in a face to face meeting
• Present to your team at the kick-off meeting
• Include them at the top of all project documentation e.g. sitemaps, functional specifications and creative briefs
• Re-iterate them verbally at the start of any new project phase e.g. site IA, development and design
• Remind everyone of the KPIs when reviewing any revisions of work and citing them as reasons for your feedback and suggestions

Defining realistic and measurable web project KPIs, and keeping them at the forefront of everyone’s mind throughout a project, is not only one of the most crucial parts of a web project manager’s role, but also takes comparatively less effort than most other project tasks you will perform for what is a huge benefit to all. It keeps everyone focussed on why the project exists in the first place, acts a guide to all decision making from beginning to end and serves as a project success indicator that benefits both client and web agency.

You arrive at the office at 9am with your day mapped out; you finish your coffee, catch up on a few RSS feeds and prepare to start your scheduled work feeling at one with the world. It’s now 9.16am. If you’ve received ten e-mails, two client phone calls, a good new business lead and have before you a design and development team that need briefing in order to start work – all that demand immediate attention that supersede your scheduled work…

Chances are you’re a Web Project Manager and it’s a normal day at the office.

Why didn’t I take the blue pill?

Right about now you wonder why you ever made the switch from web developer to project manager…

Moving from web development to web project management is a long and difficult journey. One of the biggest challenges along the way is learning how to deal with approximately one trillion things each day, very approximately.

No two web agencies are the same and no two projects the same, but somehow you have to find a way to stay on top of things before you fall down in a crumpled heap begging for mercy. Getting Things Done, or GTD as it’s known to fellow cult members, is what personally saved me, and can save you, from becoming this broken down sorry excuse for a web project manager.

Getting Things Done (GTD)

Founded by David Allen and introduced to me by a good friend, and web guru, Branden Faulls, GTD is a system that is accompanied by the tagline “The Art of Stress Free Productivity” and while I can’t proclaim to now be stress free, I am certainly less stressed, a lot more organised and am able to deal with a great deal more than I could before adopting this system.

I won’t attempt to describe in detail what GTD is as it’s a huge topic, if you want to read more your best bet is to buy the book from Amazon or download the audio book from Audible, my personal preference. What I want to discuss here is the parts of GTD I use on a daily basis that enable me to do my day-to-day web project management job.

Next actions, waiting for and Inbox Zero

The primary concepts I use from GTD are ‘Next Actions’ and ‘Waiting For’ items. By using just these two GTD principles, of which there are many more, I am able to make sure I never forget to complete a task no matter how many other actions I have, how long it has been since it last entered my head or how small it is when compared to the larger issues at hand. Best of all it results in regularly achieving, on a daily basis, having no e-mails in my inbox, known in GTD circles as ‘Inbox Zero’ – this alone is guaranteed to reduce your stress levels! To learn more about Inbox Zero check out Merlin Mann’s excellent talk at Google in 2007.

So, how exactly to apply these principles to my working day, it’s pretty simple really, however don’t let the simplicity lure you into thinking this happened overnight without many different attempts and approaches to implement it. It really is about trial and error, what took months to devise and get working for me at my last company completely fell over when I joined my current company Rawnet, but the overriding principles are always the same.

Using the very real scenario in the opening paragraph let me explain how GTD enables me to capture and action everything…

Processing e-mail to Inbox Zero

I will quickly scan all ten e-mails, looking to identify if any of them require me to do something or not, or if it was a piece of information I was waiting for:

• If it contains something I have to do, I will open up my Backpack list and under the Next Actions list I will prefix the ‘to do’ with a project identifier and add the action (you’d be surprised how often a huge e-mail can be digested with and result in a one line action item). I’ll then drag this e-mail to the project folder in my e-mail client and move onto the next
• If an e-mail contains no next action and no waiting for I will simply digest and drag to the project’s folder
• If an e-mail contains something I was waiting for from someone, I will locate this in my Waiting For list in Backpack and edit the item specifying the Next Action that I can now complete having got the information I needed and drag the item from the Waiting For list into the Next Actions list
• If a Waiting For item means I can quickly send off another e-mail in response that will move the project forward in two minutes, I will do so, regardless of the other high-priority things I need to do. If you can move a project forward with one quick e-mail that will no doubt take someone a while to reply to, just do it rather than capture the fact you need to! Once sent, I’ll add a new Waiting For that will remind me that I need an answer in order to progress the project
• If the Waiting For signals the end of a task and requires no Next Action I will just tick the item forever banishing it to the completed list

The end result is all e-mails are moved out of my inbox and to the relevant project folder with all Next Actions and Waiting For items captured in my centralised master Backpack list – I then await the inevitable wave of euphoria at seeing the “No messages in your inbox” message, ahhhhh.

But wait, a client’s on the phone wanting to talk about their project, now what!?

Unexpected client phone calls

Out of nowhere, and before you know it, the handset is pressed to your ear and you await the unknown that is the unexpected client phone call. With baited breath you await the first question, is it a huge content delay, a 180° shift in design brief or a new piece of functionality needed? Hoorah, it’s not a big one, the client is simply asking you what dimensions the hero banner will be on the homepage and if you could possibly give their technical lead a call to discuss the required hosting configuration.

What the client doesn’t know however is that the minute the phone rang, I had clicked my magic Backpack shortcut and opened my master list – while the client talks I am immediately adding Next Actions to my list, but wait, why not take advantage of this unexpected call to close off some vital issues needed to move the project forward! With a quick scan of all Waiting For items I spot three things I need from this client in order to move other phases forward, I proceed to enquire after all three and manage to get answers on two, perfect! I tick them off or change them to Next Actions and hey presto, project moved forward.

This technique, and world-class Backpack quick draw speeds, allows me to:

• Fully concentrate on the call and the client (a client knows and doesn’t like when you’re distant or sound unsure of all of your Next Actions or Waiting For items for their project)
• Instantly and digitally capture all that the client wants without having to scribble notes I realise later I can’t read before deciphering and re-typing into a digital format, taking twice the time
• Close off outstanding issues on the spot without having to flip through a notebook looking for more illegible notes I made three weeks ago

Being able to quickly and accurately, take client requests on board, get key information from them at the drop of the hat while being able to recite all of the Next Actions you have planned for their project makes you a more efficient web project manager and the client feel confident that you are on top of their project which equals client love, and let’s face it, that’s the love we crave isn’t it!?

Although all of this sounds like a complete pain to implement, after a few days it really becomes second nature and takes just a few minutes out of your day, but boy are they minutes well spent.

However, the ideal solution eludes me

Although my personal GTD inspired processes have helped me a great deal, they are by no means perfect. For instance Backpack has no way of allowing you to add deadline dates to Next Actions or Waiting For items, you can’t prioritise items in any more a sophisticated way than order by most important, not ideal.

Free GTD Tools I recommend

Trust me I’ve tried most of them! The following tools are the ones that stand out as having a good balance of portability and ease of use when trying to implement the GTD basics:

• Things: Mac/iPhone only, but very highly regarded
• Tracks: Ruby and web-based tool, initial testing are very positive indeed!
• Backpack: 37Signals web-based tool, excellent for more than just basic GTD
• GTD Gmail: Great tool for those who process work e-mail using Gmail

Develop your own GTD-based processes

As anyone who knows about GTD will tell you, the processes I use only make up about 5% of the entire GTD blueprint and even then don’t really follow the teachings to the letter, but they work for me at this time and at this company. I would urge all of you to try and develop your own processes based on the Next Actions and Waiting For items principles and see for yourself how organised you suddenly feel.

^ Back to top

I would always strongly encourage any small web agency to build and maintain a stable and trusted freelancer network that can be called upon in times of project management crisis, however, there is a long-term and real danger of outsourcing work on a regular basis that can go un-noticed until it is too late.

Why outsource at all?

At any one time, a web agency will need to outsource web project management, design or development work to a freelancer for a variety of reasons. These range from lack of in-house skill, employee illness to a sudden influx of business that cannot be resourced internally.

All of these are solid reasons to outsource work and can prove commercially viable. Because most of the reasons are a reaction to an unforeseen event, a wise agency management team will always have a bank of reliable freelancers with a vast array of design and technical skills to call upon in such times.

The snowball builds

The negative effects of outsourcing are slow to develop at first making them very difficult to identify, but once the seed is sown, the effects gain velocity and size and by the time they are plain for all to see it is difficult to recover from. This snowball building usually follows like so:

1. Small web project arrives that needs management/technical/creative skills or resource your in-house team don’t currently have
2. The in-house team are working on large client work that is too in-depth and risky to handover to a freelancer given timeframes and account relationships
3. Small project work is outsourced to a freelancer
4. In-house remain on large client work and/or within skill set
5. New small web project ends and in-house team haven’t learnt any new skills
6. In-house team can’t take on any new small projects that require new skills
7. Go back to Step 1

The snowball effect

The effects of this on a one-off basis is negligible, the project is completed, and with a drastically reduced cost to the business resulting in a higher profit margin and a happy management team, but if repeated it can have disastrous long-term effects on your business, for example it can:

• Stop your internal online team from developing new skills
• Reduces the chance of the in-house team gaining valuable experience
• Decrease team morale due to being kept constantly on the same large client projects

As the cycle continues, the in-house team slowly becomes out of date with the latest web trends and technologies (given that larger clients are generally slow moving) thus impacting on your agency’s ability to respond to new web projects effectively, and staff members become increasingly frustrated with the lack of opportunity to develop their skills and experience online, eventually opting to leave the agency for one where these kind of opportunities are available.

The reality

I have personally seen, over a three year period, a web agency go from having a high revenue generating skilled in-house web project management, design and development team become a low revenue generating relatively un-skilled team where all web design and development work was outsourced. The passionate and ambitious skilled employees left one by one, and were replaced with employees who were mostly indifferent to the industry and saw it as a job rather than career.

Was the overall revenue of the agency the same? Just about, was the business a creative and skilled web agency still? Not at all

This slow but devastating transformation impacted almost every part of the business, for example, potential clients did not recognise the business as a web agency any longer and ceased to invite to tender for web projects and thus the client list reduced and it became almost impossible to attract new web skilled employees to the company.

Spot the warning signs

Early identification, long-term strategy and pre-emptive action are the keys to avoiding this negative spiral. The early warning signs are there to be spotted and come in several forms:

1. The need for freelancers seems to become more frequent than the month before
2. One regular freelancer becomes two, then three
3. Freelancers are used on the smaller projects while in-house staff are on the large projects
4. Team morale drops
5. There are ‘office whispers’ of frustration at freelancers “getting all the fun work”
6. More new project briefs are answered with use of a freelancer in mind from the outset
7. Skilled and experienced employees choose to move on to another company in the same industry

The long-term strategy and pre-emptive actions that must be applied to avoid this predominately focus around a disciplined approach, from the start, and an on-going commitment, from the directors and senior management, to developing the in-house team’s skills and experience.

Pay now, not later

The willingness of a business owner to resist the temptation of using a freelancer and reduce profit margin in the short-term on some projects, and allowing for in-house team research and training (and mistakes – the most effective training technique in the world!), for the long-term benefit and growth of the agency is the essential ingredient to avoiding the transformation.

It takes determination, discipline and a fair amount of sheer entrepreneurial courage in the face of adversity to apply this long-term strategy, but in doing so the future of the agency is only made more secure by the skill set and the value of the in-house team being kept on the cutting edge of the web industry.

^ Back to top