Task: Assess Target Organization
This task describes how to assess the current status of an organization and to describe it in terms of current processes, tools, people's skills, market environment.
Disciplines: Business Modeling
Purpose
  • To describe the current status of the organization in which the application is to be deployed, in terms of its current process, tools, people's competencies, people's attitudes, customers, competitors, technical trends, problems, and improvement areas.
  • To motivate why the target organization must be engineered.
  • To identify stakeholders to the business modeling effort.  
Relationships
RolesPrimary Performer: Additional Performers:
Outputs
    Main Description

    In order to choose the most efficient path through business modeling, you need to understand the current state of the target organization in terms of its people, processes, and tools. The goal of this task is to understand problem areas and improvement potentials, as well as any information on external issues such as competitors, or trends in the market. When this task is complete, you should know:

    • The current state of the target organization.
    • What kind of people there are, their levels of competence, skills, and motivation.
    • Which business tools are currently used in the target organization.
    • To what level current business processes are described and followed. 
    • What areas have the best improvement potential. 

    The reasons for assessing the current state is so you can:

    • Choose which business-modeling scenario (see Concept: Scope of Business Modeling) to follow.
    • Identify which areas should be considered first.  
    • Motivate why you need to change (if you need to change) process, tools, and people in the target organization.
    • Create motivation and a common understanding among the people in the target organization that will be directly or indirectly affected by the changes.

    This task is only adding value if you are doing business modeling in order to engineer your business. If you are only building a chart of an existing organization in order to derive system requirements, a full assessment is not necessary. See also Concept: Scope of Business Modeling

    Steps
    Initiate an Assessment

    It is recommended that you initiate the assessment with a workshop where you gather the key stakeholders (known at that time). The primary purposes of such an initial workshop is to make the business analysts meet the stakeholders of the business-modeling effort, and to gather a comprehensive list of problems from stakeholders of the project. See Guideline: Assessment Workshop, for details on how to conduct such an initial workshop.

    Identify the Stakeholders

    Identify the stakeholders to the business-modeling effort. Identify stakeholders outside the target organization, such as:

    • Customers. Who are the customers? What requirements do customers have on the products, in terms of time-to-market, features, security, robustness and safety, and complexity.
    • Competitors. Who are the competitors? In which areas are the competitors strong? What can be learned from competitors?
    • Other stakeholders. Are their any other stakeholders involved? Are suppliers and partners involved? Are relationships with them a problem? Are there people with strong influence and opinions that need to be kept in the loop to avoid surprises?

    Identify stakeholders within the target organization, such as:

    • Project managers
    • Sales people
    • Customer representatives
    • Marketing people

    Ask each stakeholder (representatives) what his or her expectations are on the target organization. This can be done either as part of and assessment workshop, or in the form of a questionnaire. 

    Interview people to understand their attitudes towards change. If people are negative or skeptic towards the change it is impossible to succeed with the change, unless you can turn the negative attitudes into positive.

    You must analyze and quantify your customers' present and future expectations. Do not make assumptions about customer expectations-get the information from the customers. You can either interview the customer, more or less formally, or you can use other market-research techniques, such as telemarketing.

    Describe the Structure of the Target Organization

    Describe briefly the structure of the organization, the roles, and teams they currently have. Also look at the relationship between different parts of the target organization. For example, what is the relationship between sales and maintenance; or between product development and sales?

    It may be inviting to use the business-modeling notation to present this information, but it is often better to use whatever description style the stakeholders are accustomed to, be it text, 'org charts', or the Unified Modeling Language. 

    Identify Key Persons

    Identify any key persons in the target organization. A key person is a person who has one or several of the following characteristics:

    • Has the "ear of the masses".
    • Can act as mentor.
    • Is an expert in some area(s).
    • Is opposed to the business-modeling effort.
    • Is responsible for the budget.

    To succeed with a business-engineering effort it is important to have the key persons on board. You will need to involve them:

    • During the rest of the assessment to gather information.
    • As experts to help identify changes to the target organization.
    • To contribute in a pilot project, then be mentor.

    Notice: Watch out for people that want to discuss principles of business modeling, rather than implement an effective new organization.

    Assess Business Idea and Business Strategy

    Most organizations have their business idea and strategy well documented. In the case where you are documenting "virtual" target organization (meaning that you are doing business modeling to understand the business processes of your target customers in order to build better products), this step could be excluded. 

    Explore the strategy to assess:

    • Whether current processes are in line with the strategy. 
    • Whether it is concrete enough to be understood by the people working in the organization. 
    • Whether it is measurable. 
    • If it is perceived as realistic. 

    See also Guideline: Target-Organization Assessment for more information. 

    Benchmark

    Determine the following:

    • Who to benchmark. If you are aiming at a detailed benchmarking effort, you would look for non-competitors, but still with sufficient similarities. 
    • What metrics to use for benchmarking. Relevant metrics are often a combination of time, cost and quality. 
    • How to perform the benchmarking - is it a partnership with another organization, or will it be enough to look for public information?

    See also Guideline: Target-Organization Assessment for more information. 

    Measure Target Organization

    Measuring an organization is about understanding its business processes and measure them. You need to consider the following:

    • Define a set of metrics to use that are a good mix of customer perceived metrics (such as delivery punctuality) and internally perceived metrics (such as production costs). 

    • Determine who to collect metrics from. 

    • Define effect means of collecting the metrics - it has to be easy and as little "intrusive" as possible, otherwise people will not consider themselves having time to give it. 

    See Guideline: Target-Organization Assessment for more information. 

    Identify the Underlying Reasons for Change

    Ask the stakeholders why they want to change their business processes and business tools. The following are some typical answers, and the effect they have on how you choose to explore and introduce the business processes:

    • "We want to use this new technology and need to know how it affects our way of working."
      An example could be a company that has decided to build an e-commerce web-site. The least controversial way of approaching this is in many cases to consider the changes as a new line of business, rather than a change of an existing set of business processes. 
    • "We need to make our business processes more effective to meet the competition."
      In this case you need to ask some follow on questions to understand to what degree you need to become more efficient - are we talking about minor improvements, or about major rework and lots of new kinds of technology support. You also need to understand who those competitors are, and what kind of metrics is used to compare. 
    • "Our old legacy systems are breaking in the seams and we need to replace them before they burst." This also requires some follow-on questions to understand whether there is an expectation the business processes will change or not. If not, the approach is often to perform some high-level business modeling to get a map of the current organization, sometimes a domain model may suffice. 
    Estimate the Capacity for Change

    Analyze the capacity for change in the target organization. Organizations just like individuals can accommodate change but only within a limited range. Some organizations are better prepared for change than others are. To understand the organizational capacity for change we recommend that you interview the people in the organization, to understand the attitudes, and willingness to change.

    Factors to consider are:

    • Whether there is a wariness of current conditions - the risk then is that any suggested change is perceived as being for the better and not properly questioned. 
    • Whether there is a wariness of change - the organization may have gone through several reorganizations for various reasons that were not perceived as successful by the stakeholders. In this case any suggested changes need to be made rather concrete and be well motivated in order for people working in the organization to even consider whether they are of any value. It is also of value to explore why previous change efforts were not successful.
    • What are the general attitudes among people working in the target organization. Are they "young and hungry" or "experienced and settled"? 
    • Whether the target organization is an existing one, or whether it is something intended to be build from scratch. If the latter, you need to understand the intended capabilities of people in the new organization, and how much of ramp-up time it would be possible to give them. 

    In additions to the soft factors mentioned above, you should also assess the readiness for any new technologies, such as those needed to build an e-business solution. Examples of such technologies are [CONA99]:

    • Client/server.

    • Database management.

    • Programming languages, such as HTML, XML, Java.

    • Scripted server pages and servlets, such as Microsoft's Active Server Pages, Java Server Pages.

    • Object communication protocols, such as OMG's Common Object Request Broker Architecture (CORBA), the Java standard Remote Method Invocation (RMI), or Microsoft's Distributed Component Object Model (DCOM).

    • Components, such as Microsoft's ActiveX/COM.

    • Web applications frameworks, such as IBM's WebSphere or Microsoft's Windows DNA.

    This assessment will strongly influence the level of risks you should be willing to take when forming the architecture of your solution.

    Identify Problems

    The best way to identify problems is to gather a number of key people for a problem-identification session. See Guideline: Brainstorming and Idea Reduction, for general advice on how to organize such a session.

    Ask questions such as:

    • What are the problems in the target organization?
    • Is there a perception that something is broken?
    • Are projects routinely behind schedule or over budget?
    • What problems do they have?
    • Have any metrics been collected that can be analyzed?

    Identify what negative effects each problem has, or will have, if it is not eliminated or reduced, for the projects. To know the effect of a problem helps you understand how critical it is to eliminate or reduce the problem.

    Identify root causes of each problem. To know the root causes of a problem helps you understand how to remove or reduce the problem, and how much it will cost. Fishbone Diagrams may be of help. If there are several root causes to a problem you need to weigh them against each other, in which case Pareto Diagrams may be of help. 

    Warning: It is very common to rush headlong into defining the solution, rather than taking time to first understand the problem. Write down the problem, and see if you can get everyone to agree on the definition.

    Rank the problems with respect to the effect they cause. For example, use a 1-to-5-scale, where 5 is for problems with the most dangerous effect, and 1 is for harmless problems. The primary purpose is to understand the relative importance of the problems.

    One of the simplest ways to gain agreement on the definition of the problem, is to write it down and see if everyone agrees. List the problems in a table:

    Problem 

    Effect 

    Root causes 

    Ranking 

    The quality of the delivered software is bad. 

    - The customers are dissatisfied.
    - We have to release bug-fixes after the main release. 
    - The test cases does not provide complete coverage.
    - Testing is not automated.
    - The test people are not adequately trained. 

    #5 

    ... 

    ... 

    ... 

    ... 


    Draw Conclusions

    Analyze the results of the collected information and compile a list of areas and issues to focus on. Issues that should be addressed early usually fall into one or several of the following categories:

    • Major problem areas. Areas where you can improve the performance of the business processes a lot.
    • Areas where you can make short-term profits. Areas where you can show fast results.
    • Areas where an improvement will have high visibility.

    Document the gathered information and the conclusions in the Artifact: Target-Organization Assessment.

    Make Recommendations

    You need to include some recommendations for the future as part of the assessment. The recommendation should describe what approach to take to business modeling. See Concept: Scope of Business Modeling for a set of typical scenarios.



    More Information