The customer issues inadequate requirements - what should the project manager do?

Drawing on a personal example and established definitions of project management, the author addresses a difficult question: what should a project manager do when the client’s or stakeholders’ requirements seem unreasonable or pointless? Three legitimate courses of action are examined in turn: 1) proactively persuade stakeholders by making a reasoned case for a better solution, recording the proposals in writing to guard against future claims; 2) accept and fulfill the requirements, recognizing that the client is responsible for defining the deliverable; or 3) leave the project if the requirements conflict with personal moral principles or make the work meaningless. Two “bad practices” are also singled out: ignoring the client’s requirements in favor of one’s own judgment, and resentfully doing substandard work while passively complying. The key takeaway is that a professional project manager must balance defending expert judgment with understanding the limits of their responsibility, while being prepared to make difficult moral choices.

"I love strawberries. But if I go fishing and feed it strawberries, I won't catch a single fish."

In one of my first projects, where I was then working as a young specialist in schedule network planning, a rather offensive situation arose. I was working on the task of creating a cost model that provides automatic recalculation of the budget when work deadlines are shifted in the schedule network schedule.

In this task, I was driven primarily by "sports interest"; no special material bonuses were provided for solving the problem; I just really wanted the development to "take off." The work was hard, I had to spend several weekends overtime, and I finished making the final presentation before showing it to the customer at around 3 am. As a result, the customer tore my work report to smithereens because... the presentation on the cost model was not designed according to the customer's corporate template. In fact, no one looked at the cost model.

Who is to blame, and how to avoid such situations?

Let's see what project management theory tells us about this topic.

By definition from the classical approach to project management, a Project Manager is a person appointed to lead a team and responsible for achieving the goals and results of the project. The customer, by definition, is the person or group of people who will benefit from the results of the project. It is important not to confuse the role of the owner in project management methodology and the role of the owner in the legal context of contractual relations. For example, in a construction project, the role of the owner belongs to those who will operate the constructed building in the future. And in an IT system implementation project, the owners are future users of this system or their representatives. The Customer has a responsibility in the project - at the beginning of the project he must approve the future results of the project, and at the end of the project he must accept the results obtained.

In both classical and adaptive project management approaches, one of the first steps of the project manager is to gather requirements. In this case, requirements can be issued not only by the owner, but by a wider circle of persons called stakeholders (interested parties). By definition, stakeholders are individuals or organizations that can positively or negatively affect the execution or completion of a project. An example of a stakeholder is government supervisory authorities in construction projects. They will not use the results of the project, but their requirements are decisive.

Also, any approach to project management in one way or another states that one of the criteria for project success is the satisfaction of stakeholders.

From all of the above, an unambiguous logical conclusion follows that the project manager does not formulate requirements for the results of the project - he fulfills them.

Let me return to the question posed in the title. So what should you do if the owner and other stakeholders issue requirements that are incorrect in your opinion and demand that you create a result within the project that will not bring any benefit to anyone in the future? Based on the best international project management practices and common sense logic, three options arise.

1. Convince stakeholders.

Working as a project manager implies a proactive position, having your own opinion and a willingness to defend it, and not just diligence and a willingness to mechanically carry out any instructions and tasks. Therefore, if you think that the requirements for the project results are incorrect or not optimal, try to convey this opinion to stakeholders and convince them to change the requirements. It's in your best interest. Explain how the option you propose will be better for them. Stakeholders, in fact, often have a poor understanding of what they want.

2. Do what you are told.

If you tried to convince someone, but it didn't work, remember that the project manager does not define requirements for the result of the project, it performs. If the project product turns out to be useless due to the fact that the requirements for it were formulated incorrectly, this is primarily the responsibility of the customer and it is not the fault of the project manager.

Of course, in this scenario, you run the risk of hearing the phrase at the end of the project: "So you're a specialist, why didn't you immediately tell us that the requirements were incorrect?" Moreover, you can hear it even if you have repeatedly proposed demands to change it. In order to minimize such a risk (precisely minimize, because it is impossible to completely eliminate it), in such situations I highly recommend "leaving traces," that is, formally recording your proposals, at least in the format of an email.

3. Leave the project.

We could have ended with these two options if not for the moral and ethical side of the issue. A decent doctor will not carry out manipulations that will harm the patient, even if his superiors or the patient himself demands it. In addition, an important part of motivation in project work is understanding the value of the product you create. Therefore, if you are required to do something that contradicts your principles and moral beliefs or is simply uninteresting, and it is impossible to convince stakeholders to change the requirements, then the honest and correct decision would be to leave the project.

This is the prose of life.

I will separately dwell on the options for "bad practice" of actions in the situation under consideration. This is a bad practice, but unfortunately it occurs quite often - when the project manager takes one of the two positions below:

The customer gave incorrect requirements, so I do what I think is correct, and not what the customer requires.
I sit in the role of the "offended", I work carelessly and do hack work, because my ideas and suggestions are not valued here.

Such options are not provided for by best international project management practices.