Presumably, you are considering acquiring new software to address some business need – this need can be in the form of an opportunity for improvement or a problem that must be solved.  Many times, organizations jump to a technology solution and fail to clearly understand what the business really is.

With respect to technology, a needs assessment is an evaluation of the technical tasks and functions an organization must be capable of performing (that it currently isn't) or the needs that technology must be able to meet (that are not currently being met).  A true needs assessment requires that all possible needs be identified.  Determining whether they are realistic, necessary, and affordable comes at a later point in the planning process.

Requirements are discrete and measurable bits of functionality that must exist in the software to satisfy the need.  For example, an organization may have a need to send out Board reports via email.  However, the discrete software requirement may be that the new software system must print the reports directly to an Adobe .pdf file to insure that the statements cannot be altered.

What are the different kinds of requirements?  Generally speaking, they can be broken down into two groups:  Functional and Technical.

Should all requirements be given the same weighting?  Not all functional areas within the organization are, or should be, considered equal.  Let’s assume for a second that your software evaluation was only considering two functional areas: accounts payable and finance.  And let’s assume that the project sponsor has decided that accounts payable is the major focus of the evaluation while finance is a minor focus.  Wouldn’t it then follow that the individual list of requirements for accounts payable should get a higher weighting than finance?  It would not make sense to give them an equal rating.

This seems like a lot of work.  Is all of this really necessary?  Defining what you require in a software package is, in my opinion and experience, the hardest part of the entire software evaluation effort.  It is very easy to say what you don’t want.  But the effort of defining your requirements is a very intentional and disciplined act.  The degree of probability that you will get the best software match for your organization is directly proportional to the amount of focus and hard work that go into the requirements document.

This is the beginning of the relationship between your organization and the software vendors.  You will make a declaration of need.  The vendors, heart swelling with love and desire, will declare back that they feel your need and will be able to satisfy all of your software desires—and then some.

What is the best method to elicit requirements from my user base?  On smaller projects, the functional area team member may begin compiling the list of desired and required features and adding these to the precompiled list he obtained from other sources.  On larger projects, requirements are typically gathered through an interview process.  Numerous people from a functional area are “interviewed” to determine what their normal processes are and what is important to be included in the requirements document.  These interviews do two things:  one, they gather the desired information, and two, they begin the process of getting buy-in from rank-and-file members of your organization who are not on the project team.  They will more likely support the final decision if they feel that they had some input.

Resources for Software Needs Assessment and Requirements Definition

(Book) Software & Vendors & Requirements, Oh My!  A Project Team's Guide to Evaluating Business Software

Software Requirements Definition: How to Avoid Disasters in Software

(Book) A Practical Guide to Needs Assessment

(Book) Needs Assessment Basics

(Book) Software Requirements

Resources
	Sign-up for FREE Software Selection Tips

When a software selection project falls out of the sky and onto your plate, you need a strong heart, a sharp brain, and the courage to tackle the task.  This is the book that provides all three, and more.  It is a clear and methodical map through the unclear and needlessly chaotic process of software selection.

Click Here
To Learn More About The Book

When the need for a Yardi custom report arises you don’t have to call a consultant – you can create the report yourself!  All you need are the right tools to get the job done.  This video series uses Lupine Partners’ proven in-house training method and a takes a learn-at-your-own-pace approach for providing all the technical information, tools, and know-how you need in order to become skilled at writing custom reports for Yardi Systems’ software.

Click Here
To Learn More About
The Video Series

Planning a software implementation is something that MUST be done correctly in order to have a successful system migration.  Lupine Partners has once again taken our time-tested and proven methodology to bring you our Video Series on Implementing Yardi Systems' Voyager™ product.  The videos and documentation provided in this series will teach you how to implement Yardi Voyager without consultants, but within your time and financial constraints.

Click Here
To Learn More About
The Video Series

Get your
Lupine Partners T-Shirt Today!
Order Now while supplies last.

Click Here To Order