A question of balance: perspectives

The most powerful way to plan a project involves use of three equal perspectives: business, technology and customer. The customer perspective is often the most misunderstood and misused.
Scott Berkum, 'The Art of Project Management', O’Reilly, May 2005 (updated 2008)

The good news is that we are getting better at understanding the customer perspective and we can continue to learn from others on how to tap into the customer’s reaction. Sheetai Kumari gives us great advice in How to Develop Powerful Psychologically Optimised Websites, May 2013

Her tips include:

• Identify Persuasion Triggers
• Place Visual Anchors
• Address Colour Psychology
• Devise the Information Flow
• Implement User-friendly Features
• Use White Space

Sheeta wants websites to relate directly to cognition through cultural triggers. These, she says, need to be assessed as part of a communication strategy for website design. This is true for other forms of technology platforms too.

User Testing design ideas can resolve conflict in the extended development team and is recommended by Rick Whittington in his blog, How Usability Testing Can Resolve Internal Conflict, May 2013. We've all been there when the cross-functional team pulls in different directions with the technology limitations versus the design ideas, adding in the client trying to influence with their own perspective – a classic project management dilemma.

There can be some confusion for developers in exactly who the customer is for the project. Some label the client as the customer while others feel it is the end user. Where do you stand on this? We lean on the end user perspective.

Yet another take on lining up with the user is explained in Pixel Media’s approach where they state that Alligning content and Analytics to customer intent is key for them as a business.

Finally, just for some light relief, Wabbaly offers some very visual ‘tasters’ for what can be designed with the users’ life-style in mind. Enjoy.

iMedia Teamwork today and what it means for business

The nature of teamwork has changed over the years and today we are more used to virtual teams and cross-functional teams. These terms are now embedded in job descriptions and the skill of working in such a team or managing such teams successfully is sought after. Virtual teams mean a group of people who are brought together for a particular project but do not share the same physical workspace. This might include team members from other countries. Cross-functional teams might also be virtual teams but this term relates more to the mixed skill-set of the people brought together rather than their physical proximity.

In some of the latest team research from Ashridge ManagementIndex 2012-13, (scroll down the page to Published Research),77% of respondents say they are increasingly asked to manage cross-functional and virtual teams.

The benefits and limitations of such teams is analysed in an interesting research paper from Michigan State University which although from 1992, has been cited today at The Team Building Directory under the heading Resolving Conflict at Work. (The sub-heading Cross Functional sourcing team benefits and limitations relates better to the import of the article, we believe.) This paper actually goes further than the benefits and limitations because it looks at factors affecting the teams' performance. Now, these factors are crucial and perhaps more relevant for iMedia. In fact, the benefits are all conditional on factors – so that's a lesson in itself, isn't it?

Benefits

• If the team members are selected carefully, the team brings greater knowledge and skill together at one time and increases the effectiveness of the product.
• If the client gives the right participation, then the product benefits as well.
• If the team is given the right authority levels, then the product benefits as well.
• If the team leader is effective, then the product benefits from greater team effort.

Limitations

• More time used in reaching decisions
• Issues over team’s autonomy to make decisions
• Interference from outsiders trying to influence the team
• Lack of insight on whether the team is performing well
• Over-domination of some team members
• Lack of time

Factors affecting the team's success

• Selection of the team – type of skill, personal chemistry (personality?), willingness to participate and ability to influence a section of the organisation.
• Size of the team – the larger it is the more difficult to manage, of course.
• Access to the right information, tools, materials, budget requirements, management support, client participation (note we have transposed the word client for supplier in this case, to make better sense for our industry.)
• Recognition of the team’s role and their contribution to success. If there is evaluation by the company, perhaps annually, then their contribution in a team should count.
• Assigning people to the team that have the requisite skills needed.
• An effective trained team leader
• Clearly defined project/task
• Motivation of team members is significant.
• Organisational readiness for cross-functional teams

This then leaves us with questions. Are your own teams being effective and efficient and if not why not? If the great majority of teams today are cross-functional and virtual, what conditions should management create to help these teams succeed? Does your company ask and listen to your teams about what they need?

Tough questions with no straight answers. But, only you can answer them for your own company. Do you want more successful projects might be your starting point?

Object-oriented media: has its time arrived?

Earlier this week I was in Amsterdam and came across a heron, sitting patiently on the top of a car on Lindengracht in the Jordaan. Since gracht means canal you are probably not surprised. However, this particular canal was filled in many years ago (after a riot over a game involving catching an eel suspended on a rope over the canal, since you ask) so this heron's vantage point was nowhere near water. Two days later I returned to the Lindengracht and the bird was again sitting on a car. Is this, I wonder, a triumph of hope over experience?

I've been hoping for many years that broadcasting would be able to embrace the idea of transmitting a programme made of independent component parts ... objects. Multitrack audio is an easy example to understand: mix the instruments (objects) in the receiver instead of the studio. A listener could change the mix if required, to give a different balance between voice and background for example. The intended, or default, mix would be transmitted along with the objects.

This concept has recently gained traction in BBC R&D with a great paper from Tony Churnside linking to an interactive drama based on their concepts. A special kind of radio receiver, a perceptive radio, has been developed which adjusts a programme based on what it knows of the listener's environment.

The idea of building programmes from objects isn't new but in the past the technology (ie computer power) was restrictive and there wasn't really a distribution channel. The basics of this are actually part of the MPEG-4 standard, although they seem to have been forgotten behind the bright and shiny new video codecs. At one time we would consider using objects to counter bandwidth problems: distribute relatively static components early and slowly ready in the receiver to be put together on-the-fly with low bandwidth dynamic information. This is like the sprites used in video games or symbols on a weather map. The same techniques would allow an end user to take some control over a programme.

It is this last idea that is still the most exciting to me. Is it still a triumph of hope over experience? I note that Tony links interactivity to objects at the end of the paper, so I think we're getting closer.

Your clients and how they brief you

Briefs have been problematic, leading to misunderstandings and breakdown of relationships in many projects. How do you try to avoid this? We've long advocated having a company scoping questionnaire that is devised by the staff from their experience and tailored for particular clients. We've also suggested that you make sure this questionnaire is updated regularly to keep on top of changes and innovations that the teams have come across.

However, some clients feel the need to use their own way to brief. They may have an in-house approach and this can make it difficult for you to influence exactly what information you get from them. The best way in this case is to marry your own needs by finding the gaps unanswered for your scoping questionnaire matched against the brief you are given. Many clients will see this as a professional approach and be happy to provide the extra information. Some may not be so forthcoming. Whatever approach is taken - to scope together or for the client to brief you - the clearer the information at the start of a project, the better for all, as we know.

Educating your clients is in your interest. So where might they find help with briefing? Can you point them in directions that will allow a better fit with the information you need. If they use briefs, do they have a mechanism for revising the brief? Here is where you might influence them for the future.

With that in mind take a look at some of the guidelines for briefs for iMedia projects. Which guidelines line up with your needs better than others? What would help you work better with clients? Do some raise issues that your own scoping questionnaires neglect? You might use the guidelines to drive change to your own guidelines. Some companies use their guidelines to drive business to themselves as well.

• How to write the perfect brief, Harmony
• Writing a brief and how to get a project started, The Design Council
• Writing a website design brief that gets results, Mark Kelly, Smart Insights, February 2013,
• How to write a website brief, Method and Class

Using Prince2 and Agile simultaneously: symbiotic or chaotic?

Have these two approaches been causing your company friction? We've been concerned that they can seem to pull in different directions from a management point of view; but the business situation in iMedia - flexibility, fast-changing scope, and clients who want to see faster results - all play towards Agile.

It can come across as an us versus them situation between programmers and the rest of the team and management. Yes, you guessed it, it all comes down to control!

First let's clear up the Agile/DSDM approach conundrum. Agile techniques can fit under a Dynamic Systems Development Method (DSDM). DSDM has guiding principles that back iterative and incremental development: Agile seems to fit perfectly here. But DSDM goes further as it enshrines higher level management aspects like focusing on the business need, communication and quality: aspects of a project that fit with Prince2 methods. The linking mechanism may well lie in understanding DSDM.

However, DSDM, like Agile, is seen as an IT project methodology, whereas Prince 2 fits an international general project management image. There's the positioning of the relative approaches in a nutshell. If you work with clients who have a general business background they are more likely to relate to Prince2 principles which make overall communication easier in theory. If your clients are used to working with IT, they may well be au fait with Agile and/or DSDM approaches so communication at the product development stage might not be as big an issue as it can be. Doesn't it all relate to the project context?

If there is friction between your inter-team approaches involving Prince2 and Agile, there are pros and cons on both sides and both parties need to understand the core criticisms that can be valid. So, Agile methodology can be seen as: lacking discipline, lacking rigour, over-emphasis on product development, needing strong collaboration from clients, client-driven, putting over-reliance on visual documentation, nibbling away at the true project.

Prince2 can be seen as: over-bureaucratic, using linear development (a waterfall approach in IT terms), light on product development, a straight-jacket,over- business-driven, prefers non-visual documentation, takes too long to start, over-zealous about specification.

These can all be true depending on the context of the project, and projects differ as we know. Perhaps emphasis on one approach may be needed for one project and the other for another. What is clear is that unless your team are all pulling in the same direction, your project will suffer. The answer might lie in combining the best of both approaches because then they might demonstrate that ‘flexibility and dynamism can exist from within a structure of stability and control’. See page 8 of Agile project management: Integrating DSDM into an existing PRINCE2® environment, Best Management Practice White Paper.

This white paper is worth a look if your company is having bother with these aspects. Another perspective that reinforces the two working together can be viewed at Indigo Blue Consulting.

Orphans ahoy!

I've written in the past about orphan works. These are copyright things (works we call them in the rights biz) whose rights owner is unknown or untraceable. Now the UK Enterprise and Regulatory Reform Act has been passed and the game is afoot. An act name worthy of Yes Minister's Department of Administrative Affairs and one I try not to say out loud. This, amongst stuff about landlords and whistle blowers, gives the government the ability to issue laws to permit the lawful use of orphans and said laws (called statutory instruments or SIs) will be promulgated later this year. The drive from Europe is to allow non-commercial reproduction of orphans to preserve them and to permit access. I know that the boundary between commercial and non-commercial is both hazy and full of large rocks but it does at least draw a line many people find reasonable under the circumstances. However, the UK plan for orphans goes further, notably allowing commercial exploitation.

This is proving particularly unpopular with photographers and illustrators and has even been called the 'end of photographic copyright'. I suspect the debacle will not be as dramatic as many fear but it has to be seen in the context of how photographs and other images are treated on the internet ... posted and reposted and along the way losing any information about their rights ownership. There's a good (and for once non-hysterical) roundup of the issues on the Register.

As designers, builders and managers of web sites we have a responsibility to treat the rights of things on our sites correctly. This doesn't just mean clearing the rights any more. We need to make sure that any images have suitable metadata embedded in them and that any program systems do not remove said metadata. For example, ImageMagick does not carry over metadata when you process an image to, for example, resize it. However, there is a PHP Metadata Toolkit (probably others too) so you can read the metadata and then reinsert it. But you have to actively make sure it will happen.

Remember, as I said before, some day the orphan could be yours.

Unhappy client syndrome - have you eliminated it?

Clients are your customers and they do pay (don't they?) to keep you in work and the company going. They can be demanding, ignorant of your business nuances, and fail to recognise that a project is a partnership so they have to participate to make it happen.

On the other hand, clients often still have gripes about their developers that sound believable: fail to meet deadlines, don't perform as expected, produce work that doesn't meet the business needs, don't listen, and so on. Why haven't we managed to sort out these mainly communication-based problems?

Well, communication takes time and effort. It isn't good enough to have your company processes outlined on your website and in a company brochure. Many clients don't read these or only glance at them at the beginning of the relationship. It may well be that your description is still pretty technical as far as they're concerned and they don't understand it. You and your people need to reinforce the principles as well as draw your client's attention to them when needed in plain English.

There is a gap between the specialisms of business and technological development. It has been closing and some people have managed to straddle them. (These are the people most in demand at the moment. See our earlier blog, The Thorny iMedia Salary Debate, 12th April 2013.) Misunderstanding is generally at the bottom of most dissension. A Project Manager will know full well that this is the case as most of their time is spent on exercising control to avoid this and mitigation to appease the situation, so that the team can get on with their work. A Project Manager/Account Manager is there to take the strain between client and developers.

Now if you feel that none of this applies to you, well done indeed. Perhaps your company receives glowing reviews from your clients. Do you know? Are you checking what people say about you? You may not be able to employ people full time to check out and report back on tweets, postings and electronic reviews like large businesses do, but you can schedule time to check the social temperature on your company from time to time. You might be pleasantly surprised and be able to incorporate praise on your own media platforms. If there are criticisms you need to look into their validity and decide how to avoid such negativity again.

There are companies that specialise in reviews, (just think of Tripadvisor), and this fashion is spreading into all areas. Just take a moment to think about the implications especially if you're an agency by looking at 5 places to look for client reviews and recommendations for a Website Design Agency, from WWDC (which web design company), 27th March 2013. They list themselves at the top.

Happy browsing!