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."1 (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).
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!