Process Framework Needs Assessment

Definition

Process Framework Needs Assessment

the process engineering task during which an organizational process team determines an organization’s needs for a standard process framework is determined in terms of its needs for individual processes (e.g., in terms of scope, size, complexity, and formality)

Classification

As illustrated in the preceding figure, process framework needs assessment is part of the following inheritance hierarchy:

• Type: Concrete
• Superclass: Tasks
• Subclasses: None

Responsibilities

The typical objectives of Process Framework Needs Assessment are to:

• Determine the organization’s needs for individual processes by:
  • Evaluating the organization’s documentation and stakeholders.
  • Determining the organization’s process drivers.
  • Categorizing the needed processes (e.g., in terms of process scope, size, complexity, and formality).
Determine the desired characteristics of the organization’s process framework.

Preconditions

Process Framework Needs Assessment typically can begin when the following preconditions hold:

• The need for organizational process improvement has been recognized.
• The organizational process team is adequately:
  • Staffed.
  • Trained or experienced in process framework needs assessment.
• Relevant documentation and stakeholders are available to provide information required to assess the needs for the organization’s process framework.

Completion Criteria

Process Framework Needs Assessment typically is complete when the following postconditions hold:

• The organization has been evaluated.
• The scope and variability of the organization’ processes have been determined.
• The needs for the organization’s process framework have been determined.

Steps

Process Framework Needs Assessment typically involves the process team performing the following steps in an iterative, incremental, and parallel manner:

• Read Documentation.
  Read any existing organizational documentation that may influence the organization’s needs for processes:
  • Contract
  • Statement of work (SOW)
  • Business or application vision statements
  • Requirements specifications
• Evaluate Stakeholders.
  Interview representatives of the relevant kinds of stakeholders that may influence the endeavor’s needs for process:
  • Identify the major categories of [potential] stakeholders of the endeavor.
  • Set up interviews with representatives of these categories of stakeholders.
  • Interview the stakeholders to determine their expectations, desires, and needs.
• Determine Process Drivers.
  Based on readings, interviews, and experience, answer the following questions:
  • Kind: What kind of endeavor is it?
    • An enterprise?
    • A program?
    • A project?
  • Mission: What is the mission of the endeavor?
    • To produce one or more business models?
    • To reengineer a business enterprise or organization?
    • To develop one or more applications?
    • To operate one or more applications?
    • To support one or more applications?
    • To maintain one or more applications?
    • To retire one or more applications?
    • To develop a framework of reusable components?
    • To develop a reuse capability?
  • Size and Complexity: What is the size and complexity of the endeavor?
    • How big and complex is the business model in terms of business objects use cases, and/or processes?
    • How big and complex is the business in terms of products and services, customers, organizations, facilities, business processes, etc?
    • How many programs are there in the enterprise? How many applications are there in the program(s)?
    • How big and complex are the applications in terms of their requirements, use cases, components, classes, work products, etc? How interrelated are the components and classes?
    • How big and complex is the framework in terms of its components and their interactions?
    • How complex is the endeavor in terms the technology used?
  • Importance: How important is the endeavor?
    • Business critical or safety critical?
    • Important?
    • Quick and dirty R&D effort?
  • Quality: How important is the quality of the work products?
  • Schedule: How tight and inflexible is the schedule and its associated milestones?
  • Experience: How experienced are the stakeholders (especially the development, customer, and other relevant organizations) in terms of process (e.g., CMM level)?
• Categorize Process.
  Based on the documentation, stakeholders, and process drivers, categorize the endeavor process in terms of the required amount of process and the required degree of process formality:
  • Light-Weight Process – Some projects are simple, small, short duration (e.g., a few weeks), and not business critical. Such projects can be staffed with small teams. Because staffing will be small (e.g., 1 to 5 persons), developers will be forced to wear many hats (i.e., play many roles). Such projects cannot justify the overhead of a large, complex, formal process. Instead, they can succeed with only a minimum amount of process formality. Examples of such projects include:
    • The creation of a quick-and-dirty research prototype that is not intended to evolve into a production application.
    • The creation of a quick-and dirty version of an application created to meet a tight market window that is intended for rapid replacement by a well-engineered version of the application.
  • Medium-Weight Process – Many projects are of medium complexity, size, and criticality. Staffing may range between 5 and 20 persons, and duration may be between a few weeks to six months. Such projects require and can justify a medium amount of process formality. Examples of such projects include:
    • Standard electronic storefronts that can be provided by integrating and configuring standard COTS components.
    • Back-end support applications that will be used by customer staff rather than the customers of the customer.
  • Heavy-Weight Process – On some projects, failure is not an option. Such projects tend to be highly complex and very large in terms of both application and required staffing (e.g., over 20 persons). Such projects also tend to be of long duration (e.g., over six months). The applications produced by such projects tend to be business critical to both the customer and the customer’s customers (i.e., the various user organizations). On such projects, quality is critical. Such projects can justify the overhead of a large, complex, formal process, and will use the majority of the process components provided by OPF. In fact, such projects are often required by contract to conform to governmental (e.g., FIPS) or international (e.g., ISO, ANSI) process standards. Examples of such projects include:
    • Safety critical applications such as air traffic control, avionics, power-station control, medical instrumentation, military applications, etc.
    • Business critical applications involving large sums of money such as banking, insurance, business to business (B2B) electronic marketplaces, etc.

Techniques

Process Framework Needs Assessment can typically be performed using the following techniques:

• Reading
• Interviews with project stakeholders
• Experience with similar projects
• Process needs assessment checklist.

Work Products

Process Framework Needs Assessment typically results in the production of the following work products:

• Partial method description document including front matter, introduction (e.g., references, stakeholders), process drivers, and process categorization.

Guidelines

• Different organizations have different needs for a process framework in terms of the size, complexity, and criticality of its endeavors.
• Hire a methodologist as a consultant if the process team has inadequate training or experience in assessing the endeavor’s needs for a process framework.