The interview focuses on his, and 37signal’s, planning philosophy of which the crux is that too many people over plan and that the best way to progress is to plan loosely stay relaxed and adapt as you build, rather than deciding exactly what to build before starting and while in motion trying not to deviate from the plan.

Busting your ass planning something important? Feel like you can’t proceed until you have a bulletproof plan in place? Replace “plan” with “guess” and take it easy. That’s all plans really are anyway: guesses. I think companies often over think, over do, and over devote to planning. So next time call a plan a guess and just get to work.
Jason Fried, Let’s Just Call Plans What They Are: Guesses

In this article I’d like to expose a common and potentially damaging trait I’ve noticed in the web design and development community that has stemmed from 37signal’s philosophy and Agile methodologies.

37signals love and hate

Now let’s get one thing clear, I without question utterly admire the 37signals gang!!

The Web 2.0 cool meter (probably can be coded in CSS3)

Image source

The web applications they produce, such as Basecamp and Backpack, really are fantastic and I believe have spawned the beginning of an entirely new generation of web applications that we see today – web legends.

When I read Rework I found it to be such an inspiring read that I read the whole thing in one session due to its brilliant writing style and structure – literary geniuses.

Finally, when interviewed, each of them seems to be obscenely cool and intelligent while maintaining a completely relaxed and down to earth attitude – demigods.

However these guys have plenty of opposition to their way of thinking and working, for example…

Check out this interview of David Heinemeier Hansson by Jason Calacanis that at times gets a little fruity:

Or articles that have a similar tone to mine:

I think 37signals dominance in the web products field has distorted their ability to critique the client-based approach.
Imulus, 37signals Is Arrogant, And For Good Reason. But Are They Right?

…Really bad advice there, based on a bad premise. Sure, if you define planning as messy and preventing you from getting real, then it would be a waste of time. But is that planning?
Tim Berry, No, 37signals, Planning Is NOT What You Think

But although this article of mine may sound like just another one like the above that flat out disagrees with the 37signals mentality, it’s very much not…

Running Web Projects is not running a business

The problem I want to address is rather more abstract than if 37signals are right or wrong, I want to talk about the effect their attitudes combined with huge success and massive exposure have had on some web folk.

The problem is that I run into production teams that hero worship 37signals, read all their books, blog posts and podcasts and take away from it that planning is rubbish in web development and web projects. They use examples like the great success of Basecamp to confidently demonstrate their point and laugh at your seemingly old skool way of thinking.

The Waterfall Project Management team as seen by developers

Image source

When you insist on writing a functional specification before any development begins suddenly you hear the cry to “go Agile on this one” when it seems to be based on little more than knowledge from a few blog posts and an impression that it’s the way forward, that it will magically mean the web project is delivered quicker, to a better standard and probably on budget.

But getting infatuated with details too early leads to disagreement, meetings, and delays. You get lost in things that don’t really matter. You waste time on decisions that are going to change anyway.
Quote from Rework

However if you dig a little deeper and start to fire questions back at these guys n gals, accompanied with knowledge gained from really reading up on, and analysing, all different types of project management methodologies like Agile then you often you start to uncover a few uncomfortable truths.

The biggest one being that most of the people shouting about how running a web project in a Waterfall-esque way to begin with is old hat mistakenly think that the 37signals gang are putting forward a fantastic new model for delivering web projects for clients, let me say this loud and clear, THEY’RE NOT!

The guys at 37signals are always talking about two things, running a business and building and developing web application products – and believe you me there is a huge difference between developing a product to sell and delivering web solutions for clients.

Agile is not suitable for everyone

The reason I found Rework such a breath of fresh air was mainly due to the fact that the lessons they hand out about running a business and developing a product really resonated with me. On almost every page I was putting myself in the shoes of someone doing both of these things and the advice they give just made so much sense and was so against the traditional way of thinking – I was literally blown away by it.

However, as I read the small pieces on the topic of planning I started to connect what I was reading to things I was hearing at the time regarding how web projects should be run “in an Agile way” and I got really scared.

Actual real proof that could be used in a court of law

The harsh truth is that in most cases the people saying we should dump web project plans and functional specifications don’t know diddly squat about the commercial realities of delivering web projects for clients as a small digital agency – there I said it.

Why do I say this? Simply because if you take a traditional agency / client relationship where they pay you a fixed fee to produce a website or web application “as quick as possible” while they’re busy running their business, having few details nailed down before beginning production is a recipe for disaster and a massive risk, for both you and the client.

And because the client is often super busy running their business they rarely have the time that would be required in order to conduct an effective Agile process. They know what they want, they know exactly what their business needs online, and with a few challenges and alternative recommendations from you it’s time to nail things down to make sure both parties are happy and then build it.

In some cases, perhaps where a digital agency has a long standing relationship with a client or where the client has a particularly laid back approach, less pre-production planning may be ok – it’s all about risk analysis!

Or, it may be possible to change the way you work with your clients, something Paul Boag approaches in his excellent presentation “No Money, No Matter”. He talks about how he wants to try and change the traditional model of fixed cost projects and move to a more long-term relationship with clients where smaller more incremental projects are taken on that result in the evolution of a website rather than re-design – a great approach, a winner for both client and agency – but really hard to get a client to commit to unfortunately.

A fantastic presentation by Paul Boag, defintely go and watch it!

Image source

However, it’s shame to say it but more often than not, if it’s not written down beforehand exactly what a client is going to get, and signed off, the result is features are missed, defined too vaguely and ambiguously and leave the client with a solution that wasn’t what they had in mind – something the agency will have to do more work for, often for free, in order to rectify this – or in extreme cases the client will exploit these gaps in specification and squeeze more work out of you citing “When you said I’d get a News feature I thought you knew I meant like the BBC Homepage!” FML

This of course does not mean you don’t deviate from the signed-off proposal or functional specification, in fact I would argue that the most common and successful web project management approach in small digital agencies is a hybrid of Waterfall and Agile. Pawel Brodzinsk, an Agile and Kanban advocate, but also a very pragmatic guy, echoes my feelings when he says:

When you consider which methodology you want to follow think which one would be the best for your team and for your client. Don’t believe these fancy presentations telling you how Scrum is great or how Kanban is great. Ask presenters why this or that worked in their case. Ask when they failed and why – most of the time they won’t tell that unless you ask.
Pawel Brodzinsk, Agile Bullshit: Agile Is Good, Waterfall Is Wrong

Digital agencies tend to go Waterfall in the beginning in that you conduct requirements gathering, produce sitemaps, wirefames and a functional specification, all in sequence and with client sign-off as a pre-requisite for moving onto the next phase.

But then they often go slightly Agile during development as the budget remains fixed but the client is usually free to request higher priority features not thought of or needed at the specification stage and the agency will allow them in as long as impact on timelines and cost are addressed or other features in-scope are moved out of scope.

We can’t always work agile, and we can’t always work waterfall. We can work Agifall (I totally did not coin this, but love it)…or some sort of hybrid. I like to think that most web project managers who work with full UX, Creative (design and copy) and Development teams adapt each experience to their clients’ needs and the project needs.
Brett Harned, What’s The Difference

Then once a web project is live and a new pot of money exists to refine the system, you’ll rarely see a full blown functional specification for each new feature. The pot of money will be used to implement new features in isolation, put live and then move onto the next one until the money runs out, and if you’ve done your job right the client has received massive value from the features.

These approaches are very much not Waterfall, but that isn’t to say Agile doesn’t have its place…

Agile is for suitable for some

While not trained in Agile and therefore my opinions carrying little or no weight (oh well), from the research I’ve done, in general I believe Agile (or as some douche bags would mistakenly call it, the 37signals way) is suitable for large web application projects, especially internal ones that are constantly being refined, or anything that ventures closer to software development rather than website development.

Digital PM Martin Crockett is known for his diplomatic manner

It requires several things that smaller companies and projects rarely have e.g. a dedicated production team for the whole project, less emphasis on creative and design work upfront and very heavy client interaction to provide timely feedback throughout the project.

I used to work a lot with Nokia and they continually developed their global CMS using Scrum and it was perfect. Perfect because they had a huge core system in place – local agencies and other stakeholders would submit feature requests, they’d analyse them, determine what the priorities were and develop the features one by one in sprints.

Agile is often banded around as the “cool” way to do things, but when I question anyone seriously on it, the only people who seem to be successfully using it in the way it was intended are those who work on web projects that are big and are based on a large core system that is constantly being updated and refined.

People wanting to “go Agile” should be fully aware that it’s not really something you ‘try out’ in my opinion. Instead you could look at something like Kanban as a lightweight Agile style to trial before considering a full move – a full move to Agile is a very big strategic decision that requires a lot of change management, training and discipline!

But ultimately, and again I quote Pawel Brodzinsk, there is no ‘better’ web project management methodology, if it gets the job, leaves clients happy, is of high-quality and your business is making a profit then however you’re doing it is right!

You can do an equally crappy job under the banner of Agile as under any other. You can tell Waterfall stinks because Scrum is a thousand times better. Or you can tell Scrum stinks because Kanban is a thousand times better. And both will be equally false. On the other hand if your teams are well-organized the name of your approach is third-rate. You will deliver and will deliver quality. And yes, I’ve just said you can do it perfectly using one of old-school heavy-weight approaches grouped under the infamous ‘Waterfall’ name.
Pawel Brodzinsk, Who Cares If You Are Agile?

It may appear I’ve gone slightly off topic here but it’s all related…

Bringing it all back on topic

Ok, so I’ve wandered into the treacherous area of discussing Agile and Waterfall methodologies and their suitability for web project management in digital agencies, dangerous waters indeed, but it really is all to do with the point in hand.

The point being that I see and hear a large number of very talented people in the web community shouting and screaming that an Agile approach is the way to go.

But when you question them in any amount of depth the substance behind their argument is often based on a rather naive belief spawned from reading a few blog posts and books from some incredibly cool and successful guys like 37signals who preach to not over plan, or Andy Clarke who says to forget Photoshop and start mocking up concepts in HTML for the client – to just get building and adapt as you go.

Although I don’t agree with Andy, he looks way cool

But while reading these great articles they fail to recognise these guys are not giving advice on how to deliver web projects to clients in a digital agency environment, but how to run a business, develop a product or engage clients if you’re talented enough to be able to design and code to world class standards – not something many people are.

If you question them further on what they believe Agile actually is you tend to then get a few mumbles about “no functional specification” and “let’s have 15 minute stand up meetings” but not much more than that.

It’s at that point you realise these people are actually just repeating what they’ve read online and assuming its good because it’s said by ‘cool’ people and they want to be “cool” too – a totally understandable human trait, but dangerous if a Managing Director bases an agency’s strategy on it!

But just remember, being a good Web Project Manager means you possess the power to be incredibly empathetic, so put yourself in the developer’s shoes for just a moment and remember there’s always two sides to a story.

A developers perspective

I can’t help thinking however that when you get someone who clearly doesn’t understand 37signals or Agile speaking out about the benefits of it and how it should be adopted immediately, it doesn’t necessarily mean they’re just naive fools who have a lot to learn, but maybe it’s more sincere than that.

I believe a big reason these guys n gals latch onto Agile or 37signals-esque approaches is because they see it as a chance to skip all the ‘boring’ parts of their job!

Web developers who are passionate enough to keep up to date with people like 37signals, hungry enough to buy and read books like Rework and brave enough to speak out are almost certainly massively talented themselves and very creative people, and to them, functional specifications, prescriptive work broken down into features with defined functionality that’s been signed off leaves them little room for creativity and must make them feel like nothing more than robots at times – not a worse situation to find yourself in as a creative person.

So when they hear of a way of working that appears to cut all the boring parts out of their job and allows them the freedom to just get on with developing straight away it’s no wonder their eyes widen, their ears perk up and they want to jump all over it!

But even within the confines of prescriptive work and functional specifications, it is possible to let your team have some freedom, some room to experiment and bring new takes on already agreed functionality to the table – it’s your job as a Web Project Manager to listen to these ideas and if they sound great then to potentially rip up that part of the agreed scope and propose the new idea to the client and get approval.

Rob Borley hit the nail on the head on this subject in his latest post and really I want to quote it all here, but I think that’s naughty so I’ll just give you some highlights but it’s really worth reading.

Let them in on the solution. It can be tempting at times to solve (or try at least) all the problems yourself. It is much better to get your production team (designers and developers) in on the act as early as possible in the project. Allow your team the time and space to express themselves. Allow them to be creative; to try a new technique in a real project situation. Build some time into your schedules to allow for this kind of experimentation you will have a happier, more enthusiastic and, ultimately, more productive team.
Rob Borley, Give Your Team Room To Express Themselves

In summary

So before I get ripped apart in the comments section by developers and actual qualified Scrumasters, please note that I do know many people who work in digital agencies who adopt a proper Agile approach like the cool kids want and things work out great for them, be it on websites or web applications for clients – it most definitely can work.

All I’m asking is that the next time you hear someone demanding that they go Agile, to question them in depth about why they think it would be a better approach than they’re currently using, what they think Agile really is – and if at any point you hear well known agency names used to back up the theory, look into those agencies, find out what kind of work they do, do they work on large-scale web projects or knock out small to medium websites and web applications for clients.

Find out if it’s just someone saying what they are because they think it’s cool or if they really have in-depth knowledge and can put forward a great business case for the switch. Or perhaps consider it’s just a cry out to be given more freedom in their work, it could be their desire to be creative in their solutions just dying to get out – if so, try to facilitate it in your role as Web Project Manager, you’re in the perfect position to make that happen and it will almost certainly be beneficial to everyone.

But, if at ANY point you hear 37signals being held up as the ultimate piece of evidence that confirms how an Agile (less planning) approach works, please smack them on the botty, sit this person down and explain the differences between running a business, developing products and delivering websites and web applications to clients!

Working without a plan may seem scary. But blindly following a plan that has no relationship with reality is even scarier.
Quote from Rework

True for a 5 year business or product plan, not true for good web project plans. Ok, let the lynching begin…

I’m pretty sure code monkeys will do this to me one day

Image source

Related reading:

• Pragmatic Web Project Planning »

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

Example small website brief

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

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

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

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

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

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

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

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

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

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

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

Pragmatic web project planning

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

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

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

Defining scope, identifying risks and granular project tasks

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

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

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

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

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

Producing a project schedule

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

Planner: Create a project schedule & even export as HTML

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

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

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

Client tasks and revision time

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

This means adding tasks such as:

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

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

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

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

Dependencies

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

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

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

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

Lag

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

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

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

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

Resource allocation

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

Milestones

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

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

Why GANTT charts work for me

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

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

They allow me to:

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

Need I sell it more? This stuff sells itself…

The rewards of web project planning

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

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

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

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

In summary

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

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

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

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

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

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

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

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

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

So, I open up the floor to you guys…

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

Look forward to your comments :)

^ Back to top

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

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

Fire Fighters and Forest Rangers

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

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

Two planning personalities; Fire Fighters & Forest Rangers

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

The two web project planning personalities

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

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

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

The Fire Fighter

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

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

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

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

The Forest Ranger

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

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

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

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

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

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

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

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

Why Fire Fighting sometimes works

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

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

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

Consistency is key

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

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

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

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

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

The planning personality hierarchal truth

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

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

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

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

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

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

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

Pragmatic Web Project Planning: Part 3 »

^ Back to top

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

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

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

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

Why plan at all?

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

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

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

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

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

Why web project planning is often skipped

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

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

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

Lack of time

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

The default answers to these questions are:

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

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

Lack of web project planning skills

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

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

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

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

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

Damn, now I actually want a curry.

Lack of resource available to plan

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

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

Lack of budget

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

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

The belief planning over complicates

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

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

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

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

Web project planning is not fun

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

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

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

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

Why small web agencies and freelancers should plan thoroughly

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

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

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

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

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

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

^ Back to top