This article outlines the "Waterfall" approach I have generally used in project management and offers techniques and tips to use to help make life easier and to solve some common problems – the end goal is always efficient, profitable, project management that delivers great products we can be proud of.
Waterfall approach to Project Management
“In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a "gate" that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has been a source of criticism by supporters of other more "flexible" models.” - http://en.wikipedia.org/wiki/Software_development_process#Waterfall_model.
Concept
Early on you will want to define the concept; particularly for a campaign. This can inform the site requirements, the architecture, and the design. A project should start with a clear specification of what you aim to achieve. A project scope will define what you are going to do and relate this to your budget. It will identify questions you might have – it maybe that you need to build in contingency to plan for unknowns. If you specify what you are going to do at the start then the clients expectations are set and managed from the offset; if they try to change the scope further down the line (eroding margin) you can refer to this original agreement.
Don’t forget to set up hosting and Google Analytics and purchase URL’s early on. You will also want to agree the cost arrangement and possibly an ongoing maintenance agreement for post-launch.
At this stage you should define technical standards – e.g. The site will meet AA accessibility standards and be tested to Grade-A browser support.Always provide context to any deliverable you hand over – make sure they understand the rationale behind everything you give them.
What if the client just can’t decide what they want?
Sometimes a client will want more things in their project than their budget will allow. There is a solution – sit down with them and create a requirements list. List out every feature in excel and put resource times and costs against it (but keep in mind sometimes you’ll get an economy of scale by doing some work together). Then get the client to prioritise it using the MoSCoW method:
- M - MUST have this.
- S - SHOULD have this if at all possible.
- C - COULD have this if it does not affect anything else.
- W - WON'T have this time but WOULD like in the future. Alternatively WANT.
Help guide them to work out what is really important and what they don’t really do based on their objectives and user requirements. If everything is a MUST have then they will realise they need more budget – but generally they’ll realise that some things just aren’t that important this time around.
System and Architecture Development
Before you start to design the look you should consider the structure of your site from the USERS PERSPECTIVE. Produce a sitemap to tell you what pages you will need and produce wireframes to define the structure of each page.For an IT company based in Berkshire these two personas, typical of your users (do your research into what’s typical; and use intuition), require different solutions to engage them. Geoff has a family; he’s unlikely to relocate, but he already lives in Berkshire. He’s not actively looking but would consider a good job if it came along. A tailored newsletter would help Geoff – you’d have to get him to sign up, but if the newsletter alerted him to jobs relevant and near him Geoff would be happy and may just apply. David is actively searching; good SEO will help him find the IT company in Berkshire. He’s young and not too far, he may relocate – when he hits the site he needs to know that it’s relevant to him and nearby. This will influence your homepage design. Writing personas helps you think about the user and in turn the user experience; they can also help your client who will often think about what THEY want not what their users want until they see a persona – so get the client to sign off on the personas.
Often all the above is produced from experience and intuition. If unsure you can try a few methods such as user testing and card sorts to help inform your UX with solid stats. The bigger the project, or the more important that you get it right, the more important it becomes to build your project on researched foundations over intuition. Concepts can be tested cheaply – investigate http://verifyapp.com/ (I’ve not used this service before – but it sounds interesting!)
Remember some golden rules in UX
- The homepage is not guaranteed to be the first page a user sees.
- People will NOT have fun “discovering” content – if things are hidden people won’t find them. Clear navigation – always!
- Avoid dead ends – use related links, drivers, on every page.
- Include social media elements to share content easily.
- The shortest pathway to the content you want is the best pathway.
- Don’t get crazy; there is a good reason why many sites are essentially the same. People scan the top left first – it’s fact; your most important content should be here. Your search should be in the top right, the logo top left – break the mould and you may find you confuse people. Breadcrumbs go at the top, not the bottom.
- Ignore me – do your own research; trends change, new research comes out – be cutting edge!
Design
If a concept has not yet been defined it should be. You may want to use moodboards to set a tone for the site.
Are there brand guidelines that must be accounted for?
A good web designer can work with wireframes and understands that what they are creating doesn’t need to fit on an A4 page. Websites are dynamic, so too should be the person designing it. They need to consider both why the architect has defined things the way they have and also what the developer will do with it next. They need to consider accessibility – it’s no good to design a box that would be impossible to build properly in HTML, e.g. because it uses texturing that cannot wrap. This really requires understanding of how websites are built.
Ideally you should provide the client with two design routes to pick from. These should be presented in person; never sent by e-mail “What do you think?” but instead in person or over the phone so you can say “This is why we have approached this the way we have…” Also, present it as “Do you think this meets your users expectations”. If you give them a choice of two they will be inclined to choose one; they may ask to choose a little bit from one and a little bit from another. This is normally a bad idea, if they don’t share common elements it’s because they don’t work together. Ideally try to manage it so they pick a design and have only a few tweaks. The more involved they feel the easier the sign off process will be – saying that, don’t be afraid to defend your corner as the digital expert.
Designs should be optimised for a minimum of 1024 wide. Nobody uses 800x600 anymore. Keep in mind that browsers have scroll bars, so while the screen is 1024 wide, the web design should be no more than 974 - 984 wide. We should all be using grids in layouts, 960 is a great number as it’s slightly smaller than full width, and it’s divisible by 3, 4, 5, 6, 8, 10, 12, 15, and 16 (imagine the grid possibilities).
Do not be afraid of scrolling. Remember the fold is not a line, it is a region. Do not be obsessed with everything being above the fold – just design in a way where the most important content is above it, and the user knows they can scroll.
Before going to client the designer should have checked the design for accessibility including insuring the colours validate. As a project manager you’ll want to make sure this has happened or check this yourself.
Make sure web-safe fonts have been used or you have the technical scope to use image replacement like Cufon on non-websafe fonts.
A developer should always review a design before it goes to the client – there is no point in exciting the client with something that cannot be delivered.
[NB: Involving the developer in design almost seems contrary to hardcore waterfall approaches. While phases are distinct they should also be a team effort. The UX leads UX, the designer leads design – but other disciplines should be involved to educate and inform the deliverable. Do not think of each phase gateway as a wall – the design should not be flung over the wall for the developer to pick up!]
Programming
The site developers will include the front end developer (working in HTML and CSS) and the back-end developer (working in e.g. PHP, but they could be .NET, ASP). They will deliver the site to the documentation defined at the start (A WTS if one was written).
The front end developer shouldn’t need to alter interface designs to make them work. This should have been thought of at the design stage by the designer.
The back-end developer should understand fully how the site works from designs, wireframes, sitemap, content map – ideally all explained clearly in a single Technical Solutions document.
System Integration
When the programming is done the finished templates need to be brought together with the back-end system and any third party software.
This is also the time that final content should ideally be ready to be added before testing.
System Test
Before the client sees the site internal testing should be carried out. The site should meet the accessibility standard specified at the requirements stage (normally AA) and be cross-browser compatible (meet A-Grade browser support, which now includes mobile)
Acceptance
At the end of every phase the client should review and sign off on content before moving to the next phase.
The acceptance phase is the clients chance to review that the project has been delivered to:
- The agreed specification
- The architecture they signed off on
- The designs they were shown
- Includes the content they have signed off on
- The technical standard they expect (the expectation you set for them)
Normally I suggest a user acceptance testing period (UAT) where the client reviews the site on a demo environment and checks that it is up to scratch. If not they provide a prioritized list of bugs and changes. Prioritised because during scoping you will have defined the amount of budget proportioned to amends. If you only have 2 days and they’ve asked for 10 days worth of amends you are giving them 8 days of time for free. The project manager may want re-organise the priorities, which should be discussed with the client. They might have prioritised something trivial over a bug fix that is a true show-stopper.
When you and the client are satisfied the project has been delivered to spec it can go live (a final test) and then you can pat yourselves on the back!
Maintenance
It is a fact that in software development you will have bugs – a good client should be able to understand this. I am not saying a site should launch with show stopping errors; but if you dig deep enough you’ll find niggles. Even if on delivery the website seems perfect, browsers and operating systems will change, tweaks are made to the site and/or something was missed.
It is a fact that in software development you will have bugs – a good client should be able to understand this. I am not saying a site should launch with show stopping errors; but if you dig deep enough you’ll find niggles. Even if on delivery the website seems perfect, browsers and operating systems will change, tweaks are made to the site and/or something was missed.
When the client has completed the acceptance phase they have accepted the agreed project is done. There is a balance between good account management where you fix some post-launch bugs for free and good project management where you avoid spending the next year giving them freebies.
For a large project an ongoing paid for Service Level Agreement (SLA) will allow for regular maintenance, bug fixing and updates. Smaller projects may need less frequent updating and warrant charged bespoke maintenance only.
New functionality should ALWAYS be dealt with as a mini-project, not a bolt-on to the SLA – this means that the new functionality is properly thought out. If it’s just bolted on and added improperly it can and often does cause problems in the site elsewhere and may cost you more than you bargained for.
Don’t forget to keep track of agreed hosting and stats monitoring agreements.
3 comments:
Wow, fantastic weblog structure! How long have you been blogging for?
you made running a blog glance easy. The entire look of your
website is excellent, as well as the content!
My website killing games
Write more, thats all I have to say. Literally, it seems as though
you relied on the video to make your point. You clearly know what youre talking about,
why waste your intelligence on just posting videos to
your weblog when you could be giving us something informative
to read?
my blog; live girls
Magnificent goods from you, man. I've understand your stuff previous to and you're just too
magnificent. I actually like what you've acquired here, certainly like what you are stating and the way in which you say it. You make it enjoyable and you still take care of to keep it smart. I can not wait to read far more from you. This is really a terrific web site.
Feel free to surf to my web blog :: Homepage des Autors besuchen (http://www.sceg.ch/sceg08/index.php?option=com_easygb&Itemid=43)
Post a Comment