This article continues the series and talks about more things Web Project Managers want more than money; things that would keep our sensitive egocentric control freak selves happy :-)

Heed the Web Project Managers motto

Image source

4. Reliable support staff

As a Web Project Manager you simply do not have the time to perform every task yourself during the lifecycle of a web project, this is when support staff can seem like a gift from the Gods, but there is a massive difference between support staff and reliable support staff.

This kind of person is actually rare to find, but if you’re lucky enough to find one they can provide you with the vital breathing space you need in order to keep on top of all your web projects.

In short, a reliable web project management support member is one who you can delegate tasks too safe in the knowledge they will be completed, and to a quality level you are happy with – sounds simple, right?

Noooooo, how many times have you had to chase someone on a tasks several times, only to find that when it’s eventually finished it’s of poor quality and you mutter the immortal words under your breath “I should’ve done it my bloody self!”

“WTF, I asked you to gather content from the client an hour ago!”

Image source

Don’t just expect support, provide it too

Of course, finding reliable web project management support is gold dust and most Web Project Managers would take this over any financial bribe, but I believe it is crucial to not only use the support you have, but to also provide reliable support too!

Offering your support to other stressed and overworked Web Project Managers (and any team members for that matter) is vitally important because it:

1. Encourages others to support you, and each other
2. Shows humility in that you don’t think you’re ‘above’ web project management support tasks
3. Keeps you humble by reminding you what it’s like on the other side of things

Just remember one thing… the golden rule of delegating tasks to others, is to always be on hand to support them while they’re completing them. There’s nothing worse than dumping a load of work on someone and not being around to answer questions or provide encouragement.

Always fully appreciate a person that can provide reliable web project management support, they’re often are the unsung heroes of digital agencies!

Special thank you: This is an apt point to thank my bestest pal in the world, Deb, for all the support she gives me on this blog by way of superhuman proof reading skills, thank you!!! :-)

5. Understanding production teams

Effectively managing digital production teams of web designers and web developers is one of the black arts of web project management. If you get a great production team on a web project it will invariably be a resounding success, but if you encounter difficult production teams, then get ready for the pain!

But before I get into the kind of digital production team a Web Project Manager wants more than money, it’s important to understand things from their perspective, and never has it been summarised better than in the quote below… a short must read for any Web Project Manager.

“Developers often treat PM as The Source of All Evil. And to some point they’re right. It’s a project manager who brings more work. It’s a project manager who bugs everyone asking when they’re going to be done.”
Pawel Brodzinski, What Can Project Manager Do For Developers?

Having worked for a few years as a front-end developer, and been ‘affectionately’ referred to as a Code Monkey I can definitely remember and understand what it’s like on the production side of a web agency.

But it’s funny how life has a way of holding a mirror up to your past behaviour as time goes by…

As people who know me will testify to, when I hear digital production teams commenting about how web projects are being run, how standards are the most important thing and that more budget is needed for proper testing, I’ll often have a little ‘old wise man giggle’ to myself and think back to the time I was saying (shouting) exactly the same things to previous bosses when on the digital production team.

But of course, once you cross over to the dark side of web project management everything changes.

Web Project Management, a new reality

When you transfer from the digital production side of things and become a Web Project Manager your whole world is changed forever. Even if at some stage you decide to venture back into production, you will be doing so with new commercial knowledge about the realities of running web projects and in some cases businesses themselves.

Suddenly your priority balance shifts slightly away from code standards and is weighted more towards clients, budgets and schedules. Rather than having one or two things to work on at a time for solid periods, you have a million things to deal with and numerous key decisions to make on a daily, and sometimes even hourly, basis.

As a Web Project Manager you are constantly being pulled in three directions by the client, your boss and your production team, and each of them want different things from you at all times – somehow you have to find a way to keep everyone reasonably happy at all times – this is where a Web Project Manager would sacrifice any pay rise in the world to have an understanding production team ploughing through the work!

This means that when you’re pulling a developer off the work they’re on, breaking their flow, to fix a bug raised by a client, or you ask a designer to stick to a certain level of design so you can hit budget and schedule, the dream is to have production team members who fully appreciate the pressure you’re under and happily oblige.

In most cases Web Project Managers completely understand the production team’s point of view and try to accommodate it where possible. We’ll try and organise their work into solid blocks, create task lists and test their work, but all these things have to be combined with our new pressure filled priorities, and sometimes it’s a bad mix.

The devs didn’t react how the Web PM had hoped to the decision

Image source

More than anything, Web Project Managers out there would just like a certain amount of understanding of this fact from production teams. For them to appreciate that as well as having pressures like cash flow, budgets, schedules and clients on their mind, they’re also are the one person who has the complete overview of the web project at all times and are making decisions based on that overview knowledge that’s ultimately best for the business and project.

Sometimes these decisions can appear stupid, rash, akin to demanding low quality work, short sighted or naive, and in some cases they are! But as I’ve learnt over time, if a Web Project Manager seems to be a reasonably intelligent person who understands what the production teams are saying, the decision they make is probably the right one for the web project or agency overall, and if the production team continues to have a job and steady flow of web projects to work on, you can be sure the decisions made weren’t too bad at all.

To all digital production teams out there, I’m pretty confident if you could spend just six months as a Web Project Manager your perspective of things would change too. You would find that when you’re pulled in lots of different directions on lots of different web projects you’re sometimes just too busy to provide the perfect brief, create all tasks as nice lists, insist on world-class quality code every time and have time to create accurate detailed functional specifications that leave not a single detail in the land of un-scoped or ambiguity…

How do I know this? Because I really was once one of you, fighting for all things good and right in the world!!

All we ask is you trust us. Our hearts are in the right place, we want the same things as you, but our priorities are weighted differently to yours. Surely there’s some happy place in the middle we can meet, and over time get to that place together by keeping our business healthy, steadily growing and profitable through a utopian mix of design masterpieces, technical wizardry and commercial realities…

The real Web Project Manager reality

In the last two articles I’ve given just a few of the things Web Project Managers want more than money, but there are many more. However, the painful truth is getting all of these things is extremely unlikely and a little la la land given the real commercial world we live in.

But, by being able to identify what these things are is the first step on the path to improving how you run web projects, how to interact and conduct yourself with your team members and superiors, and if you can improve things even slightly in all those areas, you’ll be well on your way to being a happier Web Project Manager!

But enough from me… as someone managing digital accounts or projects, what things do YOU want more than money in your web project management job?

Related reading:

• Five Things Web Project Managers Want More Than Money: Part 1 »

Read on to find out what would go a long way to making Web Project Managers out there a little less Mr. Grumpy Gills…

Note: If you’ve never watched Finding Nemo please do so!

Note to bossman: If you’re reading this, it’s not a whinge, see #3 ;-)

1. A solid pre-sales process

So a brand new web project is heading your way, it sounds awesome; you’re excited and can’t wait to get your teeth into it. You begin to the review all of the pre-sales documentation with the intention of beginning to plan the web project.

As you start to break down the project into tasks and allocate time, your web project management instinct and experience kicks in as the horrid reality dawns on you that the deliverables are ambiguous and what’s been sold looks unrealistic for the time and budget, and at this finite moment in time, you’re the only one that realises it – you bow your head and weep like a little girl.

Web Project Managers are masters at subtle body language

Image source

Inheriting a web project with these kinds of issues puts the Web Project Manager in a very tricky situation from the start where one of the first actions is to start to push the client back on things and re-define project scope. This immediately affects how the client feels about you and makes trust that much harder to gain – trust from a client being one of the most important factors in web project success and is always formed most strongly at the beginning of a business relationship.

When I hear of this situation arising it reminds me of an article by Rob Borley called Under Sell and Over Deliver. The article title pretty much says it all and I’m sure it’s the dream of all the Web Project Managers out there, much more so than a pay rise.

Have a whinge, then try to fix the problem

However, if you’re finding yourself in this position more and more, rather than bitch and moan (well, at least after bitching and moaning) I would suggest you try doing something to help resolve the situation, for example:

1. Speak to the people selling web projects and explain what the problem is and the position it puts you and the agency in
2. Try to get involved in the pre-sales process so you can identify potential issues early on
3. Track all project actual vs. actual times so you can give average percentages for project phases (handy when sales people know the budget they have to work with)
4. Involve the sales people in parts of projects so they can understand what they’re selling a little more
5. Have a major hissy fit at whoever sold the project until they burst into tears

Too often do I hear of people complaining about elements of their job yet they consistently choose to do nothing constructive to try and resolve the situation – to me this is just gutless whining and I have no time for it.

If you have a problem, raise it with the relevant people in a professional manner and try to suggest solutions, in most cases the recipient will be understanding and take your comments on board for next time – and if they don’t, proceed to Step 5.

2. Adequate time to manage projects

Web project management takes time and there is nothing worse than being forced to manage web projects without enough time to perform even the basic project management necessities e.g. regular monitoring of budgets, schedules and tasks all the way through the lifecycle – but, how much time should a web project manager need per project? 10%, 15%, 20% of the project?

How much time a web project manager needs is very much a ‘how long is a piece of string’ question given how different web projects can be, some are simple and take little time, some are little but have a difficult client and thus take a long time, and others are tantamount to delivering the Death Star project before the Ewoks have a chance to help destroy it.

Wicket PMP dealt with people questioning his time in his own way

Image source

I read a blog post a while back (but typically can’t find it now) that stated because there is no way to determine how much time should be spent managing web projects, the only real way to know is to analyse your own time and if you’re finding you don’t have enough time to do the following on a daily basis then you are not being given enough time to effectively manage web projects:

• Review all budgets
• Review all progress against schedules
• Redefine all tasks completed and left outstanding
• Revise all budgets and schedules accordingly
• Update the client

A common cause for project management overload isn’t in fact that you have too many projects on the go, but you have too many at a similar phase at the same time. As Brad Egeland puts it…

Having your project life cycles staggered is definitely one key to sanity and greatly increases your chances of success. One cannot sanely go through life managing 5 projects that are at the same point in their project life cycles at the same time. The demands on the project manager vary by phase.
Brad Egeland, Managing Multiple Projects – Stagger the Lifecycles

However, it could be argued that you’re not finding the time to do these things because you’re working inefficiently, but if you know you’re a competent web project manager and have the trust of your boss, this workload analysis holds true and you should raise it with them and hope for understanding and support.

If you don’t raise it as soon as you feel you’re not getting enough time to manage a web project, the likelihood is that you will probably lose control of the project and the risk of it being over budget, late or of low quality is increased significantly. It will often also result in you getting a smacked bum when perhaps it isn’t fully deserved, and that sucks donkey balls.

A happy web project manager is one that feels they have enough time to manage all the projects on their list in the right way. As with web designers and developers, if we have enough time to do our jobs properly we feel more confident of delivering high quality projects and that’s what makes us happy much more than money.

3. Trust from your boss

Trust is important to every Web Project Manager out there and is a key component in web project management. Trust from your client and your production team, or lack of, can seriously affect the result of any web project.

I talked about how to gain trust from all of the above in a previous article called Web Project Management: Honesty, Trust & Integrity and it mainly revolves around conducting yourself at all time in a manner that is clearly seen as being full of honesty and integrity no matter what temptations arise.

But, to a Web Project Manager, more valuable than any salary is having the trust of your superiors, because as we all know, when managing a web project you are the person right on the front line at all times, making critical decisions on a daily basis and are ultimately responsible for success or failure, and when this depends on more internal and external factors than you can shake a stick at, well… this is a very precarious position to be in!

I mean let’s face it, when things go well you look like a superhero, a master of your trade and an example to everyone, but, when things don’t go so well, oh my, that is when any Web Project Manager needs, and needs to see, absolute trust from their boss and for him or her not to go all Alan Sugar on them.

Sometimes you wish you’d just stuck to coding

Image source

When your boss hears a web project is coming in over budget or late and you know for certain why, and that the reasons are mostly due to factors outside of your control, for them to listen to your reasons and say “I don’t think you did anything that wrong, web projects contain too many elements for you to be in full control of at all times.”, this, my Pedigree Chums, is music to our ears.

Web Project Manager Tip of the Day… Get your boss to read Good Project Management Doesn’t Guarantee Project Success

Of course this reaction is only possible if you have demonstrated in the past that you can effectively control web projects under the right circumstances and if it is a cast iron known fact that you always take full responsibility and admit fault if that happens to be the case, without that honesty and integrity you will never have trust from anyone.

For a Web Project Manager no amount of money in the world is a substitute for feeling trusted.

Related reading:

• Five Things Web Project Managers Want More Than Money: Part 2 »

Just keep swimming, just keep swimming!

I don’t, but how else can you start a Saw movie themed article?

So there I am watching the latest Saw movie (Saw 6), cringing at the gore levels and twisting plot lines when it hit me, the main character affectionately named “Jigsaw” (or John to his friends) is quite frankly an excellent project manager!

From that point on the movie took on a rather different perspective for me and was transformed into taking notes on how to run multiple projects with pin point precision (and kill people in imaginative ways).

In this article I want to discuss what an insane serial killer can teach all of us about managing projects, or has he calls them, games…

A one line synopsis of the Saw movies by a local film critic

Image source

Project kick-off meeting

When starting a new game, or project, Jigsaw always conducts an excellent project kick-off meeting. Although always by video or audio (due to certain legal reasons), he always:

1. Starts with introductions, explaining who he is and who everyone else in the room is
2. States the purpose of the meeting e.g. “I want to play a game”
3. Explains why the projects exists (usually because they’ve been a naughty boy or girl)
4. Communicates the aims and objectives of the project, or in other words, what the goals of the project are and how he intends to achieve the goals
5. Sets out clear timelines for project completion (usually around two minutes before someone’s head explodes, but at least they are fully aware of the timelines – every cloud…)
6. Explains all of the above in a language everyone involved can understand.

By following this set of pointers, a project manager should be able to conduct an effective project kick-off meeting that leaves everyone involved with a clear picture of the road ahead.

Jigsaw always conveys project timelines effectively

However, if you’re reading this John, I would recommend you allow for a little QnA session with people in this kick-off meeting to get other people’s input… just a thought.

Project planning

One of the critical success factors of any project is planning, planning and more planning.

As I’ve mentioned before in my Pragmatic Web Project Planning series, project planning allows the project manager 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

There is little doubt that Jigsaw was a big project planning fan. His projects had to be so tightly run, without planning he would have definitely been arrested pretty early on, probably in Saw II.

But alas, due to his world-class talent at project planning, scheduling and excellent people skills, giving him the ability to pre-empt most mid-project surprises, he was able to avoid the law and keep his picture on the FBI’s Most Wanted page – hoorah for project planning!

A snippet of a project schedule John kindly sent me

Personally I think Jigsaw would’ve used a Gantt chart as his primary project scheduling tool, as with many projects, more modern project management methodologies such as Agile or Kanban just wouldn’t have been suitable.

Either way, careful inspection of the Saw projects illustrates just how important project planning really is for effective project management, and serial killing.

Project teams are crucial

During the Saw series Jigsaw enlists the help of three people for his project team; some ex-drug addict criminal, his wife and dodgy police officer called Hoffman – we shall refer to them as Team Psycho Nutbags.

Initially in Saw I, Jigsaw manages the project alone with good results, but as he moves onto managing larger projects he realises that he needs support and thus sets about creating his own project team. From this it is clear Jigsaw has learnt a vital lesson, you need a team to get the job done.

Task Delegation and team empowerment

Working as a project manager with a team, Jigsaw demonstrates how delegating key project tasks to team members are a crucial part of managing successful projects.

Many project managers find this a difficult thing to do and usually it’s solely down to trust issues, in that the project manager doesn’t fully trust a team member to complete the task to a good enough standard thus adding risk to the project.

A key lesson Jigsaw has learnt however, is that when you empower team members with a certain level of responsibility they will often exceed your expectations and perform above and beyond.

At first John’s team felt overwhelmed by his unique PM style

If as a project manager you have trust issues with team members and feel uneasy delegating key tasks to them, but at the same time clearly have a packed work schedule building death traps, you could start by delegating lower risk tasks to test the water.

These tasks would ideally be challenging but not soul destroying, or you run the risk of the team member thinking you’re just handing out the boring work you can’t be bothered to do.

When delegating any tasks it’s vitally important to always make it clear you are there for them if they need support.

In my experience, and I’m sure Jigsaw’s, what you tend to find is if you delegate the right tasks to the right people and are there to provide support, over time you will trust the team member more and more, they will feel and appreciate that trust and you will be able to hand over more project critical tasks thus freeing up valuable time for yourself to build those torture machines.

Project team development

Not only does Jigsaw demonstrate a supreme skill set when managing projects, but he also understands the advantages in developing his project team’s skills.

Although forceful, John’s development techniques are effective

Throughout the Saw series, while personally managing multiple projects, Jigsaw is constantly teaching his project team new skills – but why when he has so much killing to do and so little time?

A good project manager will make it part of their remit to teach their team new skills for a variety of reasons:

• It increases the skill set of the individuals and thus helps grow the company
• Team members with new skills can take on more key project tasks
• Team development increases team morale
• Willingness to share knowledge rather than protect it improves company culture

In my experience, those who are willing to take the time to develop their teams are the ones that ultimately have the most success simply because people are more willing to work for someone who is clearly not just looking after themselves.

Game over, project completion

As with all projects, it is important to clearly define the markers that define a project as complete.

All too often I hear of projects that have been run really smoothly, encountered few problems until right near the end when the project manager is beginning to talk about completion and the client suddenly pipes up about how they thought they were going to get more features or services before the end… uh oh.

This situation mostly only arises when a project manager has not clearly defined the deliverables, and scope of deliverables, that will constitute the project as complete.

Jigsaw, an experienced veteran project manager never makes this mistake. As previously mentioned, he always clearly states what the project consists of and the victim is never under any other impression, just perhaps under a slow body crushing device with blades.

What do you mean we only have 15 hours budget left!?

Of course real life project management isn’t as clear cut as Jigsaw’s games (no offence John mate), and often what is stated as the project completion deliverables at the start of a project have changed dramatically by the end, but this is ok, in fact, I would say for larger projects this is completely normal and to be expected.

Many times I’ve been running projects that had several huge shifts mid-lifecycle, for example:

• New functionality requested that is of higher priority than previously in-scope functionality
• One or several phases take far longer to implement than initial estimates allowed for
• Client’s budget or timeline is cut mid-project and an early completion is demanded

In each instance, it was required to re-state the project completion deliverables to the client and the project team so that it was clear to everyone involved where the finishing line was.

Constantly re-establishing the finishing line

Hearing of a project suffering from lack of a clear finishing line at any stage of a project is a subtle way to identify those true practitioners of project management amongst the sea of people just pretending to be project managers… why?

Simply because establishing and re-establishing the finishing line is very easy to do if a project has been run according to project management 101 guidelines.

You can always tell a real project manager from a wannabe

Image source 1
Image source 2

In order to determine project completion deliverables throughout the project you just need to:

1. List the completion deliverables last communicated
2. Gather updates on all deliverables progress
3. Analyse the current budget used and remaining
4. Estimate the remaining tasks in the project against the remaining budget
5. Look at the results, are you looking under budget, on budget or over budget
   1. If under budget, smile and tell the client you’re on track
   2. If on budget, smile and tell the client you’re on track
   3. If over budget, smile and try to explain to the client why, negotiate additional budget or provide them with the de-scoped features or features you proposed are moved to a later phase
6. Once understood, clearly re-state the project completion deliverables and scope in writing and get agreement
7. Wait a period of time and go back to Step 1

Generally, as with most project information, if you have been honest and consistent with the client from day one, they will understand that the initial estimations were a little off and a slight re-adjustment is needed that means neither side lose out.

It tends to only get ugly when the client has received few progress reports, been told everything is great for the whole project and then suddenly has a project manager pushing back on everything spouting “out of scope” and “over budget” phrases – phrases that must feel exactly the same as if the agency was cutting a jigsaw shape from their flesh!

Although don’t forget to always get your agency’s credentials in the website footer, always leave your mark – another great tip from John.

Despite all the bad feeling John’s players must have towards him and his games, if you could stitch all their limbs back together and re-animate them, I doubt a single one of them could whinge that they didn’t know where the finishing line was in their game.

Formal project completion documentation

Assuming you’re an awesome project manager like John Kramer, you will rarely come up against this problem of hazy project completion, and as well as the finishing line always being clear to everyone involved, you’ll also make sure you formally close the project with documentation and a client signature – ahhh, there is little sweeter than when you get the written confirmation that the project is complete and any extra work will require further funding.

Of course you could just try ringing or mailing the client and saying “Game Over”, but I just can’t see this going down to well, unless of course you have fostered a Saw movie theme with your client throughout the project, in which case you’re amazingly cool and so is the client and I want to be both of your friends forever and ever and ever.

Project management 3D glasses

Although this article hasn’t professed any remarkable project management revelations, hopefully you can see past the slightly odd dark association, don your 3D glasses, look past the initial visual layer and appreciate the links and inspiration you can make and take between project management, and general digital work, that you see in everyday life rather than just relying on project management books and blogs.

These everyday associations are brilliantly pointed out in articles and presentations like…

Phil Bennet’s Project Management is like Star Wars article, where he maps things like Han Solo being frozen in Carbonite and The Force to project management.

Adaptive Path’s SWSX 2008 presentation entitle 10 Tips for Managing Creative Environments where Bryan Mason and Sarah Nelson talk about how professional kitchens and orchestras are run as a tight knit team in relation to running a digital team.

Andy Budd’s presentation on UX where he presents analogies of website user experience based on when you first walk into a hotel lobby.

So the next time you watch a movie, order a coffee or arrive at a hotel, be a super nerd and try to recognise how the processes you see could help you in your current role.

ARTICLE OVER!

Related reading:

• Pragmatic Web Project Planning »
• Web Project Management: Honesty Trust and Integrity »

In my latest article published on Smashing Magazine I discuss a few approaches that can help when having to explain to a client they’re wrong.

Stop waffling and take me to the full article!
How to Explain to Clients They’re Wrong »

In the article I talk about first asking yourself if the client is in fact wrong, and if so, how you can talk to them in a language they understand so as to give yourself the best chance possible of making them understand your reasoning.

Voicing my opinions (big mouth) on Smashing Magazine

I also discuss the advantages of establishing yourself as the web expert and highlighting any high-profile clients you’ve worked with, so as to increase your reputation and credibility with the client and thus your recommendations.

Mentioned also is how backing up your recommendations with third-party evidence can sometimes be the edge you need when trying to convince a client to go with your suggestions.

However sometimes a client just simply won’t listen to you and pretty much order you to do what they want. In cases like this the article advises to admit defeat gracefully and professionally, but not to let it necessarily be the end of the debate as there’s always a way to turn to defeat into victory that results in a win / win for both you and the client!

Read the full article: How to Explain to Clients They’re Wrong »

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 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?

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.