Method Needs Assessment

Definition

Method Needs Assessment

the process engineering task during which the process team performs endeavor analysis, organizational analysis, product analysis, and process formality risk analysis and comparison to determine the specific needs for the method

Classification

As illustrated in the preceding figure, Method Needs Assessment is part of the following inheritance hierarchy:

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

Responsibilities

The typical objectives of the method needs assessment task are to:

• Evaluate the endeavor’s documentation and stakeholders.
• Determine the endeavor’s process drivers.
• Categorize the needed process in terms of process size, complexity, and formality.

Preconditions

Method needs assessment typically can begin when the following preconditions hold:

• The endeavor is started.
• The process team is adequately:
  • Staffed.
  • Trained or experienced in method needs assessment.
• Relevant documentation and stakeholders are available to provide information required to assess the needs for the endeavor’s process.

Completion Criteria

Method needs assessment typically is complete when the following postconditions hold:

• The endeavor has been evaluated.
• The needs for the endeavor’s process have been determined and documented.

Steps

Method needs assessment typically involves the process team performing the following steps in an iterative, incremental, and parallel manner:

• Read Documentation.
  Read any existing endeavor documentation that may influence the endeavor’s needs for a method:
  • Contract
  • Statement of work (SOW)
  • Business or application vision statements
  • Requirements specifications
  • Customer or development organization process standards and guidelines.
• Evaluate Stakeholders.
  Interview representatives of the relevant kinds of stakeholders that may influence the endeavor’s needs for a method:
  • 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 with regard to process.
• 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 reusable component?
    • To develop a reuse capability (e.g., reuse repository, reusable components)?
  • 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, business use cases, business processes, and/or business tasks?
    • 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 systems and 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?
  • Organizational Readiness: What are the characteristics of the organization that will influence the process that can be used effectively?
    • What is the organizational culture? Is the organization used to using a mature, relatively formal process? Are the developers primarily "cowboy" coders who are used to doing the work however they individually please? Is teamwork or individuality more highly valued. What is the usual management style: autocratic or delegatory? Is reuse ad hoc or organized?
    • What technology is the organization used to using? Has the organization mastered object-oriented or component-based development? Are leading- or bleeding-edge technologies embraced or avoided? Is twenty-year-old technology the norm?
    • Are resources available for new tools and training?
  • 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

Method needs assessment can typically be performed using the following techniques:

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

Work Products

Method needs assessment typically results in the production of the following work products:

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

Guidelines

• Different endeavors have different needs for process in terms of process size, complexity, and formality.
• Hire a methodologist as a consultant if the process team has inadequate training or experience in assessing the endeavor’s method needs.
• This task is typically performed iteratively, incrementally, and in parallel with the method needs assessment, process tailoring tasks, and process documentation task.
• The results of this task are documented in the process description document as part of the process documentation task.