How to identify potential projects and clients
For many years, when student numbers were lower and we did not require so many industrial clients for our projects, our Department tended to rely on informal contacts for client recruitment: friends of Departmental staff or lecturers in other University departments.
In fact, from time to time, we still use clients who work for another part of the University, whether in an academic or administration department, in the Students’ Union or in a spin-off company. Our University’s many health and medically related departments and organizations have proved to be a particularly fruitful source of IT projects.
Some, but not all, of these clients have the advantage that they understand well the educational motives behind our projects and they may, as a consequence, be more tolerant and forgiving of student groups who fail to meet project requirements. Another institution we know of operates industrial projects for HND level students, using exclusively this type of client, who is internal to the university, but external to the department, because the project organizers find that they can negotiate project outcomes with these clients more easily.
Clients who are internal to the University can still provide the students with a real need for a software system and with a real challenge. However, we have some evidence that, when given a choice between University-based clients and organizations totally unconnected with the academic world, our students prefer to work with the latter. Although we perceive the University to be a big business environment, projects provided by entirely external organizations seem to be accorded greater credibility or authenticity!
Some academics may have personal contacts with big IT companies and these might be a useful source of projects. There may be some dangers, however, if the projects turn out to require methods of tools that are not part of the general academic curriculum. However, it is worth considering.
Some clients become personal contacts because they come back to us with further project ideas, and this is an excellent way to get further projects.
About three years ago, our demand for project clients increased significantly, in part because of the introduction of our fourth year software company course. We needed to recruit upwards of a dozen clients each academic year, whereas previously, we might only have recruited two or three. As a result, we embarked on an exercise in cold calling, contacting almost fifty local companies across business and industry sectors, identified from the Electronic Yellow Pages.
Roughly a quarter of the companies asked for more information to be supplied about our requirements for project clients, from which three came forward and visited our Department. Eventually, one of these companies, a china and glassware retailer, became a client for our second year project that year.
The exercise did not prove effective or efficient as a means of finding suitable clients. However, we learnt a lot from it: a number of organizations will drop out of the client selection process, either because they are too busy, or because the need for a software system has changed. Hence, when selecting clients, always keep one or two potential clients in reserve, so that the student project can go ahead even if a company pulls out at the very last minute. This does happen. You need to be prepared for it!
Furthermore, you may find that you have not been speaking to the right person in a potential client organization. More than one company representative we negotiated with during this exercise was very enthusiastic about a computing project, but was too junior in the organization to sanction the project and authorize the payment of project prize money.
We concluded that cold calling as a method of recruitment placed no particular onus or responsibility on potential clients to commit to successful project completion: clients recruited this way may have insufficient stake in the project’s outcome. Better to advertise in such a way that client organizations have to take the first step in contacting us.
Broadly speaking, we
have found two different successful channels for recruiting industrial project
clients. The first is via existing publicity and networks in the local business
community, both through a paper newsletter that is produced on a quarterly
basis and circulated to local businesses by Sheffield’s Chamber of Commerce and
through an electronic mailing list maintained by
We would wholeheartedly recommend that you explore contacts with the Chamber of Commerce and Business Link networks in your area. We have always found them obliging and supportive. The main caveat here is to be prepared and plan ahead! When a newsletter is only produced on a quarterly basis, you may need to supply copy four to six months in advance of your requirement to start a project, to allow for both newsletter circulation and the assessment of client and project suitability.
The second avenue that we exploit is a very good working relationship with our University’s Careers Service, which operates a brokerage for student projects. The Careers Service employs a member of staff whose job it is to raise projects from local organizations, for students of all disciplines to pursue, either as an extra-curricula activity or as a part of an accredited learning programme. This member of staff is well briefed on our industrial project requirements and refers to us, on average, about six project clients per year. On a recent occasion, a client referred by this route has supplied three usable project briefs.
We are uncertain how many other universities’ careers services organize a similar student project brokerage facility, but we would encourage anyone involved in industrial project work to make contacts and develop links with their respective careers office. At our institution, they are very supportive and also make a contribution to our group project curriculum in the areas of developing teamwork skills and developing negotiation skills.
There are a range of motives that an external organization may have in approaching us as potential project clients. These motives vary, depending on the size of a client’s business, the business or industry sector and whether the business is in the private, public or voluntary sector.
Low risk development: sometimes, clients want feasibility studies and prototypes for software products which are initially too risky to implement on a commercial basis. This has usually been the motivation of small, private client companies who already utilize a considerable amount of software and communications technology, or whose main business is within the IT sector.
Some potential clients may be attracted by the high quality of development methods, or by increased access to the latest technologies. Potential skills transfer between commercial and academic organizations has also been the motivation of small, private client companies who already utilize a considerable amount of software and communications technology, or whose main business is within the IT sector.
In only a minority of cases have our clients been motivated by the opportunity to assess the calibre of our future graduates. Few of our clients are of the size or business type to recruit computing graduates. However, we would expect this factor to be of paramount importance in the case of large national or international IT companies acting as industrial project clients.
Whilst low cost software development is often the main motivation for a client, if this is their only motivation and if they show very little interest in the educational rewards that students might derive from the project, then reject the project. Do it tactfully, but reject it. Furthermore, on no account accept low cost development of a possible commercial product, intended for sale to a third party, without making the copyright and licensing issues crystal clear, (see below on negotiating copyright).
In general, be guided by your gut instincts in selecting a client. If the client has both demonstrable enthusiasm and realistic expectations for the project then there is a good chance the project will succeed.
Of course, an enthusiastic client who has no free time will not be suitable! So, at the start, invite the potential client to meet you in the Department. If he or she does not show, or has to reorganise the appointment because of pressure of work, this is nearly always an accurate indication that this client does not have the time that you and your students need. Similarly, if the client wants you or other lecturers to visit them, then they probably do not have enough time to get involved. After all, our clients are expected to make regular visits to meet student groups at the University site, sometimes on a weekly basis, when the project is underway.
The location of the client can have a bearing on project suitability. It is useful to offer students the opportunity to visit the client site, perhaps as a part of the requirements elicitation process, - to see the business context in which the system will operate, or later, to obtain system validation from a range of potential users. So, for this reason, it has helped us to recruit clients who are located within a short car, bus or tram ride of our campus.
However, we recognize
that this mode of operation will not suit every institution. Some universities
utilize Web-based communications to particularly good effect in the management
of student project progress, for example
We are one of a number of institutions that has experimented with teleconferencing as a vehicle for communication between our fourth year students and clients located in our region, twenty to forty miles away. However, in the main, we feel some face-to-face communication between client and students is vital to a successful project. There is a danger in over-reliance upon e-mail to support client –student communications. There’s a real risk that the requirements elicitation process will be superficial and incomplete and that it will not yield the level of mutual understanding of a project’s objectives necessary for the project to work well.
Before going any further, you need to ensure that you are dealing with the right person in the client company. In this case, the right person is someone with sufficient authority to approve project and design decisions and who is also sufficiently representative of the intended user group of the planned software system to influence matters relating to system usability. If the person with authority will not also be a representative system user, then other user representatives ought to be encouraged to have a regular involvement with the project.
Previously, we have said that an ideal client representative should also have little or no experience of computers, in order that students are afforded the fullest opportunity to practise eliciting customer requirements. We felt that a computer literate user might provide too great a part of the software specification themselves and might unduly prejudice design decisions from the start. However, as computers become more ubiquitous and as the recent expansion of internet usage continues apace, it is now very rare to meet a potential client who has no experience of technology and no conception of the system or, at least, the kind of user interface that they want.
There are still clients for whom a little knowledge is a dangerous thing and, if possible, these clients are to be avoided. A case in point is a client who wanted a database system to store information on his suppliers and customers that would also deal with aspects of contract expiry and renewal. This client had some specific ideas about relational databases and a very particular semi- relational model of his system in his head. Compliance with the model in his head seemed to become the key acceptance criteria for all our student teams’ systems. For him, the project was a failure, in large part because all the students’ systems relied on more normalized structures than he had conceived or understood. For the students, project work became dispiriting because they could not conform to the client’s convictions about the data model.
Assessing a project’s suitability is one of the most difficult aspects of organizing industrial projects and it is one on which we have frequently been asked to advise by colleagues considering the introduction of industrial clients and real-world project briefs.
Suitability relates to scope and technical difficulty of a project’s requirements and to the degree of familiarity with required hardware and software on the part of students, project supervisors and technical support staff. First and foremost, suitability should be assessed with respect to the level of risk of project failure.
Our most fundamental rule is this. A project is not suitable if it is mission critical to the client organization. In this case, the consequences of failure are too high. Project supervisors and students should not have to carry this level of responsibility.
With regard to project resources, we would advise against a project that required software or hardware that the department does not already possess. Bringing in new hardware or software has many attendant risks: the new kit may not be delivered in time; the technicians may not be able to install it successfully; staff may not be trained in time to offer support to students. The nature of our project clients – typically SME organizations – has meant that most software development takes place on a PC platform, with Visual Basic, (VB), as the students’ most popular programming environment.
Not every university department will want or be able to host projects on a Microsoft platform. Some universities may prefer to develop industrial project software under Unix, or for an Oracle platform, in which case larger client organisations will be needed, who have this level of technical architecture in place.
Despite the prevalence of
VB, and to a lesser extent, Borland’s
The scope of a project and the amount of effort it will require cannot be determined or quantified with any accuracy at the time the project is first discussed between potential client and project lecturers and supervisors. We ask potential clients to bring a description of their project idea to the initial meeting with us, outlined on a single side of A4 paper. It is hard enough to make useful estimates of effort even when a project’s requirements have been fully specified by the students, let alone when we have only a high-level sketch and some broad brush statements of business objectives.
So, although we know, for example, that our second year projects typically allow a team of five students to devote up to five hundred hours of effort to system development, we do not make judgments of suitability on this quantitative basis. Instead, we have tended to make predictions on past experience of the capabilities of students in a particular year, using a particular type of technology to solve a particular category of problem.
Whilst every computing department will have its own ideas about the capability of its students and the particular competencies that it expects of them at a given stage in their university education, here are some guidelines that we tend to use. Of course, these guidelines change, particularly in response to changes in technologies and development platforms. Whereas once we preferred clients who wanted a computer system to replace an existing manual system, we increasingly encounter clients who have an existing computer system, want it replaced and require our students to help with the migration of data. Doubtless, the guidelines below will be out of date within the next three to five years!
² The design of a simple web site is not sufficiently challenging for an industrial group project in the second or subsequent years of undergraduate study, although it could provide a useful dummy run in the first year.
² A single user database system or a small networked system for a PC platform, constructed using a 4GL tool, is typically feasible for our second year and conversion Masters students to develop to the point where the client can install and use it.
² A small to medium sized database rarely offers students much scope to practise interesting system modelling, nor to engage in serious problem solving and algorithm design. So, a database system that has some additional, more “meaty” requirement is preferred. This gives the best students the opportunity to shine.
² A multi-user system, a database which is to be editable across the Web, or a Web site that requires considerable scripting to support e-commerce transactions are all considered too risky for development by students in their first two years of study, but can be suitable for fourth year undergraduates and advanced Masters students.
² A project is eminently suitable if it has a few core mandatory requirements (functional or non- functional), that most student teams have a reasonable chance of implementing, together with a number of optional, highly desirable requirements that not all student teams will elicit or satisfy.
On our second year and conversion Masters industrial group projects, we have more than one client. Usually we have three clients, so student teams are offered a choice, based on the outline A4 description of requirements that the client has discussed with supervisors.
How we have managed this choice and allocation process is open to debate, but we firmly believe a choice must be offered, in order to maintain students’ feelings of ownership of the project and their continued commitment to it. All right, in the real world software employees may not have the luxury of choosing the projects on which they work! Didn’t we say claim real world authenticity for our projects? Well, in order to minimize risks of project failure and to encourage best results from all participants, we allow them more control over the project selection process than might be the case in an industrial setting.
Latterly, student teams have been asked to nominate their first and second choice of client, up to six weeks before the project starts. Clients are allocated to teams on a first come first served policy, so a team will not get its first choice if another four or five teams have already expressed this client preference. It has been argued that the first come first served policy encourages a quick rather than a considered response. On the other hand, those teams who organize themselves quickly are to be encouraged and should be able to do background preparation prior to the project’s start date, if they so wish.
How has this allocation policy worked in practice? Over the past four or five years, it happens to have worked well, with teams’ preferences for clients being sufficiently well distributed that most have worked with their client of first choice and none has had to work with their third choice.
However, care must be taken in preparing the outline project descriptions for student consideration, to try to ensure that no one project sounds much more or less attractive than the others. The easy and difficult aspects of each project should be stated. The status of each client organization should be made clear.
Is the organization a charity? (This will appeal to the more altruistic students.)
Is the organization a private company? (This will appeal to the more business minded students.)
Does the organization have direct links with the University? (This may deter students who do not equate realistic problems with an academic settin