Planning personalities
I often come across both web agencies and freelancers who consistently do not plan their digital 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 digital projects and digital 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 digital 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:
- 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)
- 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 the first time round (The Forest Ranger)
(Ok, I realise these images show neither a Fire Fighter nor Forest Ranger, but you get the meaning behind them, no?)
The two digital 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, digital project management ideals aside, and speaking from the reality of running digital 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 digital projects using either approach? Using quotes from Karine’s article, let’s take a closer look at the reasons why both digital 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.
Project Management and Fire Fighting
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 digital projects in this way in order to look busy or have a sense of purpose.
I believe the reasons some digital project managers adopt the fire fighting approach are because they:
- Have no time to plan or run a digital 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 digital project overload – responsible for too many projects at a given time
- Have a lack of digital 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 digital project planning
- Just want to get on with the production
- Have had successes with the approach before
The Forest Ranger
While firefighters 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.
Project Management and Fire Fighting
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 digital 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 digital projects in detail
- Be responsible for an acceptable amount of digital projects at any one time thus not falling victim to project overload
- Come armed with digital 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 digital project planning
- Believe beginning digital project production work before planning is a large risk
- Have had successes with the approach before
So what’s the best personality for digital project planning?
Well first of all it should be said that although I have discussed two different digital project planning personality types, it doesn’t necessarily mean one person can only adopt one personality throughout the many projects they plan.
As a digital 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 digital 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 digital project planning and management:
- If you have the skills, experience and time to implement, the most effective, efficient and solid digital 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 digital 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 digital project planning.
Great article. I agree that every web PM has been a fire fighter at some stage. On smaller projects you can get away with it. But as soon as you move on to something larger you are simply asking for trouble.
Also, the stress and pressure involved with being on the edge in this way is simply not sustainable.
Do you think that people are fire fighters because they genuinely believe it to be the way that a project should be run or is it because of lack of experience / even laziness?
Is there something inherent about working with the web that encourages somebody to be a fire fighter?
I agree with you & Rob in that when you start PMing you have to be a good firefighter. Even as good PM’s ‘grow up’ to become experienced, proactive Rangers they still need to remember those reactive firefighting skills. In 15 years of being involved in programmes & projects & change I have not seen a single project which didn’t have at least one crisis.
The differentiator that I look for in a Project Manager is what they do after they have fought a fire. The good ones reflect on what happened and ask questions – Why did the fire start? Why didn’t we notice that it had started sooner than we did? How could we have put it out faster? Then they proactively apply that to the next project.
Maybe that’s why a good plan feels like fire prevention, but with the hindsight that comes from having fought a few fires at the sharp end.
Anyway – another thought provoking post – am looking forward to part 3!
I’m hearing a lot about Agile Development. Not sure how (or if) it would work at a small agency like ours. I’d be interested in a case study.
@Rob I think its a bit of both, but also because they dont really have the passion to run web projects that we do.
When I don’t love doing something I tend to do it quick n dirty too if the truth be told, but if it’s something that could be expensive to get wrong, I bring in the professional and give them the time and money they want!
As for if there is something inherent about working with the web that encourages somebody to be a fire fighter… wow, that’s an interesting question, not one I’d really thought of before. Web projects do seem to be extremely fluid in nature and thus that could make them hard to manage in a structured way, or it could be that the industry, and practice of web project management is still really in it’s infancy and so a tried and tested formula hasn’t yet been created? Unlike with I.T. projects and making a TV programme… those projects have been run for a million years now, but maybe in the first ten they were run by Fire Fighters too! Very interesting…
@Jim, I’d be grateful of just one crisis in a project ;-)
Very true what you say about learning from mistakes. I’ve gotten into the habit of jotting down anything that I miss during any web project now, and then adding it to my mega huge web project task list template.
This combined with an ever increasing sized lessons learnt document help me try to avoid future fires, although new ones just keep popping up!
Maybe it will be complete when I retire.
@Jon, Agile… the cool kid on the block. I know what it is and roughly how it’s meant to work. I have friends who are ScrumMasters and say how amazing it is, but, none of them work in a small web agency…
I have my reservations about the practicality of Agile in a small agency simply because of the kind of projects we tend to work on; small to medium sized websites.
However, when developing web applications I think it would prove extremely effective, and that’s why it works in large company environments.
The big barrier in my head I have is how you would go about mixing up the methodologies in a small agency. I’m not sure its feasible to run two projects using a Waterfall / Agile hybrid way, and three others using Agile and with team members spanning both… sounds messy to me – but I’m very open to hear opinions from someone with experience of Agile in a small agency!
@Rob and @Jim, what do you think about Agile in a small web agency?
I personally find a hybrid of Waterfall and Agile works best, in that each project has a fixed price, but the scope is flexible-ish throughout the project, as long as quality and schedule arent affected.
I manage a small group of web developers and dbas (8 developers). I think you need to find the right blend of the 2, but I definitely lean towards the firefighter approach. Its unrealistic to expect full planning, before you tackle a project. If you keep your projects on the smaller side and employ an agile style of coding, you can certainly forgo a lot planning, and basically plan on the fly. You also need to staff your team with the right talent mix. Agile developing is not for everyone. As you mentioned in your firefighter description, your staff needs to be able to produce and deal with the adrenaline that comes at times when developing without much planning. Freelancers, however cannot afford this luxury and need more planning to “control” a project.
@billb, Agile certainely has it’s place, but I would ask for kind of projects do you and your team work on? Websites, web apps? How many projects does the team work on at the same time? Is it a team that works together on all projects?
I’m considering writing a post on the practicality of Agile in a small web agency environment simply because I can’t see it working..yet. Not only because of the variety of work but also the fact that in that agency environment you are working with different people all the time but also the clients not feeling comfortable with such a project management methodology.
I would go into more depth here but it would list the points of my planned article. But everyone who I meet who says they work in an “Agile” way, either genuinely does and is part of a team that builds web applications or very large websites, or, just say that to make their lack of planning skills look intentional – and I’m yet to find someone working in a small web agency who gives Agile the thumbs up as an agency-wide methodology that works well.
However, I SO want to meet people who can convince me, I feel like I’m not quite in the cool gang while I’m not practicing Agile :)
@thesambarnes
Good points. I do manage an in-house web team that primarily works on 3-4 large websites. While we do client based work from time to time, mostly we are developing for in-house management. We work on both full website creation/redesigns with many members of the team, and on web app projects, with one or 2 developers at a time.
I am not a purist of any methodology at all. Rather, I try to be effective and practical. Keeping up on technologies, and techniques, and molding them to my particular situation. We have a relatively small team, and have had to adapt our development in order to keep innovating. We have adopted many techniques of agile/iterative development.
Personally, I am also not a fan of too much planning, because plans change too frequently, and plans really only create an ‘illusion of agreement’
I have written an about this topic, it may be of use to you in creating your agile post. Iterative Development is Effective: http://www.effectivedevelopment.net/2009/03/iterative-development-effective/
@bill, while I can see you fall into the category of ‘Agile’ people I described (someone that genuinely uses a form of it), you also confirm that you do work in the type of environment and work on the type of projects that I believe Agile is perfect for.
But like you, I too believe in not picking a methodology and running with it, it has to be whatever works for each company, and sometimes each project. At small web agencies I find most use a hybrid of Waterfall and Agile.
Waterfall in that phases are planned sequentially, planning, design, build, test etc. but Agile in that if a change is required to a phase that has been signed off, most agencies will make not point blank refuse to do so (as per Waterfall methodology), but instead work with the client to accommodate scope flexibility under a fixed price budget by perhaps compromising in other areas (as per Agile).
I will steal someone else’s quote and say that I believe in “appropriate planning” for a project, sometimes its little, sometimes it’s a lot – it really depends on the project.
One, of many, ways to judge what appropriate planning is, is to ask the questions “Has the planning captured, for us and the client:
* What is going to happen in this project?
* What is not going to happen in this project?
* If scope creep starts to happen, has ambiguity been reduced enough to push back?
* When is everything in the project meant to start?
If the answer to that question is “yes”, enough planning has probably been done. Sometimes this can be done in an e-mail, sometimes its five documents – the key lesson is to know when it’s one or the other.
Interesting article from my perspective since my background is in larger scale software development where I introduced Agile methods, and now my company also develops a simple project management service for freelancers, small agencies, designers, etc.
I think that an Agile approach is especially well suited for a smaller agency. In my experience, the smaller the shop, the less formality you need, but the principles are solid.
The place to start is really in incremental/iterative delivery. Instead of creating a detailed spec, estimating every piece of the project, then delivering the first big chunk to a client 3 months later, an Agile approach would say:
Get an overall sense of the client goals, etc., then choose a few of the basic website functions and deliver those in a couple of weeks. Get feedback, choose some additional priorities, and repeat.
When it’s “good enough”, the client may decide to go live, even without all of the features in the original plan.
To be fair, Agile is probably more beneficial to the client than it is to the web shop – they’ll have more visibility, be able to see the site evolving quickly, and yes, be able to kill the project if it’s moving in the wrong direction.
@DaveC, thanks for your comments. I’m so interested in this topic of Agile for small agencies, you make some really good points that have got me thinking.
Again, I really can see the advantages to this approach in the development phase, but the clients I deal with all tend to want to see design first and want to know exactly what functionality they’re getting – plus would find it difficult to find the time to review and provide feedback on version of features.
The more I research, and hear, about Agile, I am more swayed towards a methodolgy that uses approaches from several traditional methodolgies… I so need to to compile my thoughts into an article! Would love to kick off a healthy debate on the topic.
@thesambarnes says:
“but the clients I deal with all tend to want to see design first and want to know exactly what functionality they’re getting”
Yes, all clients want this, I think :-) But what design? The entire thing? The home page? The signup page or shopping cart? Just the overall structure?
I think even with design, it’s possible (and beneficial) to incrementally deliver. Not where you change everything each time, but “finish” a manageable piece.
“plus would find it difficult to find the time to review and provide feedback on version of features.”
Yes, there is a time commitment, but the idea is that you’re doing this to reduce the client’s risk, and you’ll need this frequent communication anyway for a good outcome. The alternative is “signoffs” on what “we all agreed to” a few months ago, then an adversarial relationship during the “construction” of the site.
So maybe you design the overall layout and call it good. Then next time the client might be reviewing a catalog page layout. Most humans can’t reasonably review more than 3 or 4 major things at a sitting anyway – so why force them to review 20 major items with lots of details up front?
To fail to plan is to plan to fail. I like the analogy of the fire figher and the forrest ranger. The plodder will end up getting more work done, better than the ball of fire who burns out before the job is done. Bella
@Bella, agreed, it’s such a perfect little analogy – wish I’d thought of it :)