At Bam Creative, whenever we start a project, we use a set of processes or standards that we’ve created internally over the last few years as a measure of what we do with every project. It’s what I like to consider our Best Practice methodology. There are a number of drivers (you could even say beliefs) behind all of these processes or deliverables, but one that I would like to write about today, is the concept of succession planning.
No, I’m not talking about your clients retiring, I mean the project or the website retiring from you. Let’s face it; clients don’t stick with you forever, and not all websites last for life.
Now, there are a number of reasons why your code or design may end up with another web person at some point. It could be that:
- The client has moved to another supplier
- The client has brought the website internally
- The project is in the hands of one of your co-workers
- You’ve left the company where you originally built the site
No matter what the reason, I believe that we should all be considering the inevitable when creating any new website or web application. We should be ensuring that any process of moving the website away from ourselves should be as smooth as possible, and that the client has been given the best succession planning up front, not as an after thought.
Our clients pay us to provide them the best design, code, advice and consulting as possible. They want us to consider their best interests all of the time. I like to think we need to be fairly unbiased and putting ourselves in their shoes as much as possible too.
OK, so a few practical examples?
Well, code commenting is an example of what I’d call succession planning – we’re commenting the code well so another developer in the future can look at the code and make heads or tails of it without spending half a day scratching their heads.
Using industry standard tools and languages where possible – no matter if you’re a Microsoft junkie or open source zealot, using some weird ‘never heard of, outside of [insert tiny country name here]’ software package, and encrypting it with some other odd script is probably not ideal for the client.
Logical file structure and path naming is great succession planning in action – an example is all of our common files, such as CSS and Javascript code, live in a sub directory called ‘common’. All of our image files are stored in a directory called ‘art’. Even if the new supplier doesn’t use the same structure, they are going to be able to work with this one within minutes.
Logical file names are also very important – there’s nothing like inheriting someone else’s work, and finding image files named image372.jpg, w_09_on.gif or my favourite, untitled4.jpg, to cause some grief. Perhaps companyname_logo.jpg or menu_aboutus_off.gif would have worked so much easier?
Another form of succession planning is being transparent about what the client does and does not own, and what the impact is of this situation. For example, you may have software that you license, and do not sell outright. It should be made clear during the sales process that although the client is welcome to use the software, they cannot take it elsewhere.
I guess in just about all of these points, we’ve thought about what is best for the client, not ourselves. It’s easy to make a website or web application so convoluted and mysterious that the client HAS to return to you every time for any simple fix or all of the maintenance, but is that what you’d want your suppliers to do to you?
Photo: Cashews and Bok Choy.
Entrepreneur, 