The Art of Finding Facts

The Art of Finding Facts

The exciting aspect in fact finding is simply that there are so many different ways to search out and identify facts within a business domain. If we find that one technique doesn’t seem to be delivering what is expected, we have 5+ additional techniques we can employ in sequence or in parallel and in various combinations until we feel we have identified a sufficient fact population to accomplish our goal. Kendall, K.E. 2011 singles out and defines the following fact finding techniques, all of which should be considered by an analyst at the beginning of each systems design project as potential ways of identifying critical facts related to the new system:

Brief Overview – Fact Finding Techniques

  • Interviewing – face-to-face conversation with those who have a relationship with the system
  • Joint Application Design – approximately a week long design workshop involving a mix of user, IT, and management all working together to develop business requirements for the system
  • Questionnaires – paper forms, electronic formats (email, webforms), remote or in person used to obtain facts from a user’s perspective
  • Investigation – using existing non-human data sources relating to the system
    • Quantitative Document Reviews
      • Decision Making Reports
      • Performance Reports
      • Records
      • Data Capture Forms
    • Qualitative Document Reviews
      • Memos
      • Signs/Posters/Bulletin Boards
      • Corporate Sites
      • Manuals
      • Policy Handbooks
  • Observing Behavior (decision maker) – watching and recording how the decision maker(s) performs their job functions in order to identify how this might affect the design of the system
  • Observing Environment (decision maker) – reviewing the environment in which the decision maker(s) perform their job functions. Our environments give off subtle clues as to our personalities and our personalities affect the way we use systems

In the majority of cases throughout my professional life, when faced with fact finding in relation to a complex system, I have never employed just a single fact finding technique. I usually find that I instinctively use at least 2 different techniques in order to make sure that all my bases are covered. This also provides, in my opinion, the highest probability in locating the majority of the critical facts which apply to the systems I am developing/designing.

I have also noticed that the 2 different techniques I might use may not always be the same combination as I used on the previous systems design. This is due to the fact that with each new system, the environment in which I am working has changed. The changes can be as slight as a different department within the same company or as substantial as a different company altogether.

For the majority of the systems I have designed I have employed some combination of techniques from the top four items in the list above: interviewing, joint application development, questionnaires, or interviews.

Here are some of the environmental factors which usually affect the combination of techniques I employ.


I have found that the majority of all enterprise systems I have worked on or designed there is always a time crunch, a crunch which was there before the project was ever conceptualized. This ever present lack of time dramatically affects an analyst’s ability to perform proper fact finding. When time is the issue, I usually find myself turning to the techniques which require the least amount of time to complete. This is whether or not they are considered the best or the worst for the task at hand.

Technique Selection: questionnaires, maybe a few interviews if I can find the time


I have found that some management styles preclude analysts from free access to the users and those invested in the system. With restricted access to those important sources of facts, analysts are left to less interactive techniques which at times can be more time consuming and less constructive.

Technique Selection: Investigation


1. Kendall, K.E. (2011). Systems Analysis and Design.
  Pearson Education, Inc., publishing as Prentice Hall

Published by

Tim Clark

Experienced Business Owner, Chief Information Officer, Vice President, Chief Software Architect, Application Architect, Project Manager, Software Developer, Senior Web Developer, Graphic Designer & 3D Modeler, University Instructor, University Program Chair, Academic Director. Specialties: Ruby, Ruby on Rails, JavaScript, JQuery, AJAX, Node.js, React.js, Angular.js, MySQL, PostgreSQL, MongoDB, SQL Server, Responsive Design, HTML5, XHTML, CSS3, C#,, Project Management, System Design/Architecture, Web Design, Web Development, Adobe CS6 (Photoshop, Illustrator)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s