Perficient Healtchare Solutions Blog

Subscribe via Email

Subscribe to RSS feed

Archives

Follow Healthcare Technology on Pinterest

Posts Tagged ‘business requirements’

Business Requirements – Quality Sources

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.

Business Requirements – Version Control

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.

Read the rest of this post »

Business Requirements – WARNING Write your Own

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.

Tools of the Trade: The Requirements Approval

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.

Tools of the Trade: The Traceability Matrix

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.

Read the rest of this post »

Tools of the Trade: The Gap Analysis

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.

Tools of the Trade: JAD Sessions

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.

Tools of the Trade: The Detailed Interviews

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.

Tools of the Trade: The Initial Interviews

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.

Tools of the Trade: Evaluating Corporate Culture

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.

Requirements Gathering for a Multi-Application Solution

When documenting business requirements for a multi-application technology-based solution, is it crucial to have proper representation from the impacted systems in each discussion? For example, provider contracts may be stored in one internal application (i.e., SharePoint) but must be exposed to providers via a second application (external portal) after being passed through a third application (internal workflow tool) to manage the contracting process from a workflow perspective while automating the process at the same time. Further complicating the mix is the validation required of a provider’s signature if the option to electronically or digitally sign a contract is provided via the external portal. So right from the beginning, there are four different technologies or systems for which requirements must be gathered and solutions must be developed.

So during the business requirements phase, should a Technical Architect from each potentially impacted system be present to fully understand the coordination required between all systems to meet the end goals being set by business leadership? Or should their involvement be reserved for the system requirements phase and onward? There are pros and cons to each approach. If the Technical Architects are involved right from the start when business requirements are being documented, the discussions may become too technical and the business goals may not be understood in their entirety before decisions are made to change or sometimes even kill the project as a whole. On the other hand, Technical Architects can help the business understand some fundamental issues concerning the end solution being requested, things that may be more costly than alternatives or just technologically impossible.

The benefit of involving the architects early comes in handy when business requirements start specifying technical requirements for applications that are not fully understood by the business users who are requesting the functionality. For example, the business user may need application 1 to launch inside application 2 to make his or her job easier, and may document such a business requirement in the BRS. However, once the BRS is approved and system requirements are being gathered, it may be revealed that the two applications are technologically incompatible and cannot be integrated in this way. At that point, the process of properly changing requirements takes over and slows down the progress of the project itself. In this case, I have seen projects get postponed over months and even years. Every time the project is picked up, the same arguments over the technologies take place but are never resolved because the business requirements were never re-visited with the Technical Architects who could have provided the necessary insight into the impacted systems.

So a lesson learned is that when it comes to business requirements for technology-based solutions, it is crucial to involve the Technical Architects of the potentially impacted solutions to ensure that the end goal being proposed by business leadership is technologically feasible. When to involve the architects depends on the dynamics of the teams. Some companies have architects in the business requirements sessions to ensure no time is wasted asking for solutions that are too costly or impossible. Other companies involve architects after the business requirements have been documented but not officially approved for the next phase. This allows the business to document their requirements without lengthy technical discussions and also allows the architects to provide their input without causing major delays.

Requirement Pitfalls – Caution: Requirements in Danger

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.