Friday, 19 September 2014

Lolcats and the lexicon of being online

When we put together the various editions of our book, one of the things we included was a glossary. Abbreviations, acronyms and slang terms are a part of any subject and can often be used by specialists as a shorthand. Unfortunately, if you don't know the shorthand then this can make it impossible to understand a subject that you actually may be able to follow were you to speak the language. Hence glossaries.

Our glossary is getting a little elderly now, although it should still be useful.

An altogether more up-to-date and wide-ranging glossary was recently published by the Guardian, modestly called The ultimate internet glossary. It goes from 4chan to Zoopla (or is it Zynga) and includes lots of cats.

What is it about cats? It has been jokingly suggested that problems with the internet could be fixed if they took all the cats off it. This lets me mention Henri le chat noir and, en passant. (Wasn't Lolcats a song by the Cure? That's a QTWTAIN by the way.)

As with all things in life you can Google glossaries. They range from the technical (from and Matisse Enzer) to the basic but undoubtedly useful (such as this glossary for 'older adults' from the American National Institute on Ageing).

If you feel like contributing to the daunting task of keeping such a thing up to date then there is a Wikipedia glossary, however at the time of writing it is somewhat poor IMHO and in need of TLC.


Friday, 12 September 2014

Pointing the finger – blame and risks in digital project management

There are many aspects during a digital project that do not go according to plan; even if you had one. Project Management is about control but, particularly in digital projects, your clients and your team can often seem to conspire against the progress of the project. Your management, on the other hand, are meant to be there supporting you. If this isn’t the case, you’re in trouble. Are you in a company that has an attitude of ‘sacrificial accountability’?

It is common that if and when things go wrong, someone takes the blame and resigns from his/her post. I think that most people view this as acceptable when it is clear who has had the overall accountability during the time that the problems brewed and blew up. But looking for the sacrificial lamb is another thing entirely as John Linwood, ex BBC, found out. He was Chief Technology Officer for the BBC when the plug was pulled on a £100m Digital Media Initiative project. He took the BBC to a tribunal for firing him and won because they believed that the Senior Management were dodging the blame and placing it on Linwood.

John Gough in Avoiding Blame for Botched Projects, (undated 2014), summarises the Linwood story and points to internal company politics as a driver. We all know company politics and how it can invidiously dominate decision-making. How’s your company for this?

The risk of being sacked as the accountable one is real but companies are beginning to understand that they need to get on top of risks before they cause trouble. Enter the Digital Risk Officer. Have you heard of them or seen a job advert for one? You may well find you have to relate to them in your client companies. Apparently, these people will be hot news in 2015 according to Gartner research 2014 . Now this is in response to security issues and technology as companies realise that with the plethora of technology-driven channels of communication and the increasing use of them by the public at large, that the risks of service failures increase. It will be interesting to see if these officers are increasingly used as easy target sacrificial lambs by their companies when things go wrong! But if you meet them as part of the client-mix, you can be sure that they’ll make strong demands of you making your job more accountable too.

Now you’re in the mindset of blame, perhaps you need to become aware of a nasty blow coming from an unseen upper-cut! This has crept in from the side of a legal ruling about blame in a service contract. The original case was about pipes and little to do with digital project management. (See, The Best Practice Group, Your Service Provider’s Duty to Warn, by Alan Watton (23 January 2012) But as the ruling can be generalised to all service contracts, we need to take note. The judgement found that the contractor (expert) should have warned the client about the possible risks in the project because they as the experts were in the position to know the possible impact on the clients while the clients as non-experts – and the very reason for using the contractors – were not in the position to understand the impact.

The key concept is ‘a duty to warn’ about the risks pre-contract and during the life of the project and exists independently of written clauses. You have to account for what your advice does and does not cover. You have to be clear in writing about what your advice does not cover and what your proposed solution does not cover including any possible consequential impacts. Well, that’s a tall order in our uncertain digital world. You need to throw this concept to the legal bods who draw up your contracts as service providers. Now if you are too small to have a legal section, check if the templates you use for contracts cover this angle and raise any queries with your management.

You’ll probably do a lot of ‘warning’ without realising it. So, for example, if you recommend that your client should do some pilot testing with users to check the system out and assess its impact on the project objectives pointing out to them the pros and cons of this, then you are warning them of the possible negative effects/risks. If they take the decision not to do this, they accept responsibility and accountability. Likewise, you’ll probably be recommending various types of testing from stability to security, for example. You can indicate the pros and cons of all of them, so if the client chooses to ignore your advice - because of lack of budget maybe - then you have fulfilled the ‘duty of warning’ principle.
Blame is not a nice topic in any field. Better to be prepared though.

Friday, 29 August 2014

Prince2 and its relevance for iMedia now

Who would believe that it’s more than 25 years since Prince2 started making an impact on project management. Its original success, arising out of a commitment to train project managers from the IT sector, has helped turn project management into a recognised profession. That’s what we owe it. And, it recognises that as the project environment changes, its practices need to adapt. The present lot of project managers have more access to technology through social media as well as conventional media and they are deploying these to communicate with their global teams, stakeholders and management. This is a far cry from 25 years ago. This implies recognition of the expansion of the team, the cultural differences, the importance of managing stakeholders and communication with management. The role of project manager has changed with the times and now encompasses more upper management and business strategy, as well as the day-to-day projects. celebrated its 25th birthday on 15th August 2013 with a review of Project Management: Past, Present and Future, by James Hancock. He recognises the changes that technology has brought for the profession and that Project Managers utilise more technology now. But, just like the book, Project Management circa 2025 (2009) edited by David Cleland and Bopaya Bidanda, they all seem to miss out the role of project managers with digital (iMedia ) projects. The chapters in this book address the financial services sector, space exploration, Pacific, European, Indian and Arabic geographical areas, and give attention to the changing role for team management, competencies for project managers, and the impact of cultural and social issues.

No consideration is given to the developers of digital pathways that lead to the changes in the general project management role. Maybe this is because general project management is all about controlling risk factors in the general projects while digital project managers are risk takers themselves by the nature of the type of projects they manage. They still try to control as many risks as possible but when you are pushing the envelope there’s no safety net! General project managers would struggle with the black holes faced by digital project managers. They work from being able to predict the likelihood of risk from previous experience that has been codified from other projects. As an analogy if you have built one house, although there will be variations, a second house has many of the same processes. But digital project management can be like designing new bricks as you build the house. Fundamentals are different and unknown. Now this gives an edge to digital project management that will affect the competencies needed as well as the management skills.

What would you look for in a digital project manager? Maybe you’d agree with Access’s definition of, The Top 10 Skills You Need to be a Super Digital Project Manager – but maybe not as the role spans such a wide set of skills depending on the digital sector. It’ll make you think though, and the first three words, ‘Dark art, witchcraft, science’, are far removed from a traditional project management role and reflect the differences I have been trying to highlight.

The applicability of Prince2 to iMedia is something I've thought long and hard about. You can read more in a white paper on the ATSF web site.

This discussion in no way undermines the strengths of using Prince2 methods and processes. It is versatile enough to employ as needed to fit a project and many digital project managers now have this qualification. All this blog is doing is highlighting some differences in digital project management that can affect Prince2’s use in such projects. Any hints and tips for using Prince2 in digital projects would be fantastic – thanks.

Wednesday, 13 August 2014

Stakeholder Analysis - don’t forget it’s a continual process

At the scoping stage, you’ve done your initial analysis with the matrices and communication results for all the people who might influence the course of the project. Fantastic. Yes, it does help greatly. But, so many forget that this arrangement is dynamic. Various stakeholders emerge as the most important at different stages of the project. Don’t be caught out. Quite often you just need to flag yourself to ask the dominant stakeholders for a forthcoming phase if they want to be kept informed differently. They’ll appreciate the heads-up and the acknowledgement of their increased status for the phase, while you retain the good will ... and control.

The dynamic nature of stakeholder analysis and communication is neglected at the peril of the project. This factor is not really given the attention it deserves yet, even though stakeholder analysis is cited in many top project management jobs. There are a few who show the wisdom of experience and we should try and learn from them even if they are general project managers rather than digital project managers.
Take for example Omar Muhammad and Abid Mustafa in Managing stakeholders – going beyond conventional wisdom, Project Smart (27 October 2013).

They are experienced in delivering complex projects in the telecommunications industry. This means they are closer to iMedia projects than many. You need to take a view on what they say as to whether your own projects are as complex, but, I’m sure you’ll recognise several of the stakeholder issues they mention.

The first issue they address is the difference between a stakeholder’s motives and expectations. This happens quite frequently. Do you recognise someone blocking progress but you can’t identify who because all the stakeholders appear positive to your face? The article writers warn about different agendas shown in levels of management meetings where you might be excluded. The second issue addressed is ‘Not all stakeholders are equal’, and the writers suggest your team adapts their management style appropriately. The third issue is, revolving alliances. This explains that you become part of a shifting set of alliances between the stakeholders that happens over the course of the project. I reckon the underlying message is, ‘Don’t make enemies’ as you may need the stakeholder’s support in an alliance later!

Finally, Omar and Abid give some hints and tips on ‘picking the right fight’. It’s a shame that they don’t define what ‘acceptable levels of behaviour’ are for stakeholders. But this sounds similar to conflict resolution techniques that we covered in our team management courses. There, you agree boundaries of acceptable behaviour for your team at the beginning of the project that can then be used if a team member becomes so problematic that his/her behaviour is having a negative impact on the project. This is an extension of conflict resolution techniques for stakeholders where you pre-empt difficulties by instituting boundaries of behaviour. Essentially Omar and Abid recommend that you only pick the battles with stakeholders that you can win. Good luck with that!

Otherwise there are some free resources that can help you over specific stakeholder problems. Take a look at free-management – and their range. We’ll focus on the stakeholder one now. The book covers how to identify stakeholders, plan their management, manage their engagement, and control their engagement.

I can imagine that if you are only involved in the short, sharp end of iMedia projects that all this seems unnecessary fuss and a lot of time and effort. Those of you that have to juggle several stakeholders, possibly internationally, will appreciate the insights. Hope they help.

Friday, 25 July 2014

iMedia Project Scoping – getting it right

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.

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.
  1. The project meets the business needs of the clients.
  2. The project allows the user to access and complete relevant tasks.
  3. The project is robust and reliable.
More simply defined this means that the business needs, the user needs and the technical needs have been addressed and assessed. Are you doing this?

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 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.