Pre-project analysis
Sergey Nuzhnenko darkboatman , a leading systems analyst at SuperJob, shares his experience in launching IT projects from an analyst perspective.
According to the results of the performance at the last mitap , I have a series of notes in which I will try, freeing myself from the restriction on the format of the speech, discuss with you the principles of performing pre-project tasks and show some examples from life.
This is useful for customer representatives, systems, business analysts, project managers, others involved in the launch of IT projects, iterations or sprints.
')
By pre-project we understand all the tasks that need to be completed before obtaining the consent of all parties, approving the budget, and most importantly, understanding what we are doing and why, and also in what way, that is, who needs to be involved and who will have to set the task later. These tasks are the same for both the large project and the short two-week iteration.
We know that, firstly, a good statement of the problem is half the solution, and, secondly, it is not so important how productive you are doing something if you do not do what is necessary. Systematic pre-project work is given depressing little attention. An overwhelming number of discussions, books and articles are devoted to what to do within the project, or to search for a product in cooperation with the market. In the gray zone is the transition from understanding what needs to be sold, to the work itself.
What needs to be done to build an IT system or service?
Here is a list of large tasks that are somehow solved for any system:
Underlined items we will call “pre-project”.
A pre-project (although it is not always called that) can be performed under different conditions: on the system as a whole, on subsystems, or on each feature of the product.
All of these tasks can be carried out for years, months, or fly by in a week as part of preparation for a sprint planning session, and can be accompanied by different amounts of paper and different patterns of interaction between participants.
However, before we begin to fix goals, the notorious 4 parameters of the project triangle - to formulate the responsibilities of the project participants, to appoint external status meetings with the sponsor and to uncover other commonly used project management tools - it is necessary to fully complete the tasks of the pre-project :
1) Understand the time and cost
2) Supplement the system:
3) Create a basis for acceptance (contract for the volume and quality of the result, also called "technical task")
4) To determine the resources: types, stages, terms, volumes of work and sources of resources
Without this, nothing (good) will come.
All the problems that will be discussed below develop on a deliberately unfavorable background, common to all pre-projects.
It is necessary to quickly determine the cost of the system amid high uncertainty.
There is a bargaining over the budget and deadlines - this is a conflict, originally embedded in any pre-project.
The customer wants Chrysler Escalade, there is money for GAZ 69, but he needs a Renault Logan. It happens that at the same time the solution provider wants to sell yachts and airplanes, but really can only make an inflatable boat, and now they will go looking for someone to buy Logan from.
The project is not yet “sold” and there is a struggle for its launch.
We have identified the frequent problems of the pre-project as the maturity of the customer and other participants of the IT project grows:
1) "Letter from Uncle Fyodor"
2) The full life cycle and the structure of both the system and the financial asset are not taken into account.
3) The tasks of the pre-project phase are not taken into account.
4) Invalid requirements communication mode selected.
Overview of the proposed solutions, which we will discuss in more detail in the following sections:
In addition, it is necessary to remember the basic principles that avenge in the absence of attention to themselves. Among them:
The brief review is completed, we will move on to the details in the next notes of the series.
According to the results of the performance at the last mitap , I have a series of notes in which I will try, freeing myself from the restriction on the format of the speech, discuss with you the principles of performing pre-project tasks and show some examples from life.
This is useful for customer representatives, systems, business analysts, project managers, others involved in the launch of IT projects, iterations or sprints.
')
By pre-project we understand all the tasks that need to be completed before obtaining the consent of all parties, approving the budget, and most importantly, understanding what we are doing and why, and also in what way, that is, who needs to be involved and who will have to set the task later. These tasks are the same for both the large project and the short two-week iteration.
We know that, firstly, a good statement of the problem is half the solution, and, secondly, it is not so important how productive you are doing something if you do not do what is necessary. Systematic pre-project work is given depressing little attention. An overwhelming number of discussions, books and articles are devoted to what to do within the project, or to search for a product in cooperation with the market. In the gray zone is the transition from understanding what needs to be sold, to the work itself.
Pre-Project Tasks
What needs to be done to build an IT system or service?
Here is a list of large tasks that are somehow solved for any system:
- Understand the problem or opportunity
- Identify the expected benefits (effect) qualitatively or quantitatively.
- Understand the “solution image” (concept or vision) and its cost
- To allocate the budget in money or natural resources
- Determine the types of resources, the scope of work and start their order
- Determine the basis for acceptance (as we learn that the work is done)
- ...
- (Here is a dull list of works on design, planning, development, deployment, implementation, etc., which today remains outside the scope of our discussion)
- ...
- Acceptance result
- Measure effect
- Confirm the return of financial investments
Underlined items we will call “pre-project”.
A pre-project (although it is not always called that) can be performed under different conditions: on the system as a whole, on subsystems, or on each feature of the product.
All of these tasks can be carried out for years, months, or fly by in a week as part of preparation for a sprint planning session, and can be accompanied by different amounts of paper and different patterns of interaction between participants.
However, before we begin to fix goals, the notorious 4 parameters of the project triangle - to formulate the responsibilities of the project participants, to appoint external status meetings with the sponsor and to uncover other commonly used project management tools - it is necessary to fully complete the tasks of the pre-project :
1) Understand the time and cost
2) Supplement the system:
- Show the customer an understanding of his goals.
- Show users a solution to their problems.
- Successfully complete a budget auction
3) Create a basis for acceptance (contract for the volume and quality of the result, also called "technical task")
4) To determine the resources: types, stages, terms, volumes of work and sources of resources
Without this, nothing (good) will come.
Difficulties
All the problems that will be discussed below develop on a deliberately unfavorable background, common to all pre-projects.
It is necessary to quickly determine the cost of the system amid high uncertainty.
There is a bargaining over the budget and deadlines - this is a conflict, originally embedded in any pre-project.
The customer wants Chrysler Escalade, there is money for GAZ 69, but he needs a Renault Logan. It happens that at the same time the solution provider wants to sell yachts and airplanes, but really can only make an inflatable boat, and now they will go looking for someone to buy Logan from.
The project is not yet “sold” and there is a struggle for its launch.
Review of problems and solutions
We have identified the frequent problems of the pre-project as the maturity of the customer and other participants of the IT project grows:
1) "Letter from Uncle Fyodor"
2) The full life cycle and the structure of both the system and the financial asset are not taken into account.
3) The tasks of the pre-project phase are not taken into account.
- Excessive detail requirements
- Not presented the volume and sufficient division of the system
- No understanding of customer goals
- There is no basis for acceptance of the result
4) Invalid requirements communication mode selected.
Overview of the proposed solutions, which we will discuss in more detail in the following sections:
In addition, it is necessary to remember the basic principles that avenge in the absence of attention to themselves. Among them:
- Understanding the essence of the IT system and its life cycle
- Understanding the view of the system as a financial asset
- Understanding what a cone of uncertainty is and how to use it
- Understanding the basics of evaluation
- Understanding the full range of tasks of the pre-project phase, the failure of which dooms us at best to refuse to launch the project, at worst - to torture in a deliberately disastrous project, and at worst - to karmic debts for stillbirth IT systems
The brief review is completed, we will move on to the details in the next notes of the series.
Source: https://habr.com/ru/post/345618/
All Articles