I’ve been a desktop Balsamiq user for some time now and am finding it more and more indispensable with each project. It’s been replacing project specification docs to the point where I don’t really have to write any other instructions. By linking pages together and viewing it in fullscreen mode, we can see how the home page, section pages, contact pages, and even modal popup windows and AJAX behaviours should work.

I can “knock together” a basic site in a few minutes – and an intranet in a few hours. In each case, the result is much clearer and easier that written briefs or specification docs. Clients can understand them just as easy as programmers and designers!

And when the client approves the mockups, we can refer back to them if there are any additional requests. “That wasn’t in the mockups you approved. We can do it, but it will cost an additional $x…”

The webapp will make collaboration that much easier. Really looking forward to its release!

And it turns out that my struggle to get this part of my business right has been based on a bad definition. (Or probably, more accurately, no definition.)

So in order to find the right tool – the question must be asked: “What is project management?”

And the answer is best summed up in explaining what it’s not.

Earlier this year I purchased Sitepoint’s The Principles of Project Management – and on page 8 the obvious truth stood out:

Firstly, project management is not personal productivity. This is an easy mistake to make, however. Most folks’ early experience with project management is on smaller projects on which they’re doing most of the work themselves. It’s easy to start treating the project schedule as your diary, the task list as your to-do list. But as soon as you add anyone else to the project, be it a client who wants to understand the time line or a colleague helping out with some of the work, this approach starts to cause problems.

If you make your project management tools double as personal productivity tools, you’ll almost certainly be including far too much detail. Keep a clean line between what you need for yourself personally, and what the project needs. This way, when you have slightly larger projects with more people involved, your tools will scale.

If you think about it, many of the project management tools pitched at web design businesses are very much focussed on tasks. Way too much detail – and the whole project management things just gets way too hard.

So I have found a solution that is surprisingly low-tech:

A whiteboard.

Yep – that’s it. It happens to be a magnetic whiteboard though. So here’s what I do.

1. The whiteboard is divided up into columns – with each column representing a milestone. “Received Content”… “Design Approved”…  I have about 7 stages I think from memory (I’m writing this from home) but there’s no magic number. Divide your workflow into milestones you can tick off.
2. Each project is represented by a little piece of paper with some essential details. And it’s held to the whiteboard with an amazing piece of technology called a magnet. When you have received the content, move it into the next column!

This overcame a couple of problems:

1. Software wants you to enter due dates for everything, whereas in reality a lot of when something gets finished depends on the client. So due dates regularly got missed, and planning went out the window. The whiteboard has no dates.
2. It’s quite easy to stand back and see any bottlenecks on your process. Got a lot of projects sitting in stage x? Why? Then do something about moving some of those along.

That’s about it. Check the whiteboard once or twice a week with your team and get progress on where everything is at, and what projects can be moved to the next column.

This does not address the question of the detail though. What actually needs to be done during each stage of development? And how do you know when it’s done?

Ah, well that’s a topic for another post…

I read this article on email and customer service about 6 months ago but while I was looking at some goals for 2008 I thought it was worth revisiting. So how do you stack up in those figures? If I’m not careful I tend to find myself amongst the 70% who fail to respond within 24 hours. Definately something I’ll be fixing for 2008. A good tactic is mentioned in Mike’s first point:

Automatically respond to all emails received: People will be more willing to wait for a reply if their initial communication has been acknowledged. Include a commitment to act on the issue and when you will respond fully.

I think people will generally understand if you can’t address the issue immediately – but it’s important to acknowledge the email and set an expectation of when you will be able to do so. It also ties in to something I wrote back in 2004 about controlling your email (instead of the other way around!) – it’s as relevant now as then. So, my top tips:

1. Choose when to check your email – don’t let your computer decide for you
2. As you’re going through your messages, fire up your diary (or whatever time management tool you use) and mark a time to actually attend to the task or issue
3. Respond to each email as soon as you read it (even if it’s only a brief response) – and at that point you can let the other person know when you’ll attend to is as well

Of course, if it’s an emergency you may need to deal with it straight away and all the above advice is null and void, but we don’t live in a perfect world, do we?

Originally posted at almostanything.com.au

Still in alpha, but at least it’s open source and downloadable. For many, that’s a far more attractive proposition than paying for Basecamp on a monthly basis.

And if it’s anything like Basecamp it’s really simple to use.

Might have to check this one out…

Or maybe NetOffice Light?

Dunno. Anyone got any other ideas?

The other problem is that projects seem to be taking forever to get finished, as we’re trying to do a bit here, a bit there – spreading ourselves way too thin.

A new house, anyone?

My brother and sister-in-law are having a new house built at the moment, and it was something my brother-in-law said to me last week that got me thinking. He was commenting on how quickly the house is being built – the slab was only laid about 5 weeks ago and it’s not far from finished. What he didn’t mention was the 6 months they waited for the builder to actually start!

If you’ve ever built a house, you’ll know that there’s a lot of stuff you have to worry about before the builder can start. Tap fittings, door handles, carpet colour… there’s quite a list. And only after all these things have been arranged does the builder actually start. And once they do, they get stuck in and the house actually goes up very quickly.

So here’s my lesson:

I’m only going to work on a couple of websites at a time. That way we can devote more attention to each project, and actually get the job done much faster.

When new clients come on board, we can give the client a start date and a to-do list, and make sure they understand that everything must be checked off that list before we can start.

So the client might have to join a queue before their website gets started, but once we do actually start it should come together quite quickly, as we’ll have everything we need in front of us.

Anyone care to share their thoughts/experience?

Why?

One of the main reasons is that phpCollab is still stuck on version 2.4, and has been for along time. Sure, they have a 2.5 in beta, but that’s been in beta for a long time, too. NetOffice have a stable 2.5, a 2.6 beta, and a starting to get some direction for a 3.0 release. Bug fixes seem to be attended to in a reasonable amount of time for an open source project, so we’ve migrated over to the 2.6 release. It features:

• An improved interface
• Time tracking
• Built-in customised reports
• Meetings

I feel that time tracking is the most important addition. With some minor customisations, we will be able to run a billing report so we can send an itemised invoice for each project. We can see how many billable hours have been done each week (and hence measure productivity). We can check each person’s workload based upon estimated hours allocated with each task. Useful stuff.

We’ll get some of these mods together and post them here soon…

When dealing with project management for website development, there are really on two things to juggle.

1. Tasks
2. Resources

Sounds simple, right?

Tasks

Tasks are fairly obvious. They are the things you have to do. I have found it useful to group your tasks into phases – it helps to get a better overview of where you are (instead of looking at a great long list of unrelated tasks) and it’s also easier to set up a template of standard tasks that you then simply customise for each job. We generally use the following phases:

1. Planning
2. Content gathering and editing
3. Design
4. Programming
5. Construction/Assembly
6. Testing
7. Post Launch

Tasks near the beginning and end of a website project tend to be repeated, so make a template out of these at least. And look for the things that you generally do in the middle phases, and write these down as well. You can easily customise your list if the individual project warrants it.

Once we have our list of tasks together, we now need to make them happen!

Resources

In project management, resources can be anything from people to equipment to buildings or meeting rooms – anything you need to get the tasks done. Relating back to web design, we’re really only talking about people, or manhours more specifically. Time. If you have 80 hours of tasks to be done, and George has 20 available hours this week and Mildred has 15, it ain’t going to get finished this week!

Another point to consider – people aren’t productive 100% of the time. We’re not robots. So if you employ someone for 38 hours per week, you’re wasting your time allocating them 38 hours worth of tasks. Never going to happen. I work on allocating 4 hours out of every 5. If they happen to get finished earlier than expects, then good! Get a head start on tomorrow’s work. But you need to allow time to get coffee, visit the loo, chat about the movie you saw on the weekend or whatever.

Okay, that’s enough theory. Next installment we’ll start getting our hands dirty!

This might be okay if you’re working on one or two at a time, but when you get to half a dozen or more, you’ll quickly find you need some project management skills.

I’ll be outlining here over the next few posts a method that works for me. I’m always fine tuning it, so it’s by no means perfect, but if you currently have no management system in place at all this will hopefully set you heading in the right direction.

I’ll be referring to phpCollab (as that’s what we use), so it might be a good time to download, install and configure it before we go much further. There’s setup instructions on their website, so I won’t repeat them here.

There’s your homework for now, next time we’ll deal with basic project management principles.