Project EE/06/B/FPP-169000 Learning Materials for Information Technology Professionals (EUCIP-Mat)
1. Number of study hours 20 2. Short description of the course Course deals with Project Management with stress to IT field. Detailed overview of project life cycle, economy and quality assurance is presented. 3. Target groups The employers of IT core level professionals are the target sector here. The first target group consists of IT students (vocational school basic level IT training and the first courses in colleges and universities) in the field of technology, and IT practitioners not having vocational certificates yet 4. Prerequisites There are no prerequisites for this course.
5. Aim of the course - learning outcomes After taking the course students have basic knowledge about IT Project Management.
6. Content of the learning materials
A.5 Project management
A.5.1 Information system projects All projects that are initiated and implemented bring along some kind of changes, improvements or enhancements. This is where business projects and IT projects are similar.
IT and business projects are also similar because they both: • Are one-time; • Have deadlines; • Are innovative; • Are interdisciplinary, i.e. related to various fields; • Entail high risks; • Are important for the organisation or company; • Require complex planning and management; • Entail conflicts.
In the following, these similarities are discussed in more detail.
Projects are one-time events, because exactly that task will never need to be solved again or a need for solving a similar task in the near future is improbable.
Projects have deadlines, because there is a definite date by which the project needs to be completed.
Projects are innovative, because exactly that task has never been encountered before. Even if the initial conditions are the same, there is always something that makes the project innovative. Most often, such new element is time or the organisation itself where the project is being implemented.
Projects are interdisciplinary, i.e. they are related to various fields, because there are specialists from more than one narrow specialty needed for implementing a project. This property makes it especially important to consider everything related to establishing a project group.
Projects entail many risks, because we cannot foresee all actions needed for achieving the goal and thus there is much uncertainty in projects. This makes projects risky. The main risks entailed in projects are related to deadlines, money and people.
Projects are important for the organisation because in most cases the successful implementation of a project has a significant effect on achieving the main goals of the organisation.
Projects require complex planning and management, because exactly that task with exactly the same initial conditions has never been encountered before. This makes planning and implementing projects complex. All organisational measures being applied become very important in management of a project. At the same time, the project manager must be aware that very often quick, clear and unambiguous decisions are needed in project management. In usual management of an organisation, decisions can often be postponed and the time until then is used for gathering more information. In case of project management, this is possible only rarely, because the time available for implementing a project is limited.
Projects entail conflicts because by bringing along changes in the usual activities, they always raise resistance in some related parties. Because of this, the decision-making process related to a project can often become emotional and this also increases the risk level. Regardless of the wide range of similarities between IT projects and business projects, they also have significant differences. Let's compare an IT project to a specific project for construction of a house, in order to better highlight these differences. The most important differences between these two project types are related to the following: • Exactness of the initial task presented by the customer; • Perceptibility of the final result; • Reliability of planning; • Assessing the progress of the project; • Output; • Resistance related to changes;
The initial task of a construction project is very exact and clearly stated for the constructor. For this, the project has been prepared in co-operation between the architect and the customer. In case of IT projects, the initial task is often stated as an imprecise idea of the customer about what the new software solution could or should do.
In case of a construction project, the architectural solution and the drawings can give the customer a fairly clear perception about what the house will look like. On the other hand, it is very difficult to make an IT solution clear to the customer.
The duration of implementing a construction project can be determined relatively precisely via work volumes. In case of IT projects, determining the time needed for implementation of the project is one of the most difficult tasks, because many changes can be made in the course of development activities and such changes need additional time to implement.
In assessing the intermediate results of a construction project there is no doubt about the extent of the tasks already performed. The intermediate results are easy to assess and the intermediate acts are also simple to prepare. In case of IT projects it is often impossible to assess the intermediate results because the result and its quality become evident only after the entire work has been finished.
A construction project and an IT project have absolutely different outputs. The former results in a material object and the latter results in an immaterial value.
While in case of a construction project the attitude towards changes brought about by the project is largely positive, in case of IT projects the attitude towards coming changes is often negative.
Project management means applying knowledge, skills, means and technology in such a way as to make it possible to perform the activities needed for achieving the goal of the project.
In projects, information technology and information systems can have the role of goal or the role of means for achieving a goal. If, in the course of implementing the project, an information system of the organisation, a specific information technology solution or even the most basic project management software is used, then information technology and information systems have the role of means for achieving a goal in the project. These means are used for managing the project. But if the organisation wishes to implement a new information technology solution or an information system, then it is considered to be the goal of the project.
In the most general way, projects can be divided into development projects and implementation projects. The goals of development projects are often not specific, but entail a vision instead. If a company decides to initiate a development project within the company, then often the first step needs to be the determining of the problem that is to be solved with the project. Also, the activities needed for achieving the goal are not always known in case of a development project. It is very difficult to determine the duration of an activity in such a project. In case of development projects, the determining of the end goal and the achieving of this goal are the most critical. These are followed by the time and expenses needed for achieving the results. Development projects are often internal projects of an organisation and as a rule they have a long initiation stage.
Implementation projects are less unique than development projects. In case of implementation projects, the goals are clear and specific. The tasks of the project are well known and it is relatively easy to determine the duration of the tasks. Often, the initiation stage of an implementation project is very short.
At the same time, there are no projects that are purely development projects or purely implementation projects. Every project has properties of both these types. This can be illustrated with the following schematic.
Most projects have a higher share of development elements in the beginning, but the more a project advances, the lower becomes the share of development elements and the higher becomes the share of implementation elements. On the other hand, a project never completely loses the development property, because even in the last stages and with the last actions, something new and developmental may be needed.
The elements of project management are as follows: • Project scope management: Scope management has to provide a clear answer to the question of what needs to be done or what the project needs to achieve. This is not a one-time action at the initiation of the project, but is instead performed during the entire process of the project. It is especially important in case of IT development projects where the initial goal is often lost from view somewhere in the course of the project;
• Project time management: Time management has to provide an answer to the questions of what order do the tasks need to be performed in and at what time a certain task needs to be done. These are critical questions for all projects, as they largely determine the success of the entire project;
• Project quality management: Quality management has to ensure the conformance of the intermediate results and the end results to the stated requirements. Without quality management it is impossible to reach an end result that satisfies the customer;
• Project cost management: In the beginning of the project, cost management has to determine the costs of the works and resources needed. In the course of the project, cost management has to provide a continuous overview of the resources already spent for the project and the resources still needed to be spent for achieving the results of the project;
• Project human resources management: In the planning stage of the project, human resources management has to determine what kind of people and how many are needed for implementing the project. In the course of the project, human resources management has to deal with motivating and informing people, with conflict management, with activity supervision, etc.;
• Project communication management: Communication management has to determine what kind of information exchange needs to be established and with whom it needs to be established;
• Project risk management: Risk management has to provide a continuous overview about the level of uncertainty related to the project and the possible factors that could endanger the achieving of the project's goal;
• Project procurement management: Procurement management has to ensure that correct agreements are signed with correct sub-contractors at the correct time and that all sub-contractor works are covered with correct contracts;
• Project integration management: Integration management deals with relations within the project itself and also with relations outside the project. Leaving any of the various relations (finances, time, means, etc.) unchecked is certainly dangerous because it can lead to a failure of the project.
The prerequisites for a successful project management are as follows: • The project is a part of a wider vision, strategy or goal; • Resources, time schedule and quality have been prioritised accordingly and this hierarchy of priorities is followed during the entire process of the project; • The initial task of the project has been formulated precisely and correctly; • The quality requirements have been stated and are also managed during the entire process of the project; • The time schedule and the resources needed have been clearly determined and co-ordinated with all related parties; • The reason for initiating the project has been sufficiently justified; • The following has been exactly determined: o The roles of every participant of the project; o The areas of responsibilities of every participant of the project; o The decision-making rights of the project manager/participants of the project; • A competent project team has been established, with the following qualities: o Professional competency; o Competency in project work; • A precise and correct project plan has been prepared; • The process of making changes has been exactly stated; • The project risks have been determined and the possibilities for hedging these risks have been considered; • The project-specific values and rules have been stated; • The communication plan has been prepared and is followed during the entire process of the project. • There are lots of ideas that lead nowhere; • There is low control over the progress of projects; • Projects are not precisely prioritised or not prioritised at all on the organisation level; • The goals of projects are unclear; • The organisation does not monitor its current capability to implement projects; • The organisational structure does not support project management; • Risks are not dared to be taken or are just ignored; • The initial task is unclear; • There is no relation between the goals of the organisation and the goals of the project; • There are conflicts between the project organisation and the main organisation; • There is no clear overview of projects and resources; • There is no knowledge about the relations between projects; • New projects are continuously being initiated without taking into account the projects already in progress.
A.5.2 Quality, time and expenses
The three most important things to be monitored in every project are time, resources and quality, and these three are very closely related with each other. The triangle of relations between these three is often called the Iron Triangle, illustrated below.
The Iron Triangle means that a better result usually needs more time and more resources (money). It is almost always possible to differentiate between the cost of implementing the project and the cost of the new system being implemented. The latter are divided into one-time expenses and fixed costs.
The cost of implementing the project means one-time salary costs of employees in the course of the project.
The cost of the system means expenses incurred in implementing the new system that has been created in the company as a result of the project. These expenses are divided as follows: • One-time expenses; • Fixed costs.
One-time expenses of the system being implemented are considered all such expenses that are incurred in the course of creating the system in the course of the project and not being project expenses.
Fixed costs of the system being implemented are considered all such expenses that are incurred in the course of operating the system.
The goal of project quality planning is to plan those activities that ensure the required quality in the course of the project. At the same time, the quality plan of the project shows the customer that the company is capable of fulfilling the obligations taken with the contract.
The quality plan determines how all the other plans must be. At the same time, it also determines how the project is planned and managed and how the supervision is conducted. The following factors affect the preparing of the quality plan: • Scope of the project; • Complexity of the project; • Quality goals; • Intensity of the time schedule; • Customer requirements; • Applicable regulations; • Project management documentation valid in the company.
The quality plan is used for stating the quality goals and for describing and prioritising the project risks according to their importance. Also, the quality plan states the priority hierarchy of measures to be taken for ensuring quality.
One of the important parts of the quality plan is considered to be the responsibility matrix, which states the specific responsible parties, executors and helpers for every task.
Formulating contradicting goals must be avoided in preparing the system of goals for the project. All goals have to be reviewed and all goal conflicts determined and eliminated or subjected to the relevant priorities in order for the implementation of the project to be successful.
For example, goals can be as follows: • Decrease of expenses; • Decrease of required personnel; • Shortening of processing time; • Minimising errors; • Implementing efficient techniques; • Better organisation of reports; • Humanising work, etc.
Formulating goals is often an activity that requires time and good preparation. The end goal cannot be formulated and written down in a flash even for small projects.
It is recommended to formulate project goals in a co-operation between the project manager and the project group. This ensures a higher probability of the set goals actually being achieved.
In case of longer projects the suitability of the set goals must be regularly verified, and in case of a changed situation these goals must also be corrected.
If one component of the Iron Triangle is changed, then it must be taken into account that the other components unavoidably change with it. For example, if the customer wishes to get a result with a higher quality than stated initially, then the time needed for achieving such a result will definitely be longer and there will be more money needed for that. If the budget or the time allocated for the project is lessened, then it has to be taken into account that the results cannot have such a high quality anymore as planned initially.
The changes described above can lead to changing the entire project management as a whole. Resource management, involved people, etc. need to be reviewed.
Value analysis management is a project management technique that is used for assessment on the basis of the goals of the project progress. The following are needed for performing the value analysis: • Project plan stating the tasks performed by the time of assessment; • Planned values (time, money, work volumes) by the time of assessment; • Actual values (time, money, work volumes) by the time of assessment.
By using the method of value analysis, all the various figures characterising the project are connected as an integral whole and the progress of the project is assessed via unambiguous numerical properties. Primarily, the volume of tasks performed the fulfilment of the budget and the following of the time schedule are used for this method.
By using this method, the progress of the project is continuously monitored via comparing the actual achieved value with the value planned for the relevant point in time. At the time of verification, the values of all performed tasks are summarised and then compared to the value that was planned to be achieved for that point of time.
Every project entails more or less uncertainty. This makes also the planning of time, expenses and quality imprecise.
Primarily, the uncertainty in determining these properties results from the fact that often the planners are unable to ensure the following when planning the project: • Determining the work volume of a specific task: The work volume and the number of executors of that task determine the duration of the task; • Describing the end result of the project: The less certain the end result, the more difficult it is to state the quality criteria of the project and the duration and cost of the works needed; • Dividing the project into main tasks and sub-tasks: The more efficiently the project is divided into main tasks and sub-tasks, the easier it is to plan the entire project. This kind of dividing is considered to be one of the cornerstones of project planning; • Determining the customer expectations: Inability to determine this leads to changes in the course of the project and from there on to postponing the deadlines planned in the initial stage of the project, to increasing of the expenses and to lowering of the quality.
COCOMO model for determining the cost of software The initial COCOMO model was developed by Barry Boehm in the year 1981, on the basis of 56 software projects. In the following years it was somewhat improved. This model has two parts and it assesses the number of person-months needed for completing a software project (from design works to handover test, not considering support services, incl. administration support) and the duration of the project (in months, one person-month = 152 hours): Number of person-months = C1•K•(Volume)P1, where C1 - Constant characteristic to the specific software project; K - Correctional constant depending on the quality of the personnel, the work environment, etc. It is expressed as a multiplication of 15 factors; Volume - Number of lines in the source code (expressed in thousands, not counting any comment lines); P1 - Factor of power characterising the process. Duration of the project = C2•(Number of person-months)P2 , where C2 - Constant, P2 - Factor of power characterising the rate of parallelism (both in time and in content). Software projects were divided into three categories and the relevant factors were determined for each of these categories: organic projects (for example, projects within the company that are not very complex and where the time and quality requirements are not very strictly stated), entered projects (for example, military projects where the process and the requirements are very strictly stated) and intermediate projects. The formulas for these categories are as follows:
I. Organic software projects: Number of person-months = 3.2K•(Volume)1.05 , Project duration = 2.5•( Number of person-months)0.38 , II. Intermediate projects: Number of person-months = 3.0K•(Volume)1.12 , Project duration = 2.5•( Number of person-months)0.35, III. Entered projects: Number of person-months = 2.8K•(Volume)1.2 , Project duration = 2.5•( Number of person-months)0.32.
The values of the factor K, its variation ranges (on a scale from small…large) and potential effect (in multiplications) are as follows: No. Description of the parameter Variation range Potential effect 1. Required reliability 0.75-1.40 1.87 2. Size of the database 0.94-1.16 1.23 3. Complexity of the product 0.70-1.65 2.36 4. Time limits for completion 1.00-1.66 1.66 5. Base memory limitations 1.00-1.56 1.56 6. Use of virtual machine 0.87-1.30 1.49 7. Changeover time of computers 0.87-1.15 1.32 8. Analysis capability 1.46-0.71 2.06 9. Experience of applications 1.29-0.82 1.57 10. Capabilities of the programmers 1.42-0.70 2.03 11. Experience of virtual machine use 1.21-0.90 1.34 12. Language experience 1.14-0.95 1.20 13. Use of modern experience 1.24-0.82 1.51 14. Use of software development tools 1.24-0.83 1.49 15. Required time schedule of the application 1.23-1.00 1.23
Example. If the factor K = 1 and the Volume = 9,000 lines of code, then applying the formula II gives the result that 3•1•91.12 = 35 person-months are needed for developing the project and 2.5•350.35 = 7.8 months will be used for that. When adding in 3.2 months needed for project planning and for determining the requirements, the estimated duration of the project becomes 11 months. The rate of people used across months depends heavily on the specific project, but an example can be as follows: Month 1 2 3 4 5 6 7 8 9 10 11 People 2 2 2 3 3 6 6 5 5 4 4 The COCOMO model has been developed further for specific conditions, like for example ADA (1985) and COCOMO II (see http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html, 1995) for new software development techniques. In the latter case, three models are used: Prototype model, Early Design model and Architecture model. The latter two are expressed in the form of 2.45E•(Volume)P, where E is comprised of seven correctional factors in the former case and 17 correctional factors in the latter case, and where P is expressed as 1+α and is located within the range of 1.01…1.26. In this, α is expressed as a sum of five parts, one of which is a percentage determined by the CMM level (for example, it equals 0.03 in case of level 3).
SPICE method for assessing the software process The SPICE method for assessing the software process (Software Process Improvement and Capability dEtermination, www.sqi.gu.edu.au/spice) allows for improving the quality level of the software process and also to assess the capability of the developer to fulfil a certain requirement or the capability of the customer in relation with a certain requirement. This method was developed during the years 1993-1995 and it has the following properties: - Allowing self-analysis; - Taking into account the context of the assessed process (for example, the processes are different for a development team with few members or with many members); - Assesses process parameters; - Assesses management adequacy (i.e. the conformance of the management to the process); - Can be used with any applications and organisation sizes. Different instances of the process are assessed in the structural unit, using the scale of six levels of maturity (0 – not performed, 1 – performed informally, 2 – planned and tracked, 3 – well defined, 4 – quantitatively controlled, 5 – continuously improving). The assessment is based on the rate of conformance to the goals resulting from practice, where related risks are a significant element of that rate. SPICE is a helping method for various parties, allowing the following: • The customer can assess the capability of the developer, • The developer can assess its own level of software process and determine the ways for improving it; • The evaluators can prepare an evaluation framework that takes everything into account. The documentation of the SPICE method (the SPICE suite) consists of the following nine parts: 1) Introduction and main definitions. This part gives an overview of the relations between the different parts, and also provides instructions for selecting and using separate parts of the documentation; 2) Process management model. This part determines the main activities of software development, in the order of increasing complexity of the process; 3) Process evaluation. In addition to providing the evaluation framework (i.e. what to evaluate), this part also provides the basics of evaluation (i.e. how to determine the level); 4) Instructions for performing an evaluation; 5) Creating and selecting evaluation instruments and means; 6) Qualification and training of evaluators. This part also describes the techniques for determining the level of competency of an evaluator; 7) Instructions for implementation in improving the process. This part also describes the determining of indicators and the way of using the evaluation results for improving the process; also, lots of examples are provided here; 8) Instructions for implementation in determining the capability of processes. This part also describes the determining of indicators and the way of using the evaluation results for determining the capability of the process; 9) Glossary containing all specific terms used in the SPICE documents. The advantages of the SPICE method over ISO 9000 are that while the latter has two levels (satisfactory/not satisfactory), the SPICE method allows for evaluating the process on a fundamentally infinite scale. The SPICE method also allows for narrowing the scope of evaluation to include only the currently interesting processes. The SPICE method has been used as a basis for the relevant ISO/IEC standard No. 15504 “Information technology – Software process assessment”.
A.5.3 Project organisation
Every project consists of large amount of tasks. It is always easier to plan and implement projects if the entire project has been logically divided into main tasks and sub-tasks. The project can be structured on the basis of the following: • Objects; • Functions; • Activities. There isn't a right or a wrong approach here; often, mixed forms of structuring a project are applied. But there is a rule that the following must be taken into account when dividing the project into task packages: • Integrity of the project must be ensured; • No tasks can be overlapping; • Task packages must be stated with a good overview and must clearly differ from each other.
In preparing the structural plan of a project, the entire work volume must be determined, and this work volume must then be distributed among the members of the project team and the sub-contractors. Thus, it needs to be decided already in the planning stage what tasks will be performed via sub-contractors and what will be done with own means.
The members of the project team will have to perform all or part of the necessary tasks by themselves, depending on whether sub-contracting is used or not. The project manager has to provide the following information, in order for the tasks to be successfully distributed and the project team members to perform their tasks in due time: • Information about the specific task: Every task has to be explained with sufficient depth to the parties performing this task, and they also need to be shown what part the specific task has in the entire project; • Information about the work methods: The project manager has to explain the methods that should be used for performing this task; • Information about the work means: In many cases, the executors of the task also need to be explained what means should be used for the task. This is especially so if the task can be performed by using different means, but the quality requirements dictate the use of specific means; • Information about the deadlines: The executing parties need to be given the starting and ending deadlines of performing the task. At the same time, the relations of the task to other tasks and members of the project team need to be explained.
Work results of different members of the project team have to be co-ordinated, otherwise the individual solutions being integrated into the end result of the project may turn out to be incompatible with each other. The co-ordination of work results is especially important if many spatially separated sub-groups are involved in the project.
The following has to be co-ordinated: • Goals: Work results must be compared to the project goals whenever possible and it must be verified whether there are any deviations; • Alternatives: The solution must be compared to the alternatives in order to verify whether the selected solution is the best one; • Results of project parts: The results of different project parts depend on each other. This is why they have to be compared to each other and co-ordinated, in order to achieve a unified and homogeneous end result. Primarily, the suitability of the result of the project part into the general concept has to be verified.
Often, members of the project team are divided into smaller workgroups according to the logical structure of tasks. Such workgroups must be handled as parts of the project organisation. These parts make up the internal structure of the project organisation. Management structure of the project is a scheme of formal co-operation relationships, expressed as an original entwined complex or pattern of positions and relations. The formal structure of the project organisation represents job positions and their groups (sub-units) that are connected into an integral whole by formal legal relationships between them. This structure helps better understand the nature and role of the organisation and the problems related to it. There are following types of project organisations: • Pure project organisation; • Matrix-type project organisation; and • Project co-ordination.
With pure project organisation, the project is established so that it doesn't affect the existing functions and fields of the company. The project manager has the same rights and obligations as the manager of the relevant function or field and answers directly to the top-level management. The involved members of the project team are working only for the project. If the project team is created from employees of the company, then such employees are excused from their usual work responsibilities for the duration of the project. As this is often not possible, there are many cases where new people are hired.
With matrix-type project organisation, the project is established so that the project group is created on the basis of the existing employees of the company. Here, too, the project manager has the same rights and obligations as the manager of the relevant function or field and answers directly to the top-level management. Employees from all such fields and functions that the project is related to are involved in the project group.
With project co-ordination, the project manager is not answering directly to the top-level management. Instead, a co-ordinating unit is established in the company that deals with all active projects. Project managers establish continually changing workgroups for their projects. Employees are involved for short-term periods from the relevant sub-unit that has the necessary know-how for the specific task.
The project group can be unstructured or structured. The latter version can consist of project sub-groups or independent partial project groups.
Unstructured project group: In this case, the group develops the solution to the problem as a unified group, without establishing sub-units.
Project sub-groups: In case of larger projects with a wider scope it is useful to divide the project group into sub-groups, whose activities are co-ordinated by the following persons: • In a hierarchic project group, this is the project manager; • In a non-hierarchic project group, this is the dedicated co-ordinator, or the sub-groups co-ordinate their activities themselves via direct communication (in a smaller project).
Independent partial project groups: Several project groups with different staff are established for implementing one project, according to the project stages, and these project groups are independent from each other. This is a recommended approach in case of such projects that require very different qualities from the members of the group.
Distribution of areas of responsibility is a very important activity in organising a project. Many misunderstandings and discrepancies in projects are due to shortcomings in distribution of tasks and responsibilities. It is unavoidable that the entire work volume is divided into smaller parts in a project, and that the executors of these parts gather in groups according to this. Distribution of responsibilities and tasks is an unavoidable consequence and result of united activities and united goals. Distributing responsibilities means distributing the activities and actions resulting from the goals of the project, between the single persons and workgroups performing these activities and actions.
The advantages of a very precise distribution of areas of responsibility are as follows: • The employees are concentrated on their area of responsibility; • The motivation of the employees increases; • The progress of the project can be monitored better; • There is a higher probability of staying within the time schedule; • There is a higher probability of staying within the budget; • It is easier to ensure the quality of the result; • It is easier to assess what has been done already; • It is easier to take into account the individual capabilities and competencies of people; • People are learning faster from the experience gathered from projects.
The disadvantages of a very precise distribution of areas of responsibility are as follows: • The project organisation is less flexible; • The members of the project team are concentrating only on their own tasks and are less interested in the results of the entire project; • The extent of creativity lessens; • There is less probability of the synergy effect developing.
CUSTOMER Every project has a customer, someone who orders the project. This can be the management staff of the company itself, the manager of a department or the manager of a field. These are called customers inside the company and usually the projects are development projects of the company in this case. The other possibility is that the project is ordered from outside the company, by a person or another company. Regardless of whether the customer is from inside or from outside the company, the customer has certain tasks that are related to the following: • Presenting a project order; • Assigning a project manager (in case of a customer from inside the company); • Stating the main form of the project organisation (in case of a customer from inside the company); • Stating the decision-making rights; • Determining the milestones/stages of the project; • Stating the project priorities; • Decision-making at milestones; • Supporting the project manager. The customer should be able to determine what is the most important in case of the specific project – whether it is time, expenses, quality, environment-friendly solution, etc. Determining the hierarchy of priorities provides the project manager with the basis for making decisions in the planning stage of the project.
PROJECT MANAGER Project manager plans, manages and supervises the work of the project group from the viewpoints of the content, the personnel, the deadline and the budget.
Thus, the main tasks of the project manager are related to the following: • Planning the project; • Managing and co-ordinating the project; • Supervising the project.
Planning the project: This task of the project manager can be differentiated into short-term planning and long-term planning. Often, the system is used where the project plan is handed over to the project manager in a ready-made form. In this case, the task of the project manager is to implement the project. The only planning performed by the project manager then is detailed short-term planning on the basis of the given general project.
Such a system can be applied in companies where there is a separate unit for project planning. But even then it is recommended that the project manager of the specific project take part in the planning of the project. Of course, the project manager of the project needs to be known in this case. On the basis of the above stated it can be said that the preparing of detailed plans is always the task of the project manager, but the preparing of general plans may not be.
Managing and co-ordinating the project: In the course of managing and co-ordinating the project, the project manager has to do the following: • Monitor the following of the project plan; • Lead the subordinates; • Assign the members of the project group; • Perform the project activities in a competent way from the aspect of content and professional field; • Preparing the necessary means; • Informing people; • Establishing the necessary contacts; • Preparing decisions.
Supervising the project: In relation with supervising the project, the project manager has two tasks: • Verification, involving the following: • Verifying the implementing of the project; • Verifying the end result of the project; • Reporting: • The project manager reports to the customer of the project about the progress of implementing the project.
Project supervision is obligatory from the viewpoint of project management and for achieving the end result.
LEADING GROUP In case of external customers and large projects, a leading group of the project is often established. The tasks of the leading group are as follows: • Acting as a connecting element between the customer and the project team; • Dealing with general co-ordination of the process; • Acting as an initiator in setting goals and determining priorities; • Making preliminary decisions at milestones of the project; • Supporting the project group.
MEMBER OF THE PROJECT GROUP – SPECIALIST The tasks of the member of the project group are as follows: • Supporting the project with professional know-how; • Participating in situation analysis and in formulating detailed goals; • Participating in planning deadlines, resources and expenses; • Performing specific professional tasks; • Participating in assessing solutions; • Following the approved project plan. MAIN USER The tasks of the main user are as follows: • Acting as a connecting element between the end consumers and the project team; • Organising the preparing of the initial task; • Explaining the necessity and goals of the project in the organisation; • Facilitating the preparation of implementing the solution; • Registering problems accompanying the new application and forwarding the relevant information to the project manager.
END CONSUMER The tasks of the end consumer are as follows: • Providing own input to the initial task via describing own needs; • Notifying about all errors and problems during the implementation period.
The following example shows a plan of a consultation project, prepared using Microsoft Excel software. The result of the project was intended to be a prepared development plan of a tourism object, together with marketing strategy and analysis of feasibility and profitability. The Excel software was used because the customer had no project management software whatsoever and it is very important in projects that both parties, the customer and the developer, can exchange information freely.
December January February March Mon 3 10 17 24 31 7 14 21 28 4 11 18 25 3 10 17 24 31 Tue 4 11 18 25 1 8 15 22 29 5 12 19 26 4 11 18 25 1 Wed 5 12 19 26 2 9 16 23 30 6 13 20 27 5 12 19 26 2 Thu 6 13 20 27 3 10 17 24 31 7 14 21 28 6 13 20 27 3 Fri 7 14 21 28 4 11 18 25 1 8 15 22 29 7 14 21 28 4
Tasks Sat 8 15 22 29 5 12 19 26 2 9 16 23 1 8 15 22 29 5
Sun 9 16 23 30 6 13 20 27 3 10 17 24 2 9 16 23 30 6
Opening meeting, preparations DEVELOPMENT STRATEGY Description of the activity environment Reviewing the mansions Development concept of the Lihula Mansion and fortress hill Investment plan Discussion meeting for the development plan MARKETING STRATEGY Target groups Marketing goals Marketing strategy Activity plan and budget Discussion meeting for marketing ANALYSIS OF FEASIBILITY AND PROFITABILITY Activity model of the complex Economic profitability and sustainability of the project Socio-economic effect of the project Assessing the project's level of preparation Risk analysis of the project Discussion meeting for analysis of feasibility and profitability SUMMARIES AND INTRODUCTIONS Project end seminary Final formulation of the document Finishing the project, handing over the work
A.5.4 Project planning and supervision The techniques for determining deadlines for a project are important not only for planning of the project. These techniques are also used later in both planning and implementing of the project. The time schedules prepared as a result of determining deadlines facilitate monitoring the following of the overall time schedule of the project. All these techniques can be used for correcting project plans in the course of the project. The following units of measure can be used in determining deadlines and in preparing time schedules: • Work hour; • Work day; • Work week, etc.
The simplest technique for project planning and monitoring is a list. This technique means listing the tasks of a project on a single page. The duration of every task is stated beside the task. Then, beginning and ending deadlines are determined for every task, according to the logical progress of the entire project.
GANTT – This technique can be characterised as a simpler technique based on a line diagram. This technique was named after Henry Lawrence Gantt, who first used it for visualising the time duration of tasks. This method has significant advantages over the list technique, primarily because the durations of the tasks in time are visualised.
PLANNET – This technique (PLANningNETwork) is an enhancement of the previously described technique. One of the most significant disadvantages of the GANTT technique is the lack of dependencies, and this shortcoming has been eliminated in this technique. It is also shown where spare times are created.
PLANNET – This technique is often used in project planning, for the following reasons: • This method allows for a convincing optical and visual presentation of the progress of the project; • This method allows for showing buffer times and relations between tasks; • This technique can be applied with low labour and time resources; • The principles of this method are used in most project management software packages.
Planning network techniques were developed for planning large-scale projects, and all three techniques are based on the critical path method.
The critical path of a project consists of the events having the longest durations. Thus, the duration of the entire project is equal to the sum of durations of the critical path tasks. The tasks of the critical path have coinciding earliest and possible latest beginning times and also coinciding earliest and possible latest ending times.
The determining and clear differentiation of the critical path is necessary for the following reasons: • In order to know which tasks would affect the end deadline of the project in case of any time deviations of these tasks; • In order to determine the priorities of the project tasks; • In order to timely utilise measures for keeping the deadline of the entire project; • In order to spend less time on project supervision.
As the tasks belonging to the critical path do not have any spare time, every time deviation in these tasks affects the end deadline of the project. At the same time, the determining of the critical path tasks provides a good tool for ensuring the timely finishing of the project. If the implementers of the project know what tasks are critical from the viewpoint of the success of the project, then it is possible to monitor more closely the progress of these tasks. It does not guarantee the success of the project, but it gives a possibility to ensure it.
In regard with planning networks, two more terms have to be defined that are important for project management: • Event, and • Activity.
Event: Achieving the determined state or set goal.
Activity: All tasks performed in order to arrive from one event to the other.
In planning networks, a network of activities is prepared room events and activities, whereas different techniques use different ways for visualising these.
As defined above, the critical path is what determines the duration of the project. There is spare time for performing all other tasks. Knowing the critical path tasks and the amount of spare time for other tasks, it is possible to ensure optimum use of the project resources. This again allows for probable decrease of expenses, as the waiting times and stoppage times decrease.
On the basis of the above stated, all plans should be analysed after preparing them in project planning, in order to determine the existing buffer times. In case of complex projects where there are many possible paths, all paths need to be reviewed from the beginning to the end in order to determine the earliest beginning. In order to determine the latest possible ending, the paths have to be followed in the reverse order, i.e. from the end to the beginning. Also, it is recommended to prepare a separate list of tasks having spare time, stating both the tasks and their spare times as a table. Such a table allows for fast decision-making regarding any adjustments of the project plan.
Project management software helps the project manager primarily in project planning and supervision. On the other hand, the capabilities of even the most advanced software are limited. The following table shows where software can help the project manager and where it cannot.
Project management software helps in the following: Project management software does not help in the following: - Managing large amounts of data; - Working with standard plans; - Making changes in the project plan; - Optimising the project plan; - Analysing the data of the actual situation and comparing it with the plans; - Simulating the effect of a change; - Visualising the project structure and showing the relations between activities; - Exchanging information between project participants. - Defining the goal of the project; - Establishing the project organisation; - Structuring the project into task packages; - Determining the time spent for a task; - Determining the dependencies between specific tasks; - Conducting discussion meetings of the team; - Solving problems related to the human side of the project.
Most of the project management software packages consist of the following modules: • The module for planning tasks and deadlines; • The module for planning resources (people, means); • The module for cost planning; • The module for monitoring the progress of the project.
A.5.5 Project evaluation As all projects intended for solving problems require the use of extraordinary resources, it is very important that the following is evaluated: • The feasibility of different solutions, and • The risks associated with the solutions.
Feasibility evaluation In this stage, the feasibility of the proposed solution to the problem is determined. Of course, no feasibility evaluation is needed in case of smaller and common problems. On the other hand, if the solutions are innovative or rarely used, the feasibility analysis is definitely needed.
It is especially important to evaluate the feasibility of projects related to the following fields: • Technology: The technical feasibility of the project is evaluated by using calculations, norms, models, etc.; • Environment: The environmental effect of the tasks performed in the course of the project and the system applied after the project, the conformance of the end result of the project to the various environment protection norms, etc. is evaluated; • Economy: The economic feasibility of the project is evaluated.
Risk evaluation Risks can be divided into known and unknown risks. In order for the project to progress successfully, it is necessary that the majority of risks related to the implementation of the project are known to the implementers of the project. Also, it has to be taken into account that different solutions have different risks. Even in case of only one possible solution to the problem, risk evaluation has to be performed. By knowing the possible problems related to the project from early on, timely action is possible and relevant measures can be taken.
Project risk can be defined as an event that can endanger the successful implementation of the project by appearing.
For example, a change of a top-level manager can be a risk for some organisational project. The new manager can have an entirely different view on the problem and the ways of solving it, so the project can be cancelled. Usually, this kind of risk cannot be avoided. On the other hand, cancellation of the project can be avoided if the justification and activity plan of the project are very correctly and comprehensively formulated.
Risk analysis of a project includes the following aspects: • Risk sources: Risk sources can be very different, depending on the project. They can be divided into internal end external risk sources. The above stated example entailed a risk source from inside the company. Risk sources from outside the company can be many different interested parties, forces of nature, the economic environment, etc.; • Risk types: The main types of risks affecting the success of a project are as follows: • Economical risks (reception of payments, changes in the value of money, etc.); • Technical risks (technical solutions of the project and their implementation); • Legal risks (contracts and laws); • Personnel risks (insufficient qualification of the personnel, illnesses); • risk evaluation: The probabilities of the different risks becoming true and also their effects are different. This is why risks should be evaluated according to their importance. The following properties of risks should be evaluated: • The probability of the risk becoming true; • The effect of the risk becoming true; • The efficiency of countermeasures.
A kind of a rated list of risks should be prepared on the basis of risk evaluation, showing the probabilities of the risks becoming true and their relevant effects on the project.
The success of the project depends directly on the skills, activities and diligence of the planner and also on time spent by the planner on planning. In the course of project planning, a specific model is created that describes the activities and resources needed for achieving the required results. The goal of planning is to create a comprehensive overview of the entire project. The prepared project plan must allow the following: • Distributing project resources; • Avoiding overloads and lack of use; • Ensuring a constant work speed during the project; • Being aware of the critical tasks; • Preventing risks; • Managing changes taking place in the relevant field of activity.
In case of smaller projects the planning stage is sometimes left out, as the initial data gathered in the course of generating, developing and preliminary research of ideas is used to directly enter the implementation stage. But the successful conclusion of such projects is related to high risks because the planning stage is where it is precisely determined what, when and how should be done. In planning, all tasks and resources needed for achieving the set goals are determined.
The project plan prepared as a result of the planning stage must give a systematic and logical presentation of the project's contents and the contribution needed (money, time, technology, etc.). This presentation should be laconic, clear and unambiguously understandable for everyone. The plan must be prepared in such a way that whoever reads it gets the correct understanding of the project.
Project plan can be used as following: • Basis and support for the leading group in making decisions; • Tool for the project manager for managing work; • Basis for the leading group and the project manager for supervision of the project's progress; • Archive material for use as support and background information for coming projects or as just an informative tool.
The prepared project plan is used as a basis for planning further activities in the implementation stage of the project. This allows for better consideration of such circumstances and changes that could not be foreseen in the planning stage. A good project plan is flexible, meaning that it can be changed according to changes taking place in the environment or in the limitations.
Even the best project planning cannot always guarantee that everything goes as planned during project management. Often tasks are began or ended too late, the budget is exceeded, and the achieved quality is not what was planned initially. Also, different interest groups can significantly affect the progress of the project, whereas such effect can be positive or negative.
Besides interest groups, there are also many components of the external environment that can negatively affect the progress of the project.
In order to correctly evaluate the effect of unforeseen changes on the progress of the entire project, the following questions have to be answered: 1. What is the cause of the problem that has brought about the change? 2. Is it possible to solve the problem? 3. Does this problem have an effect on other activities of the project as well? 4. Are any changes necessary to be made in project management? 5. How can similar problems be avoided in the future?
The causes of problems bringing about changes must be analysed together with the performers of the relevant tasks. The structural plan of the project has to be used for evaluating the possible effect of the problem on other tasks of the project, because the structural plan states the relations between different task packages. If project management software is used for project planning, then it is easy to simulate the effect of the problem on deadlines and expenses.
When solving a problem, the existing priorities must be taken into account. On the other hand, it is very often necessary to determine new priorities or to change the hierarchy of existing priorities when solving problems. For example, the priorities of expenses, deadlines and quality can come to have a different order of importance.
It is possible to develop problem elimination strategies for main problematic and change-causing fields of the project (deadline changes, increase of expenses, work volumes, quality).
In case of such problems appearing that require some changes to be made, the reaction in project management has to be as quick as possible, because the later the changes are made, the more expensive these changes are. In order to ensure success of applied measures, the activities needed for eliminating the problem must be supervised especially tightly, otherwise the chain of planned changes can break at one point or be implemented inefficiently.
After the project plan and the time schedule are prepared, the preparation of budget can be started. This cannot be initiated earlier because all decisions made in planning have some kind of effect on the amount of money needed for implementing the project. For example, the expenses of one and the same task being implemented in winter or in summer can be entirely different. Also, the means used for implementation of the project, the experts involved, etc. can have an impact on the amount of expenses needed.
Information for preparing the project budget can be gathered from various price lists, price queries, earlier similar projects, etc.
Cost types of a project Cost types of a project can be divided in several different ways. The most commonly used classifications are as follows: a) Direct and indirect expenses: Direct expenses are those that can be documented and that are directly needed for implementing the project. These expenses must be accounted precisely during the project. Direct expenses can be salaries of the project manager and the executors of tasks, accountancy expenses, expenses on materials, sub-contracting expenses, etc.;
Indirect expenses are those that cannot be registered precisely. These are often also called general expenses. For example, telephone costs can be considered such expenses. It is clear that this communication channel will be used in the course of implementing the project, but it would be pointless to try to separate telephone calls related to the project from other work-related telephone calls. Indirect expenses are agreed about as a percentage of the overall cost of the project. As a rule, the financers have stated precisely what kind of expenses can be considered indirect. Usually, these are various general organisational expenses, because these are the most difficult to determine as exact direct expenses. The percentage agreed for the indirect expenses depends on the rules stated by the financer;
b) Expenses for project implementation and expenses for applying the new system: In this classification, the expenses for project implementation are considered to be one-time salary expenses of the involved employees during the project implementation;
The expenses of the system are considered to be those that are incurred in the course of applying the system developed as a result of the project. These expenses can be further divided as follows: • One-time costs; • Fixed costs.
One-time costs of the system being applied are considered to be all those expenses that are incurred in the course of creating the system developed as a result of the project and not included in the project expenses.
Fixed costs of the system being applied are considered to be those expenses that are incurred in the course of operating the system developed as a result of the project.
The following example can be used for illustrating the different cost types of a project. For example, a company decides to exchange the entire hardware and software used in the company and to order a new information technology solution.
In this case, the following are considered to be project expenses: • Expenses related to creating the new information system; • Expenses related to hardware installation and software installation; • Expenses related to user training. The following are considered to be one-time costs of the system being applied: • The price paid for the hardware and the software. The following are considered to be fixed costs of the system being applied: • The expenses incurred in the course of operating the information system (these are primarily maintenance expenses and expenses on updates of hardware and software).
Both the project expenses and the system expenses are very important for implementing the planned project. On the other hand it should be said that in some projects only project implementation expenses are involved, because not every project results in a new system or a technical solution.
This can be illustrated by the project “Supplementing the existing information system with a warehouse management module”. In this case, there are project implementation expenses, but no new system is created and thus there are no expenses related to this.
Cost planning of a project is important, because it allows the following: • Getting an overview about the expenses of individual parts of the project and the expenses of the entire project; • Determining the incurrence and changes of expenses in time; • Preparing the plan for needed monetary resources; • Evaluating the profitability of the project; • Making project management decisions.
If it has not been determined how to plan the cost division in the project budget, then it would be reasonable to divide expenses into at least four cost types: • Personnel expenses: Personnel expenses are considered to be the salary expenses of the employees involved in the project, together with all relevant taxes; • Material expenses: This cost type is related to all such means and measures of the project that are necessary for implementing the project; • Capital expenses: These expenses are related to the following: - Depreciation of the project means; - Rental; and - Interests. • Sub-contracting expenses: Sub-contracting expenses of a project are considered to be the salary expenses of people involved from outside the organisation and the expenses of ordering services from outside the organisation.
For an efficient cost management, a cost plan has to be prepared for all individual project parts and cost types, together with the plan for project cash flows.
After approving the project, the cost plan is accepted as the project budget. According to the planning, the project budget states the main expense articles for every project part.
Importance of cost planning A cost plan is important for primarily the following parties: • The financer of the project; • The management of the organisation; • The project manager.
Cost planning allows the financer of the project to ensure the timely availability of the necessary monetary resources.
The management of the organisation uses the cost plan as one of the bases for decision-making.
The project manager uses the cost budget as a tool for project supervision and verification.
It must be noted here that often the management of the organisation is also the financer of the project, usually in case of development projects within the organisation. Organisations where project management method is used extensively should definitely establish a unified system for cost planning of projects and for project planning in general. This would provide the following benefits: • Allows for an easier comparison of projects in the initial stage where the decision is made about what projects to implement; • Allows for an easier comparison of projects after the end of a project where the results of projects are evaluated.
Cost planning methods Very different methods can be used for determining the amounts of expenses needed, depending on the cost types.
In many cases, the following methods can be used: • Re-calculation: The cost budget of a project is prepared on the basis of some earlier finished project, the costs of which are precisely known. For example, a final cost report of a previous project can be used for determining the personnel expenses for different tasks. The relevant expenses stated in the previous cost report are re-calculated according to the ratio between the work volumes of the previous project and the new project; • Comparison: The new project is compared with a similar project successfully implemented and finished earlier. The comparison is used as a basis for evaluating the feasibility of the new project; • Evaluation: This method can be used if the planner of the project has very good knowledge about all expenses to be incurred in the course of the project. In this case, the project manager can determine the total cost of the project by evaluating it him/herself or by using the help of various experts; • Gathering price quotes: The project manager takes price quotes from all parties involved with the following: - Gathering the means for the project; - Assigning the personnel involved in the project; - Supplying the materials, etc.; • A combination of the above stated methods: The above stated methods can be combined and different methods are used in cost planning for different cost types or project parts.
Whenever the project manager can, he/she should prefer the last but one method in planning, because this allows for preparing the most detailed cost budget. On the other hand, this method is not possible to use in all projects.
A budget should be prepared as realistically as possible, but the expenses should be planned with some spare. The goal of the budget cannot be in achieving the least expenses; it has to be the achievement of the main goal of the project in the best possible way.
The most common mistakes made in preparing a project budget are as follows: • Taxes are forgotten when planning salary expenses; • The monetary part and the non-monetary part of expenses are stated incorrectly in the budget; • The budget is “inflated”; • Expenses made before the correct time are presented; • The budget includes expenses not related to the project; • The budget is made unreasonably tight.
The main goal of a project is to achieve its end result and to use these results. This is true regardless of the type of project. Thus, finishing a project is one of the most important stages in project work. A correctly finished project allows the experiences gathered from it to be used in other undertakings. Finishing a project is also important from the economic viewpoint. The company is able to present the final accounts to the customer. In many projects, the ownership right of the result of the project is transferred to the end user as the project is finished, and often the project is only then starting to pay itself off.
A well-planned finishing of the project quickens the final touches and handover of the end result of the project and ensures its quality. The experiences received from the project (both good and bad experiences) are collected and registered in the final report for further development and management of project activities in the company. Upon finishing a project, an evaluation must be made about what has been achieved, analysing the progress, activities, effects and results of the project.
Evaluation is necessary for providing feedback to the project's implementers and for providing analysis materials for its financers. Project evaluation can be performed on two levels, evaluating the following: • The progress, i.e. the process of the project; • The result of the project.
Evaluating the process The goals of evaluating the progress, i.e. the process of the project are as follows: • Analysing whether the project functioned smoothly, whether the project activities were performed smoothly and according to plans; • Analysing the quality of the information and communication provided by the project group and exchanged between the project group and the customer; • Analysing the quality of the project activities; • Evaluating the content development of the project.
The following questions have to be answered in process evaluation: • What were the strong sides and the weak sides in everyday activities of the project? • How can the activities in future projects be enhanced and improved in order to avoid the mistakes made in this project?
Evaluating the result The result of a project is a physical object, a phenomenon, a psychological state or generally any object that is created in the course of the project. Project results can be divided into intermediate results (e.g. scheme of a system) and end results (a ready-made system).
Evaluation of the results of a project is based on the initial task of the project. The end result of the project is compared with the set goal, whereas it is especially important to state all deviations from the planned result.
Results can be evaluated by answering the following questions: • To what extent was the result conforming to the planned goal? • If there were deviations, then what was the extent of these deviations when compared to the plans? • Was the project goal changed in the course of the project? • What were the reasons for changing the goal? • To what extent does the result conform to the changed goal? • Were the stated quality requirements fulfilled? • Were the deviations from the planned quality registered? • Were the quality management measures taken in due time?
The end results of most projects can be adequately evaluated without great problems. But the evaluation of intermediate results is problematic in case of many projects.
The latter is easy in specific implementation projects where a tangible result is produced, like constructing a house. Here it is possible to evaluate entirely unambiguously the extent of the works performed, the quality of the works, and the extent of the works still to be done.
But in many development projects and especially in IT development projects the intermediate results are difficult to evaluate. Both the result and its quality, and also the extent of the works to still be done are not easy to evaluate. This is why in many cases the result and its quality can be evaluated only in the end of the project. This requires a high level of objectivity from the verifiers and evaluators, otherwise the evaluations can be wrong and the work motivation of those evaluated can drop significantly.
A.5.6 Project management and contracts In classic approaches, IT project consists of the following stages: • Preliminary analysis and selection; • Analysis; • Project design; • Project activities; • Implementation of the result; • Use of the result.
But the sequence of these stages is certainly not required to be linear. The best way is to have these stages in parallel or in repeated cycles. The best situation is where the developer can handle all these stages, instead of every stage being handled by a separate narrow specialist. The contract is one of the most important documents in projects. A formal contract signed between the customer and the implementer is what protects both parties in case of pretensions between the parties. It can be said that a project is managed with a contract, and this is not an exaggeration. The customer needs the result of the project for his/her main activities. An initial task is presented to the implementer, and there are limitations that have to be considered when implementing this initial task. The implementer can use sub-contractors for performing the necessary works. This also requires contracts to be signed, because there are two parties again whose interests have to be protected. In some projects the contract is signed but it will not be needed. These are projects where everything goes well and there are no disputes between the parties. In such cases it can seem that the signing of the contract is unnecessary, but in reality this is not so. Projects entail risks and the real value of a contract becomes apparent if something unforeseen happens or if there are disputes between the parties. A contract regulates the relationships between the parties of the project. The nature of the project, i.e. the project's goal and its results are stated for each party. A contract also states the criteria of evaluating the quality of the project's implementation. A contract being signed at the initiation of a project is a document that states the distribution of the following among the parties: • Obligations (activities, rights); • Liabilities (sanctions, means of influence); • Risks (possible dangers). The price of the contract is the price for these three components. A contract is an agreement of one party, the implementer, obliging to perform the stated works ordered by the customer, at the implementer's risk and using the materials provided by the implementer or by the customer, and the other party, the customer, obliging to receive the performed works and to pay for these according to the conditions stated in the contract. A contract describes the procedures and relationships regarding the project works, the general accepted principles, and the type solutions for behaviour in different situations. A contract must definitely state the possible behaviour in case of conflict situations. As a rule, the object of a contract is the result of the work performed by the implementer, not the work itself. The obligatory elements of every contract signed at the beginning of any project are as follows: • Requisites of the customer and the implementer (names, legal forms, addresses, registration numbers and license numbers); • Description of the object of the contract, i.e. the project goal; • The deadline for finishing the project; • The work methods for performing the activities necessary for reaching the goal; • Obligations of both parties, the customer and the implementer; • Liabilities of both parties; • Qualification of the performers of the works; • The quality management system; • The sanctions for an incorrect fulfilment of the contract; • The procedures of project management.
Intermediate deadlines and overviews of the project are used for ensuring that the actual progress of the project conforms to the plans made earlier. During project management, the project manager must be active instead of reactive to events, because only so is it possible to affect the progress of the project and to ensure the following of the time schedules and results schedules.
The more time the project manager and the project team spend on planning and implementing the individual measures for ensuring the following of the project schedule, the higher is the quality of these measures. Good planning also ensures that there are more options for reaction in case of deviations from plans.
The goal of planning intermediate evaluations of the project is to establish a proactive warning system that shows as early as possible and as exactly as possible when it is necessary to react to deviations from plans.
Often, percentage of completeness is used for evaluating the progress of the project. This figure is intended for helping to evaluate how many percent of a task is performed. This is a very good numerical figure for using in reports, as it is relatively well understood by all evaluators.
PT (time) = time spent until the moment of evaluation x 100/estimated total time to be spent
PT (work volume) = volume of works performed until the moment of evaluation x 100/estimated total work volume necessary
Use of percentage expression in evaluating a current result is problematic if it is not supported by other figures. The question “How many percent of the work is done?” often gets the answer “90%”. Experienced project managers know that “90% done” does not equal “10% still to be done”. This is a purely psychological problem. The figure of 90%, seemingly very precise at the first glance, is used here to denote that a very large part of the work is completed and there is still some part that needs to be done. As a conclusion it can be said that percentage of completion is an interesting figure that can be calculated easily but only for a certain kind of projects. Unfortunately, IT projects are not among such, because it is an extremely complex task to determine precisely the amount of work done at a certain point.
In order to correctly interpret the data gathered in the course of an intermediate evaluation of the project, these data have to be analysed comprehensively. The goal here is to determine the effect of the present situation on what was planned earlier. There are several methods for evaluating this effect. The easiest and at the same time the most commonly used of these is the so-called “is/should be” method. This means comparing what is achieved by the current time with what was planned to be achieved by that time. This is used as a basis for evaluating the effect of deviations on the further progress of the project.
If the analysis of the data has shown that problems with expenses, deadlines, quality, etc. can emerge in the process of further development of the project, then measures must be planned for eliminating the possible problems.
In case of endangered deadlines, the following measures can be used: • Shortening the durations of the critical path tasks: Either an increase of efficiency (involving an external specialist, training, better organisation of the order of tasks, etc.) or an increase of resources used (overtime work, additional labour force, priority changes, etc.) can be used for that; • Decreasing the planned work volumes: The work volume of some tasks or the entire project is decreased. This means that with the same amount of personnel, the duration of the project is shortened. This measure can be used if the project has a large planned work volume that was stated as too large in the initial planning; • Changing the order of the tasks to be done: While reviewing the progress of the project, the tasks having been planned for performing one after another are changed to be performed in parallel or partially parallel to each other. This can be used for tasks that do not require the entire personnel and where technology allows this; • Changing the deadlines: This means changing the deadlines of individual milestones or, if possible, the entire project. This measure can be used if the relevant agreement can be reached with the customer and the circumstances causing the change in deadlines are independent from the project group.
In case of larger expenses and necessary work volumes, the following of the above stated measures can be used: • More efficient performance of tasks; • Decreasing the planned work volume.
The selection of the measures to be used depends on two important factors: • Expenses: How much additional time, labour force and money resources are needed for using this measure? • Effects: What are the effects of the specific measure on deadlines, budget and quality?
In order to select the correct measure, different measures have to be compared from the viewpoints of both expenses and effects.
A.5.7 Quality management and updating of information systems The word “quality” stems from the Latin word “qualitas” and means a property, a quality, a value or a goodness. Usually, quality is considered to be the technical properties of a product, i.e. the set of all properties that can be measured and objectively recorded. This approach is based on the viewpoint of the producer and shows the extent to which the producer has been able to make the product conform to the specifications and norms regarding this product. If some properties of the specific product are not conformant to the norms regarding the product, then this product is considered to be of low quality. Like products, so also projects cannot be evaluated by using only one property as the basis of the quality assessment. The definition of quality has to be expanded, taking into account the customer-based aspects of determining the quality. Quality evaluation of a project is always centred on the customer and his/her perceptions and requirements about the end result of the project. It is also important to consider how the customer has perceived this quality during the implementation of the project. Thus, it can be said that the quality of a project is largely a subjective measurement that depends on the customer.
On the basis of the above stated, the quality of a project can be defined as the conformance of the end result of the project to the requirements stated by the customer and to the generally accepted norms.
Based on this definition, there can be certain cases where the end result of the project can be fully conformant to all valid norms but still have low quality. This is so if the customer has stated higher quality norms than the generally accepted norms.
In most cases the fact of the software being completed according to the deadline or with a delay of a couple of weeks is soon forgotten. The quality of the software not conforming to the requirements of the customer causes a long-term dissatisfaction.
Thus, quality is more important than any other measurement. In order to ensure a good quality, a written quality management plan is prepared. The goal of quality planning is to plan those project activities that ensure the quality conforming to the stated goal. At the same time, a quality management plan shows the customer that the company is capable of fulfilling the obligations taken on with the contract.
The quality management plan states the quality goals, describes the project risks and orders these risks according to their importance. It also states the order of importance for the different quality management measures.
Quality management planning involves the stating of quality criteria for the end result of the project, and it is used as a basis for quality verification later on.
Quality criteria can be divided as follows: • Quantitative quality criteria: For example, duration of faults, work speed, etc.; • Qualitative quality criteria: For example, user-friendliness, decent presentation, etc.
The following can be used as keywords characterising the quality of the end result of a project: • User-friendliness; • Ease of maintenance; • Frequency of faults; • Functionality; • Efficiency; • Speed; • Economic properties, etc.
One of the most commonly used methods in quality evaluation is the method of dividing the life cycle of the product into two parts: production and use. As a rule, higher quality in production brings about higher costs, but higher quality in use brings about lower costs. This is exactly the same with most IT projects. In order to find the right quality level, the costs of the life cycle of the product have to be summed up and the quality level has to be selected so that the total costs are the lowest. The quality level determined this way can be considered optimal quality.
Inefficient quality management can lead to a situation where the optimal quality is determined on the basis of the total costs of the product’s life cycle, but the expected cost of the project becomes significantly higher. This is due to additional quality management works that need to be performed in the course of the project or during the use of the system, as additional works bring about additional expenses. In the end, the result of inefficient quality management is a not satisfied customer and a deterioration of the company’s reputation. All this naturally brings about a decrease in profits.
Quality management is possible only if quality criteria have been clearly stated. Then, quality is considered to be the conformance to these criteria. In case of complex products and services, including IT, it is very difficult to verify the conformance to all quality parameters. This is why it is important that the development process is easy to monitor and conforms to specific criteria.
An information technology project consists of very different components that all affect the quality of the end result and must all be objects of quality management. These components can be the hardware and software used, the development process as a whole, the project documentation, the qualification of implementers, and the methods of performing the works.
In most information technology projects, the following needs to be dealt with in order to achieve a high-quality result: • Searching and documenting errors; • Testing the source code; • Technical inspection; • Testing the integrity; • Testing the system.
In case of especially complex software systems beta testing is also needed, with experts from outside the company, customers or the general public acting as testers.
Standards can be divided as follows: • Official standards (approved by an accepted standardisation organisation); • Industry standards, i.e. de facto standards (may not be officially approved, but are commonly used); • Technical framework standards (sets of standards, instructions for using these); • State recommendations (typically reflect the viewpoint of the State as a customer); • Internal standards of a company.
Standardisation of IT equipment and systems in a company ensures a good compatibility and reliability of different parts of the system and allows for managing the entire system more efficiently (faster and with lower cost).
The advantages of using internal standards are as follows: • Minimising expenses; • Components can be exchanged; • Minimising the expenses on component compatibility (no need for interfaces); • Simpler and better procedures (known well-functioning procedures can be taken over from other companies); • Quality management.
When creating internal standards, it is recommended to use them as much and as early as needed and as little and as late as possible.
International IT standards can be used as a basis for internal standards of a company. Today there are hundreds of standards regarding terminology, system life cycle as a whole, different development stages, programming languages and methods, project management and work procedures, quality management, documenting, security, reliability.
Usually the goal of implementing an IT standard in a company is to improve the work procedures or to give the customers a signal of a good level.
Quality management can be performed in a variety of ways, starting with implementing simple principles and ending with complex quality management systems supported by the relevant software.
The international standard for software quality evaluation ISO/IEC(9126) has two levels, and states the main quality criteria and also sub-criteria for every criteria, as follows: • Functionality (conformance to tasks – whether all functions are available; precision; compatibility with other systems; conformance to norms, e.g. laws, security); • Reliability (completeness – the frequency of faults; fault tolerance – reaction to faults in the outside environment; restorability – how difficult is it to start working again in case of a fault); • Efficiency (time efficiency, resource efficiency); • Usability (conceptual clarity; ease of learning; comfort of using); • Maintainability (ease of analysing – how difficult is it to find the place for a change; ease of changing – how difficult is it to implement a change; stability – how profound is the effect of changes on the system; ease of testing); • Transferability (adaptability – can it be transferred; ease of installation – how hard is it to transfer; conformance to norms; ease of replacing).
Also, systems used in quality competitions and prize awarding can be used for quality evaluation. The most well-known of such systems are EFQM (The European Quality Award) in Europe and the Malcolm Baldridge award (The Malcolm Baldridge National Award for Quality) in the USA. The former of these systems measures the following quality components: 1) Management – 10%; 2) Company policy and strategy – 8%; 3) Personnel management – 18%/2 = 9% (components 2 and 7 give a total of 18%); 4) Gathering and use of resources – 9%; 5) Processes – 14%; 6) User satisfaction (evaluation) – 20%; 7) Satisfaction among the employees of the company – 18%/2; 8) Effect on the society – 6%; 9) Business results – 15%.
The system of the Malcolm Baldridge award takes into account the following factors (the number in parentheses is the maximum possible amount of points, thus also the level of importance in the entire quality evaluation): 1) Management (100); 2) Quality information and its analysis (60); 3) Strategic planning of quality (90); 4) Involvement of employees (150); 5) Quality assurance (150); 6) Quality results (150); 7) Customer satisfaction (300).
Also, the model of maturity of the software process (Capability Maturity Model – CMM) can be used for evaluating quality management. CMM method states five levels of maturity of a software process, depending on the level of realisation of certain key processes: • Level 1: chaotic and unpredictable, high risk level (70%); processes are not determined and the success of software development depends on efforts of individual people; • Level 2: there is a constant level of project fulfilment, without any significant fluctuations from project to project (15%); main project management techniques are used for monitoring expenses, time schedule and functionality; • Level 3: improvement of project expenses, time schedule and quality in further projects (10%); the software development process is documented, standardised and integrated into a unified development process of the entire organisation; • Level 4: significant improvement of one or several parameters in further projects (5%); detailed measurements are performed about the software development process and the product quality, and these measurements are used for ensuring a continuing increase of the levels of both the former and the latter; • Level 5: optimum level has been reached for virtually all parameters (1%); continual quantitative feedback is received from the process; innovative technologies are tested and implemented.
The standards of the IT field are approved by the leading standard-making organisation IEEE, where annually nearly 1,000 standards are established for various fields like electricity, biomedicine, nanotechnology, telecommunication, information technology, etc. The quality of an IT project or an information system project can also be evaluated via customer satisfaction. The result of the project can be handed over to the customer in due time and precisely in the configuration that the customer wished, but if the preparation of the initial task did not take into account the actual needs of the customer, then the project can still bring about customer dissatisfaction and the work of creating a system cannot be said to be of high quality.
Thus, every project manager and especially a project manager of an IT project almost always has the following question to answer: whether to do what the customer wants or to do what the customer needs. Of course, the only correct answer to this is to do what the customer needs, because this is the only way to ensure customer satisfaction and to be able to say that the work done is of high quality. Often, the problem is that the customer is not a specialist of the IT field and has only an indefinite idea of what the possibilities of IT are and how the new information system could support his/her business. This is where the project manager needs to assume the leading role in the initial stage of the project and to very comprehensively determine what the customer needs. This is the first but very important step towards a high-quality result.
If the offered solution is based on the needs of the customer, but has the following problems as well: • Difficult to use; • Not secure; • Full of errors that hinder normal work with the solution; • Difficult to learn, etc., then such an end result of the project cannot be said to be of high quality in any way. All the above stated problems affect the satisfaction and quality assessment of the customer in a negative way.
Quality management is usually orientated towards achieving the long-term strategic goals of the organisation. Quality management goals (for example, improvement of the internal work procedures or achieving some quality certificate) and quality policy are planned on the basis of the company strategy. Quality management method is selected according to the goals. This means that the task of the quality manager is to deal with the entire company, whereas the project manager deals with a project or projects. While the activities of the quality manager are mainly directed inside the company, the activities of the project manager can be directed both inside the company (a development project within the company) and outside the company (fulfilling an order of an external customer).
Quality manager Project manager Manages the implementation of quality management system Manages a project or projects Verifies the conformance of the prepared quality management system documents and their amendments to the overall goals of the company Verifies the conformance of the project documentation and its amendments to the goals of the project Co-ordinates the quality management system documents before presenting these for approval Co-ordinates the project plans with the customer and the management of own company before starting the project Manages and supports work with quality plans Works with the project plan in the stages of both planning and implementing the project Develops the quality information system Develops the system for gathering and distribution of information for the project Plans internal quality audits and supports internal auditors in preparing and conducting audits Plans and implements the internal control of the project Reviews, evaluates and prepares necessary information for presenting to the management of the company for their review Analyses the data related to project implementation and prepares the decisions to be made at milestones of the project Manages the continuous improvement process of the quality management system Manages the recording of the information gathered from the project, so that the received experience could be used for better management of future projects Plans and implements the activities for increasing awareness about the quality management system in the company If necessary, then plans the measures for increasing the qualification level of the project participants Informing the manager of the company immediately about any circumstances that make it impossible to fulfil work obligations Informing the manager of the company and the customer immediately about any circumstances that could hinder the successful finishing of the project
Software testing is divided into static testing and dynamic testing. The main task of static testing is searching for errors in the early stages of design and specification of the program. Static testing also allows for verifying such properties of the system like e.g. maintainability, reliability, analysability.
Static testing can significantly reduce the expenses and time needed for software development. On the other hand it has to be remembered that static testing does not replace dynamic testing and there is no guarantee that software, having passed static testing, works faultlessly. The techniques of static testing are usually divided as follows: • Static analyses: o Analysis of data flows; o Cyclomatic complexity; o Analysis of command flows; • Reviews: o Unofficial review; o Technical review; o Comprehensive review; o Inspection.
The techniques of static analysis provide the software developers with information about such errors as unusable program code, unassigned variables, etc.
Dynamic testing techniques are divided as follows: • Functional testing; • Structural testing.
Functional testing techniques are also known as so-called Black Box technique and input/output testing techniques, because with these techniques, the tester is interested not in the software itself but only in inputs and outputs. The tester does not have to know or have knowledge about the program code and its structure; the tester concentrates on testing the functionality of the software, finding the answer to the question of what the software does, not how it does it.
The software component testing standard BS7925-2 defines the following Black Box testing techniques: • Equivalence Partitioning; • Boundary Value Analysis; • State transition Testing; • Error Guessing; • Syntax Testing; • Random Testing.
With structural testing techniques, tests are based on the internal structure of the software. These techniques are also called White Box techniques, because with these tests the tester has to have knowledge about how the software is implemented and how it works. Generally, these techniques are used by the software developers themselves. Structural testing techniques are typical module testing techniques where only parts of the software system are tested. Structural testing techniques are divided as follows: • Coverage testing: o Statement coverage; o Branch and decision coverage; • Data flows testing.
Functional testing techniques can be used in all testing stages, starting with component testing and ending with approval tests conducted by the end user. As every component form can be considered a different part of the system structure, we can consider the component itself as a “black box” in component testing, so that tests are based on functionality, not structure of the component.
Similarly it can be said that structural testing techniques can be used in all testing stages. In practice, these techniques are used in testing components and integration.
7.1. Which of the following categories includes the Boundary Value Analysis: Static software testing techniques; Structural testing techniques; Functional testing techniques. X 7.2. Which of the following is the role of a project manager? Developing quality information system; Planning and implementing the internal control of the project X Managing the continuous improvement process of the quality management system. 7.3. Which of the following abbreviations is used to denote a software process evaluation method? SPICE X; IEEE; GANTT. 7.4. Which of the following statements is true? Development projects are less unique than implementation projects; Implementation projects are less unique than development projects X; Neither type of projects is unique. 7.5. Which of the following is the correct number of main elements of project management: 9 X; 10; 11. 7.6. Which of the following is true? The logic of the Iron Triangle is valid: For hardware purchases only; For software development only; In both cases X. 7.7. Which of the following parties needs the cost plan of a project? The financer, i.e. the customer of the project; The management of the company; The project manager; Everyone X. 7.8. Which of the following activities is facilitated by project management software: Optimising the project plan X; Determining the time spent for performing a task; Defining the goals of the project. 7.9. Which of the following elements is not an obligatory part of a contract: Obligations of both parties, the customer and the implementer; Project management procedures; Methods for evaluating work volumes X.