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?

Managing client expectations – a common project problem

From the number of job descriptions where this phrase features, this is a skill in big demand. What's more, these jobs are in the higher pay brackets too. Most difficulties stem from lack of understanding on both sides, lack of clarity about what will be produced, and in the end a lack of trust. It needs someone to apply some analysis and jump in and sort out any emerging problems.

In iMedia projects the risk from miscommunication increases. Why is that? Well, we’re talking about what for most people is an intangible process (computing processes), we are working internally across specialisms that have their own language of description, and working with clients who have their own specialisms, descriptive languages and markets. Then, of course, we deal in look and feel – very subjective issues.

Very often it is the things that are not said that prove to be the gremlins. These are implicit expectations the client has about the project. The only way to get clients to verbalise these is to ask specific questions. The client may not have realised that they even needed to consider X,Y and Z, but if you raise the issues and insist you have to have some answers before proceeding, this educates the client into giving information that is vital. (The project 'Scoping' questionnaire we have discussed previously can help with this).

For example, it is very important for you to know if a site has to be designed for the client to update. The client might presume that is what they'll get as all their contacts operate in that way. But, unless you ask the key question about the assumption (implicit expectation), you’ll be up **** creek! And we've all been there!

Just to be clear, managing client expectations is part of the wider role of stakeholder management, that we also discuss in these pages. Stakeholders can be anyone who can influence the project and so this can include clients, your direct contacts there as well as indirect contacts in their company. It can include your internal team and management too. All their expectations have to be managed in appropriate communication – dealt with elsewhere but I felt it needed to be put in context here.

So not an easy issue at all but a skill that is highly valued although not one that is analysed well in cyberspace! All I can offer you in the way of recent thinking is:

• Managing Client Expectations (April 2009) on Continuous Thinking (author unknown)


• Managing Client Expectations (December 18th 2009) by Raj Modi, Ezinearticles.com - a slightly sideways look as he discusses consultancy and client expectations but has validity


• Finally, if you really can’t manage the client any more as they are beyond managing this might hold some answers! How to fire a client (August 2005) by Andrew Neitlich in Sitepoint