Suppose you’ve been assigned a project with explicit responsibilities and expectations. In this case, it’s still a good idea to make sure that you’ve correctly identified the underlying need that the project is supposed to meet so that project solves the right problem.
For example, imagine you’re an IT manager and several people in your department have asked for a new database and data-entry system. You informally ask them: “Why do we need the new system?” The answers you receive include: “We can’t get the data out fast enough” and “I have to sift through four different reports to compile an update on my clients’ recent activity.”
These responses describe symptoms, not underlying problems or needs. You need to ask more probing questions, such as “What type of data do you need?” “How are you using the data now?” and “How quickly do you need to retrieve the data?” Unless you know the answers to these and similarly detailed questions, you risk wasting time and money by designing a system that doesn’t address your group’s fundamental concerns.