In any project venture, large or small, a list of requirements is must be obtained from a targeted area. People are the main resources for information regarding a project. Requirement details are only as good as the sources information is obtained from, thus the SME.

SME, Subject Matter Expert, is a title normally associated with technical personnel but the title works for business resources as well. To avoid missing, ineffective, or statements that don’t give detail, it’s best to gather information from resources with a depth of knowledge. The SME could be anyone with understanding of the nuances and modifications a process, procedure, tool, or application has evolved to in its present form. Projects have a defined timeline and a project manager is aware delays will occur but to deliver a project on time, superior knowledge is a must. A project will have rough and slow progress if resources delivering requirements are new or uninformed.

There are instances where a staff associate is thrown onto a project to represent a department and is not knowledgeable of processes. Knowledge gaps affect numerous firms and knowledge retention is a major issue. If a department neophyte must be on a project it would help to assign a mentor to assist the less informed associate. A SME should know the “What,” and if they don’t know the “What” the SME knows how to start the detective search and “Who” may have the answers. To obtain quality requirements, assign quality resources, assign a SME. If a SME is not available implement a SME mentor or create a partnership involving a SME.

A requirement document can be viewed as a live document that evolves as other general and finite details are added. It’s wise to implement a method to track additions, deletions, and any modifications. In the rush to write requirements and capture changes that occur from start to finish, version control is a function to implement at the very beginning.

Version control is the tracking of changes made to a requirements document and along with the authored the adjustment, date, and the time of day a change is made if needed. There are numerous software applications used track changes, but if sophisticated software applications are not available or in your budget there is a way to simply track modifications. First, develop a filing system to log input for requirements. Today most input is electronic to allow saving files from other resource personnel. Document input from others is a necessary step to track.

Second, combine artifacts into one document to develop the initial draft. The draft should have the beginning version number as 1.00 or 0.001 or something to the effect displaying the starting number system. The steps may sound insignificant but can prove to save valuable time to recover from a deleted requirement as needed. Keep originals saved separately for easy retrieval. After combining the various artifacts the next step is the input ledger.

The input ledger is nothing more than a table within the requirement document to record date, author, and a list of modifications. After this third step is where version control begins. Any changes made to the requirements document can be saved as the next version increment. There is another phase to carefully watch as well, called The Review.

Upon each draft of the requirements document there is a review session. The document is circulated for review to numerous team resources. A tracking method to use is the labeling of a reviewed file with the reviewer’s name or initials and the date the review was returned. The easiest way is the circulation of one document that will track the changes via color labeling and/or name of the reviewer embedded in the requirements document.

Documentation of each version will aid in retaining ideas and changes made throughout the cycle of revisions until final signoff to establish a finished requirements document.

The title of this post gives away the final outcome, but the advice should be heeded when writing requirements. Requirements are a list of desires, functions and a vision on how an application should work. If there is not the staff to write requirements it would be wise to hire a firm that will assist in recording a project’s functionality. Not writing your own requirements can place the project on a slippery slope on unmet milestones and missed items.

Handing the sole task of writing requirements over to a vendor that will implement a project could ensure a document is slanted in favor of the vendor. A good example is the purchase of a car, tv or other good. The salesperson is biased towards what they have to sell and looks to move the consumer in the direction of the merchandise of hand. Likewise, a vendor is aware of their limitations and could write requirements slanted to favor those limitations. It is best to take the time up front to write a solid document outlining the constraints and requisites for a project. Writing your own requirements doesn’t guarantee each item is met precisely as written but does give a description of what is desired.

The RFP (request for proposal) is a prerequisite tool of requirements that request a replay from parties on how to achieve results and how to deliver solutions per listed requirements. Numerous firms can implement a project and write the requirements as well, but it also places a vendor at a disadvantage. The disadvantage is not knowing “The What” desired vs how to build “The What.” It is wiser to invest the time up front in researching and writing requirements or else there will be more time, money, frustration and loss spent on trying to hit a moving target or aiming at no target at all.

There are numerous moving parts functioning during the building and answering of business requirements. A major tool in the checks and balances of requirements is “The Approval.”

The approval sheet is a section in a requirements document but serves a more lengthy purpose than just one document. Approvals occur numerous times throughout the document between the business team and the IT team. The approval process can aid in keeping project items on track. In times past, and in some cases currently, the business team has submitted a list of requirements, better known as “The WHAT.” The IT team took the list and went off to build “HOW” the “WHAT” should function. The results are large disagreements because the business didn’t understand what the IT team built. In short, time and money were wasted and redesigns would occur. The process of building and communication was revamped using “Approvals.”

Both business and IT teams meet, discuss various facets of a project and via written approvals, task are kept close to the desired outcome of the project. If a task could not be configured, a work around was agreed upon or the option to scrap a task was agreed upon. A project without a solid approval process is asking for chaos to ensue. There are numerous cases in which projects did not have a strong approval process and teams went off on a tangent, designing items askew, or working on unrelated task which resulted in IT dictating the project, leaving the business wondering where the partnership went wrong.

The approval process keeps teams aware to the “agreed” task to complete and the desired outcome. A good example is when a person agrees to purchase an automobile of a specific make, model, and color but never gives a list of requirements to the dealer. The dealer brings in a new car to show, and the customer is not happy. The customer’s desire was not offered and the dealer is unhappy because of a wasted effort. A team could have a well assembled requirements document but with no approval process in place that will oversee modifications or changes, is highly likely to result is adjustment troubles, frustrations, and time/money loss.

The approval requires specific signatures that represent both teams, signing off on requirements and those modifications, changes, and adjustments that occur. Approval also acts as a very good tracking tool for projects as well.

How to track the solution for requirements is an ongoing process and if proper tracking is not executed requirement/solution documentation can become a maze, if not just flat out confusing. There are numerous ways to list solution answers to requirement and one easy method is the traceability matrix.

The traceability matrix is basically a table listing the business requirements in one column and solutions in a corresponding column. The document removes searching for a specific solution list in one document and matching items in separate business documents. The traceability matrix acts as a roadmap providing a guide reader through each solution and removes the confusion of juggling numerous documents. The compilation of knowledge into one document makes answers readily available.

Another aspect to employ within the traceability matrix is the numerical identification of both requirements and solutions. Numbering requirements aids in rapid identification but what can be more revealing is numbering solutions. Numbering solutions has a two folded benefit:

• Easy visual identification of requirements paired to solutions
• Clearly identifying which solution answers more than one requirement

The second benefit can guide staff to further develop a specific solution to answer numerous requirements that can reduce the efforts of producing an individual solution for each requirement. Numbering solutions will clearly display how many times a specific solution answers a requirements.

The easiest format to set up a matrix is via a spreadsheet where software features can be leveraged for presentations and knowledge transfer to project stakeholders, teams and impacted areas.

The traceability matrix is a viable, flexible tool to employ concerning “Use Case” reviews of original and alternative paths, special requirements criteria and test plans.

The Gap Analysis is the examination of hindrances a project incurs that halts tasks or total project completion. Major project gaps are normally apparent but minor steps that undermine projects often times do not materialize until well into a project.

Interviews and JAD sessions give a clear view regarding current processes while the project scope speaks to the future state. The middle ground to connect the current to the new is the focal point of a Gap Analysis. The Gap Analysis is also a solution discovery tool that provides a means to resolve issues. A common example of a major gap today is the goal of building a computer interface with options and information that does not currently exist. The analysis of the major gap will uncover the minor faults impeding milestone achievement. In short, what needs to happen to make things work?

First, select an area of interest, a specific topic, or task area to complete. If the topic covers numerous items, narrow the selection to one item. After narrowing the topic, list dependences a task requires and develop a list of metrics to apply to a task. The two major metrics should contain measurements signaling completion. This metric can encompass a service level agreement (SLA) date and time, quantity, and location. The second major metric is quality identification. What defines if the final product is above standard, average or inferior? Can the product be understood? Once metrics are flushed out the next step is to list the various avenues and option to arrive at a solution.

View the pros and cons of each option and determine the best path that will both meet a goal and will satisfy project constraints. The Gap analysis will likely lead to additional JAD sessions with discussions centering on eliminating hindrances.

In project requirements the implementation of the gap analysis is a necessity to aid in project completion and can lead to the proper question to home in on removing gaps. The best way to view the situation in a positive slant is not that there is a problem to fix but a solution to build.

Moving forward in the arsenal of tools are the JAD sessions. JAD (Joint Application Discovery) is also known as discovery sessions in which the truth of processes, procedures, or workflow is truly brought to light.

JAD goes beyond the regular interview by pulling resources together to perform a review involving those previously in singular or panel interviews. The depth of the project will give an idea to the length and number of JAD sessions to hold. The sessions can run all day for a week or two or for a couple of two-hour sessions with breaks. As discussed in my earlier blogs, the building of positive relationships becomes handy in conducting JAD sessions.

Preparation for JAD discussions will aid in moving through the sessions smoothly. JAD sessions require a facilitator to speak and data documentation to occur simultaneously. The Project Manager (PM) will likely facilitate the sessions and some else can document information presented by the various participants. Here are a list of items to help in conducting successful JAD sessions:

• Reserve a room and set a conference call for offsite resources
• Establish a JAD facilitator for each meeting
• Establish a secretary to document each meeting
• Use a white board or overhead in each meeting to bring topic focus
• Circulate a meeting agenda with invitees, day, time, location, and project discussion topics
• Set meeting rules (encourage professional & discourage multitasking)
• Perform introductions (person/responsibility/department)
• Speak on the project vision and reference requirements to answer project demands
• Have workflow diagrams copies and other documentation for attendees

The above list does not guarantee topic resolution in a meeting but does provide an aid for associates to prepare and invite other resource personnel. This also helps to establish goals and milestones for each meeting. There are other specifics to handle in each session.

Remember after coving a topic to ask if there are any additional comments to give everyone a chance to speak. Slate a topic for later discussion if the resource personnel are not present or if the topic requires additional research and time. Side bar conversations will occur in meetings and encourage the sharing information relevant to the discussion. Stay within the meeting time constraints, starting on time, allot topic discussion time, provide a summary, and close the meeting.

The objective in the JAD sessions should result in:

• Uncovering current knowledge procedural gaps
• Determining if the methods, procedures, processes, and personnel are correct as thought
• Discovering boundaries hindering project success

JAD Sessions yield information for the next tool in the series, The GAP Analysis.

Once initial interviews with leadership and stakeholders are complete the next tool to use is a detailed process review. The focus is to interview specific individuals to capture detailed processes that occur in a unit, department or team the project will impact.

During the interviews reassure individuals they are more than welcome to make adjustments to any information given during the discussion to document process or workflows. This is also a time to build trust with staff associates who may feel put on the spot or that what they say could be used against them. Associates performing task know the finite details and are the best resources so be a good listener and build bridges.

Good listen skills allow the paraphrasing of information to ensure details are properly understood. These sessions may have a five person panel or just one person. Allow everyone to speak freely and have a list of probing question that focus on the process. Search for delivery dates and times (SLA- service level agreements), data checks and balances, hand off points, types of data, frequency of events. Use open-ended questions to acquire the information.

Open-ended questions are inquiries that yield and explanation and not a “yes” or “no” answer. Remember this is a time to probe for details and the open ended queries will provide a lead way to obtain information. Also, attempt to keep the detailed review short.

The initial detailed review should not go longer than one hour. Keep panel interviews to 45 minutes with a 10 to 15 minute summary to review. During the wrap-up, request documents to review and setup follow-up discussions. The detail given in the interviews should provide a wealth of information such as:

• A view of sequential operations and processes
• Work data delivery schedules
• Key workflow personnel
• Specific procedures
• Variance and Risk Management
• Documents

The culmination of data will lead to a host of tools and techniques. The next area we will cover are JAD sessions.

Second in this series of requirement gathering tools is the interview. Interviewing may sound easy and generic but there are several objectives to achieve using the tool.

First, focus upon on a list of objectives to orchestrate a plan. Several objectives come to mind, with the main goal being establishing rapport with leadership due to its impact on the project. During introductions and initial dialogues the level of “Business Intelligence” can be assessed as a secondary benefit. Business Intelligence, or BI, is the ability of an organization, department or an individual to take the culmination of information and present it in a timely manner to the correct recipients via proper channels, thus allowing the opportunity to leverage information.

The open dialogues with leadership are more of an icebreaker and to gain a feeling of the level of Business Intelligence individuals. If possible, interview leadership individually to gain an understanding their involvement and desired outcome and how far-reaching a project is departmentally. The introduction allows one to gain staff cooperation and leads to the next objective: gaining information.

During the initial meetings, the task at hand is gaining information at a high level. Look to understand the current flow and processing of information. Use high-level questioning such as where data comes from and who receives the data. The present “SLA – Service Level Agreement” and possible future SLA may be discussed. Information obtained during discussions is vital until determined otherwise via group sessions known as JAD or discovery sessions. Another benefit of these conversations is the disclosure of a contact list.

The circulation or contact list is a foundational tool for managing a project and securing information. The contact list is the life line to obtaining and circulating information.

When completed, the interviews will capture:

• General High-Level understating of department/organizational procedures
• Flow of Information
• Various BI Levels
• Established SLA’s
• Initial Contact list
• Stakeholder Desired outcome
• Project understanding of those involved
• Establishment of rapport with leadership and staff

The best train of thought is to assume nothing, question everything, and think outside the box. Start interviews with the project manager and follow up with directors and managers. This will allow the leadership to prepare staff to deliver specific information.

The next series of my blogs will focus on tools, strategies and techniques to gather business requirements. Some methods are fairly obvious whereas others are painfully discrete and can stifle an analyst’s approach. Upon entering the realm of the unknown, one item to consider in gathering requirements is the political culture of a firm and the department subculture atmosphere. The terms of EI (emotional intelligence) and BI (behavioral intellect) play a very important part in the process but those are for a later discussion in the series. This is the point where people skills come into play and are a benefit.

First, contact the area manager or supervisor. Some organizations may state to start with the VP and work through the order of command. The last thing one would want to do is to ignore the position of a person and attempt to bypass an individual and incur opposition via the disruption of staff or possible bruised egos. Many a person have gone gun-ho after answers, wading blindly into a department, oblivious to the work regiment or tasks a resource person must deliver. One should never forget hierarchical manners to go through proper channels to speak to subordinate staff.

The best plan of action in the endeavor to gather requirements is to establish a rapport with those in leadership of resources and those with a confirmed stake in a project. A positive rapport can provide access to information otherwise hidden and encourage extra effort to deliver help. The extra effort comes when the resource approached does not have the answers but knows others that can provide the information.

Understanding time is valuable; knowing and working through the chain of command (Project Managers, Project Stakeholders, VP’s, Directors, Managers, Staff associates) are foundational items. Always be polite, focused and to the point in gathering information. The best starting points are the project manager and the area manager where the project has the initial impact. In most cases the project manager and/or area manager can provide direction on where to start interviews.

Certain terms within requirements signal details are missing, thus ensuring additional discussions. Discovery sessions are the norm but when a requirement document has the follow statements, requirements are not completed.

1.) The number one offending term:;TBD – “To be discussed” or “To be Determined.” A requirement with the letters “TBD” is not a requirement and stops the progress of the technical team to interpret what to delivery. It is clearly evident the requirement was not thoroughly thought out and clearly stated to communicate the desired purpose.

2.) General Statements. A general statement, such as “the system should display information.” What are the elements of information to display? Is there an order information should follow? General statements go back to the earlier discussion on “The What of Requirements.” A requirement should detail presentation of information.

3.) Missed References: A missed reference is a when a requirement refers to a specification but the section is absent or miss-numbered making the statement a guessing game.

4.) “But Not Limited To.” The statement is designed to grant the author some wiggle room so the requirement is not written in stone. The statement itself “but not limited to” delivers an uncertainty to future change that may occur. If the requirement should address possible configuration changes, the statement should reflect future changes or list table expansions. Preparations for future modification can be built into a requirement, however “but not limited to” is a statement that causes confusion.

5.) The fifth and most lethal and debilitating offender in system requirements is the dreaded “Scope Change.” Avoid the addition of requirements out of the original project scope unless it is deemed necessary to add the new functions. It is fine to desire something else to enhance services not within in scope. Instead of changing the project scope, a greater benefit is found in making the addition/modification as a following phase or next iteration. A “Scope Change” will bring into question every requirement and cause a full review of the project. Basically it sends the project back into discovery sessions and is pure upheaval of requirements. The avoidance of the five requirement pitfalls can lead to a better project.

There are other pitfalls, such as flows with missing steps or charts that leave out systems/processes but the above five are the most common offenders in most requirements.

Metrics are essential measurements to determine if a project is meeting the established goals of time, delivery and budget constraints. This may be a bit off the requirements blog norm, but worth the mention.

There has been a change in the market where the ROI (Return on Investment) is not a requirement in the eyes on projects. Is the ROI forecast replaced by a focus upon the financial burn? Are people considering what was spent to arrive at the solution and counting up the cost after the fact? It is important to track what was spent and if the project arrived on, under, or over budget. Some organizations are of the thought, “Just track the burn.” Financial disaster, monetary suicide, bad judgment, new line of thought; you be the judge.

In these troubled financial times when institutions are trimming the fat and jobs, not laying the foundation of financial success can be the road to financial ruin. There are some necessary projects where the ROI does not have the deciding impact but when it becomes company standard not to have an ROI there is a backlash to pay. The focus of the “get the most for the dollars spent with the best solution” is vanishing in some firms because the preverbal purse strings are open. What happens when the well runs dry?

Is sober financial planning disappearing? The ROI is a metric norm to follow and it appears it is giving way to the free will spend, spend, spend until it is gone. There’s a new program to align with without the old metric. ROI is worth the effort, right?