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?