Development management in a large project
On several projects for the implementation of corporate systems, I was faced with the task of planning and controlling tasks that are difficult to predict. Imagine, you need to perform many similar tasks, and they involve a large number of people, while you do not know exactly in what sequence they will be performed and how long they will take.
The Gantt diagrams that are familiar to the project management work poorly in this case. A typical example is the development of extensions for KIS.
Below I will tell you what method we used on projects in order to control a large number of parallel tasks with minimal administrative costs.
About five years ago I wrote an article - recommendations for project managers on drawing up a schedule. The principles have been tested by time, and I still adhere to them.
However, for some type of tasks to make a consistent detailed schedule is almost impossible. In a situation where many tasks are being done in parallel, and the duration and complexity of each can only be estimated with great uncertainty.
A classic example is design. Each development goes through several stages, at a minimum - design, coding, testing. As a rule, several iterations are necessary when the task moves to the previous stage. Development has moved from coding to testing, the developer took up another task. The development was returned to coding, the developer either finishes the previous task, or immediately takes up the correction of errors. Depending on the situation and priorities, there may be a different order of team work on the task pool. The process looks chaotic and unmanageable. To present this in the form of an accurate Gantt chart, to which project leaders are accustomed, who are used to controlling everything, is extremely laborious and of little use, if at all possible.
How to be? How to control the progress of work? How to understand - we have time or not; where are the bottlenecks; Are there enough resources? who works well and who doesn't? How, after all, to report to management?
Below is one of the options that seems to me optimal, and in some conditions - the only one.
Immediately it is worth making a reservation that without using a task management system, which allows each participant to receive tasks, transfer them to other participants and mark their implementation, it is impossible to build a normal process.
In my practice, I used different tools and published a review article on this topic (see the article on Habré: Project Manager’s Tools ). Here I will describe in more detail the experience of using JIRA, which we have set up to manage development, using standard functionality, with minimal use of additional plug-ins.
JIRA is a system for managing tasks (requests) from Atlassian. The cost of a license, depending on the number of users, starts from $ 10 for 10 users. There are options to install yourself, or use the application in the cloud. Prices for all options can be found here .
JIRA is distinguished by a slightly old-fashioned interface (this is a very advanced age system, which has already passed a very long development path), reliability, a flexible configuration system for everything you can (workflow, screen type, access, notification system), a huge number of plug-ins, both paid and free, and the possibility of deep refinement.
We did not need revision, we set up and constantly improved workflow (workflow - recruitment and order of statuses for the task and transitions between them), as well as access for participants and dashboards to control the work.
I do not set myself the task to describe in detail the features and possibilities of using the application, but for further presentation it is important to illustrate some points.
The workflow reflects the life cycle of the task, in our example, design, coding testing. In fact, the process is much more complicated. Depending on the organization of the project, recruitment of participants, control requirements, the number of stages can vary quite significantly.
For example, on one of the projects was the following workflow tracking development tasks.
Many stages of coordination, distribution of work, testing on all instances of the system ... But this made it possible to confirm each step in the system, track responsibility and know exactly who and at what stage the task is.
The complexity of the task was divided into two components: design and construction. Design is the analyst’s work on document preparation and development testing. The construction is the developer's work on the development of technical design, coding, own testing before transferring to the analyst.
It is rather difficult to estimate the complexity of the task beforehand, without immersing in details, especially if there are several thousand tasks, as was the case in our case. But it is necessary to estimate it in order to understand the total amount of work, the required amount of resources and determine the terms.
For a rough estimate, a calculator is used, which, depending on the type and complexity of the task, assigns a planned labor intensity to it.
The complexity of the task is determined depending on the object and the amount of work with it. For example, for developing a form in Oracle eBS, complexity criteria are described as follows:
The type of task reflects the content of the task, the specifics of the technology, application or part thereof.
For example:
- New or changeable forms.
- New or changeable reports.
- New or changeable database programs.
- Loader'a SQL scripts.
- Signals (alerts).
- Personalization.
- etc.
Based on the complexity and type of development, the calculator calculates the planned workload.
And although the estimation error is significant, on a large number, statistically, these errors are leveled, and the general idea of the amount of effort can be used for the purposes of project planning.
So, having the status of the task and its complexity, how do we evaluate the progress of the work?
The traditional option is to plan how many tasks need to be done over a certain period and track the completion of tasks on a periodic basis. The problem is that some tasks are done long and stretched over several planning periods. And in some periods many tasks are completed, in others - too few. This does not give an understanding of the situation, especially at the beginning and at the end of the project.
You can try to schedule the completion of individual phases of the task. In the above example, we used 21 stages, it is impossible to plan each. We choose the main ones - the completion of the design, the completion of coding, the completion of the entire task. We plan a date for each task, we will monitor deviations. It seems feasible. However, when working simultaneously on a large number of tasks, it is rather difficult to see something in several hundred deviations and to draw the right conclusions. For each deviation there will be an explanation, an objective reason. Something will be done late, something faster.
On one of the projects we tried using the date control method. Planned date set performers. The fact was automatically recorded in the system upon transition from to the corresponding status.
The figure shows a histogram of deviations according to the readiness date of functional design (FD). Positive values show advancing, negative values are behind the schedule. It is seen that the largest number of PD performers hand over with a lag of 3.8 to 1.7 days. In this case, the extreme values from 43 days late to 67 days of advancing.
In this situation, we see that in the overwhelming majority of cases, performers violate the deadlines set by them. This systematic error is worth pondering over it. However, provided that the team is motivated and everyone works in good faith, this only means that people cannot specify the actual period, the performers do not take into account the complicating factors that in most cases arise during the work.
Additional time is spent on planning, and in fact no one is responsible for meeting the deadlines. If you introduce penalties for violation, the dates will be set with a large margin, and the performance situation will get worse.
Attempts to manage at a detailed level centrally, for a large number of tasks with a high degree of uncertainty are doomed to failure.
You can divide these tasks into groups, delegate detailed planning into groups. Several people, several dozens of tasks can be lined up, promptly respond to changes, make decisions about changing priorities. But at the project level, other methods are needed.
The method of mastered volume comes to the rescue. Without going into theory, I will describe how this method is implemented for the plan-fact control on developments.
We have already defined the life cycle of the task and determined the planned labor intensity of each of them. Now we assign the percentage of execution of the task at each stage. In our case, because there was a division of labor for design and coding; a percentage is assigned to each of the values.
The assignment of interest is done by an expert, estimated how much we consider the task completed, how much more labor remains at this stage.
After such a table has been compiled, for each task it is possible to determine how many person-days from the planned ones have already been mastered and thus measure the progress of execution for each task.
For example, a task has a planned labor intensity of 10 chd for design and 20 chd for development. Then at the testing stage, we believe that it is 80% complete in terms of the analyst’s work (20% of the labor costs to complete the testing are still left) and 50% in the part of the developer’s work. We are ready to admit that the design worked out 8 hours, and the development - 10 hours. Total, out of 30 man-days, 18 have already been completed.
However, we do not take into account that in fact other time may be spent. For set goals, it does not matter.
Having a table in which for each task we have planned labor-intensiveness and mastered volume, it is easy to understand how things are going.
It is possible to divide the tasks by areas, components, milestones of the project, to be able to analyze at a more detailed level and make summary tables in all the necessary sections.
The overall picture of the project becomes convenient for presentation at the management level:
Summary table based on unloading from JIRA
control plan-fact for the entire project
This method does not always find understanding. Mythical man-days are less clear than pieces of development. And he does not cancel detailed planning at the level of the group and individual performers. At the same time, this is the most objective method for assessing the current situation and predicting the completion of work.
The Gantt diagrams that are familiar to the project management work poorly in this case. A typical example is the development of extensions for KIS.
Below I will tell you what method we used on projects in order to control a large number of parallel tasks with minimal administrative costs.
1. Scheduling
About five years ago I wrote an article - recommendations for project managers on drawing up a schedule. The principles have been tested by time, and I still adhere to them.
However, for some type of tasks to make a consistent detailed schedule is almost impossible. In a situation where many tasks are being done in parallel, and the duration and complexity of each can only be estimated with great uncertainty.
A classic example is design. Each development goes through several stages, at a minimum - design, coding, testing. As a rule, several iterations are necessary when the task moves to the previous stage. Development has moved from coding to testing, the developer took up another task. The development was returned to coding, the developer either finishes the previous task, or immediately takes up the correction of errors. Depending on the situation and priorities, there may be a different order of team work on the task pool. The process looks chaotic and unmanageable. To present this in the form of an accurate Gantt chart, to which project leaders are accustomed, who are used to controlling everything, is extremely laborious and of little use, if at all possible.
How to be? How to control the progress of work? How to understand - we have time or not; where are the bottlenecks; Are there enough resources? who works well and who doesn't? How, after all, to report to management?
Below is one of the options that seems to me optimal, and in some conditions - the only one.
2. Use of work management system
Immediately it is worth making a reservation that without using a task management system, which allows each participant to receive tasks, transfer them to other participants and mark their implementation, it is impossible to build a normal process.
In my practice, I used different tools and published a review article on this topic (see the article on Habré: Project Manager’s Tools ). Here I will describe in more detail the experience of using JIRA, which we have set up to manage development, using standard functionality, with minimal use of additional plug-ins.
JIRA is a system for managing tasks (requests) from Atlassian. The cost of a license, depending on the number of users, starts from $ 10 for 10 users. There are options to install yourself, or use the application in the cloud. Prices for all options can be found here .
JIRA is distinguished by a slightly old-fashioned interface (this is a very advanced age system, which has already passed a very long development path), reliability, a flexible configuration system for everything you can (workflow, screen type, access, notification system), a huge number of plug-ins, both paid and free, and the possibility of deep refinement.
We did not need revision, we set up and constantly improved workflow (workflow - recruitment and order of statuses for the task and transitions between them), as well as access for participants and dashboards to control the work.
I do not set myself the task to describe in detail the features and possibilities of using the application, but for further presentation it is important to illustrate some points.
3. Task management workflow
The workflow reflects the life cycle of the task, in our example, design, coding testing. In fact, the process is much more complicated. Depending on the organization of the project, recruitment of participants, control requirements, the number of stages can vary quite significantly.
For example, on one of the projects was the following workflow tracking development tasks.
Many stages of coordination, distribution of work, testing on all instances of the system ... But this made it possible to confirm each step in the system, track responsibility and know exactly who and at what stage the task is.
4. The complexity of the problem
The complexity of the task was divided into two components: design and construction. Design is the analyst’s work on document preparation and development testing. The construction is the developer's work on the development of technical design, coding, own testing before transferring to the analyst.
It is rather difficult to estimate the complexity of the task beforehand, without immersing in details, especially if there are several thousand tasks, as was the case in our case. But it is necessary to estimate it in order to understand the total amount of work, the required amount of resources and determine the terms.
For a rough estimate, a calculator is used, which, depending on the type and complexity of the task, assigns a planned labor intensity to it.
The complexity of the task is determined depending on the object and the amount of work with it. For example, for developing a form in Oracle eBS, complexity criteria are described as follows:
- Very simple - single block form with 8 or less columns. Does not require special functional logic.
- Simple - single and multiblock (2-3 blocks) form with 20 or less columns. Simple functional logic is required (simple editing, cross-editing, simple calculations, totals and subtotals).
- etc.
The type of task reflects the content of the task, the specifics of the technology, application or part thereof.
For example:
- New or changeable forms.
- New or changeable reports.
- New or changeable database programs.
- Loader'a SQL scripts.
- Signals (alerts).
- Personalization.
- etc.
Based on the complexity and type of development, the calculator calculates the planned workload.
And although the estimation error is significant, on a large number, statistically, these errors are leveled, and the general idea of the amount of effort can be used for the purposes of project planning.
5. Control of task execution
So, having the status of the task and its complexity, how do we evaluate the progress of the work?
The traditional option is to plan how many tasks need to be done over a certain period and track the completion of tasks on a periodic basis. The problem is that some tasks are done long and stretched over several planning periods. And in some periods many tasks are completed, in others - too few. This does not give an understanding of the situation, especially at the beginning and at the end of the project.
You can try to schedule the completion of individual phases of the task. In the above example, we used 21 stages, it is impossible to plan each. We choose the main ones - the completion of the design, the completion of coding, the completion of the entire task. We plan a date for each task, we will monitor deviations. It seems feasible. However, when working simultaneously on a large number of tasks, it is rather difficult to see something in several hundred deviations and to draw the right conclusions. For each deviation there will be an explanation, an objective reason. Something will be done late, something faster.
On one of the projects we tried using the date control method. Planned date set performers. The fact was automatically recorded in the system upon transition from to the corresponding status.
The figure shows a histogram of deviations according to the readiness date of functional design (FD). Positive values show advancing, negative values are behind the schedule. It is seen that the largest number of PD performers hand over with a lag of 3.8 to 1.7 days. In this case, the extreme values from 43 days late to 67 days of advancing.
In this situation, we see that in the overwhelming majority of cases, performers violate the deadlines set by them. This systematic error is worth pondering over it. However, provided that the team is motivated and everyone works in good faith, this only means that people cannot specify the actual period, the performers do not take into account the complicating factors that in most cases arise during the work.
Additional time is spent on planning, and in fact no one is responsible for meeting the deadlines. If you introduce penalties for violation, the dates will be set with a large margin, and the performance situation will get worse.
If you want to control something, think about what you will do with the results of the control, what decisions can you make based on the collected data?
6. Method of mastered volume
Attempts to manage at a detailed level centrally, for a large number of tasks with a high degree of uncertainty are doomed to failure.
You can divide these tasks into groups, delegate detailed planning into groups. Several people, several dozens of tasks can be lined up, promptly respond to changes, make decisions about changing priorities. But at the project level, other methods are needed.
The method of mastered volume comes to the rescue. Without going into theory, I will describe how this method is implemented for the plan-fact control on developments.
We have already defined the life cycle of the task and determined the planned labor intensity of each of them. Now we assign the percentage of execution of the task at each stage. In our case, because there was a division of labor for design and coding; a percentage is assigned to each of the values.
The assignment of interest is done by an expert, estimated how much we consider the task completed, how much more labor remains at this stage.
After such a table has been compiled, for each task it is possible to determine how many person-days from the planned ones have already been mastered and thus measure the progress of execution for each task.
For example, a task has a planned labor intensity of 10 chd for design and 20 chd for development. Then at the testing stage, we believe that it is 80% complete in terms of the analyst’s work (20% of the labor costs to complete the testing are still left) and 50% in the part of the developer’s work. We are ready to admit that the design worked out 8 hours, and the development - 10 hours. Total, out of 30 man-days, 18 have already been completed.
However, we do not take into account that in fact other time may be spent. For set goals, it does not matter.
7. Project Reporting
Having a table in which for each task we have planned labor-intensiveness and mastered volume, it is easy to understand how things are going.
It is possible to divide the tasks by areas, components, milestones of the project, to be able to analyze at a more detailed level and make summary tables in all the necessary sections.
The overall picture of the project becomes convenient for presentation at the management level:
Summary table based on unloading from JIRA
control plan-fact for the entire project
This method does not always find understanding. Mythical man-days are less clear than pieces of development. And he does not cancel detailed planning at the level of the group and individual performers. At the same time, this is the most objective method for assessing the current situation and predicting the completion of work.