I believe the reasons I get asked this so often is because the existing articles out there that define what makes a great project manager don’t include the “web” part and either focus on I.T. project management or just project management in general.

Corporate project management has a sexy reputation

Image source

However it should be noted that many of the points made in these articles are very relevant to web project management, for example, The 12 Attributes of an Effective Project Manager.

For those who are just too damn busy (lazy) to click the link and read, it lists a few attributes that a good project manager should ideally have, e.g.:

1. Skill in negotiating win-win solutions between stakeholders and the project team
2. Staying calm particularly during turbulent times
3. Desire to hold the team accountable for deliverables
4. Ability to earn the respect of the team regardless of reporting relationships

It should go without saying that these attributes are as applicable to someone managing the construction of a carbon freezing unit as a web project, or put another way, GreatWebProjectManager extends GreatProjectManager.

Here are a few more similar articles that are worth a read:

• Characteristics of Great Project Managers
• How to Be a Good Project Manager
• The Best Project Manager in the World

But here lies the problem; we are awash with articles explaining what makes a great project manager, but what makes a great WEB Project Manager?

Is it the unique ability to be able to annoy clients, their Managing Directors, design and development teams in one day? Hadouken!!!! K.O.

I definitely wouldn’t mess with any of these killers

Image source

Or perhaps it’s their powerful skills in having chronic OCD but somehow avoiding medical diagnosis for their entire life?

One day all my minion resources will line up like this before me!

Image source

Ok ok, while these are things all Web Project Managers are proud of; be it secretly or openly, let’s get serious on what really makes a great Web Project Manager…

Web Project Management experience

Of course “experience” is something, that if you have it, makes you a more wise and skilled person in anything and web project management is no different. But the key distinction here is between web project management experience and experience working on web projects.

Often you’ll find all sorts of different people from different backgrounds running web projects, from designers and developers to digital account managers and I.T. managers, but while all of these people will no doubt manage to deliver the website or web application, more often than not, there are noticeable lapses in certain areas that cause web project difficulties and these lapses are where an experienced web project manager really shows their value.

Often the lapses will be in the areas that are the weaker area of the person managing, for example, often a digital account manager will be great at building a rapport with the client, but will commit to unrealistic deadlines or miss functionality out of the scoping stage.

A designer will often ensure the design looks world class but fail to realise that by delivering a world class design with a zillion overlays and cool UI features, the entire project budget will be blown on front-end development.

An experienced Web Project Manager will be aware of these common “gotchas” and direct the project accordingly, making sure all aspects of the project have balanced attention and are aligned with the scope, budget and timelines while maintaining a level of quality both agency and client are happy with.

Hands-on digital experience

As with most project management positions, although definitely not always the case, it’s often a huge advantage if you have hands-on experience of the disciplines involved in the project – the same is true for web projects.

I’m always in awe of web project managers who deliver great solutions having never used paths to cut something out in Photoshop, turned a PSD into a HTML template or created a Hello World script in a server side language.

The fact of the matter is these Web Project Managers are out there and doing a fine job but I genuinely believe a Web Project Manager with hands-on practical experience in the disciplines required in web projects is a valuable aid for the reasons Luc Richard gives:

To be an effective project manager, you must be capable of designing and developing the solution yourself. Otherwise, you have two options. You can either (a) ask others to make decisions for you, or (b) simply pretend you know what you’re talking about. In the first case, you’re a project co-ordinator. In the second case, you’re a project mangler.
Must Project Managers Be Technically Savvy?

However while I don’t agree that to be a great Web Project Manager you need to be capable of delivering the solution alone, I do agree that without a good grounding in all the web project’s disciplines you really are at the mercy of your team when it comes to estimating effort, scheduling tasks, assessing risks and generally making sure everything goes smoothly by being able to anticipate and avoid problems.

Plus, the harsh truth is, having hands-on experience allows you to spot when any of the production team are just flat out slacking or spinning a yarn about why problems are occurring…

Come on, I dare any Web Project Manager out there to deny that they get a sense of smug joy when they teach someone on the production team something about Photoshop or code, or laugh at the ridiculously long estimate you’re given to change a banner – oh their little faces, they look like startled little Ewoks :-)

Production teams are so cute n fuzzy awww

Image source

But, in the defence of all production teams out there, they do a really hard job and having to design or code under pressure really is a tough thing. This is another reason why a great Web Project Manager will have spent their time on the production side of things and really be understanding and empathetic with their team in times of stress and woe, and in some cases even fight the corner of the production team to management and clients when unrealistic schedules are being proposed.

But it should be said, if you’ve found yourself running web projects having come from a position of little hands-on experience, such as account management, don’t remain ignorant to what these guys do, I believe it’s your duty to open up Photoshop, HTML editor and get Apache, MySQL and PHP running and just start learning the absolute basics.

I’m not talking about designing a website or developing the operating system for the Death Star (I can here the Apple and Linux groupies shouting it would be a Windows-based system of course, tut), but just learn enough so that you can talk to your team on their level and also explain to clients how things work, trust me, it will benefit you massively in the long run and it honestly isn’t that hard, you just need the drive and motivation to want to better yourself.

Ability to communicate with everyone

With any project management role, a key skill is the ability to be able to effectively communicate with everyone involved in the web project knowledgably and on their level.

While hands-on experience will arm you with the knowledge to talk to designers and developers with confidence, communicating with suppliers, your superiors and clients is a whole different ball game – a great Web Project Manager has to be a chameleon!

I’m literally not moving until you finish that login form

Image source

As most seasoned Web Project Managers out there know, when talking to designers or developers you often have to adapt your tone in order to communicate effectively.

For example, when talking to designers you have to appreciate that most are extremely territorial about their work and so you have to respect that and frame your questions and feedback accordingly, because the last thing you want on your web project team is a designer who doesn’t feel trusted by you and has been reduced to a pixel pusher.

With developers it’s slightly different; these guys tend to want things explained in logical straightforward steps. If you start to try and tell them how to code or insist they “code something quick and dirty” they will immediately hate you and fantasise about watching you in a fight to the death with the Rancor monster (probably while a naked Princess Lea sits by their side)

However, these personality traits are not negatives, everyone is different and these traits are actually part of the magical formula that makes a great designer or developer. Part of working a team is learning how to work with other people that are very different to you.

But while speaking to designers and developers you can have little geeky laughs about Comic Sans and drop shadows, or how bad that code is due to all its embedded CSS and JavaScript, but when you hit the meeting room with your bosses or clients a Web Project Manager has to change their skin again.

Your boss generally just wants to hear how things are going and if there are any barriers they can help remove for you. Although they have a genuine interest in the quality of design or code being produced, they are busy people and tend to want to be told about results and the impact on the business.

Likewise with clients you have to shift again and focus on what the project, and each decision made during its lifecycle, brings to the table in terms of achieving the business aims and ROI rather than hearing how the CSS3 you’ve used is ground breaking stuff.

Uh huh, CSS3… uh huh HTML5 uh huh… zzzz

Image source

Being able to adapt to, and blend into, each very different environment at the flick of a switch is something a great Web Project Manager can do and often where average ones tend to fall a little short.

In summary

I believe what separates a great Web Project Manager from an average one is the ability to look at a web project and be able to envisage the whole solution in its entirety from an early stage and with few gaps, thus being able to manage the project’s risks and maintain momentum.

They’ll be able to understand the creative requirements almost as well as a designer, the technical requirements almost as well as a developer and communicate both in a way that results in clear tasks that need to be completed and the perfect solution being delivered, all while not being sniggered at for pretending to play at being knowledgeable in these areas but instead gaining respect.

Perhaps some of the technology requirements are out of the Web Project Manager’s comfort zone; well the great ones will go home, dig in and do a bit of research until they feel comfortable they have grasped the basics.

A great Web Project Manager should be able to produce good project plans, schedules, sitemaps, wireframes and functional specifications that production teams can work from with ease, rather than loose, fuzzy, vague and ambiguous documents that are recipes for disaster and all too commonly produced by people just wanting to pass the work onto someone else.

They’ll also be able to keep production teams motivated and focussed on producing quality work while taking all of the crap and stress from all directions in an attempt to shield them and let them work their magic unimpeded by project politics.

And finally a great Web Project Manager will be able to talk to everyone involved on their level and in their language which leaves everyone in no doubt of the expectations and objectives of the project.

Am I a great Web Project Manager? No, but I strive to be and so should you. Is the above a complete list of everything that separates great Web Project Managers from the not so great? No, but it’s a bloody good start.

What do you think separates a great Web Project Manager from an average one?

Related reading:

• How To Explain to Clients They Are Wrong »
• Web Project Management:Honesty, Trust & Integrity »
• How to Keep the Peace When Making Decisions »

About the Author

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

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

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

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

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

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

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

Benefits of project communication logging

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

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

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

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

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

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

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

Web project delivery definition

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

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

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

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

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

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

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

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

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

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

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

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

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

Download WBS Template »

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

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

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

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

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

Download WBS Template »

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

Related reading:

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

^ Back to top

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

Why outsource at all?

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

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

The snowball builds

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

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

The snowball effect

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

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

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

The reality

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

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

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

Spot the warning signs

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

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

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

Pay now, not later

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

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

^ Back to top