I was delighted and honoured to write an article for this year’s 24ways advent calendar. The topic is Project Management, with a bit of a festive analogy used to impart some top tips for keeping projects on track.
Go on over, check it out and let me know what you think!
Are you a web designer or developer? If so, head on over and fill in the State of the Web 2008 survey that the fine folks over at Web Directions have started.
Not only will you be helping us all understand the state of our industry, but you also get the chance to win some cool freebies for participating — more details here.
I’ve just returned from 4 weeks out of the office. Though I am now part of the Crackberry generation and have been able to keep vaguely up-to-date READING my email, my normal inbox processing habits are hard to keep up via an interface which relies entirely on clickwheel with hampered prescience. Another benefit (no really) of the Blackberry is that it is so painful* to write email back on it that I only ever write short urgent responses — everything else waits until I return to a laptop with email client.
This is very much a double-edged reality — on the one hand I tend to focus better on my holiday or business travel, limiting email time to 15-30 mins per day. On the other hand I am now faced with over a 1000 emails still left cluttering up my inbox.
I usually deal with this via a mammoth processing session, using many of the tips already covered in the Inbox Zero series. If you’re not nodding along with me here, stop right now and go investigate Inbox Zero. It’s a brilliant attitude to owning your email rather than it owning you and how to get brutal to make that happen.
Since I have been in roles where I have travelled A LOT, I’ve gotten pretty good at these mammoth processing sessions. Here are some extra tips — essentially how to look at your email sideways in ways that make those 1000 shrink down to something much more manageable:
Pretty simple, but sometimes the simple things make the most difference. Next time you have a mass of inbox processing to do, try looking at your email sideways to shrink it.
* Please note: I have both RSI and Carpal Tunnel Syndrome so for me using a Blackberry (and most other computer equipment) really is painful. This was not a slur on Blackberry interfaces in general 😉
I’m pleased to announce that one of my own projects has just come to fruition. My new book, The Principles of Project Management has just been published by SitePoint. It’s a short book aimed at folks like myself who have come from a technical background and are increasingly finding themselves in need of project management skills — whether to officially take that role or to help make the hard work they put in as developers or designers actually mean something, by ensuring the project is delivered properly.
The book was expert reviewed by Kevin Lawver and Drew McLellan who both did an admirable job of ensuring that the content stayed applicable to all sorts of projects and teams, both big and small. They also bravely took on the role of managementese-weeding and survived with remarkably few lasting scars 😉 Drew has written some thoughts on the book on his own blog. I thoroughly enjoyed working with both Drew & Kevin, as well as the team at SitePoint.
If your interest is piqued, then check out The Principles of Project Management book page or download a sample chapter. You can also buy the paperback or Kindle version on Amazon.
In the interests of full disclosure, I would highlight that all the links are affiliate links — i.e. if you buy the book via that link I will both be able to track it and get something back 🙂
I’ve just invented a new acronym (yeah, yeah, I know, like the world NEEDED another acronym, right?!): DFPS (Deadline First, Plan Second).
Deadline First, Plan Second describes the all-too-common phenomenon of project deadlines being set before any of the planning and estimating has been done. We’ve all been involved in or heard of such a project — the kind precipitated by a big announcement that The Next Big Thing (TM) will be delivered by March 1. Post announcement, a team is pulled together tasked with actually making it happen.
This throws many good project management practices straight out the window. It doesn’t matter if you do a proper plan, involve the team in estimating and figure out that the project will REALLY take 9 months instead of 5. The announcement has already been made — pointing out that it’s unrealistic is only going to get you accused of not being a team player. Alternatively, your management may view it as a crafty way of getting more money or people. So you may go in trying to convince them that it’s not going to happen and come out with twice the money, but you’re still signed up to an impossible deadline.
The good news? People who pull deadlines out of the air often don’t really understand the intricacies and complexities of your project. Duh, right? If they understood, they wouldn’t be setting impossible deadlines! Although this may sound like I’m just hammering home bad news, there is a flip side to this coin. If the deadlines are arbitrarily set, they are quite unlikely to have a detailed understanding of the scope of the project.
Reality is that you can probably negotiate your way through on all the other project variables – cost, quality & scope – you just need to accept that someone high up has nailed their future to a deadline and so now that is set in stone. So long as there’s a big “we did it” announcement on March 1, the definition of “it” is probably fairly fluid.
My advice? If you blatantly need more money or people, go the “it’s impossible” route at first. Get some extra resource thrown at you. Then, very helpfully, start preparing plans of what actually IS achievable for a Mar 1 go-live. Aim low at first — your project board or management team are going to be horrified at how little you’re saying can be done, so they’ll want to argue you up to more stuff. But be very aware of where your limits lie. Plan to under-promise and over-deliver. Give them something that works, but doesn’t sing, dance & play the ukulele. By then they may well realise they don’t need all the singing and dancing anyway!
PS If you’ve been keen to find a way to introduce a new approach, like Scrum then a DFPS situation might be just the leverage you need. Worth a try!
I imagine that most of you have aleady heard of Test Driven Development (TDD) where the tests that software should pass are written BEFORE the software itself is written. The list of tests is essentially just a formalised way of listing success criteria (and indeed requirements) very precisely. More than precision, this approach gives you a very fast indication of your REAL progress, since the newly written code either passes or fails the tests*.
Test Driven Development is a software development approach usually associated with agile development methods such as those championed by the Agile Alliance. It is usually assumed that agile development requires a team to be collocated, working intensively and exclusively together, and so little attention has been paid to the role of these methods in outsourced development.
For better or for worse** however, many of us are on one side or the other of an outsourcing arrangement. I discovered in my work that using test driven development as a mechanism for both validation (are we building the right thing?) and verification (is it working?) can be hugely powerful.
There are a number of reasons for this:
Hopefully as agile development methods become better and more widely adopted, an increased number of the firms providing outsourced development services will start to use them as standard. In the meantime, it can make a huge difference to your projects if you manage to introduce them ahead of the curve.
What have your experiences been with test driven development and outsourcing? Share in the comments.
* Provided your tests are well written, that is. Of course, writing good test cases is a skill all of its own!
** The pros and cons of outsourcing your development definitely deserves another post! Or arguably an entire book!
As some might have suspected from the lack of updates here recently, I’ve been rather busy! In the last 5 months I have only been at my office for about 4-6 weeks, spending the remainder of the time travelling in the US, Hong Kong, Philippines and Australia for business and the last month at home in South Africa on holiday.
As a result, I thought I’d break away from productivity and management to talk about travelling for a little while. In future posts I’ll also discuss some strategies for working effectively in teams that are spread across the world!
Without further ado, here’s my common sense list of tips for making international business travel as easy as possible:
What are your tips for hassle-free travel? Share in the comments!
UPDATE (21 Oct 07) As Tim Beadle reminded me in the comments, Dopplr is a great tool to use when you travel frequently, both as a reminder to visit friends and colleagues in the cities you are going to and also to help you run into fellow travellers who happen to be in the right place at the right time! For the Dopplrites amongst you, you can add me and maybe we will meet up one day. For those seeking an invite, leave a comment and I’ll get you one 🙂
My first SitePoint article has just been published — Effective Project Management for Web Geeks. For those of you who found this blog because you saw me speaking about Project Management somewhere, it may well sound quite familiar, but I think it’s a nice round-up of some PM basics and the basic toolkit that I recommend everyone get familiar with if they want to keep their projects under control.
Go on over and check it out and let me know what you think!