Technical Analysis

EDBOK Guide

Why Do a Technical Analysis?

A properly executed technical analysis insures that all business requirements have been extracted from the customer and understood by the team. Those requirements should be reviewed with, prioritized, and approved by the customer, and then distilled into a feasible technical architecture and design for implementation. The technical analysis can then be referenced for direction and clarification when implementing the project and used by the customer to verify and validate that the final delivered project meets the requirements as agreed upon by both parties.

A technical analysis is a vital part of a successful business project. It is critical in insuring the project is successful, meets its goals and objectives, and reduces and mitigates whatever risks are inherent with the project.

Technical Analysis Processes

A typical technical analysis (TA) process is iterative and involves close interaction between both the project team and the customers for the project. The customer in this case can be either internal or external. Iteration is necessary to insure that the requirements and conclusions are correct, understood, and accepted by all parties. The actual process used will vary between organizations and based on the type of project being developed. The TA process for a new or refurbished plant for mailing

operations will be different than one for developing a new Line of Business application and different again from one for a new product to be developed and released by a vendor. The next sections list some general guidelines. The term project is used here generically.

Vet The Project Business Definition

Normally a technical analysis starts with a project already defined at the business level. This business definition should include the business goals and the business constraints for the project. This typically includes the budget, resource, and timeline constraints to be vetted as part of the technical analysis, and any flexibility that might exist.

Ideally the business definition should state what needs to be done, not how it should be done. If a business definition contains too many hows, it should be viewed with suspicion. The TA team should go back to the business team and probe further. How definitions often mask the real pain point and can narrow the TA teams focus. Did the business definition really uncover the business needs? Sometimes in specifying a how too early in the process other potential solutions or options are overlooked.

Once a good business project definition is in hand, the TA can proceed.

The TA team needs to familiarize itself with the business definitions and make sure they understand them and the framework within which they set. If any of the business components are unclear they must be reviewed and clarified.

Review The Current Process

The technical analysis can now begin. If this is an upgrade or a replacement for an existing business project the TA team must review the current implementation, both overall and with an extra focus on current limitations and pain points. Although the current process should not necessarily be used as a starting point for the new process, an in-depth understanding of its limitations can be useful when formulating  the new process. Whenever possible, interview the current users. Read the current documentation. See where the current user actions are different than what is defined in the documentation. Watch the current users perform their jobs. Frequently what a user says in an interview is different than what they actually do. An ethnographic study is ideal if you have UX (User Experience) experts available and it’s relevant to the type of project. Ask the users what they would prefer to have. Initially make these questions open-ended. Do not suggest potential options; but let the users suggest them.

Future Requirements

The TA team should consider the future direction of the business and of the project within the business within a reasonable time frame, usually 2-3 years. The main purpose of this exercise is to ensure that technical decisions being made during the Technical Analysis won’t inhibit the direction of the business or project going forward, will not cause extra work, and will not otherwise make the current project’s work unusable due to projected future directions.

Non-Functional Requirements

Define the non-functional requirements (NFR). NFRs are requirements that, although directly related to the functionality the process must meet, are part of the environment in which the process lives. For example, if software, what is the current IT environment within which the final project has to operate? If on an operations floor, what physical environment and limitations are present?

Review the users. What skill sets do they have? What skill sets are they using, and what additional skill sets might they possess?

SLAs, KPIs, and other Metrics

Determine what SLAs (Service Level Agreements), KPIs (Key Performance Indicators), or equivalents are in place. These are usually hard requirements, frequently contractual, with specific numeric metrics that must be met. Examples include the number of documents processed per hour, number of mail trays produced in an 8-hour window, percentage of acceptable rework, maximum error rate, and any other metrics that govern the throughput, frequency, and quality of the final process. For each of these metrics, determine at least what the projected 2-3 year growth is, and, if possible, what the projected 5-year growth is. This insures your design and deliverable do not become obsolete 12 months after you deliver.

Wikipedia has a good introduction to Key Performance Indicators; see http://en.wikipedia.org/wiki/Performance_indicator.

Functional Requirements

The team should produce functional requirements. These are the actual requirements against which the project implementation will be developed. Functional requirements should be:

• Comprehensive. They should cover all of the functionality the project or process must deliver. Functionality that is obvious or already in place in the existing system should be included; nothing should be left out.
• Granular. Each functional requirement should cover one function at a low enough level that it can be tested for, but not at so low a level that it begins to dictate how the requirement should be implemented.
• Clear. The team developing the technical analysis is usually not the team implementing the project or process. If the requirements are not clear or are subject to interpretation, what gets implemented may not be what was originally intended.

There will also likely be requirements that will not be automated, but will be handled by way of new or changed manual operations or procedures for the end users. These requirements must be captured and documented, and passed on for design and development by the relevant group.

There should also be a section of known non-requirements. These are issues that  have been discussed and will not be in the project (or, at least not in the first version). This section can eliminate the same questions being raised multiple times (“but have you considered x?”) as well as providing the basis of a roadmap for future releases or upgrades.

For more background on functional specifications, see Painless Functional Specifications by Joel on Software at http://www.joelonsoftware.com/articles/fog0000000036.html.

Functional Requirement Formats

It is often helpful to develop user stories around the requirements. Instead of calling out a function like archival for instance, saying the user should be able to send a PDF copy of the document to the archive system of record via a drop down menu can help both the business users and TA team gain a clear understanding of the requirement.

One frequently used format for functional requirements is the SCRUM Theme/Epic/ User Story format.

See, for example, Mike Cohn’s discussion of User Stories, Epics and Themes at http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes for an introduction to this best-practices functional requirement format.

Investigation

At times, requirements may need some research before they are presented to the  end user. This is usually to determine the feasibility of a new function or an order of magnitude estimate as to how much work is required to deliver a function. This can help the business users prioritize and rationalize the desired functionality.

Functional Requirements Vetting

Ideally, functional requirements should be vetted with the end users. This may be difficult because there is little to nothing to show them. Two approaches are recommended; both should be used.

Initially, review each functional requirement with the end user community and have them confirm each one. If an end user cannot understand the functional requirement then it is not clear and must be rewritten. Frequently an end user requests a change: “I know that what I originally said we need, but now I really see that we need this instead.” This should not be viewed as a failure on either side; it is an iterative process and may require several iterations before a final set of vetted functional requirements can be agreed upon. Do not move forward until everyone agrees on the final set.

Another critical component during this review process is prioritization. If you ask a user, “Would you like this feature?” they will say, “Yes.” This creates feature bloat and a design that cannot be implemented within the constraints of the project. Instead, have users prioritize features: “Out of this list, what are your top three?” or, “For each requirement on this list, rate it as a 1 (highest priority) to a 3 (lowest priority).” It can also be helpful to let users know the relative cost of a feature: “This feature will take a lot of time and money and we won’t be able to do a lot of others. Is it that important to you?” Another methodology is the MoSCoW method (‘Must have’, ‘Should have’, ‘Could have’, and ‘Won’t have’). Refer to http://en.wikipedia.org/wiki/MoSCoW_method for more information.

Some tools that can be included are wireframes, paper mock-ups, and physical mock- ups. These provide a better visual representation of what the TA team is proposing. The end users should be told that these are only initial mock-ups; the final delivered process of project will most likely not look the same.

Research

At this point frequently the team will need to identify and research issues, processes, products, or technologies that might be necessary for the project. There may be new software, new hardware, emerging technologies, or new processes or methodologies available that the team should review and become familiar with before making decisions as to whether or not they might be appropriate as a component or basis for the new project.

Statement of Work

If the project is green-lighted to move forward, the TA team develops and delivers as its final report a Statement of Work. The SOW should contain (as appropriate):

• business project definition and assumptions,
• functional requirements,
• non-functional requirements,
• proposed schedule,
• estimated development costs, and
• risks identified and suggested mitigations.

There are many styles and formats for an SOW. Examples and templates can be found at the sites below, or a quick Internet search will provide more targeted examples.

• Sample Technology Statements of Work (SOWs) @ http://www.gsa.gov/portal/content/133795
• Statement of work @ http://office.microsoft.com/en-us/templates/statement-of-work-TC001184032.aspx

Turn-Over

In some instances, the TA team will also be the team to implement. When a different team is used to implement, the TA team should schedule and perform a detailed transfer and turn-over of the project to ensure the team implementing understands all aspects the TA team has worked on. The TA team should also be available during the implementation for questions as needed.