The Importance of Technology Management in the ICT ...€¦ · importance of technology management...

The Importance of Technology Management in the ICT Requirements Definition Process

Ari Lindén

Tampereen teknillinen yliopisto, Porin yksikkö, Finland Abstract--The research will concentrate on the importance of

technology management in the ICT (Information and Communications Technology, especially Telephony Technology) requirements definition process, focusing on the words (terms and features) occurrence in requirements specifications.

The importance of technology management among companies has grown. Technology terms are still very poorly understood and features behind the terms cause confusion and difficult situations for the people concerned. Very technical terms and features are difficult to handle, present, understand, or discuss, because the vocabulary is not the common language of the people in the organization. Requirements specifications, if they occur, are offered in formats, with language, terms, and features, which it may take time to really understand the purpose of or to deal effectively with. This lack of knowledge or information may cause major misunderstandings.

While there are very complex technical services or products, the importance of features are very significant items to solve and discuss, to avoid the possibility that participants do not understand each other.

Technology has grown so complex that we need external consultants and experienced specialists to co-operate with the people from the procurement unit to solve the terms, features, needs, and requirements. Terms, features or needs and requirements are presented in a way that there is a huge risk of understanding them in different ways.

What has happened to technology management in companies nowadays?

Our focus is on researching public procurement units that use very complex technology procurements. The main focus is on the national level, but as we can read from articles and other informative channels, the importance of the whole procurement market is worldwide issue.

We wished to search for more reliable and accurate information about the calls for tenders that we found [36], [37] and [38] to overcome a major lack of requirements specifications and other challenges and shortcomings.

In this study, the phases and results of the whole study were limited in order to keep the focus on the topic “The Importance of Technology management.”

The language used in the calls for tenders (cases) was Finnish.

I. INTRODUCTION (BACKGROUND OF THE STUDY)

In Finland, public sector procurement is worth about 25 billion euros (2010), which is about 19% of GDP (Gross Domestic Product), increasing annually by 6-7%. Total expenditure (works, goods and services) on public procurement has increased every year [44]. Also, the estimated value of calls for tenders published in TED (Tenders Electronic Daily) by E.U. member states is growing

[44]. Private contracts are important too, but they are not regulated by comprehensive legislation.

The qualitative research focused on public tenders in Finland between 1.6.2007 (the new acquisition law dated 1.6.2007) [1] and 2012, consisting of more than 100 000 tenders. We made some restrictions with CPV (CPV – Common Procurement Vocabulary) 64000000-6 (Postal and telecommunications services) and included very technical (Analog, Digital, IP (PBX – Private Branch eXchange), MSC – Mobile Switching Center (Mobile PBX), Hybrid Center (PBX + MSC) and their Services) calls for tenders in our research. The case research material used covers 103 calls for tenders focusing on a highly technical sector (ICT – Information and Communications Technology, Telephony Technology).

We studied the call for tenders documentation and tender documents to find out the status (occurrence) of the importance of technology management regarding (words, terms and features) in the ICT requirements definition process, [50] [30] (especially requirements specifications).

Our research is restricted to the requirements definition process in public procurement units. We concentrate to the very complex technology acquisitions used in public sector procurements and large ICT-companies. This paper and its results focus on the targeted research statement.

This paper will first present a brief review of earlier research, with major observations from cases where technology management has been ignored and also what other researchers have found or expected to happen when this behavior occurs. After that the research and the findings of research concerning the importance of technology management will be presented.

This research is an independent part of one major piece of research: one that is studying the call for tender process used in public sector procurements and large ICT companies. The researcher has experience of 30 years in business, ICT projects and project management in the private sector, dealing with public procurements and acquisitions. According to experience gained during this period, the importance of technology management has an impact on the results and the findings of the ongoing research (survey and case analyses) confirm this.

Additional information and research results are presented along with findings concerning key subjects reported in earlier papers [34], [35], [36], [37] and [38].

2283

2013 Proceedings of PICMET '13: Technology Management for Emerging Technologies.

II. LITERATURE REVIEW

The term Technology is interpreted very widely in order to meet the demands of this research and find out the results that we wish to know. However, we have made some definitions and exclusions to understand the terms and topics used to keep the main focus on the subject.

In the literature review, many published definitions of Technology, Technology Management and Management of Technology were found with some variations of both terms, e.g. (Kleine [28], Bhalla [4], Steele [55], Dussauge [14], Betz [3], Floyd [18], Phaal [42], Liao [33], Schilling [52])

Kleine [28] defines Technology as follows: “It is important and deals with areas such as, a) manufactured articles (hardware), b) manufacturing hardware (sociotechnical system of manufacture), c) knowledge, technique, methodology or ’know-how’ and d) sociotechnical systems of use”.

Bhalla [4] wrote a good book on early Industrial Technological Innovations and Management. He concentrates on innovative and strategic planning issues.

Steele [55] offers a very expressive explanation of the term Technology, “Technology is the system by which a society satisfies its needs and desires”.

Dussauge [14] and many others introduced the concept of Strategic Technology Management. The main focus of Dussauge’s book is on product technology. Product development and use of technological capabilities play a key role.

Betz [3] is one of those who have developed the concept of Strategic Technology Management. Betz thinks that: “For good management, the general principles of management must be adapted and refined to the special conditions of the process being managed.”

Floyd [18] gives us a definition of Technology, “Technology is the practical application of scientific or engineering knowledge to the conception, development or application of products or offerings, processes or operations.”

Phaal [42] gives us a slightly different point of view, when he talks of Technology road mapping: “Many managers are aware of the strategic importance of technology in delivering value and competitive advantage to their companies and the industrial networks in which they operate. These issues are becoming more critical as the cost, complexity and rate of technology change increases, and competition and sources of technology globalize. The management of technology for business benefit requires effective processes and systems to be put in place to ensure that existing and potential technological resources within the organization are aligned with its needs, now and in the future.”

Liao [33] thinks that Technology management: “is a process, which includes planning, directing, control and coordination of the development and implementation of technological capabilities to shape and accomplish the strategic and operational objectives of an organization.”

Schilling [52] describes Strategic Management of Technological Innovation issues. Her book is the number one in the field of innovation strategy in the world. Since Innovation and Strategic Management issues have grown in significance, these are issues that we also have to examine.

The term Technology management [11] [12] is defined as follows: “Technology Management is the field concerned with the supervision of personnel across the technical spectrum and a wide variety of complex technological systems. Technology Management degree programs typically include instruction in production and operations management, project management, computer applications, quality control, safety and health issues, statistics, and general management principles.”

It is defined by the European Institute of Technology Management (EITM) [15] as: “Technology management addresses the effective identification, selection, acquisition, development, exploitation and protection of technologies (product, process and infrastructural) needed to maintain [and grow] a market position and business performance in accordance with the company’s objectives.”

The term Technology management meets the following definition in many publications: “The main target of Technology Management is aimed to find, investigate and make suggestions of new technologies to be used in order to develop or enhance the profitability of the current product.”

ICT (Information and Communications Technology - or technologies) incorporates a very wide field.

ICT is a term that covers any communication devices or applications, cellular phones, computer hardware and software, network hardware and software, plain systems, services that are required to meet needs, applications associated with them (such as management applications, phone conferencing, videoconferencing, call centers, contact centers, control services, etc.), tools that are needed to keep the system alive and make changes, integration issues into other systems, information issues and reporting tools and portals.

ICT Management frameworks are management tools that provide best practices and proved standards for the successful strategically, technical, organizational, and legal management of ICT services and infrastructure.

TOGAF [59] (The Open Group Architecture Framework) is a proven enterprise architecture methodology and framework used by the world's leading organizations to improve business efficiency. It offers many tools and information, e.g. Technology Architecture Requirements Specification (e.g. Phase D).

Zachman [63] is an Enterprise Architecture [41] framework for enterprise architecture and it provides us a way of viewing and defining an enterprise [23]. It is a two-dimensional classification matrix and is very useful with other frameworks.

Gartner offers an enterprise architecture framework (GEAF) [20] that we have used in our research, e.g. the Gartner IT Market Clock. The definition of GEAF is stated in

2284


many articles: “Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise’s future state and enable its evolution.” A shorter definition is as follows: “Enterprise architecture is the process that interweaves business and IT together.”

The US Federal Enterprise Architecture Framework (FEAF) [62] provides a sustainable mechanism for identifying, developing, and documenting architecture descriptions of high priority areas built on common business areas and designs that cross organizational boundaries. FEAF offers these viewpoints: business, design and focus of data (what), application (how) and technology (where). FEAF offers many viewpoints to approach the definition, selection, and assessment of requirements [17].

We have studied many other frameworks, architectures, standards, models, and recommendations as well as examining the literature and article databases. COBIT (Control Objectives for Information and Related Technology) [8] supports IT governance. ITIL (Information Technology Infrastructure Library) [25] provides a systematic and professional approach to management. CMMI/ CMM (Capability Maturity Model Integration) [6] aims to improve software development processes, thus it is commonly used in other processes too e.g. business processes.

REQM (Requirements Management) [47] is widely used. Its purpose is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products. eTOM (enhanced Telecom Operations Map) [16] is better known in the telecom business. It is published by the TM Forum and is a guidebook that defines the most widely used and accepted standards for business processes in the telecommunications industry.

Some standards were also examined to find out what items, topics and discussions met our needs. They were: ISO 20000 Standards IT Service Management; ISO 20000-1, which is the “Specification for Service Management; ISO 20000-2, which is the 'Code of practice for Service Management”; ISO 27001 Standard (Information Security Management); and ISO 12207 Systems and software engineering — Software life cycle processes.

We also took a quick look at the ICT Standard for Management (ICT Standard Forum) and the PMBOK (Project Management Body of Knowledge).

Some models were studied to find out the most important viewpoints to meet our research needs. Models such as the performance reference model (PRM), business reference model (BRM), service component reference model (SRM), data reference model (DRM), and technical reference model (TRM) offered us description of the common taxonomy and ontology of IT resources.

In our research we have left the term Technology very wide and open so we can search for a whole set of terms and meanings in call for tender documentation. However, we

would like to point out that we are not treating the term Technology as a type of knowledge, even though it is a very important issue [27].

In our research we regard the term Management to be connected to Technology as the operations and management issues [43] that have to be done and requested in call for tender documentation.

Public procurement units need to publish some notification and information in national electronic notification systems. This notification and information sent to suppliers is called a Request for Proposal (RfP) [46]. Information may also be requested, which is called a Request for Information (RfI).

Some documents can be attached with the call for tender document that offer more information, needs, requirements and options of the acquisition. These documents are called the Technical Specification (TS) [57] and Requirements Specification (RS) [48].

Technical specifications offer information to suppliers on what kind of systems, services, and goods the acquiring party is going to buy. This information is also important when handling requirements. Very complex systems have many attributes to handle and solve so new tools may be required to define needs and requirements [7].

Requirements specifications offer information on all the requirements (mandatory or non-mandatory) [54] that suppliers have to agree with to have their tender considered in the selection criteria and validation phase.

The validity of a technology rests not only on the fulfillment of functional specifications, but also on the interaction of the technical system with its organizational environment [5].

Sometimes there are mentions of options that are the acquirer’s hopes and wishes for later review. Requirements are usually divided into different groups. These groups vary greatly, but in the literature there seem to be several groups [24] that appear frequently, functional, non-functional, quality, and options.

III. METHODOLOGY

The study data was collected partly from the Public Archive (Credita) [9] with the other part consisting of the case company's archive of received calls for tenders (PRIVATE SECTOR). The aim of the survey was to analyze all the papers in the same way, although some of the public sector data (case archive) is more accurate because we have all the required papers and information.

We examined the status of requirements specifications in call for tender documents. The objective was to find out how the words (terms and features) are presented in requirements specifications and to study and determine the status of these words (occurrence in requirements specifications). Are there differences between public procurement units regarding these words (especially requirements specifications)? The calls for tenders were studied and we assessed whether it is really

2285


important to discuss and highlight technology management issues in requirements specifications and thus whether technology management is an important issue in very complex public acquisitions.

The empirical part of the work consisted of highly technical cases opened and completed between 1.6.2007 (the new acquisition law dated 1.6.2007) and 2012.

The qualitative case study and content analysis methods were used to find out the results from the case company’s documents. We collected documents (text information) from case company and Credita archive to a database of calls for tenders, classified those with the chosen words (selection criteria) and analyzed the existence of these words to answer research statements. The quantitative research method (statistically descriptive analyses) was used to visualize the results.

The duration of the whole work was 1.6.2007 – 31.12.2012. We wish to focus our research on one full year, which is why we chose the year 2012, since it is also the most recent and the latest “fresh” information, data and articles would be to hand.

The framework for this study includes the following phases and sections [Figure 1].

In this study, the main focus and the definition of the term “technology management” [Figure 2] aims to find out if it is the organization’s strategic intent to create some competitive advantage, to achieve value for money, some development, change or growth.

Innovation issues, safety, integration and lifecycle issues are included in the scope too, because these are the issues that

have been under discussion recently and that the literature has proven to be important. Frameworks that we have searched also address these technology management issues.

Reporting and billing and several statistics issues play mandatory roles in call for tender documents.

Technical system issues (networks, hardware, and software) and tools are the most common issues that we have noticed in call for tender documents.

Information requirements, feature and needs are found inside each framework and architectural model. Operational tasks and operations are in the same position.

Project and processes [22] themselves are important things to observe.

All of these terms are connected to the procurement units’ purpose of tendering for or acquiring something and are therefore found in very complex technical procurements, whereas those that have a meaning for technology management form the main focus of this study.

In this research we tried to clarify the importance of technology management by finding out answers if there was any mention (words, terms and sentences) of technological management issues [29] [51]. We searched for signs of this in separate requirements [50] [30] [31] specifications documents and call for tender documents. Mentions of technology management, business requirements [58] [30] (competitive advantage, value for money, growth), innovative issues [13], lifecycle issues [40], statistics issues (reporting and billing), quality management [53] and issues [19], operations management issues [32] and safety issues [23] [30] [64] were the most interesting and important search items.

Figure 1: Working framework.

2286


Figure 2: Technology Management.

We searched for the occurrence of chosen words (terms and features) in requirements specifications to assess the status of the importance of technology management.

The mandatory issue was to find out the status of the occurrence of requirements specifications [49].

The second mandatory issue was to find out the occurrence of certain words (terms and features) (words 1-12 on the list above).

We decided to ignore the occurrence of monetary and time issues and requirements (0. words) because these occurrences are highly regulated. Even though quality factors are regulated in validation criteria, we wished to know the status of technical or operational quality requirements.

Words (terms and features) [10] [30] that we searched for: 0. Monetary and others (prices, payments, agreements, time

issues, etc.) 1. Operations management or operational issues and

requirements 2. Project or process requirements (term project and

process) 3. Lifecycle management or lifecycle issues and

requirements (term lifecycle) 4. Applications, hardware and network (requirements and

features) 5. Tools (requirements) 6. Information requirements (as- of now, data collection

and conversions, term data) 7. Integration issues and interfaces (term integration and

interface)

8. Quality requirements (technical and operational, term quality)

9. Safety requirements 10. Statistics requirements (reporting and billing) 11. Innovation issues (term innovation) 12. Business requirements (competitive advantage, value for

money and growth) The survey consisted of six phases. 1. Collecting data (public and private archive) 2. Selecting data (case material) 3. Analyzing (case study) the status (occurrence) of

requirements specifications 4. Analyzing (content analysis) the status (occurrence) of

words in requirements specifications 5. Analyzing (content analysis and case study) the

importance of technology management (occurrence) in very complex public acquisitions call for tender documents (especially requirements specifications)

6. Summarizing and visualizing the results First phase

All the case material was collected in a research archive. CPV (CPV – Common Procurement Vocabulary) 64000000-6 (Postal and telecommunications services) was selected and highly technical (Analog, Digital, IP (PBX – Private Branch eXchange), MSC – Mobile Switching Center (Mobile PBX), Hybrid Center (PBX + MSC) and their Services) calls for tenders were included in our research (729).

2287


Second phase In the second phase, the papers and cases were archived

one by one. The primary task in the second phase was to select the papers that met our needs (i.e. highly technical projects, 103 cases). After that, we selected the latest papers for detailed examination (very technical projects, 27 cases), because we wished to know the current status covering one whole year (2012).

In the third, fourth and fifth phases we focused on the research hypotheses.

The following hypotheses are focused on the research statement: Third phase o What is the status of requirements specifications

(occurrence) (case study)? Fourth phase o What is the status (occurrence) of words (terms and

features) in requirements specifications (content analysis)?

Fifth phase o What is the status (occurrence) of the importance of

technology management in very complex public acquisition call for tender documents (especially requirements specifications) (content analysis and case study)?

Sixth phase

In the sixth phase we analyzed the results. The results were summarized and visualized (the summarizing phase, where statistically descriptive analyses were used to visualize the results).

The study and this paper continue with the following sections. 1. In the first section, we clarify some observations and the

status (occurrence) of requirements specifications and the procurement process (hypothesis of phase 3).

2. In the second section, we present the status (occurrence) and some notifications and observations of the words (terms and features) in requirements specifications (hypothesis of phase 4).

3. The third section presents the status (occurrence) of the importance of technology management in very complex public acquisition call for tender documents (especially requirements specifications) (hypothesis of phase 5).

4. The fourth section presents the findings of the study (phase 6).

5. Discussion. 6. Conclusions and description of future research. FIRST SECTION

Some major observations and status of requirements specifications and procurement process

1. The research done in 2010 – 2011 [36] proved that there is a lack of requirement specifications in calls for tenders. In this study we have analyzed technical calls for tender in the public sector (2012, 27 cases where we have all the papers) and noticed that a requirements specification [48] (separate document) had been seen in 81 % of all the technical calls for tender [Figure 3]. There seems to have been some improvement (more separate requirement specification documents) on the findings of the previous research [36]. Every fifth tender had no separate requirements specification document, which meant that requirements were either within the call for tender documents or that there were no requirements at all.

Observation: there seems to be a growing trend to deliver more separate requirements specification documents than in previous years. Conclusion: this is because the acquisitions (systems, technology, etc.) are becoming more complex, the amount of requirements has increased significantly, and the need for a consultant seems to be obvious, which is in fact what has happened (13 cases out of 27).

Figure 3: Requirements specification documents occurrence in 2012 calls for

tenders. 2. There are several procurement procedures to use and we

have found the most common procedure to be the open procedure, although the case material consists of only very technical calls for tenders [Figure 4]. There are procurement procedures that allow tendering negotiations. These ensure that the suppliers obtain the maximum information needed to satisfy needs and requirements. These opportunities are rarely used because it usually takes more time and money [45]. In an open procedure, the procurement unit must collect and write all the information in a dossier of documents and deliver them to suppliers via the public notice channel or similar information channels. There are some other procurement procedures that might be useful but in this work and with these cases, research has been limited to those procedures that have actually been used in said cases.

2288


Observation: there seems to be no change compared to previous years or other countries [2]. Conclusion: the open procedure may be the procedure that procurement units know best.

Figure 4: Procurement procedures used in highly technical projects (cases) in

2012.

3. There is a choice between two methods of assessing offers [21] [44]: o Lowest price o Most economically advantageous tender (MEAT)

We wished to ignore these issues, because the occurrence of these issues and requirements are highly regulated and are therefore clear.

4. In this study we took an in-depth look at the call for tenders and analyzed if there were any requirements either within the call for tender documents or no requirements at all. We then searched the words (terms and features) [Table 1] with some keywords (validated and chosen from framework models) and tried to find occurrences in papers. (* search and queries were made in Finnish)

TABLE 1: LIST OF WORDS (TERMS AND FEATURES).

SUBJECT KEYWORD* WORDS (TERM and FEATURE)* Monetary and others (prices, payments, agreements, time issues, etc.)

“raha*” “maksu*” “aika*”

raha ja valuutta maksuasioihin liittyviä aika-asioihin liittyviä

Operations management “toimin*” toiminta (operational issues and requirements) “halli*” toimintaan ja hallintaan liittyviä Project and process requirements ”proj*” projekti ”proses*” prosessi ”toimit*” toimitus ”käyttööno*” käyttöönotto Lifecycle management or lifecycle ”elinka*” elinkaari (issues and requirements) “päivit*” Applications, hardware and network ”tietol*” tietoliikenne (requirements and features) ”liiken*” liikenne ”verk*” verkko ”kapa*” kapasiteetti ”kuulu*” kuuluvuus ”nop*” nopeus ”omin*” ominaisuus ”yhteens*” yhteensopiva Tools (requirements) ”hallin*” hallinta ja hallinnointi “työk*” työkalujen käyttöön liittyviä Information requirements ”tieto” tieto (as-now, data collection and conversions) “tied*” tietoon liittyviä Integration issues and interfaces ”integ*” integraatio ”liittymä” liittymä ”liityntä” liittymä ”rajap*” rajapinta Quality requirements ”laat*” laatu (technical and operational) “käytet*” teknisiin laatu-asioihin liittyviä Safety requirements ”turva*” turvallisuus “risk*” turvallisuus-asioihin liittyviä Statistics requirements ”rapo*” raportointi (reporting and billing) ”lasku*” lasku ja laskutus Innovation issues (term innovation) ”innov*” innovaatio “muuto*” Innovointiin liittyviä Business requirements ”liiket*” liiketoiminta (competitive advantage, value for money, growth) ”kehi*” kehitys ”kasvu*” kasvu ”arvo*” arvo ”kustannus*” kustannus –asiat

2289


SECOND SECTION Status (occurrence) and some notifications and

observations of the words (terms and features) in requirements specifications 1. In this study the main focus and the definition of

“technology management” targeted an organization’s strategic intent to create competitive advantage, to achieve value for money or growth, innovation issues, safety, integration and lifecycle issues, reporting and billing and system issues (networks, hardware, software, tools, information, operational tasks, project and process) by means of something that they intend to open for tender or acquire. Some issues are the focus of major debate and discussion in the public sector nowadays. Business matters, strategic and operative issues, innovations, integration possibilities, lifecycle issues, reporting and billing issues and of course system issues themselves are argued about and described with two major questions “is the acquisition a failure or a great success” and “what are the real benefits of the whole procurement project and how should they be notified, measured or followed up?” The aim was to analyze whether these matters were important in acquisitions or not.

2. In acquisitions (27 in 2012) we identified at the total sum of requirements that met the context of the chosen words (terms and features), i.e. approx. 2377 pcs. The number of papers in one call for tender is growing all the time. The complexity of the procurement, more accurate agreements, and the growing demand for needs and requirements has increased the total number of papers. There were a total of 163 pages in the 27 call for tender documents and 475 pages in the attachments. The average number was six pages in call for tender documents and 17.5 in attachments.

3. If we look at the acquirer’s opportunities to make sure that they get what they are asking for, there are some major rules to follow. One of the primary tasks for the procurement unit is to satisfy the legislative law tasks and objects. The second focus point is on the situation that there is a need to buy something. The third focus is on monetary and business matters (to achieve some competitive advantage, value for money etc.). The fourth focus has been placed on achieving some operational changes (behavioral, tasks, operations, usage, etc.). The fifth focus has been put on specifying the requirements that include quality, safety, integration, tools, information, lifecycle, project, process, and innovative issues. It is to be hoped that some thought has been focused on increasing knowledge and learning something. It is also worth pointing out that public procurement is always a competition!

4. One very important thing is notifying the people who have to deal with the target, i.e. (the acquisition). The end-user’s opinions always have to be given priority and

balanced between technology and human behavior. Another important task is describing the target and setting the requirements and selection criteria. We have observed that one crucial point “is the struggle for survival.” There is an increasing trend to use consultants in procurement projects. When a consultant is responsible for or involved in a project, there seems to be correlation with a large amount of requirements and therefore the terms and features are also seen the most frequently.

THIRD SECTION Status (occurrence) of the importance of technology

management in very complex public acquisitions call for tender documents (especially requirements specifications) 1. We have chosen to approach the term “Technology

Management” (below TM) with some well-known models. These models come from technical and operational frameworks for Enterprise Architectural – modeling. The frameworks that we relied on in this study were [60], TOGAF, Zachman, Gartner (GEAF), CEAF, FEA(F), DoDAF and some issues from ITIL, eTOM, SOA, COBIT and ISO/IEC/IEEE 42010 and 20000 standards. The requirements and features that were the basis of meeting the requirements to handle TM, as defined earlier were taken from these frameworks [Table 2]. This approach enabled us to stay focused on the terms we wished to search for in this study.

2. It was stated above (based on the definition of TM) that we are searching the terms and sentences on several topics. These topics are: mentions of technology or lifecycle management, business requirements (competitive advantage, value for money, growth), innovative issues, lifecycle issues, statistics, quality control, operations management issues and safety issues, which we found to be the most important matters to search.

3. As mentioned earlier, there is a choice between two methods of assessing offers [44]: o Lowest price o Most economically advantageous tender (MEAT) Both or at least one of these are seen in every call for tender documentation. We decided to ignore these, because the occurrence of these issues and requirements is highly regulated and therefore these occurrences are obvious.

4. Some topics such as monetary issues and time issues are either regulated by legislation, or mandatory issues in every call for tender documentation, so these topics were also ignored. We would like to note that these topics were included in our survey when we searched for words (terms and sentences) in documents. These topics have their importance in TM depending on how widely or in what way TM is described, chosen, or approached.

2290


TABLE 2: A SIMPLE DESCRIPTION OF THE PROCESS AND EXAMPLE OF COUNTING THE EXISTENCE AND OCCURRENCE OF REQUIREMENTS.

5. The following histogram [Figure 5] and the information

contained in it shows how often the chosen words (terms and sentences) occurred in call for tender documents (total amount of requirements 2377 pcs.). If these words did not

occur in call for tender documentation we came to the following conclusion: these issues were not important in public procurement projects and in acquisitions.

Figure 5: Word (term and feature) that occur in call for tender documents in descending order.

2291


FOURTH SECTION Findings of the study

In this section we present some of the major findings of this study and especially the occurrence of chosen words (terms and features) in call for tender documents.

The status of the occurrence of requirements specifications has getting better. There is some improvement (more separate requirement specification documents) on the findings of the previous research [36].

The research proved that there is a huge lack of occurrence of certain words (terms and features) that has been written to be important in technology management issues. Because these words did not occur in call for tender documentation, these issues were not important in public procurement projects and in acquisitions. Therefore technology management (partly) is not and important issue. Someone should add requirements to meet the needs and cover wider area of technology management.

Words (terms and features) occurrence in call for tender documents:

The term innovation was not mentioned in any documents. There is a small possibility that the call for tender documents that had no requirements at all tried to make innovative acquisitions. We believe that innovative procurements will come but it takes some time to have some precedents.

Business requirements are hardly ever seen in documents. This is the most surprising issue that should be taken care of and these issues should be visible in every case. There is no mention of competitive advantage, value for something, growth, monetary advantage, or some other business achievements. The term CRM (Customer Relationship Management) or business terms like BI (Business Intelligent), ROI (Return on Investment) or value creation are hardly ever seen in the call for tender documents that we have examined. Please note that in every case (at some point of procurement procedure) there have been discussions and negotiations on these topics.

The term lifecycle is seen in some documents and its main reason for occurrence is to satisfy mobile phone requirements (how to handle mobile phone lifecycle issues). Lifecycle issues are not targeted at a system or technology level. There are very few requirements stressing development issues, which is another surprise, because we believe that the main reason for acquisitions is to develop an old system or purchase some new system.

Project and process issues are touched on very lightly. Almost all the mentions aim to satisfy the needs of personnel resources in a project and some thoughts have been given to documentation (some requirements are given that a project plan should be delivered in the tender). There are very few mentions of processes relating to the firm itself.

Integration issues are seen in rather a lot of cases. Requirements are quite widely shown and the main trend is to ask whether integration is possible or not. This may be some sort of innovative issue when there are no strict technical

requirements or requirements at all, but we think (based on discussions) that there are some deficiencies in knowledge of the products that are on the market [26].

Safety issues should be in a separate document. These are so important that they should not be neglected. In some cases, safety issues were aimed at technical matters (system). Some issues were aimed at operational matters, but these were exceptional. We did not find any mention of safety issues aimed at the human aspect. One case had its own document of safety issues which is how it should be. This case was so large (many papers and many requirements) that it almost covered all the safety requirements (amount of safety requirements, please see Figure 5).

Tools requirements were set in many cases. The main requirement, or should we say question, was again to ask whether there was some kind of tool or not. When sentences were examined carefully, some requirements were found of how a tool should behave. We would like to remark that the term tool is different to the parts of the system itself (applications (software), equipment (hardware) and network (data networks)). It is usually an independent application that has some features and operations.

Quality requirements were either technical or operational. Mostly these requirements were given in service levels and in agreements. Some requirements were presented for mobile network coverage or some operational issues such as fault repair time and so on.

Information requirements were seen almost in every case and these seems to be important. We all know how difficult and hard it is to handle large amounts of information and collect or enter data into systems. There were some technical information demands and many documentation requirements.

Statistical requirements, especially billing and reporting, have been always important in the ICT sector. For the same reason, as they handle large amounts of data, such as transactions, billing tickets, data related to people, system tickets (how some part of system works), etc. We would like to point out that history has taught that billing is a very complex task to organize in a reliable way, which is why these things are always under close scrutiny and in someone’s interest.

Operational (operative) and operation issues comprised the second major part of terms and features. Various requirements concerning operational matters, operations, tasks, and information needs were given in many ways. There seem to be very exact demands of behavioral issues, which may mean that firms have asked the end user’s opinion of system features and their goal is to acquire what they really need, or otherwise that firms have a fairly good knowledge of the system itself and therefore list all the operational issues. We have seen some signs of “copy-paste” from another similar case. Sometimes requirements are introduced from a system that the acquirer wishes to develop or change. These requirements are called “as-is” demands. We would like to point out that many cases had exactly the same requirements

2292


(lots of redundancy) and we wonder if these are suitable in public procurements.

Applications (software), equipment (hardware), and networks (data network) are requirements that were frequently mentioned in all the cases. New systems are modular and versatile with many operations and features but there are limits. When many technical features are requested, they have to be solved but some of them may incur additional expense and there is a huge likelihood of facing “hidden costs” (costs that may appear during the agreement period). People like to request many things that are not relevant if we look at the “big picture” and try to aim to achieve some competitive advantage.

The term “manage something” is mostly related to applications, tools, information, and operational issues. Terms or phrases such as technology management, strategy management, lifecycle management, business management, framework models, architectural models and operations management are not seen in call for tender documents.

There seems to be some redundancy (same requirements in different call for tender documents) in documents where a consultant has participated in the project. It may be a good thing, if the cases are similar and each one has the same systems, needs, requirements, and features. However, there may be some risks that errors or mistakes in previous cases from where the information came are copied in the next case.

A large number of technical and operational requirements seem to concentrate on satisfying the need to acquire a system that has already been selected. Therefore, the main reason for competition is precisely to find the most appropriate purchaser to make an agreement with. Many of these requirements are so specific or conversely so large, that they push SMEs (small- and medium-sized enterprises) out of the game.

IV. FIFTH SECTION

Discussion

In this study, we were very lucky to receive permission to access the public calls for tender archive and research all the information needed. At the same time we were able to observe the largest national call for tender processes in the public and private sectors. The sample was statistically extensive enough to satisfy scientific requirements. The empirical part of the work consisted of cases opened and completed between the period 1.6.2007 and 2012. The duration of this study was one year (2012).

The reality in procurement units all over is that people need to cope with more and more complex systems. Needs and requirements are growing and growing. Technology and options are becoming more and more important, yet even so, technology management is not an important issue in the procurement units we researched.

In the future we will see a lot of accelerated technical change, integration demands, innovative discussions and growing user demands with ensuing social effects.

The study found that the procurement procedure mostly used is the open procedure, even if the case is very technical [39]. Technology management is not an important issue in the scope that we have defined. It has been observed that procurement unit personnel themselves are not able to define the technical solutions, especially the requirements, to satisfy their needs or are unable to specify the legal and/or financial make-up of a project. Highly technical, large, and complex infrastructure projects would seem to lend themselves to exploit this type of dialogue.

The occurrence of terms in call for tender documents is rather hard to search and categorize (various numbers of documents in different formats, lots of different sentences and expressions), but the trend and approximate sum of terms was found to satisfy the reliability of research and meet our needs.

What we have learned is that the most vulnerable structural impact target is the selection criteria in calls for tenders. The other issues are requirements and pricing tables. We can state that the points that have a direct effect on competition are the most valuable and important matters, which is why there is heavy pressure to bring them forward. There are many management issues that we would like to pay more attention to. In very complex, large and fragmented structures and technical systems there seems to be a huge possibility to forget, ignore, misunderstand, and underestimate such important aspects as technology management, even though that is the main focus of competition.

Some cases show that there is still an ignorance of requirement specifications among stakeholders. Other cases show that the requirements and language are so sector-specific that the parties fail to understand each other.

Overall, it is good to note that there are still some very high quality call for tender documents and structures that we would all like to process and accept as a professional challenge.

V. SIXTH SECTION

Conclusions and future research

The procurement procedure mostly used is the open procedure even when cases are highly technical.

There are many other procurement procedures that can be used!

Business, innovative, quality, safety and various amounts of management issues are noted as important topics, but there are only small signs in call for tender documents that these matters are being taken into account. We have found that these are the topics that have been in public debate and mentioned in articles for a while. It seems that people working in procurement units are interested in these topics but somehow these matters do not occur in call for tender documents. It may be a question of knowledge or lack of information, even though it is widely available. It may also be due to consultants, although they follow the rules of

2293


legislation, chosen procedure and demands of the customer (in these cases procurement units).

So these important matters are ignored and not put into call for tender documents. Why don´t we bring those into negotiations and discussions that we have had with procurement unit’s people? The open procedure is not the best procedure for discussing things openly and therefore it may be one reason for underestimating, ignoring, or simply forgetting these factors.

There is still some future research to do to examine additional points of view or increase our knowledge of factors such as: strategy, some additional information issues, service chains, behavior, usage and usability, functions, processes, learning, knowledge and skills, needs for change, development issues, time issues, geographical and regional issues, network models and competitive issues.

As we face hard economic times or perhaps recession, we may see very large procurement procedures and at the same time consortiums of procurement units. We may see a trend that leads us toward more complex and larger projects where management issues do not play a major role.

We may publish an open survey for people working in procurement units or those who are responsible for procurement processes (www questionnaires are ready and were tested with some unit personnel in 2012), which will give us more in-depth information of management issues in call for tender documents.

As an adjunct, we would also like to research some business aspects. We wish to show the real status of public procurements as seen from call for tender documents. The situation and status is recognized but not widely discussed within the profession.

The following recommendations for public procurements and calls for tenders have been: • Pay attention to solution assessment [61] and validation. • Pay attention to drafting the technical specification for a

particular project [56]. • Pay more attention to requirements in public

procurements.

With this research, some open questions have been met that may need further research.

Is there interest in following technological development and therefore adding requirements to meet the needs of technology management?

How do public procurement units handle this?

ACKNOWLEDGMENTS The author would like to thank: • the Foundation for Economic Education, • the Ulla Tuominen Foundation, • the Satakunta University Foundation, • the High Technology Foundation of Satakunta and • the Case Company,

• for partly funding our research projects.

REFERENCES [1] Act on Public Contracts, Retrieved 1/3/13 World Wide Web,

http://www.finlex.fi/en/laki/kaannokset/2007/en20070348.pdf [2] Annual Public Procurement Implementation Review, Retrieved 1/3/13

World Wide Web, http://ec.europa.eu/internal_market/publicprocurement/implementation/index_en.htm

[3] Betz F.; “Strategic Technology Management,” McGrawHill, Engineering and Technology Management Series, New York, 1993.

[4] Bhalla, S. K.; “The Effective Management of Technology: A Challenge for Corporations,” Columbus, Ohio, Battelle Press, 1987.

[5] Brender, J.; “Trends in assessment of IT-based solutions in healthcare and recommendations for the future,” International Journal of Medical Informatics, Vol. 52, pp. 217-227, 1998.

[6] Capability Maturity Model Integration and Capability Maturity Model (CCMI/CMM), Retrieved 1/3/13 World Wide Web, http://cmmiinstitute.com/

[7] Chen, S.L. and M.M. Tseng, “Defining Specifications for Custom Products: A Multi-Attribute Negotiation Approach,” CIRP annals, 54(1): pp. 159-162.

[8] Control Objectives for Information and Related Technology (COBIT), Retrieved 1/3/13 World Wide Web, http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx

[9] Credita; Archive of public tenders, Retrieved 1/3/13 World Wide Web, http://www.credita.fi

[10] D.7.2 v3.0 Final ICT Requirements specifications, 2011. [11] Definition of Technology Management (TM), Retrieved 1/3/13 World

Wide Web, http://www.referenceforbusiness.com/management/Str-Ti/Technology-Management.html

[12] Definition of Technology Management and Applied Engineering (ATMAE), Retrieved 1/3/13 World Wide Web, http://en.wikipedia.org/wiki/Association_of_Technology,_Management,_and_Applied_Engineering

[13] Desyllas, P. and A. Hughes, “Do high technology acquirers become more innovative?” Original Research Article Research Policy, Volume 39, Issue 8, pp. 1105-1121, Oct. 2010.

[14] Dussauge, P., S. Hart and B. Ramanantsoa, Strategic Technology Management. 2nd ed., Paris, France: John Wiley & Sons, 1992.

[15] EITM is collaboration between a number of European universities, Retrieved 1/3/13 World Wide Web, http://www-mmd.eng.cam.ac.uk/ctm/eitm/index.html

[16] enhanced Telecom Operations Map (eTOM), Retrieved 1/3/13 World Wide Web, http://www.tmforum.org/BestPracticesStandards/BusinessProcessFramework/6637/Home.html

[17] FEAF, “The Common Approach to Federal Enterprise Architecture,” May 2, 2012. Retrieved 1/3/13 World Wide Web, http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/common_approach_to_federal_ea.pdf

[18] Floyd, C.; “Managing Technology for Corporate Success,” Gower, Aldershot, UK, 1997.

[19] Folmer, E.; “Quality model for semantic IS standards,” 8th International Conference "Standardization, Prototypes and Quality: A Means of Balkan Countries' Collaboration", Oct. 7-8, 2011.

[20] Gartner Enterprise Architecture Framework (GEAF), Retrieved 1/3/13 World Wide Web, http://www.gartner.com/technology/home.jsp

[21] Guidelines for public procurement of ICT systems, Retrieved 1/3/13 World Wide Web, http://cordis.europa.eu/fp7/ict/ssai/study-action23_en.html

[22] Guide for the procurement of standards based ICT Elements of Good Practice, Europe Economics, Dec. 2011.

[23] Hesser, W., A. Czaya and N. Riemer, “Development of Standards,” In W. Hesser (Ed.), Standardization in Companies and Markets, pp. 123-169, 2007.

[24] IEEE P1220, Standard for Application and Management of the Systems Engineering Process, [Final Draft], Sep. 1994.

2294


[25] Information Technology Infrastructure Library (ITIL), Retrieved 1/3/13 World Wide Web, http://www.itil-officialsite.com/

[26] Jantunen, S.; “Making sense of software product requirements,” Thesis, Lappeenranta, 6, June 2012.

[27] Janus-Hiekkaranta, A.; “Developing a comprehensive knowledge management approach for ICT –based professional services companies,” Case Study, Master´s Thesis, Department of Business Technology, Helsingin Kauppakorkeakoulu, 2009.

[28] Kleine, S. J.; “What is technology?” Bulletin of Science Technology & Society, 5: 215, 1985.

[29] Kropsu-Vehkaperä, H., H. Haapasalo and J-P. Rusanen, “Analysis of Technology Management Functions in Finnish High Tech Companies,” The Open Management Journal, pp. 1-10., 2009.

[30] Laplante, P. A.; Requirements engineering for software and systems. ISBN 9781420064674, pp. 1-241, 2009.

[31] Hansen, S., N. Berente and K. Lyytinen, “Requirements in the 21st Century: Current Practice and Emerging Trends,” The Design Requirements Workshop, Cleveland, Ohio, June, 2007.

[32] Levin, D. Z. and H. Barnard, “Technology management routines that matter to technology managers,” Int. J. Technology Management, Vol. 41, Nos. 1/2, 2008.

[33] Liao, S.; “Technology management methodologies and applications. A literature review from 1995 to 2003,” Technovation 25, pp. 381–393, 2005.

[34] Lilja, K. K. and H. Jaakkola, “The differences between the supplier's and the customer's business cultures and their impact on the result of an IT project,” in Technology Management for Global Economic Growth (PICMET), 2010 Proceedings of PICMET '10, Phuket, Thailand, pp. 1-10, July 2010.

[35] Lilja, K. K. and H. Jaakkola, “The differences between the supplier's and the customer's equality policies and their impact on the result of an IT project,” in Technology Management for Global Economic Growth (PICMET), 2011, Proceedings of PICMET '11, Portland, Oregon. USA, pp. 1-13, July/Aug. 2011.

[36] Lilja, K. K., A. Linden and H. Jaakkola, “The Importance of a Common Language in the Requirements Defining Process,” in Technology Management for Global Economic Growth (PICMET), 2011, Proceedings of PICMET '11, Portland, Oregon. USA, pp. 1-16, July/Aug. 2011.

[37] Lilja, K. K. and A. Linden, “The Impacts of the Formal Structure of Customer and Supplier on the Outcome of an IT Project,” in Technology Management for Global Economic Growth (PICMET), 2012, Proceedings of PICMET '12, Vancouver, Canada, pp. 1-22, 2012.

[38] Lilja, K. K. and A. Linden, “The Use of Power: Differences between Supplier and Customer and the Impact on the Results of an IT Project,” in Technology Management for Global Economic Growth (PICMET), 2012, Proceedings of PICMET '12, 2012, Vancouver, Canada, pp. 1-23, 2012.

[39] KuMa 2010: Kuntien ja kuntayhtymien tietotekniikkakartoitus 2010, Retrieved 1/3/13 World Wide Web, http://www.kuntaportaali.org/attachment.asp?path=1;55264;122868;354;57710;124425;124461;164777

[40] Paletta, F. C. and N. D. Vieira Jr., “Information technology and communication and best practices in it lifecycle management,” J.Technol. Manag. Innov. , Volume 3, Issue 4, pp. 80-94, 2008.

[41] Pereira, C.; “A method to define an Enterprise Architecture using the Zachman Framework,” SAC '04 Proceedings of the 2004 ACM symposium on Applied computing, pp. 1366-1371, 2004.

[42] Phaal, R.; “Technology roadmapping —A planning framework for evolution and revolution,” Technological Forecasting & Social Change, 71, pp. 5–26, 2004.

[43] Phaal, R.; “A framework for supporting the management of technological innovation,” International Journal of Technology Management, Vol. 27, Number 1, pp. 1-15, 2004.

[44] Public Procurement in the European Union, Retrieved 1/3/13 World Wide Web, http://ec.europa.eu/internal_market/publicprocurement/docs/guidelines/services_en.pdf

[45] Public procurement in Europe, Cost and effectiveness, A study on procurement regulation. Prepared for the European Commission, March 2011.

[46] Request for Proposal (RfP), Retrieved 1/3/13 World Wide Web, http://www.negotiations.com/articles/procurement-terms/

[47] Requirements Management (REQM), Retrieved 1/3/13 World Wide Web, http://www.software-quality-assurance.org/cmmi-requirements-management.html

[48] Requirements Specification (RS), Retrieved 1/3/13 World Wide Web, http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32004L0018:en:NOT

[49] Requirements template SL-07, Retrieved 1/3/13 World Wide Web, http://www.itu.dk/~slauesen/Papers/RequirementsSL-07v5.1.doc

http://www.itu.dk/~slauesen/Papers/RequirementsGuideSL-07v3online.pdf

[50] Robertson S. and Robertson J., Mastering the Requirements Process, 2nd edition, Massachusetts, USA, Pearson Education Inc., pp. 1-560, 2007.

[51] Sahlman, K.; “Elements of strategic technology management,” Academic dissertation, University of Oulu, pp. 1-78, Aug. 2010.

[52] Schilling, M. A.; Strategic Management of Technological Innovation. 2nd edition. New York, McGraw & Hill, 2008.

[53] Sousa, R. and C. A. Voss, “Quality Management Revisited: A Reflective Review and Agenda for Future,” Journal of Operations Management, pp. 91-109, 2002.

[54] SRS std, System and Software Requirement Specification standards, Software STD IEEE 830-1998, System STD 1233-1998.

[55] Steele, L. W.; “Managing Technology: The Strategic View,” McGraw, Hill Inc., U. S. A., pp. 1, 1989.

[56] Tanel, T. L.; “The Art of Planning and Writing Specifications & Requirements,” 95 th Annual International Supply Management Conference, Apr. 2009.

[57] Technology specification (TM), Retrieved 1/3/13 World Wide Web, http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32004L0018:en:NOT

[58] Teece, D. J.; “Business Models, Business Strategy and Innovation,” Long Range Planning 43, pp. 172-194, 2010.

[59] The Open Group Architecture Framework (TOGAF), Retrieved 1/3/13 World Wide Web, http://www.opengroup.org/togaf/

[60] The specification of architecture frameworks standardization in ISO/IEC/IEEE 42010:2011, Retrieved 1/3/13 World Wide Web, http://www.iso-architecture.org/42010/afs/frameworks-table.html

[61] Tran, T. A. and T. Daim, “A taxonomic review of methods and tools applied in technology assessment,” Technological Forecasting & Social Change 75, pp. 1396–1405, 2008.

[62] US Federal Enterprise Architecture Framework (FEAF), Retrieved 1/3/13 World Wide Web, http://www.whitehouse.gov/omb/e-gov/fea/

[63] Zachman, Retrieved 1/3/13 World Wide Web, http://www.zachman.com/

[64] Zuo, Y.; “A Framework of Survivability Requirement Specification for Critical Information Systems,” Proceedings of the 43rd Hawaii International Conference on System Sciences, 2010.

2295


The Importance of Technology Management in the ICT ...€¦ · importance of technology management...

Documents

Transcript of The Importance of Technology Management in the ICT ...€¦ · importance of technology management...