Бесплатный фрагмент - IT Architecture from A to Z: Theoretical basis

PREFACE

About the author

Vadim Aldzhanov is a Microsoft MCP, MCSA Security, MCSE Security, MCTS, MCITP, MCITP SQL Database Administrator, Cisco CCNA, VMware VCP4, CompTIA A+, Network+, Security+, EC – Council CEH и ECSA, SNIA Certified Storage Professional SCSP, Wireless Technology CWTS, CWNA, CWSP, IT Management ITILv3, Apple Certified Associate — Integration | Management.

A series of books “IT Architecture from A to Z: Theoretical Basis” contains and harnesses the knowledge and experience of more than 17 years in IT. I was involved in banking for 14 years, and headed the IT department most of time. At this moment, I am an IT Architect in one of the largest holdings in the country. I have a bachelor’s degree in radio engineering and a master’s degree in Computer Information Systems (CIS). I am also continuing my education for a doctoral degree in Management of Information Systems (MIS). In addition, I have about a thousand hours of training in specialized courses on system administration, computer networks, wireless networks, storage systems, virtualization systems, information security, IT services management, project management, banking, plastic cards, strategic planning, auditing etc. My LinkedIn profile: https://www.linkedin.com/in/vadim-aldzhanov-623a7b44/

Introduction

A series of books “IT Architecture from A to Z” is an author’s attempt to collect, summarize and systematize his accumulated experience and knowledge in IT.

A series of books “IT Architecture from A to Z” — Green Book

“IT Architecture from A to Z: Theoretical Basis” is the first book of the “IT Architecture from A to Z” series which contains the theoretical basis of planning, building and maintaining IT architecture, Project management, IT services, etc. It is used as a source of proven practical materials and recommendations of standards and practices. It is a revised, amended and updated edition of “IT Architecture: a Practical Guide from A to Z”.

A series of books “IT Architecture from A to Z” — Blue Book

“IT Architecture from A to Z: A Complete Solution” is the second book of the “IT Architecture from A to Z” series which contains detailed technical information and practical examples of implementing IT solutions based on the fundamentals of the theory described in the first book. As examples, I considered Windows 10/2016 based solutions, as well as complex solutions on monitoring, managing and configuring Microsoft System Center 2016, Microsoft SharePoint Server 2016, project management solutions in Microsoft Project Server 2016, Exchange 2016, Skype for Business 2015 solutions, functionality of Direct Access 2016, Hyper-V, DFS и File Server, RDS etc. I presented the detailed requirements and examples of system assurance estimates as well as the power capacity calculations and costing solutions. The author selects solutions that are the most suitable for performing the objectives set, or have been practical for him. It is a revised, amended and updated edition of “IT Architecture: A Practical Guide from A to Z”.

A series of books “IT Architecture from A to Z” — Grey book

“IT Architecture from A to Z: Documentation Templates” contains the set of documentation templates and examples, required for daily IT routine. It is used as a source of proven practical materials and recommendations of standards and practices.

A series of books “IT Architecture from A to Z” — Yellow book

“IT Architecture from A to Z: Solutions Catalog” describes the possibilities of various IT solutions, analysis and comparison of functionalities. Over a hundred solutions have been tested or practically used so far.

A series of books “IT Architecture from A to Z” — Red book

“IT Architecture from A to Z: Alternative Solutions” contains detailed technical information and practical examples of carrying out the IT solutions based on the theory, described in “IT Architecture from A to Z: Theoretical Basis”. As examples, the author uses solutions whose priority selection criterion is “zero value”. The IT infrastructure and components described in the “Blue book” are taken as a basic solution.

A series of books “IT Architecture from A to Z” — Black book

“IT Architecture from A to Z: Cloud solution” contains the detailed technical information and practical examples of carrying out the IT solutions based on the theory described in “IT Architecture from A to Z: Theoretical Basis”. The “cloud” solutions are used as examples where possible.

The Objectives of thee Book

The objectives of the book is to help the specialists, IT managers and directors to build the architecture of the enterprise, arrange management processes, calculate the costs of implementation and maintain the IT infrastructure, select the optimal architecture solution, from both a business and IT perspective. The book will help arrange communication between business and IT, allowing them to communicate in the same “language”. The material presented in the book is not sufficient for a detailed study of all aspects of IT operations, but it is enough to understand the links of various aspects and give a direction for organization development in general and particularly in IT.

The book is not a mandatory guide for selecting a product or a solution, and presents the author’s views.

The material is presented in a logical order, supplemented with theoretical information and illustrative examples of implementation. That makes the guide useful for methodical study of all aspects of IT operations, as well as using it as a handbook when working with particular systems.

Scope covered by the Book

This book is the first one of the series “IT Architecture from A to Z” and a Russian manual, containing and harnessing theoretical knowledge of enterprise architecture, project management, informational security, IT service and audit arrangement and management. The book also considers the order of their practical use, allowing complete provision of organizational needs for building and managing IT architecture and IT infrastructure. Extensive material gives systematic description of the state of the modern IT company and demonstrates the main models and approaches of creating an IT strategy, risk management, IT service control, risk analysis and quality management, IT audits, and integration and interaction of various approaches and methods. The book is for the general public and will be useful to:

•Top-managers, IT curators, CIO’s of the large and middle companies since it provides better understanding of TOGAF based Enterprise Architecture, the IT role and involvement ИТ in business and indicators of financial investments distribution in IT services. Business representatives will be able to understand the general aspects of the functioning of the IT infrastructure, technical terms, the fundamental differences between various architectural solutions, and principles of building and maintenance of technical solutions. The book allows you to create metrics and IT infrastructure effectiveness reports understandable by both parties.

•Heads of IT department, IT architects and middle managers, and project managers who need theoretical basis of IT service management (ITSM) using ITIL recommendations and practices, project integration management (PMI) in IT, Control Objectives for Information and Related Technologies (CobiT) and information security.

This book is not supposed to be used by small IT infrastructure since the cost of paper is higher than IT requirements. It will also be ineffective for large enterprises with corporate governance, as every direction is likely to be managed by the narrowly focused experts.

Special Thanks

I express my gratitude to my friends, teachers, managers and colleagues for their help in writing the book and their invaluable experience and knowledge obtained via communication with such people as Alexander Buslayev (“AIC Group”), Irshad Guliyev (“SINAM”), Fazil Mammadov (“ROTABANK”), Yana Khmelnitskaya and Karsten Stellner (“LFS Financial Systems GmbH”), Thomas Engelhardt (“Microfinance Bank of Azerbaijan”), Andrew Pospielovsky (“ACCESSBANK”) and Alan Crompton (“Baku European Games Operation Committee BEGOC 2015”).

Legal Notice

The information contained in the book does not carry any trade secrets or other confidential information. The materials are collected from open sources, revised by the author by using his experience and knowledge. Some of the examples reviewed are for reference only and are fictional. Any similarity with real people or organizations is accidental. All companies and product names mentioned in the book may be trademarks of their respective owners.

Copyright

The information specified in the book may not be reproduced, duplicated, copied, transmitted, distributed, stored or used for any commercial and non-commercial use without the written consent of the author.

@ Copyrights Vadim Aldzhanov, 2018

Disclaimer

The author makes no warranties or statements about the accuracy, suitability or completeness of the information, links or other items contained in this document. The book is available to all readers “as is” without any express or implied representations or warranties, including warranties regarding merchantability or suitability for a particular purpose. The document may contain inaccuracies or spelling errors.

The author does not assume any liability for direct, indirect, incidental or other damages when using this guide. The reader of this manual is informed.

This book is dedicated to my parents, my loving wife and two wonderful daughters.

CONTENT DETAILS

The first book of a series includes a discussion of the theoretical basis for building an IT company and considers the following:

•Chapter 1: Building the Enterprise Architecture deals with the issues of building Enterprise Architecture, IT strategies, and so on.

•Chapter 2: Project Management discusses the foundations, applied methodologies, accepted methods of the Project Management, and so on.

•Chapter 3: Risk Management considers methods of risk assessment, risk classification and risk response.

•Chapter 4: Quality Management describes the basic principles and methods of project management when using methods based on the principles of quality management and economical production.

•Chapter 5: Business Process Management and Business Models of various business areas considers the basis of building business processes, the type of business organization and linkages with information systems.

•Chapter 6: Information Systems and Data Integration addresses issues of data integration between different information systems, various architectural solutions, challenges and opportunities. It also deals with the levels of centralization of automated management systems are considered.

•Chapter 7: Information Security considers information security issues and arranging interaction of information security and IT.

•Chapter 8: IT Service Management considers the processes of building IT service management using ITIL.

•Chapter 9: IT Control and Audit addressed general issues of IT control and auditing.

•Chapter 10: IT financing considers financing models, principles of evaluating IT projects, methods and practices for valuation of IT services, etc.

•Chapter 11: Organization of IT Activities discussed general issues on the structure, organization, management of the IT department.

•Chapter 12: Components of IT Infrastructure considers high-level components of IT infrastructure.

•Chapter 13: Components of IT Support Systems considers the high-level components of engineering and support systems.

IT ENTERPRISE ARCHITECTURE

General Provisions

This chapter describes the general information on Enterprise

Architecture. A generic definition can be represented as depicted below:

Enterprise Architecture is a set of principles, methods and models used in the design and implementation of an organizational structure, business processes, information systems and technologies. It is a management practice aimed at maximizing the impact of the enterprise, investing in IT, developing systems in achieving the enterprise goals, converting the business vision and strategy into an effective change of the company through creating, discussing and improving key requirements and principles that describe the company’s future state and enable its development.

Since the Enterprise Architecture is a complex solution including the intersection of various methodologies and techniques, building an Enterprise Architecture should take into account, but not be limited to, the recommendations of the following standards:

•TOGAF — Enterprise Architecture

•ISO/IEC 20000 — Quality in IT Service Management

•ISO/IEC 27000 — Best Practice IT Security Standards

•CobiT v5 — Audit and Control Framework

•ITIL v3 — Best practices in IT Service Management

•MOF — Microsoft Operations Framework

•PMI — Project Management Institute

The architecture is designed to respond to such challenges and problems of the organization as:

• Business discontent of the IT service for objective or subjective reasons.

• Inability to assess the effectiveness of IT use in business.

• Mess in IT solutions and systems implemented in the organization.

• The complexity of making IT-related decisions.

• The complexity of IT budget coordination and the launch of IT projects.

• Growth of “Information” value and connectivity between business and IT.

• Lack of transparent and clear connections between business and IT.

• Whether solving the actual business problems using IT is possible?

• How to make IT give companies greater value?

• How to change IT with changes within business?

• IT systems are complex, unmanageable and expensive to maintain.

• IT systems restrain an organization from responding adequately to changes within business.

• Business-critical information is untimely and inadequate.

• Communication culture between business and IT is missing.

As a result, the business does not see any value in information technologies. CIO’s face difficulties in pushing new ideas if they talk about technology. They are not understood. Everything they can do is to support what already exists and do the objectives pitched by the business. The serious problems arise with the justification of IT budgets. In fact, the CIO acts more like a foreman who fills in the holes, rather than a top manager who is developing the company. Top managers quickly lose interest in IT projects, and therefore, they lose funding and fail. IT department are replaced with various system integrators to implement “fancy schmancy” solutions that will “save” the business. The ideas also arise to take all company’s IT assets and services and outsource them. It will be difficult for the IT department to fight with integrators and the result is predictable — the integrators have one key competence, i.e. technology, and that is their forte. The IT department is turning into a “swamp”, and the best employees leave taking away the unique knowledge and skills. The goals of an integrator or an outsourcing company are the same as your company’s — making a profit. But unlike the IT department, whose interests coincide with the interests of your company, the integrator’s interests may not coincide with yours, including unique ideas and visions. At best, it will be “like everyone else,” and the business will lose its identity (if it is inextricably linked to IT) or quoting one movie character: “… we will have everything new in an old fashioned manner…”. The end is sad.

The Main Aspects of Enterprise Architecture

To fight the above-mentioned problems and consequences, the Enterprise Architecture helps shape the following important criteria.

Structuring the Enterprise

When building an Enterprise Architecture, the first and most important aspect is an understanding of the enterprise’s organizational structure, principles of management, decision-making, etc. The organizational structure is a fixed and ordered set of objects and connections between them. Depending on the specialization and operations the organization may have:

•Vertical structure — in terms of subordination

•Horizontal structure — in terms of functions and operations.

Accordingly, the management structures are distinguished as linear based on “chief — subordinate” principle and functional, i.e. “professional integration based on the operational specifics”. As a result, organization structure can be represented as the following main types and their varieties:

• Flat, the simplest structure, is suitable for work or project teams, or a small organization.

• Breakdown (bureaucratic) is based on the organizational structure, the functional division of labor and employees’ responsibilities.

• Linear, direct control (head — subordinate), communication between departments occurs through heads of departments only.

• Functional, interaction is based on function.

• Linear-functional — the interaction is combined in a linear and functional type (the most used model).

• Linear and staff — separate functional groups (staffs), conducting work independently with departments or organizations. As an example, a group of companies in the holding.

• Divisional is characterized by central coordination with decentralized management. The key figures in this case are not the heads of functional units, but the managers of individual branches, factories, and so on.

• Organic (adaptive) — the structure formation is based on the need to adapt to changes. Relationships are based not on the structure, but on the nature of the objectives set.

• Project — organized during project management.

• Matrix (program-targeted) — the principle of dual reporting, direct reporting to the manager and project manager

• Brigade (cross functional) — work in separate groups with independent management and decision-making (contrary to breakdown).

Organizational structure may depend on a number of factors:

•Specificity and diversity of operations;

•Geographical location;

• The centralization level of the organization;

• Organization strategy;

• Number and range of services provided.

IT role in the organization

One of the main criteria of building an Enterprise Architecture is to identify the IT role within the organization. If we ignore articles and recommendations about the importance of IT in the modern world given by consultants and other small talks, we have to rigidly fix the role of IT in the organization, the objectives, rights, opportunities and degree of responsibility. To understand the IT role in a particular organization, one needs to answer the following questions:

How is IT involved in business? How much does business depends on IT? Many business processes and functions are tied to complex, centralized or specific IT solutions. Business development is impossible without rapid and quality IT work. There are entire industries that depend on IT such as banks, insurance companies, other financiers, service companies, Public agencies, technology and power companies, etc. (as an example, two-thirds of the bank employees work in one way or another with a centralized banking program, while only a few rural organizations use mostly autonomous IT solutions, where majority the employees work on the field or the computerization of the company is low).

Whether your organization can be attributed to large or medium-scale business. In my opinion, as long as all the technologies of the company are stored in one head, and the CIO communicates directly with the management it is too early to think about the enterprise architecture. For small-scale businesses, enterprise architecture is superfluous.

Whether your company is actively developing IT. The company has several IT projects per year, or at least one project on implementing ERP, CRM or other complex solution. Enterprise Architecture will help to make a decision save from most alterations, errors, inconsistencies, delays and other problems. There must be one person, or groups of people in the company to have a general picture of the future and understand the development process. Otherwise, the pieces of different projects will never make a puzzle.

Whether the company periodically faces IT crises having a significant impact on the business, or there are failures in information systems affect the business and even stops it. Failures are caused by integration problems, miscalculations in infrastructure solutions, temporary solutions and just a mess. Not all projects, including IT, end successfully, meeting the deadlines, budget and stated requirements. If your company management is fed up with failures, delays, exceeding the budgets of IT projects, it is worth thinking.

Companies are looking for speed, quality and efficiency of IT development. One of the parties (business or IT) is developing much faster than the other one. If business develops faster than IT, the latter one impedes the company’s development. Conversely, if IT develops faster than the business needs, business lose money (good IT costs money) and profits (the business does not use all the potential IT capabilities). Both parties should be on the same wavelength to allow the harmonious development of all company’s elements.

Building a relationship between business and IT

IT actions should be focused on business goals and objectives. Business and IT parties see the objectives, goals and expectations differently. This is what IT staff says “…we are good in technology, we are paid for the ability to program, configure, install and solve technical problems, etc. Our work commences as we receive the statement of work…". While business sees it as “...there are so many IT innovations, IT should give us some kind of solution to increase sales. In the worst case scenario, we need a solution our competitors already have. So their sales are higher …you are welcome to implement it since you’ve made a decision though you don’t understand how this business works…”. The task of the CIO is to have an equal share in the discussion of business strategy. The general principle can be defined as: “a business describes its requirements and expectations (business requirements), while IT creates a statement of work to achieve the goals.”

Establishing collaboration between business and IT

All above mentioned is followed by another important problem, i.e. the “vacuum” in communication between business and IT employees. The task of the organization’s management and the CIO is to establish communication between the organization’s employees not only at the top-level, but also between the middle-level employees and the direct executors of business and IT. As the saying goes “the devil is in the details.” Any cool idea in general should be fine-tuned. At this stage, the specific thinking of IT specialists with having causal link, and WH-questions such as “…what happens if…,”, “… how to control…”, “…how to measure …”, as well as analysis of limit state scenarios, will help develop an optimal solution. In addition, such questions will help business representatives to understand and work out the solution from a business point of view and what to demand from IT, the ongoing solution capabilities and their future opportunities or limitations.

Getting maximum value from IT

Most organizations, except IT company, IT is used only as a tool to achieve business goals, a secondary service, just like accounting or administration, providing support for key areas and processes. IT evaluates solutions in terms of technical maturity, completeness, functionality, and so on. At the same time, the business’s only interest is making profit. A perfectly developed technical solution can nullify the business advantages of the idea itself, make it difficult to use and expensive to implement and maintain. It reduces financial benefits and makes the solution inconvenient for customers, etc. The tasks of CIO is not to develop the best solution from the IT point of view, but the most correct one. The most correct solution will be made by using the formula and of the following key components:

VALUE = BENEFIT — COSTS

From a business perspective, it can be interpreted as getting maximum value from IT. The value of information technology is the difference between the benefits of using information technology and the its cost. From an IT perspective: Compliance with IT values and requirements i.e. workability, security and manageability.

Transferring part of the work to the IT department or refusing to automate a number of elements can reduce the cost of the solution, increase ease of operation and convenience for customers.

One of the primary objectives is to define the boundaries to search for opportunities and identify the border, beyond which is destroing the foundations of IT manageability and information security.

Management of change

What we mean in the context of this chapter is the readiness for changes initiated by the business. The business environment can change quickly and radically: new business niches emerge, new products are developed, mergers and acquisitions take place. This can lead to the situation when technical solution used in the organization does no longer meet the organization’s requirements. The IT objective is to adapt an existing solution or develop a new one as soon as possible spending minimum budget to meet the business’s new requirements. As a result, when developing IT strategies and IT solutions in particular, it is necessary to keep in mind a certain flexibility and generality.

Sorting out and managing IT development

Modern realities of business and technology development lead requirement to implement more and more new technological solutions. Different methods and models of their implementation, i.e. independent development, the purchase of a Commercial Off-the-shell solution, implementation and maintenance by a third party, etc. leads to a large number of different duplicated hardware and software in IT infrastructure, obsolete solutions, and so on. Moreover, it generates constant dependence on professionals with “unique” knowledge and experience. The task of the CIO is to arrange IT management, continuous training on new technologies for employees, selection of promising directions to benefit business.

Basic principles of building Enterprise Architecture

The integrated automation of the management function in any modern enterprise requires a unified information space, in which ordinary employees and management will be able to carry out their activities, being guided by single rules for access, presentation and processing of information. Modern methods of building a single information space are based on a comprehensive re-engineering of business processes, creating an information-logical model and then implementing the appropriate software and information support using new technologies. The development of IT architecture allows you to clearly imagine:

• What information / data are critical for the company’s business and the way it is organized?

• Which applications will support the business?

• Whether these applications effectively communicate with each other and with external systems of partners and suppliers;

• Whether the technologies used meet the requirements of supporting business processes;

• Whether the information security of the systems is sufficient?

• Whether the company employees get timely access to the right data they need;

• What standards should be used in the development and procurement of system components?

The architecture is designed using common methodologies, frameworks of architecture description and modeling tools (for example, ARIS IT Architect) taking into account the customer’s experience and preferences. During the project a set of architectural principles is formed, used and prospective standards are identified, and architectural models and individual areas such as applications, data, integration, technical infrastructure, security, etc. are developed.

The approximate sequence of building a single information space of the enterprise is the following:

• Enterprise survey

° Main goals and objectives;

° Precise identification of the project objectives and goals;

° Formulation of functional and technical requirements for the project;

° Infrastructure audit of the enterprise IT system for the design of the solution architecture;

° Shaping the enterprise’s ongoing business processes, automated within the project;

° Obtaining data to justify the number of licenses;

° Evaluation of the resources required for the project;

° Project risk assessment;

° Development of a preliminary project plan, schedule and specification of supplies for each stage and whole project.

• Survey results:

° Report on the situation “As is”;

° Proposal for creating an information system “As required”;

° Proposal for “functional and technical requirements of the project”;

° Project implementation plan;

° Project risk assessment and proposals for their minimization;

° Estimated cost of the pilot project and final solution.

• Supply of necessary hardware and functional solutions for the business units automation:

° Adaptation and adjustment of basic and development of new solutions (if required) in accordance with the functional and technical requirements obtained at the survey stage;

° Deploying a platform with basic document processing and storage services;

° Trial operation of the solution;

° Integration with ERP-system;

° Putting the system into commercial operation.

• Training of technical staff and users.

• Providing additional functionality, i.e. the work allocated at the stage of the survey in separate stages.

Framework is a ready-made methodology and a set of supporting tools to be adapted for use in a particular company. Framework contains typical architectural processes, recommendations for their adaptation for a specific company, recommendations for creating templates of architectural artifacts, requirements for their filling, requirements for architects and much more.

The Enterprise Architecture model can be divided into several key levels (categories):

•A business architecture contains the company strategy, management approach, organizational structure and key business processes.

•An information system architecture describes arrangement or potential arrangement of the company’s information systems. An information system architecture can be divided into two subgroups:

•Application architecture shows the business applications deployed in the company, their interaction and relationship with the company’s business processes.

•Data architecture contains a description of the logical and physical structure of the company’s data, as well as the approach and means of data management.

•Technical architecture describes the software and equipment required to deploy business services, data and applications, IT infrastructure, application servers, networks, telecommunications, standards, etc.

The next level of hierarchy can be:

•Strategic architecture — describes the entire company. At this level, you are not immersed in the peculiarities of specific departments, business areas, etc. The strategic architecture focuses on the company’s overall strategies, business processes, investments, data, systems and technologies. Its primary focus is the implementation of the company’s strategy. At this level, principles and priorities are defined, the common IT services are created for the whole company.

• Segment architecture is the architecture of the company’s activities, the program of projects or a separate subdivision. The company will have several segments like this. At this level, you are immersed in the peculiarities and requirements of a particular subdivision, function, or company within an organization. You study the IT business case with departmental leadership. The segment architecture should have the same structure and shared services as the strategic architecture does.

• Solution architecture is the architecture of a specific IT solution. It is used to implement new or adjust the current IT solutions, services or their parts. It considers both the common requirements for the entire company and the specific needs identified at the segment architecture level. The solution architecture is limited to a single project, process, or function. The solution architecture is studies in the most thorough way. It allows avoiding unpleasant surprises in the future as the project is implemented.

IT maturity levels

In the organization grows and develops, the IT department also goes through several stages of its development. Building an Enterprise Architecture one should take into account the maturity level of the entire organization and IT in particular. The following stages and symptoms of the IT department state can be distinguished:

Initial or “localization”

The company rapidly develops or purchases information systems that give value to a particular business unit or function. The main symptoms of this stage of development are:

• IT department is secondary;

• No IT department strategy;

• No IT department budget;

• IT department acts upon request only;

• Managerial staff is concerned in maximum savings;

• Service within the business department (administration, finance) in the organizational structure of the company.

Development or “standardization”

The company moves from closure of the needs of individual business units or functions and increases IT efficiency by standardizing technology and infrastructure. The main symptoms of this stage of development: are:

• The IT department is not a strategic resource;

• No or initial level of IT department strategy;

• No IT department budget or it is managed by the third party;

• IT department hardly acts in IT infrastructure or acts passively (upon request only);

• Managerial staff is concerned in minimum investment;

• Service or department within the business unit (administration, finance) or overseen position in the organizational structure of the company.

Establishment or “optimization”

The company builds end-to-end business processes using common data and information systems. Whenever possible, it centralizes subdivisions’ business processes and functions in centralized information systems according to previously described operational models. The main symptoms of this stage of development are:

• The IT department is important;

• IT department strategy partially meets business requirements;

• Manageable IT department budget;

• IT department responses reactively to business requirements;

• Managerial staff is concerned in getting business benefits in the short term;

• A dedicated department in the organizational structure of the company, but the IT manager is not a part of the board of directors.

Mature

Reuse of existing business processes and components to create new services and opportunities. Proactive IT is an integral part of the business. The main symptoms of this stage of development are:

• The IT department is a strategic organization resource;

• IT department strategy integrated into the company’s business strategy;

• IT department budget considered as business investment;

• IT department acts proactively to business requirements;

• Managerial staff is concerned in long-term business investment;

• IT department is a part of the company’s organizational structure, CIO is a member of the board of directors.

Each of these stages has pros and cons. The IT development stage should correspond to that of the company. Experience has shown that to skip at least one of the stages is difficult since it requires huge amounts of resources (time, money, human resources etc.), and the effect will rather be to the contrary. Most companies grow stage-by-stage. The company transits to the next stage when the leadership of the company realizes or the severity of the issues arisen:

• Issues of supporting the growth and business changes

• Duplication of business processes

• Multiple platforms and systems

• Dissatisfaction with the current IT state.

Criteria of choosing a methodology

Since the methodologies vary a lot, one should set criteria to compare them.

The completeness of the taxonomy defines the suitability degree of the methodology for the classification of various architectural artifacts or whether fully focused on the Zachman framework.

The completeness of the process defines how detailed the process of creating the enterprise architecture is.

The guide to reference models defines the usefulness of the methodology in creating an adequate set of reference models. The FEA methodology is almost entirely focused on this.

The practical guide defines the degree of implementation of the speculative idea of the enterprise architecture by the methodology and shaping the culture in which this architecture will be used. The Gartner methodology is almost entirely focused on this.

The readiness model defines the degree of assessment of the efficiency of using the enterprise architecture in various departments by the methodology.

A business orientation defines whether a methodology focused on using technology to increase business value, where business value defined as cost reduction or revenue increase.

The management guide defines the degree of methodology usefulness in understanding and creating an effective management model for an enterprise architecture.

The partitioning guide defines the usefulness of the methodology in effective partitioning the enterprise into departments, which is very important in managing complexity.

The availability of the catalog defines the efficiency of the methodology to create a catalog of architectural assets to be used in the future.

Neutrality towards service providers defines the likelihood of being tied to a specific consulting organization when implementing a methodology. A high rating means a low degree of attachment to a particular organization.

The availability of information defines the quantity and quality of free or relatively inexpensive materials on this methodology.

The time of recouping investments defines the duration of your using this methodology before you can build high business value solutions on its basis.

Enterprise Architecture can be built using various methods and practices. This book briefly discusses some of them and focus on one of them:

•“Zahman Framework” is the earliest and most well-known methodology. It is ideal to “classify” architectural elements.

•“TOGAF (The Open Group Architecture Framework)”, designed for “building processes” is widely known and spread, largely due to its openness.

•“Gartner” is a methodology for expert analysis by using “best practices”.

•“FEAF” is an architecture building methodology using the “service oriented” approach.

When building an IT Enterprise Architecture, one should highlight the following states of the organization’s architecture:

• “As-is” or “Baseline Architecture”;

• “Transition Architecture”;

• “To-be” or “Target Architecture”;

• “Enterprise Architecture Management Plan & Roadmap”.

In general, the Enterprise Architecture represents a transition plan from the “Ongoing” to the “Future” state of the organization. The architectural project lasts for several years and initiates many IT projects. These projects will have different duration, different start and end dates. They need to be grouped so that changes in business and IT would take place at the right time, with minimal risk and no compatibility issues. Therefore, architecture can transit from one operational state to another several times as an architectural project lasts. The intermediate state is called the Transition Architecture.

Enterprise Architecture using the Zachman Framework

The earliest methodology and in my opinion the most complete and structured is the Zachman Framework. It was originally developed as an Information Systems architecture. The main idea is to provide the possibility of a consistent description of system’s individual aspects in coordination with all the rest. The Zachman model is used to describe the enterprise as a whole, so the proposed model can be generally used as a means for describing architectures of any complex production system. The main characteristics of this model are:

• Integrity of the enterprise;

• discussing complex issues using a relatively small number of non-technical concepts;

• applicability for solving problems, i.e. the ability to work with abstractions and entities, highlighting and isolating individual system parameters without losing the perception of the enterprise as a whole;

• Simplicity of description.

The advantages of the Zachman model over others are:

• It is easy to understand for both technical and non-technical experts;

• It has more detailed descriptions of architecture components;

• It can be applied to planning and better decision making;

• It has the most visible representation of the company’s components.

• It describes complex architecture using a small number of non-technical terms;

• It has independent tools for specific description;

• It can be used as a tool for describing architectures of any complex production system.

Enterprise Architecture using “FEAF”

FEAF is a framework developed by the US government, as an approach for the development of information technology for Public agencies to use a single architecture. The FEAF is based on five reference models:

• Performance reference model;

• Business reference model;

• Service component reference model;

• Technical reference model.

• Data reference model.

One of the useful properties of the FEA framework is the principle of a segment approach, allowing accelerating the implementation of the Enterprise Architecture. The process of developing an enterprise architecture using the FEA methodology includes the following steps:

• Architecture analysis;

• Architectural definition;

• Investment and financing strategy;

• Program management and project implementation plan

Enterprise Architecture using “GARTNER”

Gartner Methodology can be described as a set of recommendations for creating an enterprise architecture. The 2002 Gartner model is designed in four related, interdependent, and increasingly complex levels:

• Business Relationship Grid;

• Business processes and business process styles;

• Templates;

• Technological building blocks (bricks).

Essentially the Gartner methodology is neither a methodology, such as a structured Zachman model, nor a process like TOGAF or FEA. Gartner is a set of practical recommendations. This methodology is a collection of tips for building enterprise architecture from one of the world’s most famous consulting IT companies. This framework is a three-dimensional cube consisting of following levels:

• Horizontal layers;

• Vertical domains;

• Vertical elements of technical architecture.

Enterprise Architecture using “TOGAF”

The main area for TOGAF application is the software infrastructure of the information system. It best suits for describing the integration components used to support a wide range of critical enterprise applications for business. The model can be described as:

• Business architecture overview;

• Description of the current system with the level of detail required;

• Identification and description of elementary architectural blocks to be used in the new architecture;

• Development of a draft technical report;

• Submitting the draft report for review.

TOGAF is positioned not as a reference model, but a “tool for developing information system architectures”. The primary function is to speed up and facilitate the process of developing the architecture of a particular organization, providing the possibility of future development. Let us consider building of the Enterprise Architecture based on the TOGAF methodology in more details, which in my opinion has several advantages:

• TOGAF approach allows you to build the entire architectural process — from the launch of the practice to the results.

• TOGAF is the de facto standard and has a certification program.

• TOGAF is absolutely free and has lots of open resources to download and use.

• TOGAF contains a complete set of tools for creating and developing architectural practices in an organization. There is a step-by-step process for developing a description of the Enterprise Architecture and a complete range of tools, templates, etc.

• TOGAF is compatible with other frameworks, for example, “Zahman Framework”. As an architectural process, the TOGAF model supplements the Zachman model classified as an architectural taxonomy. Zachman demonstrates how to classify the artifacts. The TOGAF model describes their creation.

Even though the TOGAF methodology and Zakhman infrastructure are merged into the “enterprise infrastructures” category, their principles, structures and competencies are different. TOGAF is a functional and dynamic infrastructure including guidelines for process use patterns. While the Zachman framework is a static architecture structure, it is the most effective one for applying the analysis and meta-analysis of infrastructure frameworks. Despite the significant differences in these frameworks, they can be used together.

TOGAF Basic principles

Creating a specific enterprise architecture is considered as a transition from a general architecture to a specialized one. The architecture development methodology in TOGAF model is the process of making such a transition. The most generalized architectures in TOGAF model are called fundamental architectures. These principles of architecture can theoretically be used by nearly any IT organization in the world.

The next TOGAF specialization level is called system-wide architectures. These principles can be traced in many, but not all types of enterprises. The next one is an industry level of architecture. These principles are specific for enterprises engaged in one area of activity. The final level is the organization architecture level. This is the highest TOGAF specialization level. These are architecture of specific enterprises.

TOGAF includes two main components:

• Architecture Development Method defining the process of architecture development

• Foundation Architecture supplemented with a corresponding resource database, including descriptions of architectural principles, examples of implementation, as well as ADML.

TOGAF description includes seven (7) parts:

• Introduction contains a high-level description of the key concepts of the Architecture in general and TOGAF in particular.

• Architecture Development Method (ADM) is key TOGAF part, describing the step-by-step methodology for developing the Enterprise Architecture.

• ADM Guidelines and Techniques includes a description of the rules and techniques used in TOGAF ADM.

• Architecture Content Framework describes the approach to describe the Enterprise Architecture and contains meta-model of architectural artifacts, structure and description of typical architectural artifacts.

• Enterprise Continuum & Tools addresses the approach to architecture repository of architectural activities results.

• TOGAF Reference Models describes the reference models that to use in projects.

• Architecture Capability Framework approaches the organization of architectural practice in the company i.e. structure, processes, roles, skills and authorities required.

As the main processes of building Enterprise Architecture, it is important to implement only four key processes:

• Creation and development of Enterprise Architecture;

• Management of change;

• Monitoring the implementation of architectural solutions;

• Practice management.

TOGAF Architecture Development Method (ADM)

The processes of creation and development, change management, control of the implementation of architectural solutions in TOGAF are integrated into a single Architecture Development Method (ADM). This method can and should be adapted to the company’s objectives at all levels of architecture development. At the same time, there is no need to develop all possible documents and go too deep into details. ADM offers a ready-made set of techniques, tools, templates, and check sheets for each stage. The Architecture Development Method (ADM) contains ten phases. Each phase is divided into sub-processes (stages), individual works, and so on.

For example, phase D includes the following main sub-processes:

•Description of the current technological architecture.

° An overview of the business architecture, data architecture and applications for defining the initial data and the required level of detail.

° Description of the current system with the required level of detail, selected to identify the required changes when creating the target architecture, i.e. the registry software and hardware platforms used.

° Identification and description of elementary architectural blocks to be used in the new architecture. In fact, it is a question of available architectural templates.

° Development of a draft technical report summarizing the main results of the study of the current state and the possibility of using typical units.

° Submission of the draft report for review, analysis of comments and introduction of amendments, if required.

• Creation of the target technological architecture.

° Description of the current system using TOGAF terms.

° Defining architecture perspectives (representations).

° Creation of a target architecture model.

° Definition of IT services.

° Confirmation of business requirements.

° Definition of architecture and blocks used (templates).

° Carrying out a gap analysis.

Table: Phases and Objectives of the ADM

The main objectives of the preliminary phase are:

• To create an architectural practice;

• To prepare the company for the launch of architectural projects;

• To enlist the leadership support;

• To create architectural principles;

• To adapt the methodology for the company’s goals and objectives.

The main objectives of phase A (Architecture Vision) are:

• To launch an architectural project, define goals and objectives, framework, scope and constraints of the project, develop a vision of the architecture, define the relevant stakeholders;

• To develop a “project charter” and get a formal confirmation of the project start.

The main objectives of phase B (Business Architecture) are:

• To develop an architecture with a description of the current and target architecture;

• To conduct gap analysis.

The main objectives of phase C (Information Systems Architectures) are:

• To develop an architecture with a description of the current and target architecture;

• To conduct gap analysis.

The main objectives of phase D (Technology Architecture) are:

• To develop an architecture with a description of the current and target architecture;

• To conduct gap analysis.

The main objectives of phase Е (Opportunities and Solutions) are:

• To plan the implementation of project objectives;

• To identify major implementation projects and group them into transition architectures.

The main objectives of phase F (Migration Planning) are:

• To conduct cost and risk analysis;

• To develop a detailed implementation and migration plan.

The main objectives of phase G (Implementation Governance) are:

• To govern the overall project implementation;

• To prepare architectural contracts.

• To ensure conformance with the defined architecture by implementation projects.

The objectives of phase H (Architecture Change Management) are:

• To prepare for the next turn of the Architecture Development Cycle.

• To ensure the compliance of the change management with the actual needs of the business and maximum value to the business.

The main objectives of the Architecture Requirements Management are:

• To collect and agree on business requirements at each phase of the architectural project;

• To identify, store, the requirements, to define the priorities and use then in the relevant phases of the architectural design.

The TOGAF specification also enables flexible work with stages. The specification states the following:

Before applying the architecture design methodologies, one needs to check whether the components are applicable and then link them to the specific circumstances of the individual enterprise. This allows creating a methodology for architecture developing for a particular enterprise.

The TOGAF model enables partial implementation of stages, skipping, merging, reordering, and amending them to meet specific requirements. Not surprisingly, two TOGAF certified consultants working with the same organization can develop two completely different processes.

The TOGAF model is even more flexible for the architecture created. In fact, TOGAF “knows nothing” about architecture. The quality of the final architecture can be good, bad or even undetermined. TOGAF describes how to create an enterprise architecture, but does not describe how to create a good one. The quality of the final product depends on the experience of the company’s staff and the TOGAF consultant. Those who introduce TOGAF hoping to get a miracle cure, will be severely disappointed (like using any single methodology).

Foundation Architecture

Foundation Architecture includes:

• A set of the most common services and functions, combined in a Technical reference model (TRM);

• A set of elementary architectural elements used as “building blocks” for building specific solutions;

• Standards Information Base.

The concept of using the Foundation Architecture is defined in accordance with the breakdown of architectures included into a common continuum of definitions. A technological reference model in TOGAF is recommended for use, but not mandatory. In general, the technological reference model is not perfect for the reason that it aims to ensure the portability of applications sacrificing their interoperability and autonomy. Implementation of TOGAF model in organizations is mainly reduced to an architectural design methodology. In this sense, the Core Architecture component, which contains a set of services and standards, is some abstract implementation of the entire IT system. The Common Systems Architecture is implemented by selecting and integrating specific services to shape dedicated blocks that can be used in various functional areas, such as security architecture, network architecture, etc. (possibly, repeatedly or in various combinations).

The next level of detail is implemented at the level of the Industry Architecture, which adds industry-specific data models, applications, standards, business rules, and, if required, procedures for the interaction of various industry systems. The final level of the Organization Architecture deals with formation of the IT architecture within a particular enterprise, taking into account all of its features, including the availability of legacy systems, plans and implementation possibilities, organization of data at the physical level, etc.

The Reference Model includes a common services system (taxonomy), including such services as Data Exchange and Transformation, Data Management, Internationalization Support, Directory Services, etc.

The level of implementation quality should be defined for all services used in the architecture such as manageability, flexibility, warranty, usability, etc. along with the functional purpose. It should be noted that some services are interdependent. For example, specialized software development service components may be required to create and test relevant software products to ensure a specified quality of internationalization service.

Architectural principles are fundamental “axioms”, used as “starting points” for evaluating the current system and for developing individual architectural solutions. Generally speaking, architectural principles are a subset of the more general concept of IT principles, which define the main aspects of all activities related to the use of information technology. IT principles, in turn, are a detailed elaboration of the more “common” principles defining the activity of the entire enterprise.

The structure of a set of principles may include justifications for the formation of a system of requirements or criteria for evaluating decisions. For example, such a principle as “minimization of the number of software providers” can be further specified as a requirement of a “unified DBMS for all business-critical applications” or “using the same DBMS as the current one” depending on the characteristics of the enterprise. Architectural principles can also be used for justification of the significance of the very notion of Architecture and the necessity to develop it for the enterprise business, as well as to select options for implementing this process.

These principles are interdependent and should be applied as a consistent set. A “good” set of principles must satisfy such natural criteria as availability for understanding, accuracy of formulations, completeness, consistency and stability (not to be confused with invariability!) Usually the number of principles does not exceed 20 in order not to restrain the flexibility of the architecture or to avoid a purely formal definition of unworkable principles.

Examples of principles, used to create the TOGAF architecture (Title and Content):

• An example of use is applicability of the defined principles of IT management to all cases and divisions of an organization.

• Maximum benefit is that IT decisions are made based on the maximum benefit for the entire organization.

• Everybody is involved since information management is everyone’s business.

• Business Continuity i.e. enterprise operations should be ensured in spite of all possible interruptions in IT operations.

• Common use — the priority should be given to developing or implementing applications applicable to the entire enterprise, rather than its individual divisions.

• Compliance with the law implies that IT management should not contradict the applicable law and the adopted regulations. However, this is not an obstacle to the improvement of business processes, leading to changes in these regulations.

• Responsibility of IT services implies that IT service is a liable owner of IT resources and the executor of processes to meet the business requirements.

• Intellectual property protection implies that ensuring the protection of an organization’s intellectual property should be implemented at the architecture level, IT operation and management.

• Data in IT system is an asset and have a certain value. They must be appropriately managed, shared and accessible to users depending on their access rights.

• Quality Assurance implies that the quality of every data element must be managed.

• Metadata must be consistent within the enterprise and accessible to all users.

• Data Security ensures data protection from unauthorized use and distribution.

• Technological independence implies that applications should not depend on specific models of equipment and system software.

• Simplicity of use implies that applications allow focusing on the implementation of business objectives through a single interface, minimizing the specifics of work, integrating systems, reducing the likelihood of misuse.

• Soundness and promptness of changes implies that changes in the information system and applications are made only in accordance with the business demands and duly.

• Interaction implies that the hardware and software must integrate with one another in accordance with common standards.

• Minimizing Diversity refers to reducing the number of different options for the platforms, products and versions applied.

TOGAF Architectural Practice Management

Architectural practice is the practice of implementing an architectural project within organization. Architectural practice consists of four key elements:

• People are the foundation of any company’s activity. If people cannot do, do not know how, do not use, do not participate, do not want to or do not do something, everything else is useless. If you have forgotten about people, you have to forget about the results.

• Artifacts. Working people must achieve predetermined results. They also create artifacts enabling to share information, discuss objectives and issues, save ideas for later implementation, monitor the achievement of results, etc.

• Processes. In order to achieve results, people must do the right things in the right sequence. All people make mistakes, but if they follow predetermined processes, the likelihood of errors decreases, and their consequences can be easily eliminated. Processes help turn good ideas into results. So, one cannot just shrug off them lightly.

• Management. Architectural practice is doomed to failure without proper management. One should determine the framework and rules of practice beforehand, taking the standard processes, artifacts, roles, etc. as a foundation. It is very dangerous to make up the rules as the game is on. People will be disoriented, processes will fail, the results will be wrong and at the wrong time.

Architectural practice management is required to exclude the common mistakes made by people working on a task or project. People are unlikely to achieve results if they:

• go too deep in the theory and research;

• do useless work;

• make long preparations before commencing the work;

• re-invent the wheel;

• “optimize” their work instead of doing it;

• theorize too much;

• Search for someone to blame;

• find themselves the smartest ones;

• avoid unpleasant work.

The approach to the architectural practice management consists of six main elements:

• Methodology is the main element of the approach. It defines the company’s processes for developing, updating, and implementing the Enterprise Architecture, their roles and responsibilities.

• Artifacts include a set, templates and rules for filling in the documents, tables, diagrams, used for description of the Enterprise Architecture.

• Standards are the standards, laws and rules of business and IT used by the company. These can be international standards, Russian standards, standards of the industry, region, and company.

• Best practices and ready-made models are proven ways to implement solutions, tested in your or in other companies.

• Regulations and rules are the documents describing the goals, objectives, organizational structure, rules of work and the boundaries of architectural practice. They contain the rules of work with other subdivisions, and architects’ authorities. The regulations should be integrated with other company regulations, especially those of the IT department.

• Managerial impact by practice managers are aimed to ensure practical results in the company. One needs to plan, get people to follow processes, start architectural projects, resolve conflicts, monitor intermediate results, etc. No elements will work being unmanaged.

First, the order of implementation of architectural practice includes development of all these company’s elements from scratch — that is a very difficult task to do. Therefore, one needs to take the existing methodologies and adapt them according to the company’s needs. Secondly, the practices should be introduced gradually, as a part of the practice development. The introduction of each element should be a real value for the practice. Third, one should keep a balance between bureaucracy and personal initiative. Finally, do not be afraid to experiment and try new approaches. If they are valuable, describe them in the regulations and use them in your next projects.

TOGAF Key Documents and Templates

To implement the TOGAF methodology, the question arises: what is the minimum set of documents required to maintain an architectural project? Extra documents mean extra time and funds. From my own experience and theory (during preparation for certification), the minimum set can consist of eight documents:

• The Main Methodologies are Templates, Business Principles, Goals, Drivers, required to understand the company’s mission, goals, and strategy and register the business principles. See Template “TOGAF 9 Templates, Business Principles, Goals, Drivers.doc”

• Architecture Principles are the rules to guide the work on architecture. Architectural decisions are made based on these principles. Principles need to be formulated based on TOGAF examples. Using principles when working on architecture has proven its effectiveness. See Template “TOGAF 9 Template Architecture Principles.doc”

• Architecture Vision is a high-level description of the desired end product of an architectural project. So, these are the results to achieve. Description of the solution of the problems and tasks to start the project for. This document is important for interaction with the project sponsor and other stakeholders. See Template “TOGAF 9 Template Architecture Vision.doc”

• Statement of Architecture Work is an agreement between the sponsor and the project team on the implementation of the work. It includes all the frameworks, restrictions, assumptions, terms, budget, and project rules. It designates the project manager and states his/her rights and responsibilities. Addendum includes the architecture vision as a description of the project framework. See Template “TOGAF 9 Template Statement of Architecture Work.doc”

• Architecture Definition is a presentation of the current and target architecture and covers each of the architectural domains i.e. business, data, applications, and technology, as well as an analysis of the discrepancies between the current and future state. See Template “TOGAF 9 Template Architecture Definition.doc”

• Architecture Requirements Specification is a document providing a quantitative view of the requirements, restrictions, suggestions, and measurable criteria that must be met during the implementation of the architecture. See Template “TOGAF 9 Template Architecture Requirements Specification.doc”

• Transition Architecture. The implementation of the target architecture has several stages. Each intermediate state must be workable and valuable. This document groups projects for each of these stages. See Template “TOGAF 9 Template Transition Architecture.doc”

• Implementation and Migration Plan is a consolidated implementation plan for projects aimed to achieve the target architecture. It also includes benefits, scope, timeframe, cost, risks, and milestones of projects. See Template “TOGAF 9 Template Implementation and Migration Plan.doc”

Such set of documents can be done rapidly and in a cost-effective way. If you are going to use third party services, I recommend to include one more document — an architectural contract. This is an agreement between architects and IT project executives. See Template — “TOGAF 9 Template — Architecture Contract.doc” When accepting a project, it will be easier for you to get the desired result if you have agreed on it beforehand.

Management Strategy

When forming an IT Strategy, one can determine the strategy on “Technological Architecture” and “Information Systems (Services) Architecture” of some IT infrastructure components, as well as recommendations on choosing solution. To understand the problems of the business and translate them into the IT language, you can use the method of “problem tree — solutions”. As can be seen from the diagram, business formulates its problems in the language of business. The task of the CIO is to translate the business language into a technical language, for the further development of IT projects and setting tasks for the IT department staff In order for business and IT to understand the need to demand from each other, it is necessary to define criteria for achieving goals and objectives, as well as metrics for their measurement.

Financial control strategy

A financing strategy may foresee an organization’s behavior in IT financing. In particular, it is desirable to have a financial strategy on issues such as:

• cost of the solution as a priority when choosing an IT project solution, even if it affects the functionality. Solution capabilities must meet business requirements with minimal cost;

• focusing on the use of free software;

• balancing by cost or functionality.

For example, the cost of leasing circuits for different branches of the same bank may differ depending on the distance or geographic location. Let us say that the cost of a 10 Mbps channel (which is a standard and sufficient IT requirement) for a regional branch costs 500 USD. The city branch can get the speed of the channel up to 100 Mbps for the same cost. This branch has a current standard speed of 10 Mbps for about 100 USD a month. The average cost of a communication channel for all branches is about 250 USD. The leadership should have a certain strategy regarding this issue, i.e. provide branches with an opportunity to increase speed within the average cost, maximum cost, or leveling all up to the established channel speed (10 Mbps).

Outsourcing in the implementation and maintenance of Information Systems and projects should be used whenever possible. The capabilities and potential of the IT department staff should be increased.

Administrative strategy

The strategy of changes may foresee the organization’s behavior when changing in requirements, etc. As an example, let’s consider the situation when the number of employees remains unchanged, while the speed of Internet access has dropped significantly due to intensive use. As a solution, the bandwidth can be increased, that will affect the costs accordingly. This issue will periodically occur until it reaches the critical point. Another solution is “repressive” method, i.e. having analyzed the network traffic, the IT department determines that the misuse of the Internet has increased. Some administrative controls may lead to improvement of Internet speed without increasing the costs.

Strategy of Infrastructure Building

Architecture choice strategy

As a solution architecture, one can consider the following:

• On premise infrastructure;

• Cloud based infrastructure;

• Hybrid architecture.

“On-premise” implies that IT assets are physically located within the organization. Benefits:

• IT infrastructure is located within the organization and controlled by organization’s IT employees.

• Relatively low operative expenditures of IT infrastructure.

• Solution autonomy and higher security.

Deficiencies:

• Relatively high capital expenditure in IT infrastructure.

• The introduction of new services, or surges of existing services are difficult to plan.

• The need to hire IT specialists to maintain physical servers, network equipment, and so on) leads to additional costs.

• Indirect costs for IT engineering systems.

“Cloud based” implies that IT assets are located in the “cloud”.

Benefits:

• Relatively low capital expenditure in IT infrastructure.

• High level of planning of maintenance costs for IT infrastructure.

• Good communication, linear relationship between the resources used and their cost.

• Easiness to implement new solutions and expand existing IT services.

• No need for additional staff.

• No need for indirect engineering costs.

Deficiencies:

• Relatively high operative expenditures of IT infrastructure.

• Higher requirements for Internet bandwidth and backup channels.

“Hybrid” architecture provides combined solutions.

Benefits: The benefits of the first two solutions are used.

Deficiencies: A higher capital and operative (CAPEX and OPEX).

Recommendations for selection:

“Cloud based” solution is more preferable for initial projects, small organizations, organizations with developed geography and so on. “On-site” solution is more preferable for well-developed organizations, financial institutions, organizations where access to the Internet is not a business requirement. “Hybrid” solutions can supplement the IT infrastructure and replace some components of the IT architecture.

Infrastructure platform choice strategy

If you choose “On-premises” as deployment infrastructure, there are the following options:

• Physical servers as a foundation;

• Virtualization platform as a basis;

• Mixed infrastructure with no dominance.

“Physical servers” implies that IT services are located on physical servers. Benefits:

• Relatively low capital expenditure of IT services for small solutions;

• The resources of the physical server are fully allocated to the tasks of a particular service.

Deficiencies:

• The complexity of maintenance as the infrastructure grows;

• Deployment and recovery speed.

• Sub-optimal use of computing resources.

“Virtualization Platform” implies that IT services are located on the virtualization platform as virtual machines. Benefits:

• Relatively low operative expenditures of IT infrastructure.

• The platform is de facto standards for the deployment of “On-premises” solutions.

Deficiencies: Relatively high capital expenditure in IT infrastructure.

Recommendations for selection:

“Physical servers” solution is more preferable for small, isolated or remote IT services, or high volume systems. For all other cases, it is better to use a virtualization platform.

Choice strategy for data storage system

If you choose “On-premises” as deployment infrastructure, there are the following options:

• Physical servers and Direct-Attached Storage (DAS);

• Centralized Data Storage System, i.e. Network Attached Storage (NAS) and Storage Area Networks (SAN);

• Distributed Data Storage System, i.e. Digital Data Storage (DDS) and Software-Defined Storage (SDS).

Physical servers implies that the data is located on physical servers.

Benefits:

• Relatively low capital expenditure of IT services for small solutions.

• The resources of the physical server are fully allocated to the tasks of a particular service.

Deficiencies:

• The complexity of maintenance as the infrastructure grows.

• Deployment and recovery speed.

• Sub-optimal use of computing resources.

Centralized Data Storage System (NAS, SAN) implies that the data are located on a single data storage system partially or completely. DSS is a single complex consisting of controllers and disk storage racks.

Benefits: Relatively low operative expenditures of IT infrastructure.

Deficiencies: Relatively high capital expenditure of IT infrastructure.

Distributed Data Storage System (DDS, SDS)” implies that the data is distributed between different physical servers. A storage system is a complex distributed within the network and consisting of data controllers and disk storages.

Recommendations for selection:

“Physical servers” solution is more preferable for small, isolated or remote IT services, or high volume systems. For all other cases, it is better to use a virtualization platform.

Strategy of choosing the manufacturer

The strategy for choosing software and hardware determines the approach to the choice of manufacturer, standardization, and so on.

The following options can be considered:

• Use of a limited list of manufacturers;

• Use random list of manufacturers.

Using a specific manufacturer for each category of IT assets implies using hardware and software standards within the organization.

Benefits:

• Implementing IT asset standards simplifies providing an organization staff with IT assets;

• It facilitates the implementation and maintenance of IT infrastructure, and increases the level of the organization’s information security.

Deficiencies: Relatively high cost and dependence on the manufacturer/supplier.

Using a random manufacturer implies use of recommendations instead of hardware and software standards within the organization.

Benefits: Relatively low cost and promptness in procurement of IT assets.

Deficiencies:

• The process of providing an organization staff with IT assets is more sophisticated and takes longer;

• It complicates the implementation and maintenance of IT infrastructure, and

• reduces the level of the organization’s information security.

Recommendations for selection:

The first licensing option is recommended is recommended to organizations with close integration and dependence of business and Information Technology or a large number of employees.

Licensing strategy

The licensing strategy determines the approach to licensing methods. The following options can be considered:

Using an “Enterprise” license agreement with the annual software update. Licensing is an ongoing IT process.

Benefits:

• Greater flexibility of licensing.

• Maintaining the high level of IT infrastructure and information security due to using updated versions of systems and solutions.

• Systems are upgraded smoothly, with no surges in requirements of IT, human resources or time.

Deficiencies: Relatively high cost.

Purchasing commercial off-the-shell retail versions with no software update. Licensing “upon request”.

Benefits: A relatively cheaper option.

Deficiencies:

• Less freedom in licensing.

• The level of maintaining IT infrastructure and information security is reduced due to using not the most updated versions of systems and solutions.

• Systems are upgraded in jumps (every three, four years), and require additional IT resources, people, and time.

Recommendations for selection:

The first licensing option is recommended to organizations with close integration and dependence of business and Information Technologies.

The strategy of building engineering systems

“On premise” and “Hybrid” solutions demand to determine the engineering system requirements. The engineering systems requirements for may include:

• Physical requirements for the premises of the data center, server room, data cabinets etc.

• Requirements for a Structured Cabling System (SCS).

• Requirements for redundancy, reservation and so on.

Testing strategy

Testing is one of the important elements when building an IT architecture. Testing questions have to be identified at the design stage. There are the following platforms:

•“Test or Development” is a platform with individual IT services deployed which is used to develop services or adjust IT service elements.

•“Pre-production” is a smaller “Production” platform containing all the components of the IT architecture. It is used to test the interaction of IT services and allows emulating troubleshooting, estimating performance, and so on.

•“Production” is a platform with detailed computing resources providing IT services.

Recommendations for selection:

Various solutions can be implemented depending on the business requirements and the organization’s financial capacity. A detailed description is further discussed in this guide.

Redundancy strategy

Defining the redundancy level of IT infrastructure components indicates the requirements for duplication of components. It can be reviewed as follows:

• Components of engineering systems (channels and communication cables, switching racks, etc.). Reservations (duplication or redundancy) at the level of critical elements, such as:

• Channels and communication cables (two or more in different stacks),

• Excessive number of operating points (ensures the organization growth and backup).

• Device components (server, switch, and so on). Duplication at the level of critical elements such as:

•Processors (two or more),

• RAM (two or more),

• HDD (two RAID1hard drives + one backup)

• Network cards and adapters (two cards with one or more ports)

• Power supply units (N+N or N+1)

• IT service components. Backup at the device level and the type of their inclusion. For example:

• Two servers in a failover cluster

• Two servers performing the same function (two domain controllers)

• Two servers performing different functions in the normal mode, but can assume the neighboring function in the case of a failure (File server and print server. In case of failure, one can install the function on a neighboring server).

• Geographically separated devices within the site. Allocating a pair of devices in different racks, rooms, or buildings within the same site.

• Geographically separated devices at the site level. The allocation of a pair of devices on different sites.

Determining the backup level depends on the business criticality of failure or downtime. It is analyzed within Risk Management, formalized in documents on equipment standards.

Backup and Archiving Strategy

Backup systems and archiving IT infrastructure may define the following requirements:

• System components must be installed on dedicated physical elements (servers, storage, and so on)

• Backup and archiving systems on the same components can be combined.

• Access rights to (automatic) backup accounts should not provide an opportunity to delete data or overwrite them.

Backup building strategy

Backup component is one of the important elements when building an IT architecture. It relates to the information security, fault tolerance and recovery. The fault tolerance can be as follows:

• Fault tolerance at component redundancy level;

• Fault tolerance at the level of duplicating elements;

• Fault tolerance within the site;

• Fault tolerance with geographically distributed site.

Approaches for Enterprise Architecture Implementation

When designing company’s architecture, one should not start with developing a strategic architecture. The “Top-Down” approach (Strategic Architecture Segment Architecture Solution Architecture) is certainly the most widely spread and has many benefits:

• The general development vector of the organization is understandable.

• Less confusion on the segment and solution level.

• General rules and approaches are implemented at the organization level, and then spread to the segments and solution level.

• Common information systems and services are reusable within the company at the segment and decision level.

The main idea is the movement from “Generic-to-specific”, as well as continuous improvement of the IT architecture is based on business requirements. However, other approaches are also available:

“Bottom — Up” (Solution Architecture Segment Architecture Strategic Architecture), i.e. from the solutions of specific architecture design to strategic architecture. The company starts with a solution architecture. Before the project commences, the solution is being worked out and described. Then come higher levels of Enterprise Architecture. This method allows get a quick value from the Enterprise Architecture methods. However, there is a likelihood of dispersal of various architectural solutions without a strategic architecture foundation. It will take time and resources to bring them to a common denominator.

“From the Segment” (Segment Architecture Solution Architecture and Strategic Architecture) will be useful for the companies to solve problems in a particular division, launch a new business, or if the company is not ready for large-scale implementations of Enterprise Architecture and wants to practice more. It will help test ideas in one department or business direction. One needs to choose the company approach depending on the goals and terms of their achievement.

Your company’s information systems are likely to be far from being perfect. However, denying and redoing will be very expensive and take a lot of time. The value of such an initiative is much lower than zero. An experienced architect will fix the problems of integration, information security, infrastructure, and make the system be more valuable for the company. The process will be applied through slow and precise modifications. He will solve specific problems, instead of “doing all the right things.” Replacing the system is a major change for the company requires strong arguments.

The next important question in the implementation of building Enterprise Architecture is whether you should hire consultants or do everything yourself (MAKE or BUY)? There is no clear answer. Everything depends on the specific organization, goals and capabilities. For example, let’s imagine a situation:

We sign a contract with a respectable company “SUPER DUPER CONSULTANTS & Co.” A few months later we receive a set of documents called “The architecture of the BANANAS & Co company”, which contains the right system, many charts, descriptions, and so on. It can be called a “turnkey” solution. It is so tempting, isn’t it? It might be expensive, but prompt, professionally done, facile and flawless.

Using external resources, other people’s experience and knowledge is certainly one of the fastest ways to achieve results. However, there are a few drawbacks:

• The transition plan will be suspiciously similar to the list of product and service provided by this respectable company. Any external contractor within the project will sell other goods and services. This is a common practice and one of the main laws of sales.

• You will have only a set of documents, not an architectural practice. You will have a description, but all the processes, people, and management will be gone as the consultants leave.

• Your people will never have a chance to try, since consultants will do all the job and use a new experience and knowledge with a new customer. Your specialists will be paper architects. They will not have a key skill — the ability to make technical decisions.

In my opinion, building processes in an organization requires strong, competent, and capable managers, who have theoretical and practical skills, are familiar with the company’s culture and interested in transferring experience and knowledge to their colleagues and employees. They must play a major role and be the driving force of the organization.

I would recommend involving external consultants, but I would not give 100 percent of architectural work to outsourcers. The company should own not only the results of projects, but also people, knowledge and experience. Therefore, your staff being supervised by an expert to guide them must perform most of the work. Project implementation must include resources for training employees because the biggest life lesson is that “practice is blind without theory while theory is dead without practice.”

Enterprise Architecture Implementation Tools

What tools should be chosen and how to develop Enterprise Architecture? Today’s market offers dozens of tools, from free to expensive ones. Implementing some of them can cost hundreds of thousands dollar. I recommend using free or cheap tools whenever possible (if not available) for the following reasons:

• At the very start of architectural practice it should prove its effectiveness, therefore, significant investment and lost time will be a serious obstacle to create it.

• At the initial stage, it is better to use simple and familiar tools that do not require additional implementation and training. Success is determined by the implementation speed.

• One needs to gain experience and get his/her first results in order to shape adequate requirements for an expensive system.

• Only after the practice has been launched, and experience and first results have been obtained, is it time to switch to specialized products.

What are the minimum requirements for tools? How are they supposed to help you?

• Write and edit texts, make charts and tables, presentations, etc.

• Publish them on a shared resource, regulate the access rights to information, and discuss these materials.

Below is the set of tools:

• For example you can use a standard MS Office suite to compile documents, charts, spreadsheets and presentations. MS Office offers documents templates to use. There are Visio extensions to draw all the required flowcharts.

• You can use a corporate portal, a document management system, a corporate mail system, a corporate messaging system, or a dedicated file share in an organization’s corporate network for collaboration. The choice of solution will depend on what your company already has.

Recommendations for implementation

Based on the requirements and constraints defined above, you can summarize the basic approach in building the company’s IT architecture:

• Service oriented approach to building IT architecture;

• Minimizing risks by using tested and well-proven technologies and solutions;

• Reducing costs by maximizing and optimizing the use of current IT assets and solutions;

• Reducing the complexity and heterogeneity of the existing infrastructure;

• Maximum possible rational approach to the consolidation of IT assets (hardware, software), keeping the level of user support and / or specialized systems at the periphery;

• Multiple use of IT assets (IT personnel) on projects within the company;

• Standardizing IT assets (hardware, software and solutions) to reduce the cost of ownership, complexity of maintenance and increase information security;

• Implementation of single IT policies and procedures to reduce the cost of ownership, complexity of maintenance and increase information security in the company;

• Automation of routine IT processes to reduce the cost of ownership, maintenance complexity and increase information security;

• Creating a single information security policy in the organization;

• Creating a project team with a high level of competence.

Compatibility

Wherever possible, consider the availability of existing systems and maximize their benefits. This will reduce the cost of replacement, or the implementation and maintenance of new systems.

Following the main principles

When implementing new or intermediate solutions, or launching a business (or expanding it), it is recommended to be guided by the main requirements stipulated by this document. The cost of the solution and maintenance of IT infrastructure directly depends on the choice of a solution.

Conclusion

In conclusion, it can be said that building an Enterprise Architecture is one of the most important aspects of building an effective corporate governance mechanism with the integration of information technologies to obtain the best results. Integrating IT Service Management (ITSM), Project Management Methodology (PMM), Control Objectives for Information and Related Technologies (COBIT) will enable businesses to achieve exceptional results and maximize the benefits of IT.

PROJECT MANAGEMENT

General provisions

Project management is considered as a method and a set of procedures based on adopted management principles used to plan, evaluate, and control work assignments in order to duly achieve the desired result, within the budget and in accordance with project requirements. This chapter contains the basic principles of project management, which should be taken into account when building an IT Enterprise Architecture. Any projects involving, affecting or depending on IT are IT projects. The “project” approach should be a guidance when planning, developing and implementing various IT architecture services.

Project management is a very broad topic, affecting and interwoven with various directions of activity, such as quality management, risk management, finance management, and so on. This chapter briefly describes the main aspects, methods and techniques of project management.

A project is a one-time, non-recurring activity or set of actions to be taken within specific term, and aimed at creating unique products, services, results or clearly defined goals. The signs of the project are:

•There is an exact start date. The key feature of the project is the “time component”, i.e. there is the beginning and end of the project.

•There is an exact finish date. Date of the estimated deadline for the project is to be set, but the finish date is fixed upon obtaining the final result or achieving the objectives of the project.

•The project result is unique. This is the second distinction between a project and a process or regular activity. “Unique” does not mean absolutely new for everyone, it can be unique for an organizer or team.

•The resources and budget are limited.

• The specific order of the assignments. It may imply temporary changes in the managerial breakdown and make it different from the one established in the organization.

Program differs from the project by a larger scale and possibility to consist of many projects. For example, an organization has a transition program to a centralized IT management system, which may include several separate projects.

An assignment or a set of assignments is a set of actions to be performed by one or several persons using a simple list defining a sequence of actions.

Key Aspects of Project Management

Triple Constraint or Project Triangle describes the balance between the scope, cost and schedule of the project, which affects the final result, i.e. quality. Quality is the fourth element of the Project Triangle, located in the center, and any change in the sides affects it.

There is a huge difference between doing something well, fast or cheap. It is impossible to change one of the factors (funds, list of jobs, time or quality) without affecting at least one of the them. As an example:

• In order to approximate the finish date (time) of a project, one can spend more resources (funds) or remove some assignments (scope) from the project.

• In order to terminate a project within a budget (funds), one can either reduce some assignments (scope), which will affect the product’s capabilities (quality).

• In order to add new features (quality) to the product, one can extend the project’s timeline to allocate time for new assignments (time), thereby adding new tasks (scope) and involve new people to work faster (costs).

The idea of all methods and approaches is to focus attention on one or several factors controlling the effects on the rest.

Criteria for a project success are defined by the actual indicators to coincide with planned ones in terms of duly project termination, within the estimated budget and in accordance with the requirements for the final result. These requirements can and should be formulated and include measurable criteria, i.e. indicators of project success.

The goal of the project manager is to achieve the criteria for project success.

The main task of the project manager is to maintain the balance of the project triangle.

According to practice, only a quarter of all projects reach the criteria for success. That is why planning a project one should indicate the main success factors of the project (for example, the project budget and the continuity of the result), as well as possible tolerances — the allowed deviations of related factors (for example, the project implementation timeframe, but not more than ten percent, etc.).

To make project management more convenient, an organization can implement a classification of projects by different categories. Each organization defines the categories and characteristics of the project independently. Below is a general classification of a project by complexity:

• Simple project aims to generate new or improve existing business processes, information systems, software, documents, services, machines, and equipment. Only one business process will be changed or created in a company’s single division. Simple project usually has a low cost, a small scope of work, and a short time frame and involves a small number of employees.

• Complex project aims to generate new or improve existing business processes, information systems, software, documents, services, machines, and equipment. Several business processes will be changed or created. Complex project involves several company divisions and usually a high cost, a large list of assignments, a long time frame and a large number of employees.

Classification by priority allows defining the project implementation sequence: Low, Middle or High. The projects can be classified by purpose in regards of interaction with IT:

• Administrative projects deal with organizational changes, which usually do not affect the IT infrastructure, or involve IT resources.

• Internal projects are usually implemented within one department and make insignificant changes in IT infrastructure and do not involve many IT resources.

• IT projects are carried out within the organization and have a significant impact to IT infrastructure. They aim to replace the organization’s current IT infrastructure and involves significant IT resources.

The very first phase (stage) of the project, regardless of the project management method chosen, is the initial stage or project initialization. At this stage, the decision is made to start the project. This book suggests that the project initiators can be:

• Business units, or

• IT department.

An introductory information at this stage can be an organization strategy or a business plan.

A business plan is a document providing a detailed justification of the project and the ability to comprehensively assess the effectiveness of decisions made, planned activities, and answer the question whether the project is worth investing.

Defining project objectives is one of the most important aspects of the project management process. Each project should have at least one main objective and possibly several private, subsidiary goals. The objectives are:

• Sets the direction of the project implementation.

• Defines results in terms of end products or services.

• Serve as a source of information to resolve the project’s controversial issues.

The statement of the main objective should be action-oriented, short and simple, and as clear as possible. It is important to remember that the objective should be formulated using the terms not to confuse project participants, decisions makers or those who read project documents. At the initial stage, the formulation of objectives can be murky and express a general direction.

Determination of stakeholders allows identifying the direct customer, final decision makers, as well as general issues related to the project arrangement, such as organization, project team by areas (the managerial level), interaction procedure, decision-making, communication mechanisms, and so on.

The output of this phase is to identify stakeholders, set project objectives and general issues of the organization. Depending on the project management methodology, additional conclusions and results may be formed. A business plan, a project charter or the meeting minutes can be considered as the primary documents of the initial stage.

The next stage of project management can be planning. Planning is the most important and difficult stage of project management. This stage deals with detailed project development and answers to the main question: whether the organization is ready for the project and if the project will be successful. The level of complexity depends on the methodology and the complexity of the project. At this stage, one collects business requirements, specifies objectives, determines success criteria, details tasks, plans resources, time, and so on. Key documents at the output of the planning stage can be a project plan, terms of reference etc.

Coordination and approval of the project is a stage, or better to say, determination of the “milestone” or reference point of the project that answers to the main question: whether we start the project, or not? Once the leadership has approved the project, the stage of execution commences. This stage can be different for different project management methodologies.

Project implementation begins once the project is approved. Planning stages are completed and the project is being carried out. Implementation starts with making a project team, followed by the detailed development and distribution of assignments and estimate. The project is considered as implemented if the final product of the project meets the project requirements. Regardless the methodology implementation consists of the monitoring phase and project status control that are performed at the same time. Another important process is Management of Change. The main documents at this stage are project status reports, performance reports, and resource utilization report.

Once the project is implemented, the final stage of termination commences. The project is complete in terms of achieving the project objectives and obtaining the expected outcomes. In addition, the project owners or the leadership may decide to terminate the project ahead of schedule, or to change the project objectives leading to its termination.

Project Management Approaches and Techniques

Choosing the right Project Management Methodologies (PMM) is the first step for your team to succeed. Project management helps improve the implementation process in terms of efficiency and cost, while reducing risks. However, declaring priorities is not enough. One should have good understanding of the positive impact of each project management methodology and the way it can interfere with the successful implementation of the project.

This chapter will briefly review the most popular project management methodologies and consider those I find the most interesting ones in more details.

Process-Based Project Management (PBPM)

PBPM is the main today’s approach to the project management, based on the process approach. This approach is a guarantee that each project will be directed to the continuation of the company’s mission. Before the project starts (initiation), the project plan is analyzed to determine its compliance with the approved or established mission. If the result of the analysis is negative, then all strategies and objectives are adjusted. Each action adds value to the organization’s strategic vision. These project management methods are also suitable for administrative projects in companies.

WATERFALL Project Management Methodology

WATERFALL is a traditional project management methodology. It is also called the “cascade” or “flow” model, due to the fact that its proposed sequence of phases resembles a waterfall. The most obvious way to make your project more manageable is to break down its implementation processes into consecutive stages. Such linear structure is a foundation of traditional project management. This approach does not imply a return to the previous stages upon their termination and adoption, or making changes to the project requirements. This project management methodology involves splitting a project into a series of sequential assignments, with a clear estimated objectives and deadlines. Project members perform tasks in due course, completing each assignment before proceeding to the next one. The stages in the “waterfall” model as applied to IT software development projects, are the following:

• Requirement analysis

• Design

• Implementation

• Integration

• Verification

• Installation

• Maintenance

In this case, the developer cannot proceed to the next stage without completing the previous one. First, the requirements are completely defined, resulting in a list of software requirements. The next stage is design aimed to create the documents with detailed description of the method and plan for implementing these requirements for programmers. After the design is completed, the programmers carry out the project. The next stage deals with the integration of individual components developed by various programming teams. After the implementation and integration are completed, the product is tested and debugged. At this stage, all shortcomings that occurred during the previous development stages are eliminated. After that, the software product is implemented and maintained — introducing new functionality and eliminating errors.

The strengths of the classic project management are the requirement for the customer or company leadership to determine what they want to get at the first stage of the project. Early inclusion brings some stability to the project, while planning streamlines the implementation of the project. Besides, this approach involves monitoring indicators and testing, which is absolutely necessary for real projects. Potentially, the classical approach allows avoiding stress since there is spare time at each stage, reserved for any complications and risks occurring. Moreover, correct planning stage allows the project manager to know what resources are available, even if this assessment is not always accurate. The main benefit is an ability to estimate the implementing cost of the solution in advance and monitor the state at all stages of the project management life cycle.

The weaknesses of the classic project management are the intolerance for change. If your project is not restrained in resources and time, and the project content has been modified, you should better look at other project management systems. Moreover, in real IT projects it is quite difficult to formulate detailed requirements for the final project at the initial stage.

Agile Project Management Methodology

AGILE is a family of processes and methods for developing flexible methods to manage and administer projects. Agile is a set of ideas and principles of how to implement projects. Frameworks, individual flexible methods such as Scrum, Kanban, Crystal, LeSS, SAFe, Nexus and many others have been developed based on these principles and best practices. These methods can be quite different from each other, but they follow the same principles. Flexible methods involve changes in product requirements throughout the project. Such design implies a completely different approach to project management. The methodology was initially developed for projects requiring high flexibility and quick implementation. Flexible project management is a progressive and iterative project methodology. Its main feature is that at the beginning of the project the final product of the project is unknown as well as the project life cycle. The project activity is split into several iterative phases, short cycles called sprints. Each sprint consists of multiple tasks and has its final product and result. The Agile methodology allows project managers to constantly receive feedback and improve the product after each iteration. In accordance with this methodology, responsibility for the result is divided between three positions:

• The product owner defines the project objectives, develops the optimal schedule for the project parameters, adapts the project implementation process to the changed requirements and sets priorities in the product specifications;

• Scrum master sets priorities for task to be executed by the project team and eliminates difficulties that could prevent their execution;

• Team members execute most of the assignments, carry out daily management, create progress reports, and monitor the quality of the product.

AGILE methodology is flexible and enables changing project parameters easily, which is important for service-oriented projects such as software development or graphic design. But this methodology is not suitable for projects with strictly defined parameters and requirements.

Project management requires quick adaptation to changes, tracking recent development trends and ability to benefit from them. The human resource is equally important. Therefore, the ability to create a dynamic project team based on cooperation and flexibility and the possibility of finding a compromise are necessary. Stakeholders are also very important. They monitor and check each stage of the project, while the team members, in turn, promptly correct the project, creating high-quality products or services that meet consumers’ needs and demands.

AGILE design is better applicable for projects that require intensive interaction in real time and are implemented by highly motivated teams that do not need additional control. The AGILE methodology is distinguished by high interactivity and enables quick adaptation to the project. One of its main benefits is possibility to quickly identify controversial issues and make the necessary changes at an early stage of development, without waiting for the verification. AGILE is a design ensuring the use of recurring processes, risk reduction, prompt feedback, quick turnover and reduced complexity.

AGILE’s strengths are its flexibility and adaptability. It can be adjusted to almost any conditions and processes within the organization. That is what ensures its current popularity and the large number of systems in different areas created on its basis. One of the AGILE’s principles is “Reaction to changes is more important than following a plan.” AGILE covers new, innovative open end products. The proportion of uncertainty when developing such projects is high, while the product information is revealed as the project progresses. Such conditions make “waterfall” implementation impossible since there is no planning information. The second strength of the approach is the ability to “make mistakes” and correct them quickly without a significant impact on the status of the project as a whole.

AGILE’s weakness is a necessity to create individual management system by each team, guided by the AGILE principles. This is a complex and long process that will require changes within the entire organization, including procedures and basic values. This is a thorny path and not all organizations can do it. It requires changes in knowledge and perseverance, as well as serious administrative resources and expenses. Besides, there is a floating estimate of deadlines and budgets, uncertainty in the planning of goals and objectives, insufficient documentation and, as a consequence, increasing the likelihood of divergence of tasks and actual implementation, complexity of a project retrospective analysis.

SCRUM project management methods

SCRUM project management is a classical method within AGILE framework describing all planning, control and analysis at all stages. The methodology for implementing AGILE development involves an interactive approach. Scrum sessions (30-day sprints) are used to prioritize tasks. To simplify the job, the project manager’s responsibilities are transferred to the scrum master. Independent solution of specific tasks require small teams. The achieved results are assessed during the meetings with the scram master, followed by the determination of priority for outstanding tasks. The main features of this technique are:

• Meetings and sprint analysis;

• Small team;

• Restriction on certain periods of time (sprint) to run WIPs;

• Work in Process WIPs.

Following Agile principles, Scrum splits a project into parts to be used immediately by the Customer to obtain values, called “W” — product backlog. Then the product owner, i.e. the customer’s representative in the team identifies the priorities of these parts. The most important “pieces” are selected first for sprint performance — this is how 2—4 weeks Scrum iterations are called. At the end of the sprint, the customer is presented with a working product increment — the most important usable “pieces”. It can be a partially functioning site or application. After that, the project team proceeds to the next sprint. The duration of the sprint is fixed, but the team chooses it independently at the beginning of the project, based on the project and its own performance.

To ensure that the project meets the customer’s requirements, which tend to change over time, the incompleted content of the project and amendments are reassessed before each sprint starts. This process involves everyone including the project team, the project team leader (Scrum Master) and the product owner. Everyone is responsible for this process. Scrum Master is supposed to help project participants better understand and accept the values, principles and norms of Scrum practice. He is the leader and intermediary between the outside world and the team. His has to ensure that no one interferes with the team to work independently and comfortably on assignment. The team is responsible for ensuring that all the necessary tasks are done and the deliveries are completed at the end of the sprint. The main structure of Scrum processes is based on 5 main meetings:

• Backlog;

• Sprint planning,

• Daily meetings;

• Sprint review;

• Sprint retrospectives.

Backlog Refinement Meeting (“Backlog Grooming”) is a meeting similar to the planning phase in classic project management, and held on the first day of each Sprint. It reviews what has been done within the whole project, what remains to be done and what decision is made to do next. The product owner determines which tasks are of the highest priority at this stage. This process determines the Sprint effectiveness, because this is what the value the customer will receive at the end of the sprint depends on.

Sprint planning: Once the priorities have been determined by the product owner, the team jointly decides what exactly they will do during the upcoming iteration, how to achieve the goal set at the previous meeting. At this stage, teams may apply different planning and evaluation tools, as long as they do not contradict Scrum principles and logic. Sprint planning is carried out at the very beginning of the iteration, after the Product Ordering Meeting.

In a perfect world, Daily meetings are held every sprint day, at the same time. Team members spend 15 minutes to share information about the status of the tasks and the entire project. These meetings are not intended for discussing problems or decision-making. If some questions arise or conflicts occur after the briefing, the Scrum Master and the participants involved discuss them separately. The meetings are needed to share information and keep all team members up to date with the state of the project.

Sprint review is a stage to examine and adapt the product being created. The team presents the results of the activity to all interested parties. Its main task is to ensure that the product of the stage meets the participants’ expectations and is consistent with the project objectives.

Sprint Retrospective is carried out upon the sprint review and before planning the next sprint. The team finds out how clearly and smoothly the stage was implemented. The challenges occurring in operations, methodology and interaction are studied. This stage allows the team to conduct a reflection and to implement the next Sprint more effectively.

SCRUM strength is that it was developed for projects in which “quick wins” are combined with tolerance to changes. This framework is suitable for situations when not all team members have sufficient experience in the field in which the project is being implemented — constant communication between team members compensates the lack of experience or qualifications of some employees due to information and colleagues’ assistance. In my opinion, the main Scrum’s benefit is that one is allowed to “make quick mistakes.” Instead of preparing an expensive and long release, Scrum deliveries every two weeks are quite small. But they are easy to track and, if something goes wrong, fix it quickly.

SCRUM weakness is that it is very demanding for the project team. It should be small (5–9 people) and cross functional, which means that team members should have more than one competency required for the project implementation. For example, a software developer must be a tester and business analyst at the same time. This is done to keep all the team “busy” at different stages of the project, and so employees would help and replace each other. In addition, team members must be “team players”, be able to take responsibility and self-organize.

To hire such a mature team is very difficult! Scrum is not suitable for all teams and organizations because the process proposed may not be suitable for the development of a specific product — for example, an industrial machine or a building.

KANBAN Project Management Methods

KANBAN is also a flexible, iterative-incremental approach to project management based on Agile ideas. It is the opposite of the “SCRUM” method. The main features of the technique are:

• Each project participant assumes a limited number of assignments independently, without the manager’s direction;

• The assignment is registered in Sticker;

• The number of “unfinished” work (WIPs) is limited for each stage;

• A new assignment is taken only upon completion or “extension” of the current one (LEAN);

• More attention paid to management of change, visualization of gaps, incomplete work, etc.

• Limitations on WIPs number and their status.

LEAN looks a bit abstract, but being combined with KANBAN, it is much easier to use to build your own project management system. KANBAN is very similar to the industrial production flowchart. A piece of metal entering the process in the very beginning becomes the finished part at the very end. The increment of the product in KANBAN is transferred from stage to stage, resulting in the ready item for delivery. The main principle is to keep in store only stuff required by the customer. Therefore, KANBAN allows leaving an incomplete assignment at one of the stages, if its priority has changed and there are other urgent tasks to do — all this is OK for KANBAN.

KANBAN is much less strict than SCRUM since it does not restrict the time of sprints, or has any roles, except for the product owner. KANBAN even allows a team member to carry out several assignments simultaneously, while SCRUM does not. In addition, meetings on the project status are not regulated — one can do it in a convenient schedule, not to do it at all.

Working with KANBAN requires identification of workflow stages, which are presented as columns where assignments are indicated by stickers. The stickers are transferred from stage to stage, as parts are transferred from machine to machine within the factory. The completion level on each stage increases. The output is a product element ready for supply to the customer. A board with columns and stickers can be physical or electronic since KANBAN does not restrict its users. KANBAN system can be as flexible as you want it to be as KANBAN is a visualization of AGILE idea of in many ways.

KANBAN has four pillars to support the whole system:

• Stickers: Each assignment has an individual sticker, containing all required information on the assignment. Therefore, all required information is available at all time.

• Limited number of assignment per stage: The number of stickers per stage is strictly regulated. Thanks to this, a “jam” in the workflow is clearly visible and promptly eliminated.

• Continuous flow: Tasks from the backlog get into the flow in order of priority. Thus, the work never stops.

• Continuous Improvement (kaizen): The concept of continuous improvement was first implemented in Japan at the end of the 20th century. Its essence is the constant analysis of the production process and the search for ways to increase productivity.

Strengths — Like SCRUM, KANBAN is well suited for a well-knitted team with good communication. But unlike SCRUM, KANBAN does not have a clear timeframe, which is more appropriate for motivated and experienced teams. If adjustment and management are proper, KANBAN can be of great benefit to the project team. Exact calculation of the load on the team, the correct placement of restrictions and concentration on continuous improvement — all this allows KANBAN to save resources, stay within the schedule, and budget. And all above-mentioned is spiced up with flexibility.

Weaknesses — one can often hear that KANBAN, unlike SCRUM, suits nearly any team. But this is a false statement. KANBAN is best suited for teams whose members have overlapping skills. So, they can help each other overcome difficulties in solving problems. Otherwise, Kanban will not be as effective as it could be. As mentioned before, KANBAN is better suited in cases with no strict deadlines. The project with strict deadlines is better managed by classical approach or SCRUM.

Hybrid Project Management Methodology

Even though many teams prefer either a waterfall methodology or AGILE design, the benefits of both approaches have led to the emergence of a hybrid methodology where the stages of planning and definition of are carried out according to the waterfall methodology, and the design, development, implementation, and evaluation phases correspond to a flexible approach. This methodology is an attempt to apply the strengths of each main approach, as well as reduce the negative impact of weaknesses. The hybrid methodology can be well-applicable to IT since the project has well-defined goals at the managerial level, is well documented, and provides the ability to monitor the project status to report to the leadership. During implementation, the project assignments are well detailed and understandable to the developers due to the high communication level between business representatives and executors. The opportunity of on-job learning, making mistakes and improving the product to the current business requirements is equally good for developers and businesses. Of course, everything has to be paid for. This approach imposes requirements on both the technical level of employees training and their personal qualities.

From my own experience of project management in the IT department, this approach should not be implemented at the very beginning. However, as the IT department and business work together on several projects, this method will be a logical continuation and the most effective and productive one.

Other methods and approaches to project management

Rapid Application Development (RAD)

Rapid Application Development (RAD) is a specific project methodology, most often used in software development projects whose main purpose is to create an application quickly and efficiently.

The essence of this methodology is an approach to creating software development tools, emphasizing the speed and convenience of programming, creating a workflow that allows a programmer to create computer programs as quickly as possible. Practical definition: RAD is the life cycle of a design process designed to achieve higher development speed and software quality than the traditional design approach allows. This project management methodology identifies four project stages:

• Requirements planning;

• User design;

• Rapid construction;

• Cutover.

The main benefits of using various RAD approaches:

• Application of an iterative approach to the solutions development. The iterative approach implies carrying out work simultaneously with the continuous analysis of the results and the adjustment of the previous stages of work, i.e. feedback. When using this approach the project has a recurring cycle of Planning-Implementation-Verification-Evaluation. Iterative approach enables RAD’s prompt response to changing business requirements.

• An incremental approach implies the sequential development of a service “from piece to piece”. At the same time, each “piece” can support one of the business functions for which the service is developed. The incremental approach allows business the use some significant part of the service before it is fully developed. The additional benefits are: the product enters the market faster, there are more opportunities to develop a user-friendly interface, and it has greater adaptability to changing business requirements and simplicity of development and changes in the solution functionality. The methodology of rapid application development, on the one hand, helps improve project performance indicators and the quality of risk management. But on the other hand, this metrology is not suitable for large-scale IT projects, as it can lead to poor code quality and requires constant customer’s involvement in the execution of the entire project. RAD is a more modern and flexible design approach.

The deficiencies are a weak document base that can lead to misunderstandings, errors in the formation and development, the complexity of monitoring and auditing the development process. When designing services, incremental and iterative approaches can be combined. Once the entire service requirements are defined, its individual parts can be incrementally developed.

Extreme Programming XP

This project management methodology provides capabilities of short development cycles, frequent releases and open interaction with stakeholders. The teams focus on collaboration, efficiency, and productivity, writing the simplest possible codes to achieve the desired quality, avoiding exhaustion and poor quality results.

Event Chain Methodology (ECM)

This project management methodology helps identify and predict potential risks. Analyzing a project using the Monte Carlo method and the Event Chain Diagram helps determine the likelihood of some risks and their possible impact on the entire project. Visualizing the links between external events and project work helps create a plan which is as real as possible.

Adaptive Project Framework (APF)

Using the Adaptive Project Framework enables improving the project at each stage, based on the previous experience. By defining the project objectives and constantly monitoring the project work, the manager can ensure the success of the highest possible business value and create business value for the potential consumer.

Benefit Realization (BF)

The objective of Benefit Realization method is the benefit from the project implementation. Success is defined as the achievement of the desired / expected benefit. If customers want to increase sales of customer relationship management (CRM) software, the project will not be terminated / implemented until sales get increased by 15% — even if CRM is installed and set up duly and within the estimated budget.

Principles-based, Sustainable Project Management (PRISM) methodology

PRISM combines project planning with environmental sustainability measures. If you want to go in the green direction, PRISM has been designed especially for you! Decreasing energy consumption and distribution costs (cost sharing) are enhanced with reducing your environmental impact.

In addition to above-mentioned, there are other project management methodologies:

• Feature Driven Development (FDD),

• Dynamic Systems Development (DSDM),

• Rational Unified Process (RUP),

• Six Sigma and lean production (LEAN). Project management based on the principles of “quality control” will be discussed in detail in the next chapter.

PRINCE2 Methodology

Projects IN Controlled Environments (PRINCE2) is a structured project management project management methodology. It is one of the most popular project management methodologies, widely used by the UK business and government. PRINCE2 is Process-Based Project Management (PBPM) that focuses on top-level processes (management, organization, control), and not on lower-level tasks (work decomposition, schedule development).

The PRINCE2 methodology is based on seven principles, seven themes and seven processes. The principles are the core element of the methodology: if at least one of them is not implemented, the project is not carried out via PRINCE2.

The 7 Principles

•Continued Business Justification identifies whether the economic benefit of the project remains unchanged throughout the project’s life cycle.

•Learn from Experience implies that project teams should take lessons from previous projects into account.

•Define Roles and Responsibilities implies that project team must have a clear organizational structure and involve the right people to solve the tasks.

•Manage by Stages is required to get projects planned, monitored and controlled at each stage.

•Manage by Exception implies that the permissible deviation boundaries within the project should be clearly defined in order to establish the lines of responsibility.

•Focus on Products requires focusing on determination and achieving the project outcomes.

•Tailor to the Environment implies that project management processes and tools should be tailored to the requirements of the project environment, as well as to the scope of work, its complexity, importance, qualification requirements and risk level.

PRINCE2 ensures that every project has a business case and contributes value creation. Planning begins with a clear definition of the needs requested by the consumer, the real benefits and accurate cost estimates.

The 7 Themes

•Business Case: what value will the project bring to business?

•Organization: how to distribute roles and responsibilities among project team members in order to manage the project effectively?

•Quality: what are the requirements and criteria for quality and how to provide them?

•Plans: the steps required to develop the plan, and the PRINCE2 tools to use.

•Risk: how will the project management solve the problem of uncertain events in the project plan and in the external environment?

•Change: how will the project management evaluate and respond to the impact of unforeseen tasks and changes?

•Progress: feasibility of the project, the implementation of plans and further development of the project.

The 7 Processes

Finally, PRINCE2 involves the following seven project management processes:

• Starting Up a Project (SU)

• Directing a Project (DP)

• Initiating a Project (IP)

• Controlling a Stage (CS)

• Managing Product Delivery (MP)

• Managing Stage Boundaries (SB)

• Closing a Project (CP).

PRINCE2 allows standardizing project management procedures, improving coordination of activities, and helps understand how to plan a project and monitor its implementation, what should be done if a project plan is not executed. However, PRINCE2 methodology is not the best choice for small-scale projects or for projects with a greater of likelihood of changes in the scope of work and requirements for them.

PRINCE2 strengths are:

• Adaptability to the organizational features;

• Having a clear description of roles and responsibilities;

• Focus on project products;

• Certain management levels;

• Focus on economic feasibility;

• The sequence of project work;

• Focus on experience fixing and continuous improvement.

PRINCE2 weaknesses are lack or absence of industry practices and specific work tools.

PROJECT MANAGEMENT INSTITUTE (PMI)

General provisions

This methodology represents Process-Based Project Management (PBPM) and is based on the methodology of the traditional, classical approach to project management. The most obvious way to make a project more manageable is to break its execution into consecutive stages. Traditional project management is based on this linear structure. All processes in the PMBooK manual are divided into the following groups (phases):

Initiating

At this stage, meetings and brainstorming sessions are often held to determine what the project product should be. In some ways, the most important part of the project is the beginning. This stage gives clear understanding whether the project is well developed and can be terminated within the deadlines set by the top management and within the budget, or it has no prospects and is doomed to failure from the very beginning. This part of the project is not a place for rash promises to win. It is rather a time for a rational and creative approach to formulate initial project requirements in order to avoid dead ends. One should remember that once the project goal is set, leadership would expect you to achieve it. Initiating consists of processes that facilitate the formal authorization of a new project start.

• Develop Project Charter

• Identity Stakeholders

Planning

Defines and clarifies goals and action plans required to achieve the objectives and content of the project. Planning is the definition of clear and precise tasks, and as a result of assignments that serve to achieve the ultimate goal. The goal may be a solution to a problem or the attainment of a state or condition different from the existing one. At this stage, the team decides how they will achieve the goal set at the previous stage. At this stage, the team clarifies and details the goals and project results, as well as the scope of work needed. This information is used to make a calendar plan and estimate the budget, assess the risks and identify the stakeholders. Project planning may require a significant investment of time, effort and resources, depending on its size. As practice shows that efforts and resources can be wasted if you do not plan properly for a specific project before deciding whether to implement it or not.

Project organization is a primary project management task. A project owner, a person or group authorizes to make decisions, should be defined, a project manager should be appointed and a project team should be formed, project managing and interacting procedure should be determined, and the relevant powers to the project manager and project team should be highlighted. Project management beyond the functional boundaries of the organization is one of the project manager’s tasks. He/she has to communicate, generate ideas, negotiate, solve problems and resolve conflicts outside the functional and sometimes geographical boundaries of the organization. Setting a task, justifying the need for a project and describing its capabilities allow formulating the goal of the project. Such a formulation can be very brief, but it should be precise. Setting project objectives is important for two reasons:

• The task clearly defines what needs to be done to achieve the goals;

• A task is an event with determinable deadline.

The “SMART” method helps formulate the project goals and objectives as:

• Specific — be accurate when setting goals;

• Measurable — Set measurable status indicators;

• Assignable — be able to assign a task to someone;

• Realistic — Determine whether the project can actually be terminated duly and within allocated resources;

• Time related — determine the timeframe, i.e. the duration of project implementation.

To achieve this goal, one should perform several basic project tasks. These tasks are private goals and the main project components (sometimes the term “milestone” is used). Individual goals are not actual assignments within the project, but are checkpoints setting the direction of work. They are more precisely formulated than the main goal and action oriented. To achieve the main goal requires realizing all private goals. The allocation of resources for the project implies that money is not the only resource required. The main resources are:

• Financial resources (direct funds required for project implementation and project management);

• Human resources (who, when, how and how long is involved in the project);

• Material resources (available, required, and so on);

• Administrative resources (authorities, organization).

Besides, this list of required resources may include changes in the company’s organizational structure, office space (for large projects), and so on. The practice shows that two most likely scenarios for resource allocation can be identified as follows:

• The project manager determines the necessary resources based on a preliminary plan, which provides an initial estimate of the amount of resources required for the project. The project manager will be able to formulate resource requirements and discuss them with the authorized manager. This scenario is the most preferable one.

• Required resources are assigned without involving the project manager. The project manager usually may not have a choice, regardless of whether sufficient resources are allocated to the project, or not. One should not be misled by the leadership and agree to the level of support, which is clearly insufficient for the project implementation. Caution and common sense should be decisive at this early stage.

The document containing the project review is compiled, analyzed by experts, and then submitted to the organization’s leadership. The next important aspect of project management is the process of splitting a project into parts, resulted in a work breakdown. A work breakdown is a hierarchical representation of a project. It helps the project manager determine the tasks to be done in order to start and finish the project. At this stage, the manager has a goal and a number of tasks that must be expressed through the tasks and work to be performed. A well-defined assignment has the following features:

• Its status and termination date is easy to determine, it has a clearly defined beginning and an end;

• It is clear, since it might have been carried out before. The time and associated costs required for its implementation can be easily estimated using the experience gained during implementation of similar tasks in the past;

• It includes controllable jobs that do not depend on activities comprising other tasks;

• It is typically one continuous work sequence.

The time to complete each task within the project should be estimated. The time required to complete the task is a random value. Therefore, if this task is recurrent, the time will change for many times. This will be fair even for regular tasks. This variation is caused by the following factors:

• The qualifications level of employees involved;

• Using various equipment;

• Availability of materials;

• Force majeure (diseases, natural disasters, accidents, rotation, etc.)

Such events may occur, but it is impossible to predict them when implementing a specific project or a task. However, they should be taken into consideration. To do this, one can use the critical path evaluation method.The cost of each assignment should be also estimated. There are four main cost categories (although organization’s chart of accounts may be used) to determine for each assignment:

• Work force;

• Materials;

• Other direct costs (business trips, telephone, contractual services);

• Indirect costs (overhead).

The next step is to determine the sequence of assignments within the project. The assignments of simple projects may be carried out one by one. Another way is to analyze all the assignments and determine which ones are to be completed before starting the others. Such an analysis reveals the order in which several assignments can be carries out simultaneously. The critical path method (MCP) determines the sequence of simultaneous assignments that allows completing a project in a timely manner. Identifying critical assignments, determining the critical path and constructing a priority diagram is to provide graphical presentation of the project. This requires mastering a few simple charting rules. An assignment is the main ordered “unit of analysis”. Tasks are represented on the diagram as rectangles, called “assignment nodes”. The symbols depicted in the rectangle describe the temporary assignment properties. Some of them describe the assignment characteristics (for example, the assignment number), while others are assignment associated estimates (ES, EF, LS, LF). The project time is the longest time path in the diagram. The longest sequence of assignments is called the critical path. As long as the assignments within the critical path are completed duly, the project is within the schedule. The four calculated parameters (ES, LS, EF, and LF) for each assignment node are to be determined. The following calculated values will be used to determine the project time and the critical path:

Early start (ES) is the earliest point in time when all the previous assignments have been completed and this assignment can be started. The ES for the first assignment is time period 0.

Early finish (EF) is the ES time plus the estimated time to complete the assignment. The ES time for an assignment preceded by one task is the EF time for this previous task. The ES time for assignments that are preceded by two or more assignments is the longest EF time for these previous assignments.

Late start (LS) and Late Finish (LF) are the latest points in time when the assignment can be started (LS) or finished (LF) without increasing the time to terminate the entire project.

To estimate these points, one should move the Backward Pass. First, the LF time for the last assignment in the diagram is taken as the EF time of the assignment considered. The LS time for a given assignment is equal to its LF time minus the estimated time to complete this assignment. The LF time for all preceding assignments is the shortest LS time for all assignments for which the assignment considered is preceding. It is necessary to calculate one more value, called the time reserve for the assignment.

Time reserve is an allowable value of delay in the start or finish of the assignment, which does not cause a delay when carrying out the entire project. The time reserve is a mathematical difference LS — ES (or LF — EF). The definition of a critical path is a sequence of assignments having a zero reserve.

Terms of reference is a transition from the planning (definition, drawing up a plan) to the implementation (organization, control, termination). As shown later, the terms of reference is the foundation for internal consistency of the project providing the basis for all administrative decisions. Let’s consider the terms of reference, paying focusing on its parts and their use as controls. The terms of reference of the project is to receive:

• A description of the challenge, the general approach to solve it and the expected benefits resulting from it;

• Full description of the project assignment, time and resources required;

• A detailed description is required for the administration to decide whether to proceed to the stages of the project;

• A dynamic tool for the project manager and the project team to be used for decision making throughout the project;

• Reference documentation for administrative control;

• A means to familiarize new members of the project team with the project and prepare for its implementation;

• A report for representatives of your organization who are not involved in the project directly, but should be aware of it.

An assignment is an obvious key document in the project. The terms of reference should be understandably written and used by the leadership, the project managers, the members of the project team, and other managers, as well as specialists who need this information. The terms of reference consists of:

• Project name;

• Project objectives;

• Project Manager;

• Project owner or stakeholders;

• Project team.

• Assignments consist of three subsections: the number, a short but meaningful title, and a description. It should contain specific statement activities to be carried out.

• Estimated start and termination dates;

• Project implementation schedule;

• Project estimate summarized at the assignment level;

• Metrics and criteria for achieving goals;

• Additional terms.

All projects involving financial aspects of profit may require a thorough assessment of the project impact on income and expenses, before the project is approved.

Schedule and progress is a chart indicating the start and finish dates and the planned duration for each work package. This schedule and progress is usually depicted as a Gantt chart and network graphs specifying the logical sequence of the execution of work packages. The planning process group includes the following processes:

• Developing a project management plan;

• Content management plan;

• Collecting requirements;

• Definition of content;

• Creating a hierarchical operational structure;

• Developing a schedule management plan;

• Definition of operations;

• Determining the sequence of operations;

• Evaluation of operational resource;

• Estimation of the operational duration;

• Scheduling;

• Developing a cost management plan;

• Estimating;

• Budgeting;

• Quality planning;

• Development of a human resources management plan;

• Communication planning;

• Risk management planning;

• Risk identification;

• Qualitative risk analysis;

• Quantitative risk analysis;

• Risk response planning;

• Procurement planning;

• Development of a stakeholder management plan.

Executing

This phase deals with the main project activities, i.e. writing the code, erecting the building etc. Following the developed plans leads to the previously defined content of the project, and the selected metrics are controlled. In the second part of this phase, the product is tested, it is checked for compliance with the customers and stakeholders’ requirements. During testing, the product deficiencies are identified and fixed.

This phase includes the allocation of responsibilities to carry out the assignments. Creating an effective group is both: an art and a science. To create an effective project team, one should consider not only the technical qualifications of the project manager and the members of the project team, but also their critical roles and interpersonal relationship. The selection of a project manager and team members will not be perfect — there is always a risk in any HR decision. The main goal when choosing a project manager is to appoint an experienced and competent person who is able to get the final result duly and meet the project requirements with the resources available. From this point of view, all the basic qualities of an effective project manager can be attributed to one of the following five categories:

• Education and experience;

• Leadership and strategic thinking;

• Technical competence;

• Ability to work with people;

• Proven managerial skills.

The choice of project team depends on the following factors:

• The objectives and goals of the project;

• The nature of the activities to be performed;

• the qualifications required for hiring, assigning, obtaining authority, control, communication and performing the required activities at each stage of the project;

• Availability of appropriate personnel in the organization where the project will be carried out.

It is important for the project manager and the members of the project team to know that the newly formed teams go through go through the five stages of team development which are:

• Forming stage takes place when the team first meets each other, breaks ice build relations.

• Storming stage is natural and not avoidable. The members of the team test each other, establish a sense of boundaries and trust.

• Norming stage implies developing the norms of behavior and acceptable unwritten rules obeyed by all members. Team members know what to expect from each other in the process.

• Performing stage takes place when the project team is ready to implement the project.

• Adjourning is the last stage when project is ending and the team members are moving off into different directions.

Reintegration of the project member is the process of introduction / withdrawal of the project member to / from the project. The project manager prepares the re-integration of employees (conducts personal interviews with staff and their line management) upon termination of the project. Tasks of the project manager are:

• Monitoring the development of the team members;

• Training project participants;

• Provision of project instructions, documentation;

• Reintegration of new or returned team members;

• Returning the project participants to their units or to the line manager upon the project termination.

The project participants should be informed about their reintegration. Staff reintegration plan is a consistent withdrawal of personnel from the project. The goal of HR management is to create and maintain a highly efficient project team. Communication skills, group cohesion, ability to resolve conflicts and conducting effective meetings can accelerate the transition to executing. The project manager should always remain these stages under review and strive to reach executing as soon as possible. The performing group includes the following processes:

• Leadership and management of project;

• Quality assurance;

• Recruitment of project team;

• Development of the project team;

• Project team management;

• Communication management;

• Procurement;

• Stakeholder management.

Monitoring & Controlling

Regularly evaluates project progress and monitors to detect deviations from the project management plan, and, if required, take corrective actions to achieve the objectives of the project.

Monitoring also involves defining and creating a reporting system to provide information on the project status at specified points in its life cycle. The reports are supposed to not only reflect the chronology of events, but also provide early warning of cases and situations indicating deviations from the plan.

Monitoring is an integral part of project management and transparently present at all stages. The main objective of this phase is to monitor the status of selected metrics for compliance with the customer and stakeholders’ requirements. Identified product deficiencies are addressed during the project implementation phase.

As soon as the situations requiring changes to the work plan has been detected, the project manager should use the mechanisms for making changes that are part of the project management process.

Arranging effective project meetings will take more time than any other task. The skills of conducting meetings and ensuring their attendance are to be mastered. First, a question arises: whether a meeting is needed. If yes, what for? If not, how to get staff aware? Is it possible to solve this problem at one meeting, or via a letter, written reference, and phone call? If a meeting is required, the following recommendations should be followed:

Preparation

• Set several achievable goals for the meeting. Formulating of these goals should be concise and precise.

• Select key participants for the meeting; exclude employees whose presence is not required.

• Choose a meeting time and venue that meets the participants’ requirements.

• Prepare an agenda and bring it to the participants’ attention before the meeting.

• Include agenda items to be considered, and expected or required outcomes.

Conducting:

• Start duly.

• Instruct someone to take meeting minutes.

• Review the agenda with each participant before the meeting ends.

• Introduce participants to each other.

• Follow the agenda. Do not deviate from the topic.

• Thank all speakers at the meeting.

• Finish the meeting with the main decisions made, the main outcomes, and provide detailed information about the next meeting.

Regardless the completeness and accuracy of the plan, there will be events having hard-to-control-consequences. Such events will occur at the most inappropriate time (as per Murphy’s Law) and the success of the whole project will depend on them. The project manager must track the project status, in particular the state of the managerial triangle:

• Scope of work, quality — whether everything is developed in accordance with the work plan, or there is anything missing?

• Deadlines — whether the project’s deadlines are met.

• Money — whether the planned budget, outflow, and capital inflow are observed?

The algorithm of project control is:

• Set targets;

• Get project status and current indicators;

• Compare plan with fact;

• Set the deviation, trends and influence on the project objectives;

• Modify the plan and/or set measures to mitigate interferences leading to a delay.

Identification of controls to focus on one or more main project components is a condition, cost, and implementation terms. These means are used for three reasons:

• Tracking project status;

• Detection of deviation;

• Taking corrective actions.

There are two types of control:

• Operational Control monitors changes in the potential of the company, which allows prompt response in order to maximize the benefits for the company. Planning includes short-term and medium-term planning, i.e. 1—3 years. Management is carried out by comparing the values of fact to plan.

• Strategic Control analyzes the future chances of the company, ways of development, and possible risks. These are the tools to move forward. Planning includes long-term development, up to 10 years.

Any project may have typical deviations from the initial plan. In this case, the deviations can be:

•Positive — proceeding ahead of schedule or implementing a project at less cost are deviations from the plan that sounds delightful for the project manager. Positive deviations enable revising the plan and executing the project ahead of schedule or at a lower cost.

•Negative — delay or overruns. This situation may arise because the project manager / the project team is unable to control the process. Regardless of the reason, the project manager must find the ways to remedy the situation. In addition to identifying the cause of the deviation from the plan and its correction, the manager must find the ways to transfer resources from non-critical tasks to those resulted in negative deviation from the plan. The goal is to align the project with the plan. In any case, these deviations should be recorded in the periodic project status reports.

Getting attracted to controls and related reports is very easy. The more controls are taken into service, the less likely the project will fail, and vice versa, the weaker the control, the higher the risk of detecting serious problems when it is too late to solve them. The solution is a compromise in the control system. The control should not be too frequent. People need to be given time to work, not to collect regular statistics. The monitoring and management group includes the following:

• Monitoring and management of project activities;

• Change management and change control;

• Content verification;

• Content control & management;

• Schedule control & management;

• Cost control & management;

• Quality control;

• Communications monitoring & control;

• Risk monitoring & control;

• Procurement / contract control;

• Stakeholder involvement monitoring.

Closing

Once the project is implemented, it approaches its final stage, i.e. termination. The project is terminated in terms of achieving the project goals and obtaining the expected outcomes. The project owners or the management of the organization may decide to terminate the project ahead of schedule, or change the project objectives to terminate it. The basis for the project termination are:

• Formal contract closure with suppliers, manufacturers and customers;

• Official termination of assignments carried out by project team;

• Acceptance of project and end products by the customer;

• Ensuring that all outcomes are received duly, within the budget and in accordance with project requirements;

• Proper documenting the project and providing basic information to facilitate the staff interaction or making changes that may be required in the future;

• Issue and ratification of the final report or project status report, which shows that the expected end outcomes have been achieved;

• Termination of all work on the project, within the organization and beyond.

There are three types of project termination:

•Termination by extinction means that the planned project activities have been either successfully terminated or unsuccessful, and the decision was made to terminate it.

•Termination by addition means that the project has been successful, and its final products have been implemented.

•Termination by integration is the most common way of dealing with successful projects, and the most complex. Equipment, materials and personnel must be returned to the parent organization. Unlike termination by addition, a project cannot be considered as a competitor in the integration of resources.

In any case, the project termination includes the following main stages:

• Acceptance of the final product by the customer,

• Project documentation,

• Auditing after project implementation;

• Issue of final report.

The following checklist may facilitate in determining the project’s readiness for termination without taking into account published or planned dates and deadlines:

• Whether the project is still consistent with the objectives?

• Whether it is practical / helpful?

• Whether the leadership concerned enough in the project to support its implementation?

• Whether the organization has sufficient financial resources to implement the project?

• Whether the support of this project is sufficient for its successful implementation?

• Whether the organization has the required qualifications for the project?

• Whether the project has lost a key figure or support?

• Whether the project team is interested in the success of the project?

• What is the likelihood of achieving the minimum project goals?

• Whether it is still profitable and timely?

The complexity and duration of the project termination is determined by the size, complexity and scale of the project itself. One of the most important questions at the end of the project is reward for success and lessons learnt. The final processes contains are the following:

• Close Project or Phase;

• Close Procurement;

Termination may also consist of:

• Tests of the system developed (test protocol);

• Acceptance procedure, transfer of working papers;

• Personnel certification, lesson learning, experience sharing;

• Financial calculation and analysis of actual expenses;

• Liquidation of jobs and re-integration of staff.

Project Management Body of Knowledge (PMBoK)

Project Management Body of Knowledge describes ten areas of knowledge that a project manager should possess. The standard considers each area of knowledge separately, describes its input and output. Knowledge area processes are represented in PMBoK as discrete elements having well-defined boundaries. However, in practice, these processes are iterative — they can interact with each other and overlap each other. The standard addresses the following areas of project management knowledge:

Project Integration Management

Integration refers to the integration, consolidation, articulation, and various integrative actions aimed at successfully managing the stakeholders’ expectations and meeting certain requirements. Integration describes the distribution of project resources, finding compromises between conflicting goals and alternatives, and defines the integral links between other areas of knowledge.

Project Scope Management

Scope management refers to the processes that allow selecting, filtering, and grouping activities required for the project manager to complete the project successfully. Project scope management is directly related to the definition and control of the content to be included / not included in the project. It describes diagrams of the Collection of Requirements, the Definition of Project Scope, the Creation of a Work Breakdown Structure (WBS), a Content Confirmation and a Content Management. When developing WBS, the rule “8/80” (1 day — 2 working weeks) is used. The Work Breakdown Package WB should be developed for 8 — 80 hours. Each Work Package must be assigned to a specific department or employee.

Project Time Management

Project time management or project terms, (since time is a broader concept), refers to the processes to ensure timely project completion. The scheme of these processes includes: Definition of operations, Definition of operations sequence, Assessment of operational resources, Assessment of the duration of operations, Development of the schedule and Management of the schedule.

Project Cost Management

Project cost management refers to the processes of planning and budgeting, as well as cost management, which ensure the project completion within the estimated budget. The process flow chart includes: Cost Estimation, Budget Definitions, and Cost Management.

Estimation is a foundation of planning. Considering the work packages, we estimate time, staff, and costs. Estimation is a certain value based on the experience of working with other projects. To increase the reliability of estimates, once can use the following Cost Estimate methods: Method of analogies, Expert assessment or Method of indicators.

As mechanisms and techniques for estimating the calculation of the project cost Expert opinion, similar project, Parametric, Ballpark Estimate (Rough Order of Magnitude ROM), Top-down, Three-point Estimate or Button-up methods can be used.

The most accurate method is Button-up, but it requires the Work Breakdown Structure.

Project Quality Management

Project Quality Management refers to the processes and various actions by the executing organization, approaches and quality policies, goals, objectives and areas of responsibility. The project must meet its initial needs. The quality management is carried out via quality management system, providing a set of specific rules and procedures, including actions for continuous improvement. The best practice is carrying out these activities throughout the entire project. The quality management diagram includes: Quality Planning, Quality Assurance and Quality Control.

Project Human Resource Management

HR management within the organization includes approaches to the project team management and leadership. A project team means a pool of qualified workers with specific roles and responsibilities are defined for project implementation. During the project implementation the professional and quantitative composition of the project team may change. Proper distribution of project roles and responsibilities between project team members allows all team members to get involved in project planning and decision-making. If project team members are attracted in the early stages, their existing experience may be applicable at the planning stage of the project, and help strengthen the focus of the project team on achieving certain results. The scheme of HR management includes: Developing an HR management plan, recruiting a project team, developing a project team and managing a project team.

Project Communications Management

Communication management is used to ensure the timely formation, preparation, distribution, archiving, transmission, receipt, and use of project information. Being a link between the various stakeholders involved in a particular project, project managers spend most of the time on communicating with team members and other project stakeholders. Proper communication management consists of uniting diverse cultural and organizational peculiarities, consolidating accumulated experience, comparing different views and interests in order to build a basic project management structure. The project communication management diagram includes:

• Identification of project stakeholders;

• Communication planning;

•Spread of information;

• Stakeholder expectations management;

• Performance reports.

The information is distributed through the following channels:

• Project manager — project commission, head of enterprise. Project reports, costs, trend analysis of milestones and costs, causes of deviations.

• Project team — project manager. The team reports on the work done and challenges. The project manager provides the team with information on further actions and decisions that affect their work.

• Users, product consumers — project manager. Information on the project development.

• Project manager — project plan. Plans are constantly monitored, since this is the basis of project controlling.

• Project team — heads of functional units. In the case of a functional organization of the company the owner of the resource must control his/her employees in terms of competence, knowledge, motivation, and project distribution.

Project Risk Management

Project risk management is understood as risk management planning, identifying and analyzing risks, developing risk response methods, controlling, monitoring and managing risks during project implementation. Using project risk management, project managers achieve increasing the likelihood of the occurrence and impact of favorable events on the project and reducing the likelihood of the occurrence and impact of adverse events on the project when executing project. The project risk management diagram includes:

• Risk management planning,

• Identification of risks

• Qualitative risk analysis,

• Quantitative risk analysis,

• Planning to respond to known risks

• Monitoring and risk management.

Project Procurement Management

Project procurement management includes the purchase or acquisition of certain required entities (products, services, results, documents) produced by external organizations in relation to the one in which the project is implemented. The organization carrying out the project, can act as a buyer or seller of these entities. In addition, the project’s procurement management include the contract and change management sub-processes required to develop and maintain contracts or purchase orders. Thanks to the project supply management processes, administering all purchase contracts during the project and managing the contractual obligations assigned to the project team are possible. The project supply management diagram includes:

• Procurement planning,

• Procurement,

• Procurement management,

• Procurement closure.

Project Stakeholder Management

Managing project stakeholder’s expectations is understood as communication between the project team and stakeholders, as well as work aimed at meeting their needs and solving emerging problems that may entail changes in the project. Property building up relationships between all stakeholders on a project allows the project manager to increase the likelihood of success.

PROJECT MANAGEMENT METHODS AND TECHNIQUES

The PMI methodology describes various tools and techniques, the practical application of which allows the project manager to increase the efficiency of project execution, anticipate risks, calculate optimal project routes, assess the situation sensibly and make the right decision from the start, etc. These tools and techniques exist on their own and have long been used in various areas of human activity. The following is a list of basic methods and techniques applicable to specific processes.

Decision Tree Analysis

Decision Tree Analysis is a method describing decision making by considering alternatives and the consequences of their choice. This method is used if predicted scenarios and results of actions are probabilistic. Decision Tree Analysis is displayed as a chart and reflects the probabilities and magnitudes of costs, the benefits of each logical chain of events and future decisions, and uses an analysis of the expected monetary value to determine the relative cost of alternative actions.

When forming a tree, the following four types of graphic symbols are used:

• Squares — decision places.

• Circles — the places where the outcomes appear.

• Dotted lines — possible solutions.

• Triangles or straight lines — possible outcomes.

Expected Monetary Value (EMV) for each alternative should be estimated. It mostly consists of the sums of the winnings estimates to be multiplied by the likelihood of the winnings realization, for all possible options.

SWOT Analysis

Strengths Weakness Opportunities Threats (SWOT) Analysis is a method for evaluating the internal and external factors affecting the development of a company. It will help assess the strengths and weaknesses of your business, find new opportunities and identify possible threats. SWOT analysis divides the influence factors into four categories, identifying company’s strengths, weaknesses, opportunities and threats:

•S-strengths (the sale of goods directly to the buyer, the profit is greater than that of competitors, customer service is the best on the market, etc.);

•W-weaknesses (insufficient partners, ineffective advertising, small target audience);

•O-opportunities (potential customers will find out everything they need about your product from the Internet, purchases are made 24 hours a day, regardless of whether you work or not);

•T-threats (your competitors’ brand is better known in the market, the quality of products offered by competitors is higher).

SWOT analysis is often used in strategic planning. It can start any action of the company, such as the study of new initiatives, new development strategies, and possible changes. Internal factors are strengths and weaknesses relating to internal factors, which can be easily evaluated:

• Financial resources (financing, income opportunities);

• Physical resources (your equipment, buildings, location);

• HR (employees, sometimes volunteers, target audience);

• Access to natural resources, copyrights, patents;

• Current processes (all events taking place in the company, motivational programs, training programs, a system of departmental hierarchy, etc.)

Answer the following questions in order to find the strengths of your business:

• What are the benefits of your business?

• What are you doing better than everyone else is?

• What are your strengths seen by your customers?

• What is your Unique Selling Proposition (USP)?

• How can you increase your profits?

Consider your strengths from your point of view and from your clients’ point of view. Assess your strengths relative to competitors. External factors — the influence of external circumstances on each organization and individual person is very strong. External factors are, as a rule, the circumstances that cannot be controlled by you and your company:

• Market trends (new products, technologies, changes in the needs of the target audience);

• Economic trends (local, national, international financial areas);

•Financing (donations, government influence, taxes, etc.);

• Demographic information (age, gender, race, nationality, cultural values of the target audience);

• Relations with suppliers and partners;

• The political, environmental, economic situation in the country.

Program Evaluation and Review Technique (PERT)

The Program Evaluation Review Technique (PERT) method is often used in project management and production analysis. The PERT method is a tool that calculates the expected duration of the project or an individual process. When managing projects, the PERT method usually used in conjunction with the critical path method Critical Path Method (CPM).

The PERT method and the critical path method are fundamentally different in their application area. The critical path method is used to estimate the completion time of the entire project or groups of interrelated tasks, while the PERT method is used to estimate the duration of individual tasks. The very idea of the method is extremely simple, i.e. in order to estimate the time it takes to complete a task or process, one needs to know the optimistic, pessimistic, and most likely estimate of the duration of this task. The PERT formula is:

O — optimistic estimate of the task duration,

M — the most likely estimate of the duration of the task,

P — pessimistic estimate of the problem duration.

This equation is nothing more than a weighted average, where the most likely estimate of the duration is 4 times greater than the optimistic and pessimistic estimates. This approach prevents too much bias in one direction.

Gantt Chart

A Gantt Chart is a popular type of bar charts (histograms), used to illustrate the plan, schedule of work on a project. It is one of the project planning methods and used in project management applications. Currently, the Gantt chart is the de facto standard in the theory and practice of project management, at least to display the structure of the list of works on the project.

A Gantt chart is a segment placed on a horizontal time scale. Each segment corresponds to a separate project, task or subtask. Projects, tasks and subtasks that make up the plan are placed vertically.

The beginning, end, and length of a segment on the time scale correspond to the beginning, end, and duration of the task.

Earned Value Analysis (EVA)

Earned Value Analysis (EVA) is the calculation of project performance indicators within the scope of the acquired volume. EVA is based on the same principles as cost trend analysis and is usually used in large projects. The basis is taken from the figures: The earned value, planned and actual costs. Let’s consider the following example:

The task 1 must be completed by one performer (P1) within two days (2 x 8 hours = 16 hours), the cost of work of the performer is $ 10.00 per hour (planned expenditure = $ 10.00 x 16 hours = $ 160.00).

In fact, the performer finished work on the third day, having spent additional two hours. The indicators are the fact of time (2 x 8 hours +2 hours = 18 hours), while actual expenses = $ 10.00 x 18 hours = $ 180.00.

The result is:

On the morning of the third day the result of the task 1 = 16 / (16 +2) * 100% = 89% and the cost of the Task 1 = $ 180.00

Conclusion: Common sense tells us that we spend money faster than we get the result.

Main method indicators:

Planned Value (PV) is an amount of planned work within basic prices. In our example, PV is equal to $ 160, since the basic amount of work to be completed by Wednesday is 16 person-hours, and the base price is $ 10 per hour.

Earned Value (EV) is a completed part of the work of the planned amount. It is percentage of completion of work, multiplied by the base task budget. This indicator used to be called BCWP (base cost of work performed). In our example, EV is equal to $ 142, since the percentage of the task carried out is equal to 89%, and its base budget is $ 160.

Actual Cost (AC) is a real cost of work performed. It is measured by the amount of money that is actually available for the work performed. In our example, AC is equal to $ 160, because in fact, the performer spent 16 hours, and every hour costs $ 10.

Budget at Completion (BAC) is fixed at the start of the project as the amount of the approved budget for the entire project. In our case, it is equal to $ 160.

Cost Variance (CV) is a value deviation (formula: CV = EV-AC). $142.00 — $160.00 = — $18.00. Negative value means that the budget has been exceeded, while a positive implies that the budget has been saved. In our case, the budget has been overspent.

Schedule Variance (SV) is a time deviation (formula: SV = EV-PV). $142.00 — $160.00 = — $18.00. Negative value means that estimated deadlines are due, while positive one means that the deadlines have been outpaced. We are behind schedule.

Cost Performance Index (CPI) is a cost performance index (formula: CPI = EV / AC). If the index is greater than 1 the budget is saved, if it is less than 1, the budget has been exceeded. In our case, $142.00 / $160.00 = 0.89. The budget over expenditure is 11%.

Schedule Performance Index (SPI) is a deadline index (formula: SPI = EV / PV). If the index is more than 1 the schedule is overtaken, if it is less than 1, the base schedule is outpaced. In our case: SPI = $142.00/$160.00 = 0,89. The schedule is 11% outpaced.

Estimate at Completion (EAC) represents the expected total cost of the project after the completion of the remaining work (Formula: EAC = BAC / CPI). In our case: $160.00 / 0.89 = $180.00. The current estimated cost of the project task is $ 180.00.

Estimate to Complete (ETC) calculates how much more money is required to complete a project (Formula: ETC = EAC-AC). In our case: ETC = EAC-AC = $180.00 — $160.00 = $20.00 are still required to complete the task.

Variance at Completion (VAC) indicates expectations for cost over expenditure or budget savings (formula: VAC = BAC-EAC). In our case: VAC = BAC-EAC = $160.00 — $180.00 = — $20.00. The budget over expenditure is $20.

Formulas for calculating the project status: EAC = AC + Button-up ETC, EAC = AC + BAC — EV, EAC = BAC / Cumulative CPI, EAC = AC + [(BAC — EV) / Cumulative CPI x Cumulative SPI], EMV = probability x impact, EV = BAC /% of completion, TCPI = (BAC — EV) / (BAC — AC).

Cost trend analysis

Cost trend analysis is a method of monitoring a project and the distribution of its costs. It is to align the budget for milestones, the entire project and the timely control of cost increases. Permanently monitored values are:

• Planned costs — what was originally planned for implementation.

• Actual expenses — what was actually spent on the work done.

• The cost of the work done is what was planned and actually spent on the work done. This includes the cost of work, materials, and external services.

• Space remaining is what is left to do and calculated as the difference between the amount of work planned and what was actually made by a certain time. Space remaining = planned costs — the cost of the work done.

• Additional expenses are the difference between actual and planned costs. Additional expenses = actual expenses — planned expenses.

V-fact is preliminary actual cost and a signal of overspending. V-fact = budget + additional expenses + space remaining.

Milestone trend analysis

Milestone trend analysis is a method of project monitoring, as well as its backlog or proceeding ahead of schedule. The method allows detecting deviations in the early stages and responding appropriately to improve the situation. The method is based on the analysis of current and planned milestones status. Each milestone has an estimated deadline, which is planned at the project planning stage. This time is the starting point of regular reconciliation. Upon the milestones completion those responsible report to the project manager on the work done. The report should answer the following questions:

• What has been done?

• What should be done to complete the milestone?

• Is the work due?

The visual trend analysis is often displayed graphically.

Horizontal: reporting periods, for example, every week.

Vertical: the same scale with milestones marked. The milestones mark at X = 0, corresponds to the planned milestone indicators at the stage of project start.

The bisector indicates the position of the milestones reached.

During the reporting period, the chart is updated and analyzed. The chart indicates new forecast dates for milestones completion. Each milestone has a trend line (curve). When it reaches the bisector, it finishes.

The ideal state is when the line is clear and unchanged along the Y axis.

Vertical deviations (deviation of the predicted period from the originally planned):

Up: due deadline

Down: ahead of schedule.

Project Management Triangle

The Three Constraints are:

• Time required carrying out the project;

• Cost (money, people, budget);

• Scope (goals, tasks, quality).

An example of a good project development — The scope of work is met and even exceeded at lower costs and deadlines.

An equilateral triangle with equal sides indicates the planned values for cost, time, and scope. The picture changes depending on the deviation from the baseline values.

Project results are measured at regular intervals.

Time is measured by the time spent on the project.

Actual expenses measure costs.

Scope is measured as a percentage of the planned and completed work.

Measured values on the reporting date are applied to the axes and generate a new triangle, which is different from the original equilateral triangle. Project Management Triangle is applicable to demonstrate intermediate and general project results.

Other Methods and Techniques

Assumptions Analysis is a method used for the accuracy analysis of the assumptions and the identification of project risks, caused by inaccuracy, incompleteness or contradictory assumptions. Any project and any specific project risk is initiated and executed based on a number of hypotheses, scenarios and assumptions. Assumptions analysis explores the validity of the assumptions applied to the project. This analysis allows identifying project risks arising from inaccuracies, instabilities, inconsistencies or incompleteness of assumptions.

Expected Monetary Value (EMV) Analysis is a statistical method that calculates the average result with future scenarios that might occur. Typically, this method is used as a part of decision tree analysis.

Variance Analysis is an analysis of total variance of content variables, cost, and schedule as variance of individual elements linked to certain factors and affecting the variables of content, cost, and schedule.

Schedule Network Analysis or Network Analysis is a method for determining early and late starts and early and late finishes for incomplete project operations. See also Critical Path Method, Critical Chain Method, analysis of available scenarios and resource leveling.

Trend Analysis is an analytical method using mathematical models to predict future results based on historical data. This method allows determining the variance from the base plan by cost, time or content using data from previous reporting periods and predicting the variance of this parameter at a certain point in the future, if no changes are made to the project.

Reserve Analysis combines analysis methods to identify the essential characteristics and interrelationships of the elements in a project management plan for establishing a reserve for the duration of the schedule, budget, estimated cost or project funds.

Sensitivity Analysis is a method of quantitative risk analysis and modeling used to determine the risks with the greatest likelihood to affect the project. The analysis establishes the impact of uncertainty of each project element within the studied project objective, if the remaining indefinite elements have basic values. Usually these results are presented as a tornado diagram.

Fast tracking is a special method for compressing a project schedule that changes the network logic by overlaying phases that would have been performed sequentially, for example, the design and construction phases, or parallel performance of planned operations.

Resources Leveling is a method of optimizing the load of project resources by arranging the optimal project performance, taking into account task priority, deadlines for implementation and limited resources.

Decomposition is a method of splitting the project content and project delivery results into smaller and easily manageable elements as long as the performance related activities on the project content and ensuring the delivery results are not sufficiently specified to perform, track and monitor these activities.

Precedence Diagramming Method (PDM) is a method for creating network diagrams in which planned operations are represented by rectangles (or nodes). Scheduled operations are graphically related to one or more logical relationships that show the sequence of operations.

Network Diagram Method is a common group of visual graph display. Unlike Gantt chart, the network diagrams graphically display the dependencies between the operations, as well as the duration of each of them and resources assigned. It is then determined which tasks are critical and which ones are not. There are two types of network diagrams, i.e. Critical Path Method (CPM) and Meta Potential Method (MPM).

Critical Path Method (CPM) is a step-by-step (network diagram) method used in the implementation of interdependent tasks. The activities are listed, their decomposition structure, time scale, dependencies, reference points and results are determined. Critical and non-critical activities are distinguished by calculating the greatest (on the critical path) and the smallest (floating) execution time of various tasks. The critical path method is often used in construction and characterized by a clearly defined project path; this path is formed by the longest project activities. The critical path determines the duration of the entire project. By defining and identifying the most important tasks, one can estimate completion dates, dependencies, key milestones, and final results. Any delays in activities within a critical path lead to increasing duration of further activities. If the project duration reduced, the terms of critical activities should also be reduced. Using the critical path method allows you to compare planned and actual indicators (how the situation should develop and what is actually happening) every day. The method consists of four planning stages:

• Goals and limitations (considering the project in several aspects — duration, quality, etc.);

• Duration of activity;

• Network schedule;

• Gantt chart.

Critical Chain Method (CCM) differs from the critical path method by focusing on the use of project resources, rather than project activities. Potential problems with resources, are resolved via buffers to ensure the timely implementation of projects in compliance with all required safety measures. Critical chain method helps avoid delays in the project, determining the critical path of activities, as well as resource reserves (lead-time) for these activities. Since the charts consider the availability of resources, the project may take longer, but the likelihood of failure to meet key events may be reduced. The basis of critical chain method is the formation of the main critical activities of the project and the retention of the terms of activity, as well as the project’s final completion date. Critical activities of the project are logically linked, taking into account resource and administrative constraints. If project resources are not limited, the estimated indicators will be similar to PERT. If the project still has limited resources, it is necessary to:

• determine near-critical work in the schedule, such work very often runs parallel to the main “red” chain, but being reduced, they may easily become critical if they are ignored.

• define a critical project chain using resource links.

Monte Carlo Analysis is a method that recalculates (or iterates) of a project cost or project duration using input values randomly taken from possible values of cost or duration in order to obtain the distribution of value likelihood of the total project cost or project completion dates.

Value Engineering (VE) is a creative approach to optimizing cost at the stages of the project life cycle, reducing time costs, increasing profits, improving quality, expanding the market, solving problems and / or improving the efficiency of resource use.

Earned Value Technique (EVT) (also named as earning rules and crediting method) is a special method for measuring work performance for an element of a hierarchical work structure, a control account or a project.

Bottom-up Estimating is a work element estimating method. Activity is divided into actions. Requirements for each actions are estimated, and these estimates are summarized for this element of activity. The accuracy of the bottom-up estimates is determined by the size and complexity of the actions at the lower levels. Usually lesser activities increase the accuracy of estimates.

Top-down Estimating is a work element estimating method opposite to the bottom-up method.

Rolling Wave Planning is a type of planning for sequential development, in which the activity to be done in the near future is planned in detail with a deep disclosure of work breakdown structure, while far distant activity is planned with a relatively small disclosure of the work breakdown structure, but as work progresses the activities to be done in the coming time periods are clearly planned.

Earned Value Management (EVM) is a methodology for the integration of content, time and resources, as well as an objective measurement of project performance and efficiency achieved. The efficiency of the project implementation is measured by determining the planned cost of the work performed (i.e., the used capacity) and its subsequent comparison to the actual cost of the work performed (i.e. the actual cost).

Risk Breakdown Structure (RBS) is a breakdown presentation of project’s known categorized and subcategorized risks, indicating the different areas and causes of potential risks. The risk breakdown structure is often adjusted to specific types of projects.

Probability and Impact Matrix is a conventional approach adopted to classify risk as high, medium or low by comparing two risk parameters: likelihood and impact on the project objectives.

Responsibility Assignment Matrix (RAM) is a structure aligning the organizational structure of the uses the Work Breakdown Structure and helping designate the persons responsible for each project element.

Milestone Schedule is a summary level schedule displaying the timing of major project related milestones.

Analog Method is an analysis of all available data relating the implementation of previous similar projects in order to estimate the likelihood of loss. This method involves such key action aspects as an attempt to compare with a previous similar project. Information on the planned and actual deadlines is collected. If the terms did not match, the causes are analyzed, countermeasures are developed and the project is planned. The Analog Method is most widely used in risk assessment of frequently repeated projects, for example, in construction.

Expert Judgment refers to a technique in which judgment is made based upon a specific expertise that has been acquired in a specific knowledge area, or product area, a particular discipline, an industry, etc. Judgment is carried out using different methods with a focus on various aspects. The expertise can be carried out by an external group or person with a specific relevant education, skill set or knowledge. There can be several resources of expert including other divisions of executing organization, consultants, project members, including customers, professional and technical organizations and other miscellaneous industry groups.

Indicator Approach uses indicators of completed projects. For example, the interest rate method fully distributes costs in different phases. If the actual costs of the first phase are known, the rest is calculated according to the percentage distribution:

Analysis — 20%

Project — 35%

Implementation — 30%

Verification — 15%.

Poker Estimate implies the following key aspects of action:

• create a work group (developers, analysts, business representatives, and so on);

• Voice task;

• let each participant evaluate the project timeline based on his/her experience and level;

• hear each member’s opinion;

• choose the shortest and longest project term to discuss by the work group;

• correlate opinions during discussion, and make a common decision with the whole work group.

Estimated development time or hours

An important element in IT management within a software development project is to estimate the time required for product development. This issue is relevant in the solution development by both: internal resources and outsourcing. A classic example is shown in the diagram.

All this can lead to such grave consequences as disruption of the project deadline, excess of the project cost (overtime, etc.) or customer’s dissatisfaction with the product quality. To eliminate above-mentioned problems, you can use the following methods and techniques:

• Poker Estimate;

• Comparison with analog;

• Bottom up & Top down;

• Expert review.

After analyzing one of the methods, add the following to the project timeline:

• 15—20% percent of time to cover risks and unforeseen cases;

• consider 80% percent of the developer’s work time (instead of formal 100%), as the main working unit involved in the project when making calculations.

Project documentation

Project documentation is a set of documents describing a project and regulating activities within a project.

Projects are valid due to prompt information exchange between the project team and external stakeholders/suppliers. Each project participant is responsible for providing or not providing information.

The rule is “Information is a something ones lend and something the others borrow.”

The progress of the design work must be constantly documented, being internal information of the project. Information can be divided into two parts:

• Internal

• External.

The project information can be accessible by almost all project team, and only part of the information is provided to external recipients. The internal information can be:

• Plans;

• Statuses;

• Minutes of meetings;

• Documentation on defects, tests;

• Contracts with suppliers;

• Risk analysis.

The information to be provided outside is:

• Competency matrix;

• Journal of the division of labor;

• Project statuses;

• Milestone schedule;

• Final reports.

The project is documented throughout the life cycle. If regulatory rules for document control is missing and project documents accumulate, the project’s information environment may hamper the project implementation. Different types of projects have their own set or package of project documents. For example, the project documentation for the house construction will include a draft design and a feasibility study of the construction project, a working draft, initial permit documentation, etc. While the project documentation for the software implementation should contain a description of the automated functions, the problem statement, the classification and coding systems, and other documents. The list of project management documents package:

Charter of the project

• Description of project content

• Register of project stakeholders

Project Management Plan

Request for project amendments

Approval sheet of participation in the project

Risk Management Statement.

• Risk Management Plan

• Risk Register

Minutes of the meeting

Reports

• Project Performance Report

• Project Status Report

• Project Completion Report.

Keeping records is one of the most important elements of any project. No one likes to write documents… except those who can. Use templates (text, charts, tables and presentations) and deliverables. But before one start to create or fill in templates, the following important questions should be answered:

• What artifacts and documents are needed for your project?

• To what extent do they have to be worked out?

• How compatible is cost of time spent for creating a document to the value of the document?

Generating a bunch of unnecessary documents is an expensive, long and silly process. This is beneficial if the project is estimated by the thickness of the reporting documents. But nobody reads thick documents. They are stored on the most remote shelf and forgotten forever.

Therefore, one need to select the documents required to achieve the project objectives, i.e. results. They should be worked out in the extent necessary to achieve the project objectives. It is logical. But how can one define this line?

I recommend the method of gradual improvement or upon demand, which is the following:

• First select the minimum set of documents.

• Use common sense when filling them out. If something seems redundant, discard it.

• Assess whether you can achieve the desired results having this information.

• If not, include missing sections or documents.

• Refill them and reassess.

• Repeat the above-mentioned steps until results are achieved.

Project Management Tools

How and what project management tools should be chosen? There are dozens of tools on the market within the wide price range. Implementing some of them can cost hundreds of thousands of dollars. Like choosing the Enterprise Architecture managing tools, I recommend using free or low-cost tools whenever possible.

What are the minimum requirements for tools? What should they help you do?

• Write and edit texts, make charts, tables, presentations, etc.

• Publish them on accessible resource, regulate the access rights to information, and discuss these materials.

Set of tools:

• To compile documents, charts, spreadsheets and presentations, one can use a standard office suite, for example, MS Office containing ready-made document templates. There are extensions for Visio to draw all the necessary flowcharts.

• Joint works requires using a corporate portal, a document management system, a corporate mail system, a corporate messaging system, or a dedicated file share in an organization’s corporate network. The choice of solution will depend on what your company already have got.

Professional project management tools are:

•Microsoft Project 2016 Server / Professional

•JIRA Project Management

For developed organizations or project IT companies, it is preferable to use additional professional systems if they are not part of Project Management systems, such as:

• Work Authorization System;

• Change Control System;

• Configuration Management System.

Key success factors of the project

The chances to implement the project successfully increase if the project is supported by the company’s top management and the scope of work is reduced so that the minimum significant result for the company is achieved in the shortest time and at the lowest cost. In addition, it is worth paying much attention to planning, risks and receiving feedback from external or internal customers.

The following key success factors for a project can be identified:

•Clear and understandable objectives are vital for the project. Moreover, the achievement of these goals should be important for the project sponsor and key stakeholders.

•Quick results should be achieved to ensure short-term goals. It is important to maintain the sponsor’s interest in the project. To do this, one needs to quickly achieve the necessary results for the company to be recorded as an asset. If the nearest results will be in 3 years, then the interest in the project will drop dramatically.

•Intensive work with all interested parties is required within the project to resolve the issues involving top-management, other important and busy people. Find ways to get them involved in the project. Of course, them should not be invited to all meetings or disturbed every day. But their trustees can be involved in the project and informed on the project progress. In addition, you can prepare lists of questions with answers to meet with them.

•Revolutionary changes are attractive on the paper, but difficult to implement. It is better to avoid them. Gradual improvements are often more effective.

•Tracking value of the results is required for every architectural solution to assess benefits, terms, expenses and risks. They must be coordinated with the sponsor and interested parties. Project results should give value to the company.

•Ensuring maximum reuse of the organization’s IT assets is a great opportunity to get fast results with minimal cost. Destroying and reconstruction may be long and expensive. Breaking something that really works is unwise. The information systems and company equipment of the are used for 15—30% of opportunities.

•Architects and project managers should work closely with business and IT projects rather than generate brilliant ideas based on the “best practices”. Working “on site” for many aspiring architects is extremely uncomfortable. They are afraid to seem incompetent. Although the fact that IT specialists know deeper specific technologies than architects is perfectly normal just like the fact that the business knows better the way the company works. Working with people is the only way to achieve results.

•Maximum use and distribution of information is very important since information is a main asset of the architectural project. Access to the information should be as fast and convenient as possible. Everything you know and how it can be used should be shared to everyone.

•The results of project implementation should be monitored. Implementation projects that are often carried out by external performers, need formal acceptance of the results. They can close the project with acts and disappear. Architects must create a single system using the results of several projects. So keep your nose to the wind.

•Speak to people in understandable language. Speak to business in the language of business. Speak to IT in the language of IT. Try to avoid slang and professional jargon. The importance of communication is often underestimated. Control not only what you say, but how, when and to whom. If you are not understood, that is your fault as well as a very big problem.

•Start with a pilot project. The main goal at the start is to show real results.

•Define “The project path” which is an understandable elementary specific action. The path can be different and depends on various factors for each person and for the project. The width of the “success path” in project management can be determined using the following five criteria:

• Sufficient knowledge and skills to take a step;

• Short time step;

• Pitch having a low risk;

• Behavior-specific step;

• Clear set success of the step.

•One of the most common mistakes in implementation is to sit and wait for people to come to you to discuss problems. Do not wait and go yourself to people at all levels, ask about their problems. Name those who you have already helped or offered your help in solving their problems and tasks. Ask questions.

•Remember about the value. Each your proposal must be justified in terms of value for the company. Forget that it will be more appropriate in terms of architecture. Always remember about benefits, timing, costs and risks. Do not offer revolution without detailed economic justification.

•Do not reinvent the wheel.

•Do not start a project without intention to complete it. Two or three slow or failed projects will de-motivate the employees.

•Thank your leadership for their support, colleagues for help and patience, etc.

The main reasons for project failure

Projects implemented without using any methods often fail for the following ten reasons:

• The project is a solution causing the problem;

• Only project team is interested in the end result;

• No one is responsible for anything;

• The project plan is not well structured;

• Project plan is not detailed enough;

• Funds allocated for project implementation are insufficient;

• The allocated resources are insufficient to perform the work;

• The project is not compared to the implementation plan;

• There is no interaction between project team members;

• The project deviates from the goal.

When managing any project, including an IT project, the most important elements are the communication process of all the departments and units involved. The more heterogeneous the participants (financiers, representatives of business, IT, and so on), the more important it is to organize communication using “the same” language for all members of the project team. Otherwise, the results of the project and its stages may be similar to the diagram above.

Conclusion

To summarize the results of this chapter, the following important conclusions on the methodology and techniques of project management can be made:

•Classic method, “a tractor” (particularly a German tractor if the project is completed successfully), is a result-oriented method to have a final product whatever it takes. Everything is done in accordance with the order and instructions.

• The PRINCE2 methodology is the same, but the question arises “why do we need it if there is no income?”

• “There is no money, but everything should be done by tomorrow morning. What exactly is required is unknown — but the customer wants EVERYTHING”. It is more appropriate for using flexible project management methods.

• “Thresher” — SCRUM method

• KANBAN is good not to overload the workers, otherwise “only fools and horses work”

• The LEAN and SIX SIGMA methodologies will monitors “a number errors done”.

Speaking seriously, it is important to note that solutions for all occasions, even within the same organization, do not exist. The project management is constantly evolving, and the project manager’s awareness of the strengths and weaknesses of each methodology contributes to the successful projects implementation, expanding the stakeholders’ potential opportunities. All project management methods are good in their own way and each has its own pros and cons. The application of project management methodology depends on the goals, type and context of the project.

RISK MANAGEMENT

General principles

Risk management is the process of making and executing management decisions aimed at reducing the likelihood of an unfavorable result and minimizing the impact of organization’s possible losses caused by random events.

This chapter contains the basic principles of risk management in architecture design that should be considered. When developing and implementing various IT services architecture, it is necessary to manage risks continuously. To manage IT risks, one can use general and IT-specific techniques. This chapter takes into account the recommendations of the ISO Guide 73: 2009 “Risk management — Principles and guidelines”, as well as the CRAMM v5 method (CCTA Risk Analysis & Management Method) based on the requirements of the Central Computer and Telecommunications Agency (CCTA) that complies with BS7799 / ISO17799.

Risk classification

A general risks classification can be represented as:

Internal risks:

• Project,

• Technical,

• Technological,

• Organizational,

• Financial etc.

External risks:

• Natural,

• Political,

• Social,

• Economic etc.

Type:

• Predictable,

• Unpredictable.

The nature:

• Intentional,

• Not intentional.

Sort:

• Direct,

• Indirect.

Result:

• Malfunction,

• Violation of integrity,

• Breach of authenticity

• Breach of confidentiality

Mechanical:

• Accidents,

• Human error.

Evaluation criteria

The main resources value evaluation criteria include the following:

• Damage to the reputation of the organization,

• Safety of the personnel,

• Disclosure of personal data,

• Disclosure of confidential data,

• Disclosure of commercial information,

• Sanctions by supervisory and public authorities,

•Financial losses,

• Violations of the organization’s normal functioning.

Basic steps and stages

The following steps can be taken as basic steps:

General Risk Management

• Development of a risk management process, policies and procedures;

• Classification of resources, risks, vulnerabilities, threats;

• Classification of risk response and assessment methods;

• Creation of a Risk Management Committee;

• Creation of an expert group including IT and business experts.

Identification and Valuation of Assets

• The expert group identifies and assesses the value of resources;

• Expert group identifies potential risks.

Threat and Vulnerability Assessment

• Expert group evaluates system vulnerabilities;

• Expert group evaluates system threats.

Risk Analysis

• The expert group conducts a qualitative and quantitative risk analysis. The main criteria are defined as: “likelihood” and “impact” which are classified according to the values: “high”, “medium” and “low”.

• A quantitative risk analysis is conducted (if necessary).

• The expert group categorize risks and develops a risk matrix (registry).

The basic analysis mechanisms and elements from the technical side are:

• Business Impact Analysis (BIA) — analysis of IT services by level of business impact.

• Service Fault Analysis (SFA) — analysis of IT services by the level of impact on related IT services.

• Component Fault Impact Analysis (CFIA) — component analysis by IT service impact level.

Risk Management

• Emphasizing risks with “high” and “medium” values;

• Determining response to risks (acceptance, reduction, transfer, and so on);

• Determining possible mitigations and the cost of their implementation;

• Forming a number of project scenarios i.e. “negative”, “positive” and “realistic”;

• Making adjustments;

• Documenting results and decision-making;

• Discussing and documenting all changes to project plans.

The least number of documents to be developed are:

• Risk register;

• Amendment requests;

• Meeting minutes.

When operating IT service, a risk management (identifying new risks, protective measures, and so on) is conducted. This process is continuous and cyclical.

Risk assessment methods

Risk identification methods are the following:

• Questionnaires;

• Interviews;

• check lists;

• Brainstorm;

• Delphi;

The most widely spread tools, methods and techniques of risk assessment are stipulated in ISO / IEC 31010: 2009. There are 31 risk assessment techniques listed on Annex B of ISO/IEC 31010: brainstorm, SWIFT (“What if…” technique), FMEA, HAZOP, HACCP, Bow tie analysis, fault tree analysis, Bayesian statistics and Bayes nets, FN curves etc.

Delphi Technique

Delphi is an information collecting method used to reach consensus of experts on a certain issue. It implies experts’ anonymous participation. A project coordinator presents ideas on important points of the project related to this issue using the questionnaire. The answers are summarized and returned to experts for comments. Consensus can be achieved through several cycles of this process. Delphi helps overcome data bias and eliminates the excessive influence of individuals on the outcome of the discussion.

The essence of Delphi expert assessments is a certain generalized opinion resulting from a series of actions by independent experts, which is a more reliable than that of individual specialists.

Delphi technique implies involving two panels:

• Panel 1 consists of experts, presenting their opinion on the problem studied;

• Panel 2 is represented by the analysts, leading experts to a common denominator.

The Delphi method involves several steps:

• Formation of a team;

• Problem statement;

• Reaching consensus.

The first stage is to select an expert panel which can consist of any number of people. However, it is recommended to limit this number by 20 people.

The second stage is to take the following steps:

The problem is set — the experts are given the main question, and their task is to break it down into several smaller ones. Analysts select the most common questions and make up a general questionnaire.

This questionnaire is returned to the experts who should now tell whether something else should be added, or whether data are sufficient, or whether there is any additional information on the problem. Thus, there are 20 answers (depending on the number of experts) with detailed information.

Analysts develop another questionnaire, which is again provided to the experts. Now they need to offer their own solutions to the problem and study other experts’ alternative positions. Effectiveness, availability of resources, the relevance of solutions are assessed. The analysts highlight the experts’ main opinions and try to bring them closer. If someone’s opinions are opposite to the majority, experts voice these opinions. The experts can change their minds, which is followed by repeating the same step.

The steps reoccur until the experts reach a consensus. A study of differences in the experts’ opinions by analysts may indicate the subtleties of the problem that have not been addressed before. A final overall assessment is made and practical recommendations are made to solve the problem.

The consistency of expert opinions is verified, the findings are analyzed and final recommendations are developed at the third stage.

Along with the Delphi method structure, there are other modifications. The most widely spread one includes an unstructured stage. This modification is used if the research is aimed at finding something precise, while the study administrators are not able to immediately present the problem as specialized questions. In this case, an expert panel is involved at the stage of formulating the problem.

Another Delphi method modification is aimed at reducing the time to be spent on the implementation of the analytical phase — it is called Express-Delphi. Taking into account the fact that the traditional method with all its advantages is quite labor-intensive and requires a considerable amount of time to be applied, the express method allows saving all the main elements of the method, and the whole procedure can be carried out within a few hours, however, having a special technical base available. Each member of the expert panel spends the allotted time at the workstation. All workstations are united by one common network, which closes the leader of the event. Once the experts propose their solutions in an accelerated mode, analysts must assess them as soon as possible. This process largely depends on promptness of the material processing and systematization.

Benefits:

• The Delphi method contributes to the development of independent thinking of panelists.

• Provides a calm and objective study of issues to be assessed.

Deficiencies:

• The organizers of the event have excessive authorities, compared with experts, which means that experts can be defenseless in a sense.

• Collective opinion is far from being true in all cases.

• Analysts reject creative solutions having the least number of supporters, while these solutions can be the most effective ones.

• Operational analysis is impossible, since the last stage takes a lot of time: each stage of analysis can take at least 24 hours.

• Experts tend to be conformists, willing to join the majority’s opinion.

• Organizers have an opportunity to manipulate the expert panel.

Brainstorming

Brainstorming is a general method of gathering information, ideas, and proposing solutions to be used to identify risks, ideas, or problem solutions by a group of team members or experts. During brainstorming, participants’ ideas are usually recorded for further analysis. This is a popular group interaction method used to solve educational and business problems. The technique of brainstorming is aimed at spontaneous generation of a large number of ideas to solve a challenge or a problem.

Stages of preparation for brainstorming:

• Problem Statement

• Formation of a group of participants

• Informing discussion participants

• Listing the motivating questions.

Statement of the problem to be solved. The problem should be essentially summarized. If the problem is too big, then the organizer should break it into short elements. If the question cannot be formulated briefly or broken into elements, brainstorming is not an acceptable method for solving this problem.

Making a list of brainstormers. The most productive group consists of 10 or less people. The panel members should be:

• Participants who have been aware of the problem or task.

• Participants who are familiar with a related problem.

• One “idea collector” who captures all proposed ideas.

Writing and sharing of the information letter to the participants. The letter must contain:

• Session name,

• Problem to be solved,

• Time, date and venue.

The problem should be described as a question and several examples of ideas attached to it.

Listing motivating questions. Creativity may decrease during discussions. The organizer should stimulate the activity of motivating questions to further generation of ideas.

Stages of working with ideas:

• Listing ideas without assessing the likelihood of their implementation. At this stage, the organizer presents a problem, raises simple questions in line with the problem being solved, as well as provides a safe environment for expressing ideas.

• Evaluation of ideas in terms of their importance and contribution to solving the problem. Every idea should be comprehensible for the participants. To do this, participants carefully explain the essence of their ideas and their value for solving the problem.

• Categorization of collected ideas. At this stage, similar ideas are formulated into one, while absolutely unreal and unimportant ideas are discarded. The remaining ideas should be clearly articulated, understood by each participant and included in the final list.

The main rules are:

• Focus on quantity: this means that as many different ideas as possible should be worked since the more the ideas available, the more likely to find the best solution. “Quantity generates quality.”

• Deterrence of criticism: any criticism should be reduced to “zero.” Instead, participants should focus on adding new ideas, leaving criticism for the next evaluation stage.

• Allowing unusual ideas: unusual ideas must also be included in the list. They are generated by new / other perspectives and often the best solutions are born on their basis.

• Combining and improving ideas: the best ideas can be combined with a better idea (“1 +1 = 3”). Such a rule encourages the creation of ideas through associations.

Management of Risks (M_o_R)

The standard methodology Management of Risks (M_o_R) is applied to assess and manage risk, and includes the following:

M_o_R Principles are based on corporate governance principles and are essential for the development of good risk management practice;

M_o_R Approach is a company’s approach to the principles, which needs to be agreed and defined within a risk management policy and some other documents.

M_o_R Processes contain four main process steps:

• Identification of threats, which may affect the outputs of the activity;

• Assessment is an estimation of the cumulative impact of all defined threats;

• Planning is determining a set of managerial actions that will reduce risks;

• Implementation is carrying out the planned managerial actions, their control, determination of efficiency and adjustment, if required.

Embedding and reviewing M_o_R

Implementing processes, policies and the M_o_R approach so that they are continuously monitored and remain effective;

M_o_R Communication

Ensuring the communication between all actions within M_o_R in order to maintain the relevance of information on threats, opportunities and other aspects of Risk Management.

In addition, the following specialized techniques can be used:

CRAMM v5

Specific IT methods and standards include the CRAMM v5 method. The aim of this method is to create formalized procedures that allows:

• Complete and documented analysis of the requirements for the Information System;

• Identification and classification of risks;

• Identification and assessment of IT resource vulnerability;

• Identification and assessment of threats to IT systems;

• Forming justification for countermeasures;

• Avoidance unnecessary costs for providing Information Security Systems;

• Reduction of implementation and maintenance terms of company’s information security;

• Assistance in IT services performance at all stages of the life cycle;

• Automation of risk analysis and management processes;

• Evaluation of the effectiveness of countermeasures

• Reporting.

CORAS

CORAS is a combination of different techniques, such as Event-Tree-Analysis, Markov chains and FMECA. This method uses UML (Unified Modeling Language, a programming language to visualize the design of a system). The method consists of the following actions:

• Search and systematization of data on the object of analysis;

• The definition of the object and the subject involved in the analysis;

• Full process or task description;

• Verification of accuracy and completeness of data submitted for analysis;

• Implementation of risk mitigation;

• Estimate of the likelihood and consequences of a threat;

• Elimination of threat.

OCTAVE

Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE) is a framework for prompt identifying assets and evaluating and identifying critical threats. It is specified by the formation of specialized groups and the close involvement of the business owner. OCTAVE defines three phases:

• Build Asset-Based Threat Profiles

• Identify Infrastructure Vulnerabilities within the organization

• Develop Security Strategy and Plans. This phase consists of the following actions:

° Documenting the current status;

° Selection of risk mitigation approaches;

° Selection of cost reduction approaches;

° Indication of changes required for current organization;

° Identification of perspectives of information security.

Matrix Method

The method links assets, vulnerabilities, and controls, and determines the importance of different controls on various assets within an organization. The methodology includes three different matrices related to each other.

• Threat matrix contains the relationship between vulnerabilities and threats.

• Vulnerability matrix contains the relationship between assets and vulnerabilities.

• Control matrix contains the relationship between threats and control measures.

The value in each cell of the matrix indicates the value of the relationship between the row and column element. The following rating system is used: 1 — low, 2 — medium and 3 — high.

During the initial analysis, assets, vulnerabilities, threats, and management tools are listed. Matrices are filled by adding data about the relationship of the element of the matrix column with the element of the row.

Then the data from the vulnerability matrix is transferred to the threat matrix. The same principle applies to transferring data from the threat matrix to the control matrix.

One of the method’s benefits is universality.

Risk Breakdown Structure (RBS)

Risk Breakdown Structure (RBS) is a hierarchical representation of risks according to their risk categories and subcategories, indicating different areas and causes of potential risks. The hierarchical risk structure is often adjusted to specific types of projects.

Risk calculation

As a risk assessment, one can use quantitative and qualitative assessment method. Use the following indicators for a quantitative method of assessing risks and threats:

•SLE (Single Loss Expectancy) = Asset Value x EF (Exposure Factor)

•ALE (Annualized Loss Expectancy) = SLE x ARO (Annualized Rate of Occurrence)

•Total Risk = Threats x Vulnerabilities x Asset Value

•ACV (Actual Cost Evaluation)

Asset Value (AV) — The cost of the resource reflects the value of the resource. Fixed values can be used in qualitative analysis (1 is low cost, 2 is medium cost and 3 is high cost). For example, the server of the active directory will have the indicator AV = 3, while the workstation AV = 1.

Exposure Factor (EF) is a security degree of the resource, which shows how this resource is exposed to risk. Fixed values can be used in qualitative analysis (1 — low degree of vulnerability or impact, 2 — medium degree of vulnerability or high likelihood of resource recovery, and 3 — high degree of vulnerability or the need to replace the resource). For example, the server of the active directory will have the indicator EF = 2.

Annualized Rate of Occurrence (ARO) is assessment of the threat likelihood, which indicates the likelihood of a specific threat occurring over a fixed period (year). Fixed values can be used in qualitative analysis (1 — low likelihood, 2 — medium likelihood and 3 — high likelihood). For example, the server of the active directory will have the indicator ARO = 1.

Annual Loss Exposure (ALE) is the expected monetary loss that can be expected for an asset due to a risk over certain period of time. Fixed values can be used in qualitative analysis (1 is low cost, 2 is medium cost and 3 is high cost). For example, the server of the active directory will have the indicator AV = 3, and the workstation AV = 1.

Use the following matrix for qualitative risk assessment: