Distinguish between needs and wishes Briefing is all about defining the needs of the projects stakeholders. The challenge with this is that not all needs are of equal importance. Some needs are real needs and others are mere wishes. This distinction is important because almost any project is constrained by resource limitations, which means that there is not enough budget to grant all the demands of all of the stakeholders. Theoretically, it is easy to distinguish between needs and wishes: needs concern essential qualities that the building cannot do without, and wishes are features that would be nice to have, but the building would still be usable without them. In practice, it is not always easy to make this distinction. Different stakeholders will have different perceptions about what counts as essential and what not. For example, is it essential to have an espresso bar in an office building, instead of the usual vending machines? Employees may think so, but the projects budget holder might beg to differ. Likewise, a manager may feel that he or she really needs a private office, while the rest of the staff may see this demand merely as a status-driven wish. Distinguishing between needs and wishes is thus often a matter for debate. The best way to guide that discussion is to keep it open and active. Preferably, stakeholders are invited to contribute ideas. Also, it will often help to take the discussion to a higher level of abstraction. What is the need behind the wish? How does a need or wish relate to the projects objectives or peoples work processes? In addition, it will be useful to look into the costs and benefits. In the case of the aforementioned espresso bar, for example, it would be useful to make a comparative overview of the different options available, outlining their costs and potential benefits in terms, say, of employee satisfaction and staff interaction. Such data will not provide definitive answers, but they will make the slippery discussion about needs versus wishes a bit easier to handle. Recommendations-Make sure there is a decision maker (e.g. steering committee) that can decide whether a particular request should be seen as a need or a wish.-Challenge peoples must-have requirements. Why are they so important? What kind of value do they create? -Try to link requirements to the projects objectives or the users core activities. If that is not possible, they are probably not must-haves.-Determine how tight the budget is: is there any wriggle room to grant wishes? Are there any quick wins that do not cost much, but make a lot of users happy?-Investigate the trade-offs of a requested feature. Does using extra space for one function mean that there is less space for another one?-Make a business case for demands that give rise to a lot of debate, looking at both costs and benefits.-Be open and honest about the projects targets in terms of user quality. Wish lists are often born out of a fear of losing quality (getting less space, less privacy, et cetera).