Recently a client came to me and asked for a new, very expensive laptop. They touted how light it was—only two and a half pounds! They talked up the fact that this laptop doubled as a tablet and would allow them to take really good notes during meetings. They then switched gears and started complaining about their current computer. It was an immovable desktop. It was old. It was slow.
I was surprised by this request, because this person did not travel often or attend many meetings. The features they were really praising would not do them much good in their day-to-day work. Sure, the new laptop would perform better than their current computer. However, it also cost four times as much.
After asking a few more questions to try to ascertain why they wanted the laptop and what prompted their request, I finally understood. The client had recently attended a big conference with many leaders and directors in their field of work. What did most of those important people bring to the conference? They brought their fancy laptops.
Technology is not just the features of a software package or the specifications of a piece of hardware. Technology is also the marketing jargon, the trends, the rumors, and the “look at what they’re using!” desires. Oftentimes, technology is a single need obscured by layers and layers of wants.
The primary challenge for many IT leaders then becomes how to define high-level needs and wants. In order for a project focused on identifying a new IT solution to be successful, the layers of wants must be peeled back to find the true business-driven needs that will add value to the organization.
This is especially important in a complex postsecondary environment. These educational institutions often face stricter budgetary limitations, additional information security and regulatory restrictions, and lower staffing levels. Ensuring that the core requirements are being addressed while additional financial resources are not being spent on items that are simply nice to have is crucial.
This begs the question, “Where should IT leaders begin on their journey of identifying and separating the needs from the wants?” Defining needs and wants, of course!
Needs are things that can be directly tied to a business goal or objective and are absolutely necessary for the solution to be successful. Needs define functionality that will add value to a business or fulfill a legal/regulatory mandate. Unaccounted for needs will lead to gaps in business processes that will eventually have to be filled by another solution.
Wants, on the other hand, are nice-to-have features that could ultimately be excluded. Wants can often be ideas that a user was sold on by someone else and did not develop organically from a business process. Wants are not necessarily bad things, but they are not completely necessary. They should not be the focus when looking for an IT solution.
The line between needs and wants can sometimes be blurry. In day-to-day language, it is all too easy to use the words interchangeably. However, bundling wants with needs together can have some serious negative consequences for a project.
First, wants can lead to feature creep. Feature creep occurs when the list of things a solution must do continues to grow larger and larger. At first, this may sound like a good thing—your IT solution can do more. In reality, however, this leads to a product that is bloated and difficult to use. Incorporating all kinds of wants into a product will often result in a cluttered and clunky user experience and performance issues. When a solution is expected to do everything, it is often hard to get it to do anything.
Second, wants inflate the cost of a project. By definition, wants are not needed. However, there is likely to be a direct correlation between the number of features of a solution and its price tag. This results in an organization paying to add features to a solution that are not justified by their business processes. It is easy to see how the cost of the wants can quickly outgrow the cost of the needs.
Third, wants tend to be more prescriptive while needs are descriptive. Put simply, needs describe the features an IT solution must have. Wants, on the other hand, prescribe the solution. People often have an existing solution in mind when thinking about what they want, and it is difficult to separate the final product from the individual components that make it desirable. This can severely limit the options that are explored and cause a project to be prematurely guided in a specific direction. Advertisements, buzzwords, and the desire to not feel like you’re behind the times all contribute to this phenomenon.
One example of the prescriptive nature of wants can be seen when looking at Software as a Service (SaaS) solutions. The increased desire to have everything live in “the cloud” has created an enormous industry of software that organizations pay for monthly but never truly own. Everyone uses at least one SaaS tool during the course of their day-to-day work and many companies market their SaaS solutions as more innovative. And while there are many great SaaS tools, deciding you want a cloud solution before you even start gathering your project requirements can cause you to overlook a great on-premises option and spend much more money over the life of the solution than you need to.
The issues associated with confusing wants with needs can be avoided by creating a clear distinction between the two. As this article has done, IT leaders should start by clearly defining both terms to make sure everyone is on the same page. Remember, these words mean different things in the context of project management than they do in regular conversation.
Additionally, IT leaders should not be afraid to question people when they try to pass something off as a need. Why is that a need? What business process does it support? Why does that business process need to exist? Whom does it benefit?
Still, getting to the finish line with two clear and separate lists containing the needs and wants will not be easy. For starters, the requirements for a solution may be different depending on which unit or department a staff person works in. Ideally, all business processes are standardized across an entire organization. Rarely do we live in an ideal world.
With time, processes evolve differently in different units. New employees affect change in some areas of the organization, causing them to alter how they do things. Then, when everyone is brought back together to identify a single solution, the work now differs enough that requirements for one group are extraneous features for another.
Another challenge is getting people to approach the requirement gathering with an open mind. As previously mentioned, many people start the process with a solution already identified. This creates the risk of finding needs to match your solution instead of the other way around. The entire brainstorming process is bypassed and not all requirements end up being driven by business needs.
There is a definite need for guidance from IT leaders to successfully identify a solution that is appropriate for the organization. However, a balance must be achieved to ensure that a collaborative environment is maintained. IT leaders should be very direct in setting the goals and expected outputs, the limitations (financial, regulatory, etc.), and the timeline. They should not discourage discussion, stop people from presenting ideas that may not eventually pan out, or let their own preferences for a solution get in the way of the group coming to a consensus.
At times, the project may get stuck as participants in the requirement-gathering process find themselves talking in circles or unsure of how to proceed. This is where the IT leader can step in as a consultant and help move things along. But, they must not be too heavy-handed in their involvement to avoid making participants feel uncomfortable offering up their own views. The easiest way to not capture all the needs is to create an environment where people don’t want to participate.
Successfully guiding a project focused on identifying a new IT solution is no small feat. One of the most difficult aspects is capturing the requirements for the solution and separating them from the nice-to-have items. Done correctly, however, this step greatly increases the chances that a project is completed on time, under budget, and with a solution that will add value to the organization.
You Might Also Like
