In these first two exercises we will explore the importance of knowing your key end-users and why you need to enlist their help.  We will also look at the start of gathering requirements and how crucial that is in the process of making a decision as to whether 'To Build or Buy'.

1.  Are you going to be a key end-user of the new application?  If yes, great!  Please carry on.  If no, if you're not sure, or if you are only one of a handful or more of key end-users, you will need to consider who may be involved.  Enlist their help sooner rather than later in the requirements gathering process starting in Exercise 2. Not to do so could mean your investigation is already on shaky ground and here's why....

The Importance of Different Perspectives
When building or buying an application, considering different perspectives is absolutely essential or the design and eventual use and adoption of the application could be in jeopardy.  Moreover, it's the management of these different viewpoints that may be crucial.  Perhaps this quote sums it up best, "Poor requirements gathering and management are directly responsible for 60-80 percent of [project] failures."¹ (Meta Group)

Get other key people on board as soon as possible and consider enlisting the help of a software development Business Analyst (BA) or Certified Project Manager (CPM).

Document Findings
As well, document, document, document.  The further you continue in this decision making process, the more likely you are to need either more input or approval for funding/resources so a paper and audit trail can clearly support your endeavour.  Start a centrally accessible file repository where you keep electronic records of all your research as well as any decisions made, who made them, and when. Document the rationale or why certain decisions have been made too.  If your project ever goes south, this information could be vital.

 2.  As a key end-user, can you list the purpose, objectives and key functions of the application including how it will act (features) and how it will look (user interface or UI)?  Whether you use an electronic spreadsheet and list features with their associated actions, or draw pictures on loose leaf representing what happens when you click a particular button - if you can do this for your entire application, you are doing amazingly well!  Carry on. 

If you are one of a number of key end-users or you're not fully confident that you've captured all of the necessary features and the look of the application, that's OK.  It's important, and necessary, really, to have help from others with this requirements gathering phase.  

Set formal time aside to meet briefly with other key end-users and ask them to complete the spreadsheet/loose leaf exercise above, independently if possible, with little input/bias from you.  In a few days, you can come together as a group with all key end-users to compare results. 

Start with Independent Requirements Gathering
Why do the feature and UI exercise independently?  Group dynamics can sometimes squelch the input of valued, but soft spoken team members.  If everyone has an opportunity to put their thoughts down on paper first, an adept group facilitator, BA or CPM mentioned above could synthesize and present everyone's results for consideration. 

The Cost of Re-work
Your group requirements gathering meetings (yes - there's likely a plural on meetings) will highlight how different people's perspectives can be, but this is vital so that important features of your application are not overlooked.  This might be comparable to waking up one morning, going into your spare bathroom and suddenly realizing that you need six light bulbs in a space where you only have two sockets.  You can't understand why you didn't see this before, but you realize now that you absolutely have to have six sockets.  'If only I had talked to my wife/husband/kids...' you think to yourself as you're faced with the prospect of cutting into the drywall, adding more wire and electrical components (if it's even possible), patching the wall, etc. - all the while wondering when you're going to have the time and money to do this.  

On a similar note, your software application may have to be 'reworked' significantly and at great cost and effort if you initially overlook a key feature or function.  Two heads or more are truly better than one when it comes to application requirements gathering, as time consuming as that may seem....

As you identify your key end-users and begin gathering your application requirements, you should be ready in about a week for our next installment in this blog series.  In Exercise 3, we will build on what we have covered today and you should be ready to work through a spreadsheet tool to help you calculate whether you should lean more towards whether 'To Build or Buy' - - and how strongly.    

 

Have you been through a simple or complex requirements gathering process?  How did it work for you? Our readers would love to hear your experiences and insights!

Have you ever struggled with this age-old I.T. question: whether to build a custom software application or to buy one off the shelf?  This blog series was motivated by my recent conversations with both current and prospective customers and it really hit me - we are all facing this issue more and more often as we increasingly rely on technology to enhance productivity, to connect our computer and web-based applications, and to work smarter overall.  

As we are driven 'to do more with less', our new productivity tools need to be effective, and we need to have done our due diligence investigating all the options, otherwise, we may end up duplicating our work effort down the road, having spent valuable time and resources on a solution that is simply not viable - and no one can afford that.

My aim with this blog series is to provide food for thought for anyone, in any position or industry, seeking a software solution to improve productivity.  I have referenced the articles and tools where I utilized them, should you desire to dig deeper than I have.  Please note, we neither endorse nor profit from any recommendations made.

These exercises will require some investment on your part, but doing some homework now could save you a bundle of time, money and effort (not to mention aspirin and antacids) in the long run. 

In this blog series I will cover exercises on the topics below, so check back tomorrow for the first 2 Exercises to get you started on whether 'To Build or Buy'. 

1. The importance of knowing your key end-users.
2. Having a clear picture of your end application in mind - why this is an absolute must!
3. Estimating whether 'To Build or Buy' a worksheet tool you can use. 
4. Failure rate of custom application development and things to consider before you leap.
5. Understanding your key business drivers in the decision making process.
6. Off the shelf applications and key points to ponder.
7. Decision time.
   

What are your experiences purchasing off the shelf solutions or having custom applications built for you?  We'd like to hear from you and any of your words of wisdom or about pitfalls you encountered.