How to plan high-impact wireless applications: steps 2 through 5: go from interview data to prioritized functionality.

THINKING OF BUILDING a wireless application, and more than a little intimidated at the prospect? No matter how experienced a developer you are, wireless application development can seem like a whole new ball game. But is it? There is at least one useful skill you can carry over from traditional development to the wireless realm: good planning.

In this second of a two-part series, I discuss the concepts behind a high-impact requirements analysis (HIP, A). In the first article (published in the Premiere issue of MOBILE BUSINESS ADVISOR), I laid out the foundation step of the process: conducting interviews. This article focuses on the final four steps:

2. Analyzing processes

3. Developing requirements and scenario flows

4. Performing an accurate impact assessment

5. Analyzing and prioritizing features

You begin with the interview process and end up with a prioritized list of functionality. As I mentioned in the first article, you don't end up with a list of detailed requirements (e.g., data dictionaries, field names, detailed process maps, etc.). Instead, you're left with something just as important (if not more so): an understanding of the functionality and the top-level business requirements.

Step 2: Define and analyze business processes

You perform a business process analysis based on the interview data you gathered in step 1. The goal is to capture details for each process, including the major process action, who's involved, and why the process takes place. You're also capturing information on any existing paper or electronic forms, workers affected by the process, and existing processes issues. The key is to define each process to a level of detail that helps you develop a mockup of the functionality. As an example, table 1 shows the business processes involved with a typical warehouse inventory application.

There are a several key considerations to keep in mind when analyzing the interview data. First, you must determine how the new wireless application might interact with, or replace, existing applications. Second, you determine how the new application can help resolve existing process issues. Third, you determine what new processes you have to put into place.

Application administration is a good example of a possible new required process. In the warehouse example, you might have to define processes that let users archive inventory data on a periodic basis. That process won't exist if the system is currently executed manually.

Step 3: Develop high-level functional requirements and scenario flows

Based on the interviews and defined processes, you're ready to build the functional requirements for the application. Functional requirements definitions include the functional description, key sets of data, users of the functionality, and descriptive details. The goal is provide a high-level description of how users want the application to function.

The key to building functional requirements is to look for groups of processes you can address with a single set of functionality. In the warehouse inventory example, role-based functionality is an obvious grouping. The receiving clerk, routing clerk, and senior vice president are the primary users of the application. For the two clerks, you could develop a set of functional requirements for managing the flow of inventory. For the senior vice president and other appropriate personnel, you could define reporting functionality. Table 2 defines four sample requirements descriptions.

Also, be sure to look for functionality that crosses multiple roles. For example, you might have to define a workflow that determines when a product reaches the end of its lifecycle. Table 3 defines an example cross-role requirement description.

Based on the requirements, you can develop visual scenario flows to depict application functionality. Scenario flows demonstrate what the new wireless application can do. The goal is to help the development team communicate the application's capabilities to the business process owners. In some cases, technical requirements will outstrip the available technical capability and resources; so, it's important to watch that you aren't promising functionality you can't deliver.

Here are some key characteristics of the scenario flows:

* Graphically depicted 

* Contain descriptive text to explain the functionality

* Familiar delivery format (e.g., use handheld screens for mock-ups)

* Use role-based scenarios to illustrate how each user interacts with the application

Figure 1 shows a sample scenario flow for the inventory receipt requirement outlined in table 2. For the sake of demonstration, I've simplified the diagrams and functional requirements. You'd have more details for the diagrams and requirements, and a greater number of each.

[FIGURE 1 OMITTED]

This scenario flow walks you through how a user would use the wireless application to receive inventory and record any defects. Notice that I've used both descriptive statements and visual representation to depict the functionality. Presenting early versions of the scenario flows to key members of the interview team gives everyone a chance to confirm you've accurately interpreted the information from the interviews. The presentation may also reveal overlooked processes and issues.

Step 4: Perform a functional impact assessment

The next step is to present the scenario flows to a broad group of business process owners. Try to include people who didn't participate in the interviews. Include workers with different levels of training and experience. (But, be sure to limit the group to a manageable number of participants.)

Present the scenario flows in the context of the overall project. This helps your audience understand why you're undertaking the project, what has happened to date, and what's expected of them. Also encourage conversational feedback to get a sense of their reaction to the application, thoughts on improvements, and missed functionality you might have missed.

After you've presented the scenarios, give each person a survey form so he can give you feedback on the presented functionality. The level and detail of the survey depends on the complexity of the application. At a minimum, you should assess the business impact of the major functional components of the application. For more complex applications, you can also get into specific functional requirements.

Categories of impact might include increased efficiency, reduced costs, reduced errors, and improved productivity. You might also want to assess the ability to implement specific process changes, improve communication, and better access to support resources. The goal is to give the target user group a way to tell the development team what features will and won't have high impact.

If the group is large and the application is broad, you can use a confidence rating system to get a sense of how comfortable the person is giving his response. The confidence ratings help gauge the quality of the responses. For example, a person who has only been on the job for a month may feel less confident in his responses than a seasoned employee.

Table 4 shows a partial ratings survey for the warehouse requirements example. The data is an example average of all responses, versus one individual response.

In the example, I've outlined four categories of functionality in the survey and listed each sub-component of functionality. The sub-components are rated for impact on increasing productivity, reducing errors, and confidence in the ratings.

Step 5: Analyze the assessment and prioritize functionality

After you receive the ratings, you can analyze them to determine what processes the proposed functionality are likely to impact. Table 5 shows some findings from figure 2.

[FIGURE 2 OMITTED]

Table 6 shows recommendations based on findings in table 5.

UPSHOT: This process lets users conceptually see how the application will work, and lets them give feedback before you begin development. This can save you a significant amount of work on pilots and revisions.

Now, you've done your homework

The high-impact requirements analysis (HIRA) process involves key business process owners early in the analysis and lets them define their requirements and determine business impact. At the end of the HIRA process, you've created several critical elements:

* Defined processes for business areas where the wireless application will be deployed

* High-level functional application requirements

* Functional impact ratings by business process owners

* Functionality findings and recommendations

When the traditional development lifecycle begins, you'll be able to focus on functionality the business process owners believe will have the highest impact. This increases the chance that your new wireless application will have the desired impact on the business and users will adopt it in the field.

MOBILE BUSINESS BENEFITS

Building high-impact wireless applications requires careful analysis of business requirements.

Ensuring buy-in by the process owners and users helps you develop and deploy a targeted, well-defined application.

You can read the first article In this two-part series at http://advisor.com/doc/11174.

Table 1: Common business processes--You must understand the core
action an application encompasses, who takes those actions, why
they're taking them, and any details involved with those actions.

ACTION           WHO            WHY               DETAILS

Log receipt of   Receiving      To track flow     --A receiving paper
inventory from   clerk          of inventory      form is utilized
manufacturing                   into the          with the item
                                warehouse         number and total
                                                  re-keyed into a
                                                  spreadsheet

Log inventory    Routing        To track the      --A shipment
shipment         clerk          flow of           request form is
request and                     inventory out     filled out
inventory                       of the            --An inventory
delivered                       warehouse         delivered form is
                                                  filled out
                                                  --An additional back
                                                  order form is
                                                  filled out if
                                                  there is a
                                                  shortage of
                                                  inventory to
                                                  meet the order
                                                  --All item number
                                                  and quantity data
                                                  is re-keyed into
                                                  spreadsheets for
                                                  tracking

Review daily     Senior VP of   Manage the flow   --The report is
receiving and    warehousing    of inventory      generated out of
delivery                        data to ensure    Excel and shows
report                          inventory         macro numbers for
                                levels are        inventory inflows
                                optimized         and outflows

Product end      Inventory      As product        --About 2 percent of
of lifecycle     manager        reaches end of    inventory remains
                                life, it is       unsold before
                                recycled to       reaching end of
                                build new         life
                                products

Table 2: Role-based functional requirements--Defining
requirements by roles determines what the key processes
are and who is responsible for them.

DESCRIPTION      DATA                    USERS

Inventory        --Item data             --Receiving
Receipt          --"Received" or         clerk
                 "shipped" indicator
                 --Back order
                 designation

Inventory        --Item data             --Routing
delivery         --"Received" or         clerk
                 "shipped" indicator
                 --Back order
                   designation

Inventory        --Inventory-level       --Senior VP of
status           status                  warehouses
reporting        --Back ordered
                 inventory items
                 --Date range

Inventory data   --All inventory         --System
administration   data                    administrator
                 --Date range

DESCRIPTION      DETAILS

Inventory        --Handheld based
Receipt          --Secure login
                 --UPC barcode scanning of
                 received inventory
                 --Inventory defect
                   management

Inventory        --Handheld-based
delivery         --Secure login
                 --UPC bar code scanning
                 --Open up a back order
                 for inventory shorts

Inventory        --Needs to be PC- and
status           handheld-based
reporting        --Secure login
                 --Basic search (date range)
                 --Advanced search (date
                 range and items)

Inventory data   --PC-based application
administration   --Set archive parameters
                 including date
                 --Review archive status
                 --Retrieve archive records

Table 3: Cross-functional role requirements--Processes
that have broad impact often span multiple roles.

DESCRIPTION   DATA             USERS

Product       --Item data      --Inventory
end of        --EOL approval   manager
life (EOL)    designees        --Department
              --EOL approval   manager
              status           --Senior VP
                               of product

DESCRIPTION   DETAILS

Product       --Handheld- and PC-based
end of        --Alert notification to
life (EOL)    inventory manager of
              expired product and
              quantity
              --Approval request routing
              to designees
              --PC-based approve/
              decline capability

Table 4: Functional impact ratings example--Use a ratings system
of one to five; one being lowest impact and five being highest.

FUNCTIONAL                       PRODUCTIVITY   REDUCED   CONFIDENCE
REQUIREMENTS IMPACT              IMPROVEMENT    ERRORS      RATING

1. Inventory Receipt
   1. a Scan retrieved product   4.2            4.8       5
   1. b Process defects          3.3            5         5
2. Inventory delivery
   2. a Scan product to be
        delivered                4.4            5         4
   2. b Process back order       4.3            5         4
3. Inventory status reporting
   3. a Basic reports            5              5         4.5
   3. b Advanced reports         3              3.2       3.2
4. Inventory data
      administration
   4. a Auto-archive data        5              3.1       3
   4. b Auto-retrieve archived
        data                     2.7            2.8       3

Table 5: Example findings--You can develop recommendations based
on these findings.

An automated restore of archived inventory data is not a
high priority for the system administrators

Inventory receipt and delivery will be highly impacted by
automating the management of item data

Basic report functionality was rated very high with advanced
research not being rated as critical

The overall confidence level of the survey respondents is fairly high

The confidence level for the new administrative functionality is
only a medium level

Table 6: Example recommendations--The recommendations directly
correlate to the initial interviews and definition of processes.

Move forward with the core functionality for receiving and delivery

Implement basic reporting in phase 1 and advanced reporting in phase 2

Build basic administrative tools in phase 1 and advanced data
management tools in phase 2

You can read the first article in this two-part series at http://advisor.com/doc/11174.

Noel Jerke is an author and independent consultant with a focus on helping companies better manage information technology. His clients have included the American Diabetes Association, Martha Stewart, and the Air Force. [e-mail].