Effective processes of initiating a software project at least half determine its future success. Insufficient attention to this particular phase of the project inevitably leads to significant problems in the planning, implementation and completion of the project.
Initiation consists of processes that facilitate the formal authorization of the start of a new project or phase of a project. Initiation processes are often performed outside the project and involve organizational, programmatic, or portfolio processes. The initiation process refines the initial description of the content and resources that the organization plans to invest. This step also selects a project manager, if he is not already appointed, and documents the initial assumptions and constraints. This information is recorded in the Project Charter and, if approved, the project is officially authorized.
The project charter is a document issued by the initiator or sponsor of the project, which formally legitimizes the existence of the project and gives the project manager the authority to use organizational resources in project operations.
In American practice, this document is more often called the Project Concept. A concept (from the Latin conceptio - understanding, system), a certain way of understanding, interpreting any object, phenomenon, process, the main point of view on the subject, etc., a guiding idea for their systematic coverage.
In a company that decides to start a software development project, there should be a single system of criteria for assessing its significance. The system of criteria should allow you to choose the most priority for the company from a variety of possible projects for implementation.
The priority of any project should be determined on the basis of an assessment of its three characteristics:
• Financial value.
• Strategic value.
• Risk level.
The scale for assessing the financial value of the project may look like this:
• High. Expected payback up to 1 year. Expected revenues from the project are at least 1.5 times higher than expenses. All assumptions in these assessments are clearly justified.
• Above the average. The expected payback of the project is from 1 year to 3 years. Expected revenues from the project are at least 1.3 times higher than expenses. Most of the assumptions in these assessments have some basis.
• Average. The project improves the efficiency of production in the Company and can potentially reduce the company's costs by at least 30%. A project can have informational value or help to better control the business.
• Low. The project slightly reduces the company's costs by at least 10% and gives some improvements in production productivity.
For example. The financial value of software development projects, implementation projects or maintenance projects, which are carried out in accordance with the concluded commercial contracts, can be assessed as high. A project for the planned development of the functionality of products in accordance with the requirements of the market, initiated by the product manager on the basis of an analysis of the proposals of the marketing, consulting, sales and technical support departments, can receive an above-average assessment of financial value, and process change projects or internal automation projects can have an average financial value.
Financial value alone is not enough to prioritize a project. For example, no software company will undertake the automation of illegal drug trafficking if it is not in line with its business strategy. Therefore, an important indicator of the priority of the project is its compliance with the strategic goals of the company.
The scale for assessing the strategic value of the project can be as follows:
• High. Provides a strategic advantage, gives a steady increase in the market or allows you to enter a new market. Solves significant problems common to most important customers. Repetition by competitors is difficult or will require from 1 to 2 years.
• Above the average. Creates temporary competitive advantages. Fulfillment of obligations to many important customers. The competitive advantage can be maintained for 1 year.
• Average. Market confidence in the company is maintained. Increases the opinion of customers about the quality of the services provided or contributes to the fulfillment of obligations to several customers. Competitors already have or are able to repeat new opportunities within a year.
• Low. Strategic impact is absent or negligible. The impact on customers is irrelevant. Competitors can easily repeat the results of the project.
The third mandatory indicator of the priority of the project should be an assessment of the level of its risk. No project that has even the highest assessment of financial profitability will be put into production if the achievement of this super-benefit has minimal chances.
An approximate scale for assessing the level of risks of the project can be as follows:
• Low. Project objectives and requirements are well understood and documented. The scope and scope of the project are clear. The resources of the required qualifications are available in full. The systems being developed will not require a new technological platform.
• Average. The objectives of the project are more or less clearly defined. A good understanding of the system requirements. The scope and scope of the project are set quite well. Required qualification resources are generally available. Systems are created on a new but stable technological platform.
• Above the average. The objectives of the project are not clear enough. The tasks of a system or line-of-business application are not fully understood. Understanding the scope and scope of the project is not enough. The resources of the required qualifications are severely limited. Systems are created on a new technological platform, doubts about the market stability of the platform.
• High. The goals of the project are unclear. The main functional components of the system are not defined. The scope and scope of the project is unclear. The resources of the required qualifications are virtually non-existent. Systems are created on a new technological platform, in relation to which there is very little clarity. Technology has unconfirmed stability.
If the company pays little attention to managing the priorities of its projects, then this leads to an overabundance of ongoing projects, overload of performers, constant rushes and overtime and, as a result, to low efficiency of production activities. When starting a new project with a high priority, the company must stop or close less significant projects to provide the new project with the necessary resources, and not try to do everything at once due to the intensification of work, as a rule, this does not work.
Concept of the project
Every project should have a concept. If the project is small, then a few paragraphs are often enough to present the concept. However, starting a project without a concept is like sailing a ship without defining a destination for it.
The concept of the project is developed on the basis of an analysis of business needs. The main function of the document is to confirm and agree on a common vision of goals, objectives and results by all project participants. The concept defines what is done in the project and why.
The concept of the project is a key document that is used to make decisions throughout the project, as well as during the acceptance phase - to confirm the result. It usually contains the following sections:
• Name of the project
• Objectives of the project
• Results of the project
• Assumptions and limitations
• Key stakeholders and stakeholders
• Project Resources
• Time
• Risks
• Acceptance criteria
• Rationale for the usefulness of the project
As an example that will illustrate the theoretical presentation of the basics of project management, let's take a real project for the development of software for the automation of one of the divisions of a large manufacturing company. Let's call it the Automated Document Sales System.
A brief legend of the project. The customer of JSC "XYZ" is one of the leading manufacturers of complex technical products. Department "123", which is part of JSC "XYZ", is responsible for the sale of additional accompanying documentation for customers of JSC.
Additional documentation is not included in the standard delivery, since the owner of this technical product does not always operate it himself, but transfers it to another company that becomes a customer of XYZ and purchases operational documentation from it. Repair and maintenance of a particular product can be performed by a third company, which will already need detailed technical documentation for repair and maintenance. It also becomes a customer of XYZ and buys the required products from it.
The main function of the "123" department is to receive and process orders for additional documentation, according to the annually sent catalog. In connection with the relocation of department "123" to a new building, the task was set to develop and supply a system that automates the main activities of the department "123".
The text of the document Concept of the project, which will be given as an example, will be highlighted with a background color.
Objectives and results of the project
The goals of the project should answer the question of why this project is needed. Project objectives should describe the business needs and tasks that are solved as a result of the project. The objectives of the project may be:
• Changes in the Company. For example, the automation of a number of business processes to improve the efficiency of the main production activities
• Implementation of strategic plans. For example, the conquest of a significant share of the growing market by introducing a new product to it.
• Execution of contracts. For example, custom software development.
• Solving specific problems. For example, the refinement of the software product in order to bring it into line with changes in legislation.
Goals should be meaningful (aimed at achieving the Company's strategic goals), specific (specific to this project), measurable (i.e. have verifiable quantitative estimates), real (achievable). A clear definition of business goals is important because it significantly affects all processes and decisions in the project. The project should be closed if it is recognized that the achievement of the goal is impossible or has become impractical. For example, if the real costs of the project will exceed the future revenues from its implementation.
The results of the project answer the question of what should be obtained after its completion. The results of the project should determine:
• What kind of business benefits will the customer receive as a result of the project.
• What product or service. What exactly will be produced at the end of the project.
• High-level requirements. A brief description and, if necessary, the key properties and/or characteristics of the product/service.
It should be remembered that the results of the project should be measurable. This means that when evaluating the results of the project, it should be possible to draw a conclusion whether the results specified in the concept have been achieved or not.
Assumptions and limitations
This section describes the initial assumptions and limitations. Assumptions tend to be closely related to risk management, which we will discuss later. In software development, it is often necessary to formulate risks in the form of assumptions, thereby transferring it to the customer. For example, when evaluating a development and implementation project under a fixed-price scheme, we should record in the assumption that the cost of licenses for third-party software will not change until the project is completed.
Constraints tend to reduce the ability of the project team to make solutions. In particular, they may contain:
• Specific regulatory requirements. For example, mandatory certification of the product, service for compliance with certain standards.
• Specific technical requirements. For example, development for a given software and hardware platform.
• Specific information protection requirements.
In this section, it is also appropriate to formulate those system requirements that can be expected by the customer by default, but are not included in the scope of this project. For example, this section may include a clause stating that the development of a software interface (API) for future integration with other customer systems is not included in the tasks of this project.
Key stakeholders and stakeholders
One of the tasks of the project initiation phase is to identify and describe all its participants. According to, project participants include all stakeholders, individuals and organizations, such as customers, sponsors, executing entities, who are actively involved in the project or whose interests may be affected in the execution or completion of the project. Participants can also influence the project and its delivery results.
Key participants in a software project typically include:
• A project sponsor is a person or group of individuals who provide financial resources for a project in any form.
• The project customer is the person or organization that will use the product, service or result of the project. It should be borne in mind that the customer and the sponsor of the project do not always coincide.
• Users of project results.
• The project curator is a representative of the executor, authorized to make a decision on the allocation of resources and changes in the project.
• The project manager is the representative of the executor responsible for the implementation of the project on time, within the budget and with a given quality.
• Co-executors of the project. Subcontractors and suppliers.
Resources
In order to understand how much it will cost to implement a software project, you need to determine and evaluate the resources necessary for its implementation:
• Human resources and qualification requirements.
• Hardware, services, consumables, software licenses, critical computer resources.
• Project budget. Cost plan and, if necessary, project revenues by item and phase/phase of the project.
The specificity of the program project lies in the fact that human resources make the main contribution to its cost. All other costs are usually insignificant, compared to this expense. We will discuss in detail how to approach the estimation of labor costs for the implementation of a software development project in the next lectures. In the initiation phase, it is considered good to estimate labor costs with an accuracy of -50% to +100% [2].
It must be remembered that in addition to direct programming in the software development project, there are many other processes that require resources of appropriate qualification, and programming itself is only a quarter of all costs. The distribution of labor costs for the main production processes in the modern software development process is on average as follows:
Illustrate !
Distribution of labor costs by the main production processes in software development
Therefore, if, according to your estimate, to implement the required functionality in the project, it is necessary to write 10 KSLOC (thousands of lines of source code), and your programmers write an average of 100 SLOC per day, then the total labor costs for the project will not be 100 people * days, but not less than 400 people * days.
The remaining resources will be required for analysis and refinement of requirements, design, documentation, testing and other design work.
Before determining the size and composition of the project team for our example, we need to make an assessment of the complexity of software development. In our case, such an expert assessment took into account the costs of warranty support at the stage of trial operation of 9,000 people * hour. Based on the empirical curve of B. Boehm (Figure 15), the number of the team, close to optimal, was 10 people, of which
No comments:
Post a Comment