« Lessons Learned Again and Again and Again
On Writing the Project Charter »

Allow Constant Testing By Users Throughout the Entire Project

May 23, 2009 | Author: PM Hut | Filed under: Project Lifecycle Phases, Requirements Management

Allow Constant Testing By Users Throughout the Entire Project (#22 in the Hut Project Management Handbook)
By Wouter Baars

In the definition phase and the design phase, customers are asked to formulate their requirements as well as possible. This is difficult for two reasons. First, customers have only a limited conception of the possibilities or impossibilities of IT. They do not have a good idea of what is or should be possible or what they should or should not want. Second, customers often have only limited knowledge of their own business processes. Many IT projects involve the computerisation of a customer’s existing business practices. Even though customers may have worked with the processes for many years, they are often not able to define their own business processes. They can work fine in their own way, but cannot say exactly what that way is. The precise definition of processes is a precondition for making software that will drive computerisation. The complexity for customers thus increases if they must describe existing processes.

The list of requirements that is developed in the definition phase is often incomplete. In the implementation phase, programmers make software according to this incomplete list. When users are confronted with the initial versions of the new software, additional requirements are identified. ‘It looks good, but now can you make it so that I don’t have to keep entering my password?’ Programmers often complain that customers do not know what they want. Customers appeal to the ‘fact’ that, because software developers are professionals, they should have determined earlier in the process what the customers wanted.

In a software project that involved the automatic processing of applications for a web-based service, an extensive functional design was made. Long lists of requirements from the customer were compiled. A number of screen designs and flow charts were added, after which the programmers could get started. Probably because the project was under extreme time pressure or perhaps because the customer’s organisation was rather chaotic, the designers had neglected to include one important component: manual administration. The applications were processed by the software. Because the processing of the applications was to be automatic, the programmers thought that no manual administration would be desired. This requirement also did not appear in the functional design. When the software was delivered for testing, the customer realised that there were exceptions in some of the applications. These applications could not be processed automatically, but would have to be handled manually. The software, however, worked only automatically.

In the waterfall method, the actual project result is tested at the end of the implementation phase. This is late in the development process. The time between the definition phase, design phase and implementation phase sometimes amounts to months or even more than a year. If design errors are discovered in a late stage of the project, it can be expensive or sometimes even impossible to adapt software without beginning an entirely new project. Because we have seen that it is practically impossible to specify all requirements beforehand, a working method that allows the possibility of testing (intermediate) results earlier is desirable.

Comparing a number of prospective software houses, a customer asked the competing parties what was possible. One party was somewhat reserved and
doubted whether some of the customer’s requests would be feasible. The other party had an aggressive sales representative. When the customer asked the sales representative if a particular request would be possible, the sales representative telephoned his programmers. ‘Can we build a functionality that can do X?’ The programmer, who thought primarily in technical terms, answered that, in principal, anything was possible. Neither the programmer nor the sales representative worried about feasibility in terms of project management (e.g. time, money, complexity, risk).

The sales representative’s enthusiasm was more effective than the other party’s reserved attitude had been. The customer chose the aggressive sales representative’s offer. The newly acquired project subsequently came into the hands of a project leader and a group of programmers. After a time, it became apparent that the project did not fulfil the customer’s expectations. This had partially to do with the fact that the processes were much more complicated for the customer than they had originally appeared. During a heated discussion between the two parties, the customer referred to the fact that the sales representative ‘had said that functionality X would not be a problem’.

Next in the Hut Project Management Handbook:

Cyclical Methods of Project Management

Previously in the Hut Project Management Handbook:

Waterfall vs. Cyclical PM: Estimating Time to Implement a Functionality Is Difficult

Wouter Baars has a Master of Science degree in Industrial Engineering and Management Science. He has been a project manager for several years for The European commission, Waag Society, KPN (Dutch telecom provider) and many smaller organizations. He is specialized in creative projects such as serious game development, e-learning and software development. Currently he is teaching project management and coaching organizations that are working on their project management. More info on his work: www.projectmanagement-training.net.

Originally published by DANS – Data Archiving and Networked Services - The Hague

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Saturday, May 23rd, 2009 and is filed under Project Lifecycle Phases, Requirements Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

The problem is that, the bigger the project, the more likely it is that you won’t have something ‘testable’ for a long time. This might be why so many great applications start as something very small (or modular) that is gradually adapted.

Project Management Tools & Techniques wrote on May 23, 2009 - 1:46 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories