Project mission and objectives

Before you start with this section, please read from the textbook

• Chapter 3.

This section will highlight some of the key issues from the textbook. The following section will extend the content of the textbook and deal with “user requirements analysis”, “requirements specification” and “system specification”.

At the beginning of each project, you will have to define what the project is all about. The crucial issue is that, typically, two parties have to agree on this: the provider of the project as well as the customer or requester of the project. Many projects have problems or fail due to not clarifying the project mission and objective in the beginning. Non-communication and an only vague common understanding can evoke:

• Dissatisfaction of the customer with the project results
• Dissatisfaction of the customer with the project provider
• Time-consuming and nerve-wracking discussions during the project
• Changes in the project plan, extra work and deviations from the schedule.

The textbook (Wysocki 2009) briefly outlines the process to manage client expectations by developing “conditions of satisfaction”. This might be sufficient for projects with little (technical) complexity, but IT projects require a much more detailed analysis of the user requirements. Therefore, this issue will be separately discussed in section 2 of this module.

An appropriate approach for achieving and documenting a mutual understanding of the project on a high level is to develop a common Project Overview Statement (POS). The POS is a short document, possibly with supporting annexes. This POS helps to manifest expectations of the stakeholders. The POS contains the following parts:

Background (problem/opportunity):

An organization or person paying for a project expects that the project costs will be lower than the expected business revenue. IT projects mostly have two major possible backgrounds:

• Making internal workflows more effective
• Offering new or better services and products to customers.

No matter, if the approach is problem-oriented (inefficient workflows) or opportunity-oriented (new services), the overall motivation for starting most projects is in costs or, better, saving costs.

At least partly, this can also be considered for research projects in academia. Apart from some projects in very basic research, the motivation of funding organizations, e.g., European Commission, is, besides other aspects (e.g., social aspects), to improve the economy and competitiveness of European industry.

Mission (goal):

Typically, a project has ONE mission (or goal). The mission describes on a very high level, what the project is supposed to achieve. A mission statement should be

• Clear, relevant, and understandable
• Contain a realistic and measurable overall result of the project
• Inform about the responsibilities for completion
• Contain a time frame.

Objectives:

The objectives describe the targeted outcomes of the project in more detail. The objectives split the mission statement into a set of more manageable parts. Objectives should make clear, what is in the project and what is out. An objectives statement should describe for each objective

• Measurable result
• Time frame
• A method (or action plan) how to achieve the objective.

The following examples for a mission and objectives statement might not be perfect, but at least give an idea about the content:

• TEMPUS program of the European Commission, http://ec.europa.eu/education/programmes/tempus/index_en.html
• BRIDGE-IT project, funded by the European Commission, http://www.bridge-it.info/

Example 1: The Tempus programme

The Trans-European mobility scheme for university studies enables universities from EU Member States to cooperate with those in Western Balkans, Eastern Europe and Central Asia, and the Mediterranean partner countries in higher education modernisation projects. Established in 1990 following the fall of the Berlin Wall, Tempus has been renewed three times (Tempus II, Tempus IIbis and Tempus III – 2000 to 2006). Today, more than ever, there is need to enhance understanding between cultures, and for the European Union to work together with its partner countries in the field of higher education.

Objectives

Mutual understanding

Tempus strengthens cooperation in higher education between the European Union and its partner countries from the Western Balkans, Eastern Europe and Central Asia, the Mediterranean region and enhances understanding between cultures. As the Tempus III Council Decision (of 29/04/99) states: "cooperation on higher education strengthens and deepens the whole fabric of relations existing between people, brings out common cultural values, allows fruitful exchanges of views to take place and facilitates multinational activities in the scientific, cultural, artistic, economic and social spheres."

Cooperation

Tempus promotes the “people to people” approach: its added value lies in its promotion of international and regional co-operation, which generates better communication and new networks of personal and professional contacts between the academic worlds of the EU and the partner countries. For example, in Central and Eastern Europe, Tempus Phare helped ‘more than 70,000 staff receive training in European Union countries. [They] …worked together with the almost 50,000 European Union colleagues who visited their institutions. Many among them are now heads of departments, deans, vice-rectors, rectors…These are the people who today are shaping tomorrow’s academic environment. That they do so from a strongly international perspective is only one example of how Tempus continues to have an impact on higher education in Central and Eastern Europe".

Higher Education modernisation

The Tempus programme is designed to support the transition and modernisation processes in higher education through a range of interventions. It is a key instrument to consolidate the objectives pursued by the EU Tacis, Cards and Meda cooperation programmes. With the introduction of Structural and Complementary Measures, Tempus aims at having an impact on higher education national policies, and following national higher education priorities.

(Please keep in mind, that this statement is for a PROGRAM, not a PROJECT! Therefore, it is less specific than it should be for a specific project.)

Example 2: BRIDGE-IT project

The main goal of this project is to develop innovative geo-server technologies enabling seamless efficient geo-data content collection and multisource integration, management and dissemination, independently of proprietary GIS technology for geo-based applications and services.

Success criteria:

If you think back to the section “Background”, the motivation of most of the projects is business revenue. Therefore, also the success criteria of the project (on the high level of the POS) are business oriented. Success criteria can be increased revenue, reduced costs, or improved services (Wysocki 2009).

Example 3: Tourist Information System:

The introduction of an online tourist information system for the City of Münster (replacing the traditional call center for these tasks) could have the following success criteria:

• Increased number of persons using the touristic service (500 persons per month)
• Increased number of tourists visiting Münster (5 % per year)
• Reduced costs for providing the services (5.000 € per month).

Assumptions, risks, obstacles:

At the beginning of a project, it is most important to communicate and to clarify the assumptions of each of the project parties: customer (requester) and provider(s).

Risks and obstacles are very specific for each project. They might occur on several levels: organizational problems at one of the project partners’ sites, technological risks, relationships between team members and between project partners, acceptance of new system or product in the environment of the customer.

Example: Taking again the example of the introduction of an online tourist information system for the City of Münster, assumptions could be:

• The investment return from sponsor advertisements will cover the operational costs of the online information system.
• Information will be provided in German AND English.
• An updated dataset of cadastral data will be available at a certain date and will be passed to the project provider by the City of Münster.

Risks and obstacles could be:

• Integration and interoperability with existing software components from the City of Münster might cause problems.
• Tourists will still prefer calling by phone to get some touristic information instead of using an online solution.

Annexes:

Depending on the nature and complexity of the project, additional annexes might be required for the POS, for example, a detailed

• Risk analysis
• Analysis of financial feasibility and risks.

User requirements analysis, requirements specification and system specification

In the textbook (Wysocki 2009), the Project Overview Statement (POS) is the first approach to achieve consensus between employer and client. However, in IT projects, this step is more complex and more defined. For the development of a software system, it is most important to start with an analysis of the user requirements. The analysis leads to a specification of the requirements, proceeded by a specification of the targeted system.

User requirements analysis

The success of each project outcome depends on the acceptance by the people who it is made for. Consequently, their needs must be known in order to be successful. The goals and the nature of a project have to be defined by the needs that the intended users have for the targeted project result; they give the direction of where to go. On the one hand, this means having a look at what people want to get out of a project (services and products), and, on the other hand, it means thinking about how they get it (interaction).

There are many explicit methods for user requirements analysis, but a more detailed discussion would exceed the framework of this course. As an additional reading, you can find some introductory information for requirements analysis in IT project at Wikipedia, http://en.wikipedia.org/wiki/Requirements_analysis.

However, you should at least know more about the importance of performing a user requirements analysis. Before you proceed, please read the following short (and sometimes funny) article:

Sim D'Hertefelt (2000): 13 common objections against user requirements analysis, and why you should not believe them. InteractionArchitect.com. http://users.skynet.be/fa250900/articles/article20000609b.htm

Requirements specification and system specification

It is common sense that in IT projects there has to be a specification of the (software) product to be developed. There a many definitions of terms and contents, which base on varying theoretical concepts and many different types of projects.

For specifying the targeted product of an IT project, this text bases on the German Industry Norm (DIN) for projects (DIN 69905). It defines two types of specifications:

1. The requirements specification defines WHAT has to be developed and why. It reflects the perspective of the customer of a project.
2. The system specification defines HOW it has to be developed and with which resources. It reflects the perspective of the contractor of the project.

In the following, we provide examples how requirements specifications and system specification could look like:

Requirements specification:

1. Background and definition of goals

2. Application of the targeted product

3. Product overview

4. Required functionalities

5. Product data (information about “amounts”, e.g., number of users, number of processed data sets)

6. Product capacity and output

7. Quality requirements

8. Additional requirements.

System specification:

1. Introduction

1.1. Motivation for the project

1.2. Goals of the project, including

1.2.1. Mandatory criteria (k.o. criteria)

1.2.2. Should criteria

1.2.3. Could criteria

1.2.4. Boundary criteria (for being in or out of the project)

1.3. Project environment

1.4. Resources

2. Current state (as-is analysis)

2.1. Technical environment

2.2. System, hardware, interfaces

2.3. Workflows and system processes

2.4. Organizational environment

2.5. Documentation and information paths

3. Assignment of tasks (to-be analysis)

3.1. Summary, structure

3.2. Workflow description

3.2.1. Introduction phase

3.2.2. Operational mode

3.3. Data, data amounts, data security, data management

3.3.1. Description of processed data

3.3.2. Description of system data

3.3.3. Communication

3.4. System tasks

3.4.1. Functionalities

3.4.2. Updating

3.4.3. Reliability

3.4.4. System management/administration

4. Interfaces

4.1. Overview

4.2. System processes

4.3. Man-machine interaction

4.4. External systems

5. Technical requirements

5.1. Data processing

5.2. Data management

5.3. Software

5.4. Hardware

5.5. Hardware environment

5.6. Overall system

6. Organizational requirements

6.1. Workflows

6.2. Personnel

6.3. Maintenance

7. Quality assurance

7.1. Quality standards and certification

7.2. Software quality

7.3. Hardware quality

8. Project organization

8.1. Communication

8.2. Management

8.3. Work packages and processes

8.4. Documentation

9. Annexes, e.g., glossary, abbreviations.

The description above is ONE of many different definitions of terms and contents. Fuzziness results of several factors:

• There is a mixed use and understanding of the terms requirements specification, system specification, specification.
• Contents and detailedness vary widely due to different understanding of the terms and different complexity of a specific project.
• The know-how of customers differ widely. In some projects, customers will need support to formulate even basic features of a requirements analysis. In other projects, customers will provide a requirements specification, which already contains most of the features of the system specification.

However, no matter how it is called, and who is providing it: The content of these specification has to be developed and documented before starting a project.