Skip to content

Are you capturing what is necessary?

Are you capturing what is necessary?

Adam Hadla, Business Consultant, FINEOS

Often, when a project is assigned to us, the notion is to find out what it is, who will be involved, the time it is going to take and the strategy we need to have. The “who”, “how”, “when” and “where” get tangled a bit at times, depending on the priority of the project and what we have on our hands. Yet, I notice (from my past experience) that the most important piece, which is the information you collect from others, is sometimes overshadowed by the barrage of other project components. Examples are: the availability of stakeholders and SME’s, the current infrastructure that must be updated before you implement your project and a realistic due date to provide you with enough time to capture what is needed. (You can also view “Getting to Know Your Own Business” blog by Diane Davis for extra information regarding this area).

The information we capture while gathering requirements, talking to SME’s and investigating all the ins and outs of the current environment and how it is going to be after the implementation is crucial not only to the success of the project, but also to your own success in being an efficient analyst.

There are several factors to keep in mind while you are in the magical world of information gathering that will dictate whether you need all, half or a small portion of what you gathered. I will mention a couple that are often overlooked:

1-     The quality of the information you gather and how accurate it is. Quality information is gathered from “good sources” such as SME’s (subject matter experts), system and application administrators, domain experts, industry analysts, partners and even competitors, as supposed to information that is gathered from users who are not using the full spectrum of the application or customers that are focused on their department only.

2-     The time of the project implementation and fast changing technology. If you gather something today (even if it is good, for example), that doesn’t mean that it will still be useful after 2 years. While gathering the information, you need to keep in mind your timeline (depending on the project size), what should last until implementation and what should be discarded. For example, spending precious time to gather information from a Legacy system that the company will eventually sunset by the time you need to start working on that particular module will have data that is of no use or value. To expand a bit on the Legacy systems, I would like to mention that sometimes they are inefficient and wasteful. We are at a point in time where we should look forward and grasp the new opportunities that a fresh project/start can bring to make things more efficient.

Bottom line, if you take a step back and analyze where you are before even attempting to jump into capturing the information, then proceed with the frame of mind that every word you capture will have an impact on the whole project. You will be able to utilize all the captured components and keep them for both current and future project use.