bannerbannerbanner
IT Architecture from A to Z: Theoretical basis. First Edition
IT Architecture from A to Z: Theoretical basis. First Edition

Полная версия

IT Architecture from A to Z: Theoretical basis. First Edition

текст

0

0
Язык: Английский
Год издания: 2018
Добавлена:
Настройки чтения
Размер шрифта
Высота строк
Поля
На страницу:
9 из 9

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.


Diagram: Project cost


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.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Конец ознакомительного фрагмента
Купить и скачать всю книгу
На страницу:
9 из 9