The principles of Schedules, Work Based Structures, Resources, Effort, Duration… I understand.

But Microsoft Project… Baffles me every time. It seems to work against my logic. I’m stuck with it at work because I’m on Windows, the ‘real’ project managers in our team have fancy Macbooks with OmniPlan, which I can only imagine is more intuitive. I had given up on using it for anything other than a very bloated hierarchical list editor. Gantt charts, levelling, resource allocation, estimates and due dates were all not working the way I wanted. Until I read this in a series of articles at Tech Republic on MS Project:

Duration = Work/assignment Units

And the penny dropped. A lot of the behaviour of MS Project makes sense when you understand that the above formula remains true and unalterable.
The program still annoys me in the way it tries to think for me and automates some of its calculations while you are entering info. (hint: Enter your tasks and durations first, then do your resource allocation) And I am not about to call myself a Project Manager. But I am one step closer to understanding this tool and actually getting a few things done with it instead of spending the day cursing.

Ah, a chance for process mind dump. My favourite! Here’s what I think
off the top of my head….

Yeah, I know what you’re saying about the tendency for clients to
change their minds when they see things in action. Generally it is
hard (for them especially) to visualise things out of context and
without seeing it in action. It’s what a prototype is for – one
expects it to change in the next iteration after feedback.

I suppose you need to offer a certain number of iterations at each
phase, and you agree beforehand that by the 2nd, 3rd or 4th (or
whatever maximum budget permits) feedback session you will have
reached a final version, or renegotiate terms. Obviously the better
defined the goals and idea is from the beginning, and the better the
feedback and communication with the client, the more worth you get out
of each iteration.

Internally we then discuss behaviour/presentation that is on brand and
in scope and answers feedback so far, and make sure we are developing
to meeting those goals.

I suppose one should throw some basic user testing into the mix too…
I usually show it around the office and send links to a couple people.

See it as building up from the essentials. Your first prototype was
actually your static photoshop designs. Next we will add click and
load of linked content, and then we will add transitions and tactile
mouse interaction behaviour, then we will tweak and polish. (there. 3
phases)

As for the hard work up front… I think a large part of that can be
mitigated by good client communication and explanation of ideas, so
the designer/developer isn’t trying to guess too much at time of
execution.Brief the designer/developer effectively so they understand
the goals, and can add some of their own understanding and creative
flair to the problem solving.

Review internally frequently – we can make the mental leap to how
things behave a bit better than clients.

Also, as you know I like to develop with reusability and
configurability in mind, so swapping one behaviour for another, or
enhancing one aspect of the behaviour is more about adjusting a lever
than rewriting much more code. I think the core to making this stuff
work is getting the correct subtle balance in the various parameters
that combine to affect the overall behaviour. If we know we are
starting in the right direction, the post client feedback should be
met with this sort of adjustment (and usually is, unless they hate the
whole concept and we have to start from scratch.)

There you have my thoughts! Happy to discuss adjusting and solidifying
into a more structured process…

We currently have one of those jobs in the studio that is going around in circles. “Photoshop ping pong” our designer called it today. The client has a designer, we have designers schooled in n web design and the best logo design and branding tradition, and everyone’s trying to serve an ace. Our client-side developer waits in the wings for his turn, but the deadline has passed and the designers are still lobbing each other.

Hence my assertion. Get rid of photoshop. Ban it. Mark up the content semantically in HTML and get started with CSS design. Let the client see what it’s really going to look like and how it’s really going to behave in a browser. That is web design.

One day they will understand what I mean.

I am by no means a stickler for paperwork and requirements or over burdening a project with admin. I think there is something in approaches like 37 Signals’ Getting Real, where the most important verbs in the interface come first, and the initial spec can be sketched on a napkin with a ballpoint.

As a developer I like the idea of an agile approach, jumping straight into code and trying out a few things with test users, or even real users, and adapting to feedback with new, quick releases. But the brand custodians, and the managers in creative agencies are nervous of this kind of gun slinging approach. And perhaps rightly so. The project and budget could disappear down an iterative whirlpool, get stuck in a recursive loop, or simply fail to launch.

In the design agency world we tend to have this version of ourselves where we sell our great ideas to the client with a bit of a bang. Revealing our process is bad. We think they are paying us for our moments of genius. We are the hot shot “creative guys…”

I think in practice, neither the agile or the big bang approaches are quite right for web design. Something between could work. We need to temper our egos and work consistently towards a big release. A product needs to take shape, not be drip released or served on a platter after a brain storming meeting. Ideas need to be invented, tested, thrown away, reabsorbed and simplified. A plan needs to be laid out, with stages of progression towards a final release. Decisions need to be made, and communicated to all concerned. Feedback needs to be gathered, and converted into something useful.

Involve the client in this process, and they will understand it. They will feel like they are getting “something” because every stage is building on the previous one. And apart from the sense of involvement, they’ll get a better product for it. If our client manager gets that from our meeting this afternoon (I think he did) we may have the chance to put the thought into producing something really good.