How to Survive a Software Project – some Suggestions for Clients

A paradox: in software development projects, the client is the one who has to take the
most crucial decisions; but it does not exist any learning path to become a client: the most common way is to learn from one’s wrongdoings. This paper aims to give some suggestions to help software development clients not to be swept away by projects.

But, first of all, what is a client? “A person who engages the professional advice or service of another” (Merriam-Webster Collegiate Dictionary). The word comes from the Latin “clinare”, to lean. In general terms, the software development client is the role who will pay the costs of the project, and who is responsible for evaluating if the end product may be accepted. The client is the one who makes the big decisions in the project, and her role must be known and accepted by every stakeholder interested in the course and in the results of the project.

The client in a software development project has many responsibilities:

  • to participate actively in the project
  • to involve in the project other stakeholders
  • to express requirements, and requirements clarifications
  • to prioritize requirements
  • to control the state of the project, and the resulting artifacts
  • to manage project risks
  • to decide in case of conflict (for example, among different point of views expressed by various stakeholders), or in case of mismatch between goals and available resources (for example, when there are delays which cannot be scraped up, the client has to decide whether to respect a stated milestone in delivery by delaying the development
    of some functionalities or to complete all functionalities by delaying the delivery)


1 – Don’t be frightened because you have no technical knowledge.

On a linguistic level, some developers commonly use slang expressions, that may make the communication harder. It is their problem, but you may demand that they communicate in an understandable way.

On a substance level, the client should not accept delays or a growth in costs or suboptimal solutions requested by developers for unexplainable technical reasons.

2 – Beware of long projects.

All statistics show that project failure risks are directly proportional to their time length. If the product to be realized is complex, it is better (less risky, less expensive) to segment the work to be done in a sequence of projects (the first will realize an initial part of the product, the subsequents the remaining parts). The time length of each project must be
inferior to the year, or even shorter.

At the beginning, every project has a blind area, produced by lack of knowledge, by
indeterminateness, that must be progressively lightened. The nature of software development is the progressive knowledge acquisition of an actual problem (the application domain, like banking or health care), and the transposition of this knowledge, via abstraction processes, in an information system.

The clearing up, that is the knowledge acquisition, happens through a systematic collaboration between the client who wants the system and the developer who has to realize it. In most cases, neither the problem nor the solution are perfectly defined at the beginning of the development: they are determined step by step during
he project.

3 – Decide development priorities upon business reasons, not technical ones.

The supplier must adapt to client needs, not vice versa.

4 – Choose your supplier, don’t let it be imposed upon you.

Differences in quality and productivity in the field of software are dramatic, and the short
history of software development is full with conflicting and unproductive relationships
between client and supplier. In any case, both when you may choose your supplier and when you may not, it is mandatory that the client defines her conditions for the project (like those included in this list), and states the contract in such a way to be able to change supplier, if needed.

5 – Demand as soon as possible executable software.

There are software companies that are used to work with a long initial periods of analysis, when they produce only documents, not real software to show to the client. During this long initial period, the supplier asks that the client clarify all requirements before starting to design and to implement the system. It is an approach that is both ineffective and inefficient, because requirements are clarified more easily and faster when client and users are given a first version of the system.

The demand of the supplier to clarify all requirements in advance, when the software product is just an idea, increases remarkably the risks of reciprocal misunderstanding,
because the client is in the uncomfortable position of taking decisions without having every element to do it. It is a symptom of low professionalism on the part of the supplier, and it is the right of the client to refuse this work approach. The client shall not engage her decisions too long without getting actual results to verify.

6 – Require frequent periodical checks.

Checks should be in no case longer than a month, to show the actual advancements of the project in terms of software realized (do not accept percents of work: “it is 90% done” simply means that the product is not done). In every periodical check the work plan for the project must be verified and agreed again.

7 – Avoid “turn key” (fixed price) contracts too early.

If you are obliged to fix the price at the beginning of the project, it is better to stipulate a sequence of contracts, in order to leverage the progressive knowledge acquisition that happens through the project. For example, a first contract for a feasibility study, a second for the initial version of the system, subsequent contracts for the following evolutions.

8 – If you do not have the time to participate in the project, delegate.

Delegate every activity you can to someone else who has adequate time and skill, or to an expert you can trust. The systematic participation of the client (who takes the main decisions in the project) or of her delegates is a necessary condition for project success.

9 – Identify every potential stakeholder, and involve them in the project.

Manage priorities and conflicts among the points of view of the stakeholders in a transparent way. When a choice is needed among different possible solutions to a problem, the client has the final word.

10 – Create, and systematically update, your own project risk list.

Also, ask the supplier for an updated list of technical risks. To spot the risk factors that may endanger the success of the project, and to maintain a constant control upon their evolution, is a necessary condition to avoid to be swept away by those risks.