The Charge of the Light Brigade
Project management is a pain. There is little fun in it, there is certainly no joy in it, but it is unavoidable if you want to produce good stuff. Or keep your job on a long-term basis. Or, if you are really ambitious, both.
So why am I bothering to write about it? Me, who regards Microsoft Project as evil?. Me, who would rather design a website any day of the week than have to work out its key milestones.
Because I am so fed up going into companies and time and time again watching as projects crash and burn simply for lack of proper organisation. Different people, different company, same problem.
It is analogous to the Light Brigade, having been massacred mistakenly charging artillery, handing over the job to another British Regiment.
British Regiment Two looks at the pitiful survivors of the Light Brigade as they lie on the ground, bleeding to death. Then they look at the Russian guns which have now been reloaded and are ready and waiting.
The commanding officer makes his decision and turns to his men.
“OK chaps! Straight at them!”
Now it’s rare to find Russian gun emplacements and British cavalry regiments fighting pitched battles in a new media office in Clerkenwell, but I hope you get the point.
Real blood isn’t spilled, but profit margins are. And without consistently good margins on individual projects the company will soon die.
So what’s this got to do with User experience?
Well long ago and far away it was usually the MD and Art Director who would pitch for new work. Nowadays it is the MD and Head of UX who leads the pitch. Why? Because the standard of art direction and web graphics is now (2009) so high that it is a given. However the quality of user experience is extremely variable and is often the difference between a client getting a website that fulfils their business objectives and one that doesn’t.
Now user experience is only part of the deal when it comes to new media production, but it is a very big deal. And in my experience if a project is not managed properly then the whole user experience development and production cycle suffers.
Can you add an input field to this please?
Without good project management processes and controls what can happen – and this has happened to me – is that the user experience team is left out of key design meetings. Eventually someone might come and ask the user experience designer if they can add an input field to a wireframe.
Excuse me?
Every component of a wireframe is there for a logical and functional reason. The user experience designer must be able to justify every element of his or her output deliverables. It might make perfect sense to add the input field. Or it might not. But the user experience designer needs to know the reason for the addition. Which means they should have been in the meeting with the rest of the team when the issue was raised.
If they were not in the meeting now they will ask for another one. So adding to the overhead on the project. And so reducing the project margin. If this happens repeatedly on a project (and again this has happened to me) then the end result will almost surely be a mess. An unprofitable mess. Which will only serve to confuse users, not make life easier for them.
So in an attempt to make life easier for everyone I have created a basic outline of the critical path necessary for website projects. It’s not complicated but it does the job. If you are working in a void where every day brings the possibility of having to do the previous day’s work again, then this might be handy.
I do not claim original authorship of this critical path. I first encountered it while I was working at Epic Group in Brighton many years ago. And since then I have frequently resorted to firing up Visio or Omnigraffle and drawing a diagram which explains the basics.
By doing this now and putting it on the web for anyone to freely download, reproduce and use I hope I might be able to save a lot of people from getting very frustrated when building websites.
By doing this now and putting it on the web for anyone to freely download, reproduce and use I hope I might be able to save a lot of people from getting very frustrated when building websites.
New Media Production – Seven Stage Critical Path
Schematic of New Media Seven Stage Critical Path
Right, enough waffle, here we go.
The critical path model I propose here consists of seven high level stages. These are:
Each of these high level stages will have its own processes within it. These can be – and should be – tailored to the needs of your own organisation. What suits one group of people won’t suit another group. But the high level is not going to vary very much.
The more alert amongst you will have noticed that there is no high level user experience design stage listed. This is because user experience has to be treated as part of the overall design process. It’s not special. It works with art design, creative approach, HTML design, database design, content design. Yes it pulls them all together in the best way possible, but it is still only part of the deal.
Of course within the big Design box there will be a pre-defined user experience process flow. But then there will be for the other design disciplines as well. They all work together. You may have your own view which differs from mine, but I don’t care!
First things first, second things second.
1 Pitch
Pitch or proposal, call it what you like, this is where the business is won and the project is first defined. If as a user experience person you are at the pitch then you can make sure that what is promised can be delivered. Account managers have a habit of promising the impossible, usually due to a lack of technical knowledge. Make sure this doesn’t happen. If it does flag it as soon as you can.
2 Scope
This is sometimes called ‘Define and Discovery’ because it is the main opportunity to have a thorough look at all the issues relating to the project and identify any nasty surprises.
Other people term this stage ‘Project Definition’, others ‘Requirements Definition’.
Whatever you call it doesn’t really matter, what is important is that you define what it is that you are going to be designing and building. And just as importantly what are you NOT going to be doing. It is no fun getting to the design stage and only then finding out that your neat and whizzy interface ideas are to be constrained by an existing set of user experience parameters which make the concept sold at the pitch impossible to deliver.
It’s essential that one of the key ouputs of the Scope stage is a Requirements document. Sometimes called a Project Definition document. In fact it may well be that there are several documents covering tech, art and UX. The project manager will of course be producing all sorts of interesting schedules and budgets. Mmmm… schedules!
3 Design
The design phase is usually the most intensive part of the project, often the most fun part and should take as long as it takes. The more time that is spent in design the less time will be spent in build and testing. And it is where the user experience people have their main change to propose good user experience solutions and get them implemented.
In some cases it might be that the pitch was bought by the client solely on the strength of a budget and some creative art work. The user experience design process has to take those constraints (and a load more) and make the theoretical practical. But this is not done in isolation.
Many agencies (and client side design teams) will have their design teams organised into three disciplines:
- Art
- User experience
- Technical
The better these three teams work together at the design stage the better the end product. Each team and each team member must have an understanding of the other teams and respect what they do and how they do it. If the programmers think that all the art people do is ‘apply a lick of paint’ to an interface design then they should reflect on why the art team don’t like the tech team much. And the user experience team has to work with art and tech to negotiate (and i use that word deliberately) the best solution.
I use ‘negotiate’ because user experience teams are still sometimes a new addition to a project team and as such are often taking over roles previously the domain of others.
User experience designers need to tread carefully when explaining to a graphic designer why a certain colour scheme might not be good in terms of meeting accessibility requirements. And by the same token also be sure to explain the functional logic of the layout of a form to a techie.
Explain. Explain again. Then explain again. If you don’t like talking to people then you might be in the wrong job. The outputs of a user experience designer (be they on paper or PDFs) also need to explain, not dictate, the reasons for a particular approach to a design.
Another issue which can rear its ugly head at this point is that a diagram of a user flow which is perfect for a lead programmer to know what they need to know might be of little use to an account manager or project manager who needs to explain an issue to the client. If you are really good at your job you might be able to produce one document which is understood by very different people. But this is not always possible and so you might have to bite the bullet and produce different versions for different audiences. If you do think this is likely make sure your project manager knows this needs to be reflected in the budget.
Obviously the user experience design process has it very own critical path which I shall come to later…. I can’t wait!
It is always good practise for the Design phase to take much longer than the Build phase. Why? Just for the sake of it? No. Because my experience has shown me on every project I have worked on over the years that the longer a team spends designing how a website should work the less time than will spend building it. And vice versa.
4 Build
In an ideal world by the time all the design has been done and the build starts the main work of the user experience people should be pretty much done and dusted.Or not.
Of course there is still work to do, primarily of the “Ooops, we thought this would work but it won’t so what do we do now?” type. Or the “Our client has changed their mind / objectives / budget / hair style and so they want to change some / all / most of the site” type.
But this is normal. It’s why new media is fun to do! What is not fun is when the build process turns into a waking nightmare because the design process is being done at the same time. Late nights, busted deadlines, compromised designs.
Know that feeling?
And it is to avoid this happening that all projects should have a critical path to follow. Do the first things first and the second things second. Pretty simple. Often forgotten.
There will be a need for user experience to get involved in the build phase, but this should be more in terms of consultancy. This is often when a programmer can implement a user interface component in one of several ways, all of which are good, all of which follow the wireframes produced by the user experience people, but he or she wants to know what the best practise is?
5 Test
Yawn! Is there anything more boring than testing a project? Some people get off on it, but not me. One reason being that by the time one of my projects is being built i am working on the next one. Wondering about how the testing is going? It’s like wondering if we will all be flying around on our personal jet bikes in the 22nd century.
6 Deploy
Putting the project where it is supposed to do it’s thing. Website. Kiosk. Phone. Wherever.
7 Maintain
Even duller than testing.
And that’s it!
There is nothing complicated about the idea of a critical path. Once defined it is pretty easy to follow it. But it makes such a difference to the end result. Why not adopt a critical path today? Just remember though that a new media critical path is for life, not just for Christmas.
