Project scoping for an interactive media project is such a minefield. There are so many ways of approaching this sensitive area that trying to be definitive is asking for trouble. But, scoping a project can only be avoided at huge cost so it has to be done. Now exactly how your company decides to do this, and why, are the crucial questions. Then, do you think they are getting it right, or, could the process be improved – helping you along the way?
We were reminded about scoping recently when we had to complete a 16 page Law Society questionnaire when we were selling our house. As we hadn’t sold for over 15 years, this form was pretty daunting. And, it is a ‘live’ form that grows a few times a year every year! For those lucky ones that are staying put, this form covers the following areas in varying detail: Boundaries, Disputes and Complaints, Notices and Proposals, Alterations, planning and building control, Guarantees and Warranties, Insurance, Environmental Matters, Rights and informal arrangements, Parking, Other charges, Occupiers, Services, Connections to utilities and services, and Transaction information.
This document forms part of the contract of sale, just as a scoping document forms part of the service contract agreement between you and your client. It is highly detailed because the solicitors have to address all aspects in order to act in your best interests (and limit their liability in any disputes arising over the sale). Did you know, for example, that there’s a question about Japanese Knotweed and whether you’ve had the house tested for Radon? Because both of these have featured in legal dispute cases, the questions have been added in. When legal cases are undertaken concerning houses, the law society monitors them and adds extra questions to their form according to the outcomes. So a centralised body does the monitoring and updating for lawyers – at a cost, we have to explain. In iMedia, we don’t have this luxury – yet.
Well, you can pay for scoping templates in iMedia such as found at econsultancy. £450 for Scope Statement for Web Projects or access some free, for example, Mashable’s Free Contract Templates . Will they help? This is the difficulty. Only you know what suits your market, your kind of clients and your way of working.
That’s why Kyle Racki’s approach seems to work. She’s pretty convinced that detailed scoping at the beginning of a project puts clients off. She prefers to try to sell her company and its capabilities first – avoiding time-wasters upfront, we are compelled to point out. Then once she has the business she then drills down refining the detail as in a scoping sense, we believe. See Kyle’s, Getting Started Writing Business Proposals, at proposify 3 July 2014).
Dominic St-Pierre, Improve your Web Design Projects with a Good Project Scope (8 July 2014) at Six Revisions, lists eight key areas to cover: What type of website will I be building for you?, When do you need to have this website completed?, What is your budget for the project?, Who is the typical user of your website?, What goals do you want to achieve with this project?, What types of content will be used in this project?, Can you show me examples of websites you like and don’t like?, What’s the message you are trying to convey with your website. Dominic does a great job with tips for ‘Project Creep’. Nice graphic. He also does well to point out what he calls ‘Negative Scope’ or what you are not going to provide!
Matt Heron in How to write a scope doc for a web project (16 October 2013) at The Phuse reinforces that it depends on the questions you ask whether you cover the best options in scoping. He lists five main areas to cover: What’s the goal of the project?, What’s the scope of the project?, What are the deliverables?, What are the requirements?, Who is providing what? Who is responsible for what?
Only you can decide exactly what works for you. And you can’t become complacent. Just as the Law Society frequently updates their questionnaire by studying the equivalent of lessons learnt from the courts, you need to update your process for scoping a project according to your experiences.
Friday, 25 July 2014
Saturday, 19 July 2014
How do you know a successful project?
The answer lies in what your tests will show at the end of a project. This implies that you defined what was necessary to achieve at the beginning of the project, of course. In our Chapter 9 on testing and archiving, Managing Interactive Media: Project Management for Web and Digital Media, we summarise that there are three main areas of testing.
There doesn’t seem to be one way of describing the business needs of a project. You’ll come across such terms as ‘risk assessment’, ‘requirements’, ‘project specification’, and so on. But we’ve seen that clients are not so hot on defining their requirements, mainly because they don’t understand precisely what iMedia can do for their business. Worse, they may think they do and be clear on what they want even though you know that so much more might be achieved. This is the dilemma of working in an unstable, evolving field. This is why you can get round some of this confusion by asking what their general business needs are and then explaining how an iMedia project can serve these core business needs. Clients do know their business, but are quite often just not able to extrapolate what a combination of business and iMedia can offer. You can be the intermediaries.
Pete Tong in his blog for ayrmer (20 June 2014), makes it clear that lining up with business needs is key to success. This company expounds a ‘well-formed outcomes’ process. This means that you know enough from the beginning to define the outcomes you’ll achieve and ones that will satisfy the clients.
Duncan Haughey, Projectsmart, in Requirements Gathering 101, gives 10 rules for success and number 4 is ‘Ensure that requirements are specific, realistic and measurable’. Now, ‘ measurable’ means you can test for them and demonstrate achievement or not!
Obviously our emphasis on the user (Number 2 in paragraph 1) lines up with all the aspects of usability testing. (See other appropriate blogs here on Usability.) Then technically (Number 3 in paragraph 1), we’d all agree on the reliability and robustness criteria. (See other blogs here on Testing). So we’re not trying to define what tests you should carry out; it’s more of a reminder of the big picture for all projects. Are you addressing all these facets in ways that both you and your clients are satisfied with the results?
- The project meets the business needs of the clients.
- The project allows the user to access and complete relevant tasks.
- The project is robust and reliable.
There doesn’t seem to be one way of describing the business needs of a project. You’ll come across such terms as ‘risk assessment’, ‘requirements’, ‘project specification’, and so on. But we’ve seen that clients are not so hot on defining their requirements, mainly because they don’t understand precisely what iMedia can do for their business. Worse, they may think they do and be clear on what they want even though you know that so much more might be achieved. This is the dilemma of working in an unstable, evolving field. This is why you can get round some of this confusion by asking what their general business needs are and then explaining how an iMedia project can serve these core business needs. Clients do know their business, but are quite often just not able to extrapolate what a combination of business and iMedia can offer. You can be the intermediaries.
Pete Tong in his blog for ayrmer (20 June 2014), makes it clear that lining up with business needs is key to success. This company expounds a ‘well-formed outcomes’ process. This means that you know enough from the beginning to define the outcomes you’ll achieve and ones that will satisfy the clients.
Duncan Haughey, Projectsmart, in Requirements Gathering 101, gives 10 rules for success and number 4 is ‘Ensure that requirements are specific, realistic and measurable’. Now, ‘ measurable’ means you can test for them and demonstrate achievement or not!
Obviously our emphasis on the user (Number 2 in paragraph 1) lines up with all the aspects of usability testing. (See other appropriate blogs here on Usability.) Then technically (Number 3 in paragraph 1), we’d all agree on the reliability and robustness criteria. (See other blogs here on Testing). So we’re not trying to define what tests you should carry out; it’s more of a reminder of the big picture for all projects. Are you addressing all these facets in ways that both you and your clients are satisfied with the results?
Friday, 11 July 2014
What’s in a name?
It’s no secret that I love cross-cultural issues in iMedia. This probably stems from my origins in linguistics and English as a Foreign Language. So I was particularly intrigued in a detailed article about the challenges that asking someone to input their name can cause in data capture for an international (global?) audience. It is aimed more at web programmers and I’m amazed that so much of it makes sense to me as I’m no programmer. Furthermore, I see the article as a great piece of covert training for your iMedia clients. It’s perfect for explaining that those simple changes that clients suddenly ask for can be complex, and therefore expensive. They need to trust you to accept the vagaries of the costs of those seemingly small changes that crop up during a project. Trust in iMedia development is key to forming good client relationships. And we all want those.
What am I on about? Here are a few examples if you’re using data capture for names in any of your projects. If we are too rooted in our own culture then how does our name data capture work with cultures that traditionally use their last name first? Is the capture comfortable with hyphenated last names or even ‘von’ or ‘de’ (usually lower case) or the apostrophes in the shortened ‘de’, ‘d’’ or even ‘O’Neil’, and so on? How do we denominate the names used? Do we call them Christian or First name, Surname or Last Name, or something else entirely? How do we deal with nicknames or variations of names used instead of full names like ‘Dee’ for ‘Denise’ or ‘Joe-Joe’ for a child to differentiate from a father called ‘Joe’. Americans are used to using ‘Junior’, of course. And I haven’t mentioned non-Roman scripts yet!
Some cultures work with initials more than names. So in Hong Kong it is still common for Chinese to have a Chinese name but an Anglified equivalent where initials are common – like ‘D.A. Ho’. This all gets further complicated when the marketers want you to capture a name that the person wishes to be addressed by so they can send marketing mails. Some cultures change the form of address they use according to the person’s age or status and this is very important if you are trying to influence these people. Imagine, if you get the form of address wrong in the email, they are hardly going to be disposed to read the rest or be influenced by it! I can feel marketers quake if they haven’t taken this on board before.
If you expect me to give you the answers as to how to capture all the data and make it work for all your clients, I’m not! The article on the W3 web site is very detailed and comprehensive, but even so, it probably won’t cover all eventualities, I’m sure.
I had to come to terms with this type of problem when I created a database of first name origins. I quickly realised that I had to limit the data to mainly Anglo-European names and state this upfront. Otherwise, I wouldn’t have been able to complete this particular project at all. Name databases need constant monitoring and updating because fashions dictate new names appearing and even switches between male and female names: such as Ashley which is more often female now but has been male in previous decades. Variations in names in spelling alone makes the database vulnerable, and new spelling forms appear quickly because people want to personalise their name by making it slightly different. Just consider the spelling variations and nick names from ‘Ellen’: ‘Ella’, ‘Elle’, ‘Ellie’, ‘Nell’, ‘Nellie’, ’Elen’, ‘Elin’, ‘Elyn’, ‘Elon’, ‘Ellan’, ‘Ellin’, and ‘Ellon’. Yes, I’m sure I’ve missed some!
If you are Anglo European and have a first name (Americans often have Anglo-European origins) then check out the name origin at www.atsf.co.uk/iconnection/namesearch.php as it might surprise you. Do let me know if the database doesn’t cover your Anglo-European name and I’ll research and add it.
So, lots more to names and name databases than you imagined, I expect. Data fields can be minefields, so respect your programmers.
What am I on about? Here are a few examples if you’re using data capture for names in any of your projects. If we are too rooted in our own culture then how does our name data capture work with cultures that traditionally use their last name first? Is the capture comfortable with hyphenated last names or even ‘von’ or ‘de’ (usually lower case) or the apostrophes in the shortened ‘de’, ‘d’’ or even ‘O’Neil’, and so on? How do we denominate the names used? Do we call them Christian or First name, Surname or Last Name, or something else entirely? How do we deal with nicknames or variations of names used instead of full names like ‘Dee’ for ‘Denise’ or ‘Joe-Joe’ for a child to differentiate from a father called ‘Joe’. Americans are used to using ‘Junior’, of course. And I haven’t mentioned non-Roman scripts yet!
Some cultures work with initials more than names. So in Hong Kong it is still common for Chinese to have a Chinese name but an Anglified equivalent where initials are common – like ‘D.A. Ho’. This all gets further complicated when the marketers want you to capture a name that the person wishes to be addressed by so they can send marketing mails. Some cultures change the form of address they use according to the person’s age or status and this is very important if you are trying to influence these people. Imagine, if you get the form of address wrong in the email, they are hardly going to be disposed to read the rest or be influenced by it! I can feel marketers quake if they haven’t taken this on board before.
If you expect me to give you the answers as to how to capture all the data and make it work for all your clients, I’m not! The article on the W3 web site is very detailed and comprehensive, but even so, it probably won’t cover all eventualities, I’m sure.
I had to come to terms with this type of problem when I created a database of first name origins. I quickly realised that I had to limit the data to mainly Anglo-European names and state this upfront. Otherwise, I wouldn’t have been able to complete this particular project at all. Name databases need constant monitoring and updating because fashions dictate new names appearing and even switches between male and female names: such as Ashley which is more often female now but has been male in previous decades. Variations in names in spelling alone makes the database vulnerable, and new spelling forms appear quickly because people want to personalise their name by making it slightly different. Just consider the spelling variations and nick names from ‘Ellen’: ‘Ella’, ‘Elle’, ‘Ellie’, ‘Nell’, ‘Nellie’, ’Elen’, ‘Elin’, ‘Elyn’, ‘Elon’, ‘Ellan’, ‘Ellin’, and ‘Ellon’. Yes, I’m sure I’ve missed some!
If you are Anglo European and have a first name (Americans often have Anglo-European origins) then check out the name origin at www.atsf.co.uk/iconnection/namesearch.php as it might surprise you. Do let me know if the database doesn’t cover your Anglo-European name and I’ll research and add it.
So, lots more to names and name databases than you imagined, I expect. Data fields can be minefields, so respect your programmers.
Thursday, 3 July 2014
What do you actually do?
I have a terrible time with forms that ask me what my occupation is. I do a lot of things that (to a greater or lesser extent) earn me some money but I usually say that I'm an interactive media and database consultant. That works apart from when the form is full of drop-down menus and I have to fit it into someone else's idea of an employment taxonomy.
According to Richard Branson; when asked, Google's Larry Page said "I help people find things". Good description of the original core business there while not being particularly all-encompassing: but certainly short and very sweet. Richard didn't say what he does, probably because the list is too long, but he did ask for user comments. The first one on the page is one I particularly like: photographer Conni Freestone simply wrote "I capture memories & preserve moments". Lovely.
That got me thinking about job descriptions. What lies behind that shorthand title. The UK government, of course, has a standard list. They're very interesting to read, and well thought out. I looked at the one for web developer (a Word or ODT file).
There are skills and requirements, a brief raison d'être for the post and job responsibilities. This last list is particularly interesting because it contains these two items alongside the kind of competencies you'd expect for such a job:
Another set of sample job descriptions comes from Kate Matsudaira on the Dice web site (June 19 2014). These are more conversational than the British ones but no less interesting. The key, as Kate points out, is that "A great description can not only help boost the quantity and quality of your applicant pool, but attract candidates that are a good cultural fit for your organization.".
Similar advice comes from Business 2 Community (June 24 2014). They agree with Kate about including the company's culture in your thinking but also point out that you must "Use the most searchable job titles that the right candidates are most likely to search for". In other words, considering what the role is known as within the industry. I would add 'outside' as well - might as well cover all the bases - but if it's experienced people you're after then the insider name will be important. There is a slight risk, especially with new kinds of job, that the title might not have settled down, so do your research to find out. Ideally you should be able to ask your existing staff, especially if they have been "involved in the wider web development community".
So we come, briefly, to the Register ... a regular haunt of mine. They're looking for a sub-editor (July 3 2014), noting that "this is not a job for those with overly delicate sensibilities" but that the applicant should have "an affinity for the noble art of tabloid-style headline writing". That's my boy!
And finally ... what is the best job description? I once read a suggestion (I think by C Northcote Parkinson ... he of Parkinson's law) that the ideal job advertisement should only attract one applicant, and that person would be the ideal person for the job. This was illustrated by a sample advertisement for a security guard (or thereabouts). After several requirements it ended with words to the effect that candidates should attend for interview at a certain gym at 3 o'clock in the morning ... and bring their own boxing gloves.
According to Richard Branson; when asked, Google's Larry Page said "I help people find things". Good description of the original core business there while not being particularly all-encompassing: but certainly short and very sweet. Richard didn't say what he does, probably because the list is too long, but he did ask for user comments. The first one on the page is one I particularly like: photographer Conni Freestone simply wrote "I capture memories & preserve moments". Lovely.
That got me thinking about job descriptions. What lies behind that shorthand title. The UK government, of course, has a standard list. They're very interesting to read, and well thought out. I looked at the one for web developer (a Word or ODT file).
There are skills and requirements, a brief raison d'être for the post and job responsibilities. This last list is particularly interesting because it contains these two items alongside the kind of competencies you'd expect for such a job:
- Being involved in the wider web development community, identifying good practices we can adopt and sharing our experiences
- Sharing knowledge of tools and techniques with the wider team, both developers and non-developers
Another set of sample job descriptions comes from Kate Matsudaira on the Dice web site (June 19 2014). These are more conversational than the British ones but no less interesting. The key, as Kate points out, is that "A great description can not only help boost the quantity and quality of your applicant pool, but attract candidates that are a good cultural fit for your organization.".
Similar advice comes from Business 2 Community (June 24 2014). They agree with Kate about including the company's culture in your thinking but also point out that you must "Use the most searchable job titles that the right candidates are most likely to search for". In other words, considering what the role is known as within the industry. I would add 'outside' as well - might as well cover all the bases - but if it's experienced people you're after then the insider name will be important. There is a slight risk, especially with new kinds of job, that the title might not have settled down, so do your research to find out. Ideally you should be able to ask your existing staff, especially if they have been "involved in the wider web development community".
So we come, briefly, to the Register ... a regular haunt of mine. They're looking for a sub-editor (July 3 2014), noting that "this is not a job for those with overly delicate sensibilities" but that the applicant should have "an affinity for the noble art of tabloid-style headline writing". That's my boy!
And finally ... what is the best job description? I once read a suggestion (I think by C Northcote Parkinson ... he of Parkinson's law) that the ideal job advertisement should only attract one applicant, and that person would be the ideal person for the job. This was illustrated by a sample advertisement for a security guard (or thereabouts). After several requirements it ended with words to the effect that candidates should attend for interview at a certain gym at 3 o'clock in the morning ... and bring their own boxing gloves.
Subscribe to:
Posts (Atom)
Posts
