A Difference of Needs vs. Requirements - KELL Partners
Search
Close this search box.
Search
Close this search box.
kell partners salesforce partner
Search
Close this search box.
salesforce needs vs wants

A Difference of Needs vs. Requirements

You are so ready to get started on this project! And you’ve already made a helpful list of your needs to give to your project manager. So why did your project manager take one look at your list of needs and say that you needed to have a bunch of meetings to identify your requirements? Everything you need is laid out right in front of them! Why can’t you just get started right now?

It turns out, needs and requirements are not the same things. Understanding the difference will help ensure that you get exactly what you need out of your Salesforce implementation. Read on to learn what project managers look for when defining requirements and how you can help get your project started on the right foot.

What is a Need?

A need is something that is important to your organization or your users. Some examples of a need are:

  1. To show my board that our fundraising income has increased
  2. To track my communications with major gift prospects
  3. To send emails to my organization’s contacts

While articulating your organization’s needs is a great starting point, if you give this list to your project management, they aren’t going to be able help you complete your project successfully. Some of the problems we commonly see with needs are:

  • Lack of specificity – the need is not clearly defined
  • Unable to be measured – we won’t be able to tell whether or not the need has been met
  • Items that aren’t relevant– nice-to-have items that don’t directly relate to the success of the project.

How do we turn these Needs into Requirements?

Let’s start with the first need on our list. You want to show your board that fundraising income has increased. How do you want to do that? Do you want to give them a presentation in their monthly meeting? Email them a report once a week? What level of detail do they need to see? And what do you want to them to do with this information? Answering these questions will help you turn your needs into specific, measurable, relevant requirements that your project manager can use to deliver technology solutions.

Once you’ve finished taking a deep dive into your needs, you might come up with a list of requirements that looks more like this:

  1. Send board members a quarterly report that include the total amount of gifts received this quarter compared to the same quarter last year.
  2. Track planned touches with major donors, noting the anticipated people involved, subject, and date of each touch. As the touches are completed, update the date of completion and include notes from your interaction with the donor.
  3. Group contacts into email lists based on interests. Send mass emails to a list, personalizing the emails with each contact’s name. Report on the open rate and click-through rate of each email.

Common Requirements Mistakes

Want to make sure you’re requirements really reflect your organization’s needs? Avoid these common pitfalls that can derail your project before it even gets started!

  • Not having the right people in the room – You cannot identify your requirements by yourself. Make sure all of your stakeholders have input when identifying your needs and requirements, particularly the people who will be using your Salesforce instance on a daily basis. Bringing these people in at this stage of the process will help you avoid challenges with user adoption later on.
  • Not prioritizing your requirements – You may not be able to accomplish everything on your list during your project. You may not have enough in your budget, or you may just run out of time. Make sure you know which requirements are the most important so your project manager can tackle those first.
  • Not leaving room for flexible solutions – Your requirements should definitely be specific, but don’t get too stuck on a particular solution before your project even begins! Once you get started, you may find that another solution will work better, or find that your original plan conflicts with another requirement. Leaving room for this unforeseen changes will make your project less stressful for your staff and your project manager
  • Not being thorough – You want to make sure you capture ALL your requirements before your project manager gets started. Once configuration has begun, it can sometimes be challenging to go back make additions. Get all the requirements written down before you get started so you can account for all possibilities during configuration.

Defining your requirements may be only the first step of your project, but specific, measurable, relevant requirements will insure that everything else goes smoothly and you have exactly what you need when the project ends.

SHARE THIS

CATEGORY