Very often when people talk about the politics in an organisation and how it has an impact on decisions, what they really mean is how stakeholders exert their power, influence and interests over decisions. Now, decisions often mean decisions relating to specific projects; and that can mean iMedia projects too. This influence is described in many ways: movers and shakers is one we've come across that made us smile, for example. We have to remember that these stakeholders can be internal as well as external.
If you need some refreshing on the general principles of stakeholder analysis and management it's covered in our book, Managing Interactive Media, Chapter 4. Rachel Thompson covers the basics too in Mind Tools, Stakeholder Management.
But as with so many strategies, it isn't knowing about them that makes the difference, it's applying them correctly in a project. That's the hard part.
We've come across a couple of applications of the stakeholder concept recently that give food for thought. Jesse Speak uses it strongly in web projects right from the brief writing. Take a look at his How to write a great project brief (27.6.2012), where he uses it to home in on exactly what business problems need tackling, and refining the web solutions to these as the basis for web developments. (Loud applause, Jesse!)
Then, Sam Barnes' Web Project Manager, Questions to Ask Web Project Managers (July 2012) uses it to recognise barriers to change exhibited by clients to assess if Agile or Waterfall techniques might provoke difficult reactions in projects, and might go with Waterfall as the most risk adverse. Now there's experience for you! Sam, quite rightly, gets great feedback on his common sense advice: meaning nascent intelligence. DO WATCH THE VIDEO – SOoooo FUNNY.
Friday, 27 July 2012
Friday, 20 July 2012
Website and iMedia Localization Research Update
iMedia Designers are much more aware now of the importance of localization of their interactive products to suit the global electronic market. Localization is the adaptation of an application to suit a culture other than that of the native source. This doesn’t just mean translating the language because a culture can affect the site’s intent, colour, layout, interaction, and graphics ... among other factors.
Let’s focus on this intent of the site.
This relates to the business purpose for the site and will affect how localization is carried out, because different cultures have different ways of realising the business intent. This becomes crucial, of course, for any interactive site that is retail-based, but also has implications for any business intent such as informing, branding, positioning, launching for consumers; but then there is intent for business-to-business sites as well. Here intent relates to how a culture has expectations about the way things are done. Because of the better understanding of localization issues now, it is more common for local designers, programmers and information architects to be involved in localising sites. This might mean that because some countries lag behind in the electronic experience, the local solution might appear at odds with the parent application which might be more mature in electronic experience terms. Definitely food for thought here as it is a bit counter-intuitive but understandable.
Why localize?
London Translation has a short set of bullet points that make interesting reading – needs updating though. But their stats - like customers are four times more likely to purchase something from a site in their own language and customers stay twice as long on sites using their language – make strong points.
Global multinational companies appear to suffer with localization at a different level according to Forrester research, The Right Way to Globalise your Interactive Marketing Programs, Nate Elliott (Dec 2011)
Here, the research suggests that there is conflict between the global marketing team and local marketing teams over the one-size-fits-all approach that the global team touts for financial reasons. Elliott et al say there is another way to localize without it costing too much. Peter O’Neill’s research, also from Forrester, backs this up: Use Field Marketing to Align Marketing Content with International Customer Needs, (March 2012).
In their research paper, A Framework for Designing Usable Localised Business Websites (Vol.2010 IBIMA publishing), Ali Al-Badi and Pam Mayhew recommend that designers apply the following guidelines:
Let’s focus on this intent of the site.
This relates to the business purpose for the site and will affect how localization is carried out, because different cultures have different ways of realising the business intent. This becomes crucial, of course, for any interactive site that is retail-based, but also has implications for any business intent such as informing, branding, positioning, launching for consumers; but then there is intent for business-to-business sites as well. Here intent relates to how a culture has expectations about the way things are done. Because of the better understanding of localization issues now, it is more common for local designers, programmers and information architects to be involved in localising sites. This might mean that because some countries lag behind in the electronic experience, the local solution might appear at odds with the parent application which might be more mature in electronic experience terms. Definitely food for thought here as it is a bit counter-intuitive but understandable.
Why localize?
London Translation has a short set of bullet points that make interesting reading – needs updating though. But their stats - like customers are four times more likely to purchase something from a site in their own language and customers stay twice as long on sites using their language – make strong points.
Global multinational companies appear to suffer with localization at a different level according to Forrester research, The Right Way to Globalise your Interactive Marketing Programs, Nate Elliott (Dec 2011)
Here, the research suggests that there is conflict between the global marketing team and local marketing teams over the one-size-fits-all approach that the global team touts for financial reasons. Elliott et al say there is another way to localize without it costing too much. Peter O’Neill’s research, also from Forrester, backs this up: Use Field Marketing to Align Marketing Content with International Customer Needs, (March 2012).
In their research paper, A Framework for Designing Usable Localised Business Websites (Vol.2010 IBIMA publishing), Ali Al-Badi and Pam Mayhew recommend that designers apply the following guidelines:
- Know the target audience – use the framework they recommend otherwise you risk intimidating and offending your potential customers/clients
- Usability/Accessibility Tools and Guidelines need to be used
- Culturally Usable Websites are very different from usable cross-cultural websites. The overt and covert cultural factors need to be controlled
- Target Users Involvement – in all design phases helps create a website that suits them
- Design Consistency – still vital for culturally adapted sites
- Website Periodic Maintenance – to keep site current and culturally up-to-date
Thursday, 12 July 2012
Division of skill-sets – good or bad?
As iMedia has matured, there has been a splintering of skill-sets into specialisms. We've touched on this before and have, overall, been positive about it. So we've seen the rise of SEO and then companies specialising in this; similarly with testing, usability, information architecture, back-end and front-end, let alone across sectors like retail, business-to-business, information dissemination, social media, mobile communication.
The approach that one person can span several roles has changed because each piece of the interactive jigsaw now demands more skills at a deeper level than they used to. But someone has to have the solid overview of how these interconnect because a change in one part has a ripple effect on the others. For example, recently we've been stuck in the middle of the clients (users), the front-end needs and the back-end realities of the system configuration. Bet this sounds familiar to you.
It is increasingly problematic since the intelligence used to be shared within one company, or even one person, but now the front-end and back-end can often be different companies. In this case, getting the intelligence about how to resolve the needs into a working solution, that doesn’t crash the system, takes a lot longer. Each company fights its corner using different language. Often this arises on the updates side of applications as people move on from companies and the nascent intelligence is lost.
The project manager generally fulfils the role of mediator during the course of the application development but who does afterwards? Something to think about.
If you want a definition of front-end and back-end and the differences, Ian Peters-Campbell's blog gives a nice workable breakdown. And if you aren't convinced yet that this can be a problem area worth thinking about, these links might help change your mind.
Skillset defines it as an area of concern in its appraisal of skills in the iMedia industry. The ‘hybrid’ and ‘cross-disciplinary’ skills and a balance of creative and logical thinking are the backbone for the industry, as they say, but they are well aware that: "An absence of cross-disciplinary awareness and understanding of role context is particularly significant." See: What are the main skills issues and concerns?.
A more fun way of describing the potential conflict is found at: What is the difference between web design and front-end development? from Pete Markiewicz. This relates to internal dissension rather than across specialist companies. "Splitting web design and front-end development in a team often leads to nasty conflicts between snobby designers and angry codebeasts, resulting in lost project time. It's best that each is able to understand the other's work."
So if web and front-end cause grief, what about the back-end? And what about the back end and any databases? I think we'll find this splitting further as time goes on.
The approach that one person can span several roles has changed because each piece of the interactive jigsaw now demands more skills at a deeper level than they used to. But someone has to have the solid overview of how these interconnect because a change in one part has a ripple effect on the others. For example, recently we've been stuck in the middle of the clients (users), the front-end needs and the back-end realities of the system configuration. Bet this sounds familiar to you.
It is increasingly problematic since the intelligence used to be shared within one company, or even one person, but now the front-end and back-end can often be different companies. In this case, getting the intelligence about how to resolve the needs into a working solution, that doesn’t crash the system, takes a lot longer. Each company fights its corner using different language. Often this arises on the updates side of applications as people move on from companies and the nascent intelligence is lost.
The project manager generally fulfils the role of mediator during the course of the application development but who does afterwards? Something to think about.
If you want a definition of front-end and back-end and the differences, Ian Peters-Campbell's blog gives a nice workable breakdown. And if you aren't convinced yet that this can be a problem area worth thinking about, these links might help change your mind.
Skillset defines it as an area of concern in its appraisal of skills in the iMedia industry. The ‘hybrid’ and ‘cross-disciplinary’ skills and a balance of creative and logical thinking are the backbone for the industry, as they say, but they are well aware that: "An absence of cross-disciplinary awareness and understanding of role context is particularly significant." See: What are the main skills issues and concerns?.
A more fun way of describing the potential conflict is found at: What is the difference between web design and front-end development? from Pete Markiewicz. This relates to internal dissension rather than across specialist companies. "Splitting web design and front-end development in a team often leads to nasty conflicts between snobby designers and angry codebeasts, resulting in lost project time. It's best that each is able to understand the other's work."
So if web and front-end cause grief, what about the back-end? And what about the back end and any databases? I think we'll find this splitting further as time goes on.
Friday, 6 July 2012
When turning it off and on again doesn't work
It has always been one of my nightmare scenarios: a software update that goes wrong. The average web site now has so many dependencies ... the OS, Apache, PHP, MySQL, JQuery, Drupal ... to name but a few of the pieces of software, many open source, that need occasional updating on your site ... that it is difficult to keep up. Therefore I have every sympathy with the banks whose systems failed to recover from a maintenance update the other week. It could happen to anyone.
I realise that the bank problem was real heavy-lifting IT, and the interactive media world rarely strays into that kind of territory. But occasionally it will.
So what do you do when it happens to you, and especially when you're the code-monkey who pushed the metaphorical or even literal button to kick-start the mayhem?
According to the brief biog at the foot of his pages, Register writer Dominic Connor 'used to boss around gangs of quants, developers and sysadmins before moving to a life of headhunting in the City spiced up with consultancy' and 'Before becoming a City headhunter, ... was a mildly competent head of IT as well as developer for various banks. RBS still run some decade old code of his, he wishes them good luck with it.'
His two pieces on the subject published on the Register last week make for interesting reading, especially if you manage an IT team or are part of it. I recommend them:
Do you work in IT at RBS? Or at the next place to get hit ...? (June 29) How to survive a crisis.
So, that vast IT disaster you may have caused? Come in, sit down (July 3rd) Welcome to the world of forensic interviewing.
I realise that the bank problem was real heavy-lifting IT, and the interactive media world rarely strays into that kind of territory. But occasionally it will.
So what do you do when it happens to you, and especially when you're the code-monkey who pushed the metaphorical or even literal button to kick-start the mayhem?
According to the brief biog at the foot of his pages, Register writer Dominic Connor 'used to boss around gangs of quants, developers and sysadmins before moving to a life of headhunting in the City spiced up with consultancy' and 'Before becoming a City headhunter, ... was a mildly competent head of IT as well as developer for various banks. RBS still run some decade old code of his, he wishes them good luck with it.'
His two pieces on the subject published on the Register last week make for interesting reading, especially if you manage an IT team or are part of it. I recommend them:
Do you work in IT at RBS? Or at the next place to get hit ...? (June 29) How to survive a crisis.
So, that vast IT disaster you may have caused? Come in, sit down (July 3rd) Welcome to the world of forensic interviewing.
Subscribe to:
Posts (Atom)
Posts
