Saturday, May 28, 2011

Random project management techniques / tips / tools

Managing change requests
From time to time clients will change their mind i.e. every project you ever do – clients change their minds. I believe it’s important to be flexible to accommodate change; within reason. It is the within reason part which needs considering. You should make it clear that a project has a change request process. A few tweaks here and there can normally be absorbed without major impact to budget. But what if they change their whole strategy at the eleventh hour? You need to have set expectations that if they do this there is a cost attached. If templates are built already and they change the whole structure you should always go back to earlier phases, you’ll need to re-do the UX, re-do design – otherwise the changes they’ve asked for may be introduced without forward-thinking and you could end up delivering something that doesn’t work. Not to mention contractors build to an agreed scope; if the client changes their mind and you ask the developer to rebuild something from scratch they are within their rights to charge you for the same work. You can either absorb this from your profit or pass the cost onto the client.


File structure
Using the same file structure anyone can pick up your project easily. My preferred structure is below:

 
Versioning
As a rule I always version sequentially, not by date – simply because windows/mac will sort the files so that the latest version appears last (it is easy to pick the wrong file when sorted by date).
Versioning can be quite rigid: http://en.wikipedia.org/wiki/Software_versioning
But generally I simply go
  • Version 0_1 – first draft
  • Version 0_2 – second – and so on
  • Version 1_0 – first release to client
A minor update goes up by .1, a moderate update by .5, and a large update by a whole 1.0, e.g. if a document is rewritten from 4.0 then the next will be 5.0. If I change a bit 4.5, and if all I do is change a few typos 4.1. Simples.

Launching a site
I would always say it is never  a good idea to launch a site on a Friday or after 15:00 any day. If you put something live you want to have time to respond to any bugs that may have been missed or rise from the upload process. Particularly on Fridays where a bug could remain over the whole weekend.
Always make sure you give the site a final test when it is launched. 

Ensure you haven’t missed anything basic and yet easily forgotten, have you set up a favicon, analytics, etc, have you checked accessibility – e.g. all alt-tags set up on images, metadata, etc?

Testing a site
The site should pass a minimum testing standard of YUI A-Grade browser support -

Sometimes it makes sense to write a test plan depending on the scale of the project. If you've an efficient mind just using common sense on smaller projects can work too.

Many issues that might come up in testing can be avoided with at the requirements gathering stage e.g. don’t propose using Flash if you want it to work on a mobile, build the site accessibly and it will work across most browsers. 

To keep abreast of the latest trends (e.g. should I test in IE6, what screen resolution should I use, etc) take a look at: http://www.w3schools.com/browsers/

Fonts
Want to use a corporate font that isn’t web-safe? You can using image replacement techniques such as Cufon or Sifr. You don’t need to know much about this, just that it’s doable. This means a font, such as the National Trust font, can be used and generated on the fly on a website for titles and headers – e.g. the menu. Don’t use it for body font, sorry – it has to be websafe fonts in this instance – Cufon is great used sparingly but if you use it to replace body-copy it will make huge server demands.

What not to use
Flash – is never suitable for a menu system. It doesn’t work on mobiles. Some users don’t even have Flash. It’s suitable for games and banner adverts – and in the case of the latter ALWAYS have a non-flash alternative. Instead of Flash look for alternatives e.g. explore using JavaScript, CSS3 and HTML5. 

Bespoke video players
– You can charge the client money to build a video player (which is costly to get it working properly) and then an ongoing hosting fee as streaming video puts demand on the server and bandwidth. Alternatively, spend the money elsewhere and host it with embedded Vimeo or YouTube.

Bug Tracking
Bug tracking software, when properly embraced, is one of the most useful tools you’ll use on a project.
It allows you to:
  • Create a ticket and assign it to a developer.
  • Prioritise the order – showstoppers to nice to haves.
  • The developer can do the work and assign back to you with a notification.
  • Statuses help you track what needs to be done, e.g. “New bug, needs testing, closed, reopened, with client for review”
  • Will keep a single audit trail of the lifecycle of a bug – this helps you keep everything ordered so that bug, the one the client spotted, the one that is really frustrating them, never gets lost in your inbox.


Risk Management
When you start a project, and on an ongoing basis, it is worth identifying risks. You can’t predict them all but risk management is an essential part of project management. If you think about risks at the start you can help prevent or plan for them. Here are some commong ones:
  • Going over budget - which is why we plan our projects and agree a scope up front.
  • Choice of technology – are you using or trying something never tried before. If so your time estimates may be massively out – plan contingency.
  • Too many stakeholders – If you have too many stakeholders internally or externally you can end up in the situation of too many chefs spoiling the brew. Identify who really needs to be involved and make sure only they are involved in sign off.
  • Holidays – clients, contractors, yourself – again project planning.
  • Forgetting the basics – build a checklist, have I set up hosting, analytics, thought about accessibility, etc – even better build the checklist into your project plan.
  • Bugs and amends – always plan for things to go wrong, plan for at least one iteration of every deliverable, use bug tracking, prioritise the work to avoid going out of budget. Also, clear briefs mean more will be right first time. 
 

Do these approaches work for websites only?
No – they will work for all digital projects, everything from a basic HTML email or mobile app to an extensive piece of software development.



No comments: