Finalizing System Requirements - Moving Forward By Stepping Back

The process of defining requirements for a technology system can be daunting for a company, particularly when it involves the coordination of the voices from multiple business units or many different departments within a single business. Operational pain points, opinions, key business drivers, and priorities can vary greatly among the groups. Most companies spend time at top management levels outlining specific business strategies and those executives and top managers are able to articulate what they expect the technology to achieve.

Yet a disassociation can occur when the work to define the details for the technology begins. There are various reasons this disassociation can occur:

• The teams defining the functional requirements may have not had enough exposure to the high level business strategy.
  
• Top management may not document strategy and instead, only verbalize expectations in meetings.
• Business units or departmental groups may define the high-level strategy differently and, not surprisingly, filter the information as they believe it pertains to their area. 

All of these conditions can make it difficult for personnel to retain the big picture as they move into the detail requirements process.

"Stepping back" to clearly document high-level business strategy and problem statements is a good practice prior to diving into detail requirements. A referential roadmap that includes financial or efficiency targets allows the project team to identify how each functional solution area will roll up to the high-level strategy. The roadmap also gives the team a tool to use to determine valuation at a requirement level.

As an example, a company may define the inability to complete effective product planning and forecasting as the overall business problem. The company may have determined that they have multiple departments keying in the same product data into different systems. Perhaps these systems are not integrated and are not accessible to the multiple departments. The high-level strategy to enhance business planning and forecasting includes development of a central location for product information and the ability to reduce or eliminate data rekeying. This is the point where the company has decided to seek out technology to fulfill this need.

Assuring that the requirements team that is aware of and is invested in the high-level problem and strategy goals helps the requirements process move forward in a streamlined fashion. The project team is able to consistently review and document how well the functional areas fit with the business strategy and problem statements. For example, department personnel that will be able to add to or enhance product data using a shared system will no longer need to rekey product information from scratch. This may also allow a separate departmental database to be removed from the process flow. The amount of time personnel spend keying information and the maintenance of the database are all areas of specific improvement that should be collected by the requirements team and identified based on the functional area for the new solution.

Sharing business problem and strategy statements and goals at both a high level and detail level helps keep the project aligned. This practice allows the project team to articulate how the solution will meet the business goals specifically and is particularly helpful for defining value. Stepping back to constantly review documented business problem and strategy statements throughout the requirements stage helps a business move forward in an effective manner.

Comments

[Paul Alessi]

Kathy, your article really illustrates one of the most basic and yet, least addressed problems common to many corporate entities: the lack of detailed communication. It is obvious you have lived through this and are sharing from experience!
As you said, expecting the level of project results that are truly attainable, without providing 1) the common goals agreed upon by business owners PRIOR to the implementation of the project; 2) communication to the areas outside of the project groups that effect the results of the project (i.e.: the data entry manager, and data base administration); and 3) communication AND buy-in from upper management who effect decisions on any of those outside areas; the project can never achieve the highest potential level of success (benefits/savings).
Excellent article, Kathy!