Some of the projects froze, some fell off, the RPs were kicked out, but the tasks in Jira were not cleaned. You have 10-20 ongoing “projects” on hand and you need to quickly understand where it hurts more.
Comparing the experience of the participants at the KiFB gatherings (Francis Bacon Club) in solving this problem, we presented this experience in recorded form (for which thanks to all participants).
At the beginning, you came to an organization with 50+ projects, where a tracker was introduced with a keen desire to establish a systematic project management, including transparent reporting.
An understanding of the state of the project, based on something other than the opinion of the project manager (RP), is invested in objectivity.
Why so? RPs, like most people, are used to being beaten for mistakes. What does RP do? Hides his mistakes until it is too late.
Some of the reports are provided by financial and legal management. Payments, contracts, expenses, acts, etc. But these funds are of little use for the early diagnosis of problems if problems arise in the work process itself. If the workflow is controlled through the task tracker, it is possible to get information from it.
(But of course this works if someone on the RP will read these reports, draw conclusions and make decisions for which they are responsible).
Why do I need reports
Report not needed for report
Shot from the film “The Pentagon Wars”. The auditor brought reports. ALL reports.
A manager facing a mass of data in a mass of reports can fall into a stupor. (Strike form: if you want reports - get reports).
The company receives money by completing tasks.
The reports should primarily show the incoming flow of future money, the associated capital, the rate of profit generation and operating expenses. If tracking is used to manage changes, then this is also the rate of change.
There are different types of activities (taking place jointly and complementing each other): project, process, organizational and research, the analysis of which varies somewhat.
Project activities
In fixed-cost projects, it is important to track the rate of combustion of a job. If the work is started as tasks in Jira, reports (which we do not deal with in this article) can help. Another common way is to track a project’s status using a Gantt chart, along with a budget plan (alas, tasks in Jira are often forgotten to close).
Research
Research activity does not require the solution of all assigned tasks, on the one hand, and, on the other hand, the tasks solved do not usually generate income. Organizations for which this is not the main activity conduct research in small teams and in shorter cycles, in which management is carried out “on the fingers” of the result. Jira reporting helps little in managing.
Process activities
Consider the process activity - this is the execution of the incoming flow of tasks with payment tied to their implementation, while the tasks arrive constantly with some regularity (in other words, there is no fixed scope). For example, improvements to the IT system. In this case, reports can directly reflect the status of the process.
The incoming task is future money. Hanging task = hanging money. A problem that is rotten (no longer needed) = loss of money. The task for which work was performed, but which is not closed = related capital, which can be thrown out if the task goes bad.
How much future turnover do you have? These are new tasks, with an agreed assessment with the customer. But to see this, you need to clean out the slag - obsolete not relevant tasks.
What is the related capital? In sales prices, these are tasks that were taken into work and not completed. In cost prices, this is the labor costs for such tasks in hours or in the value of payroll. Less slag.
What is the rate of revenue generation? The amount of money to solve the problem in the sprint minus the cost of ownership of the team. But for this it is necessary that the tasks change their status + people note the time spent on the project. However, with this indicator of problems, as a rule, the least arises.
Organizational activity is primarily a change activity.
How fast are you changing? Have time to change? This is the speed of organizational tasks and the rate of accumulation of new ones. And reporting on tasks that hung on employees, allowing you to remember to implement the decisions made.
The further path to Lean is supported by more complex reports (which were not much discussed at gatherings, and are not signed in detail).
What ideas come to mind:
- Loss of time due to waiting. The ratio of time spent on the time from hiring to implementation. Backlog timeout.
- Losses due to unnecessary transportation. The number of returns over the life cycle with the calculation of the loss of time for waiting in processing
- Losses due to unnecessary processing steps. Downtime due to unnecessary stages in coordinating tasks with supervisors or supervisors.
- Losses due to excess stocks. Downtime for employees not loaded with training, PR or presale
- Losses due to unnecessary movements. Loss of time organizing meetings, finding contacts, waiting for code to compile, and running unit and other tests.
- Losses due to the release of defective products. The ratio of errors found in the battle against those found on the test. Scope of work to correct errors. The amount of work on alterations due to poor staging.
- Losses of overproduction. Implementation of functionality that did not affect business performance. Losses for testing uncritical or unaffected functionality. Support for obsolete browsers or their versions.
But before these you need to clean the tracker from the slag.
We clean Jira
Step 1. We do not configure anything
Do not change workflow, statuses, resolutions. Although it’s unusual to deal with unusual statuses, but this is data in which people invested some sense.
Step 2. We remove old projects
Report in the format (Project, Last date of the last change in the task status).
Projects for which there were no movements are candidates for transfer to the archive.
If the person responsible for the project is still working, he will say the status, if not, the quest for finding the ends begins.
We transfer the tasks of archival projects to the final status with won't fix. There are frozen projects. The status of such tasks translates into frozen.
Step 3. We remove old tasks
Report on unclosed tasks with the last change of status less than X (two years more than enough. But usually, if a task hangs for 90 days - it “goes bad”) days, grouped by assignee. Most likely they are rotten, the person responsible will say (if he is appointed and not dismissed).
Step 4. Remove unnecessary task types
A report of the distribution of unclosed tasks by task type to drop out unnecessary types.
Step 6. We analyze the tasks of the dismissed
We single out tasks with fired performers.
It is especially interesting to look at the tasks of laid-off employees in the context of their superiors. The head of the employee allowed the “drain” of the associated capital of the time spent on the task and did not organize the completion of the task.
We enter in the regulation on dismissal the obligation to outweigh / close irrelevant tasks.
Step 5. Search and parse the largest heap
Report on statuses of unclosed tasks. We identify in which status the most tasks.
If the status is a task in the work, then we build a report on the distribution of tasks in this status by performers. We single out tasks without an assigned executor, we look at tasks by “live” executors. On some artist 2000 tasks have accumulated. Hmm ...
Step 7. We standardize statuses, resolutions, life cycles
An opportunity to look equally at any project. We meet and break the resistance of the RP. Alas, people do not like to think about their interchangeability, a typical argument: “I am unique in managing a project, I need a unique life cycle.”
Step 8. We are looking for the most problematic projects. We look at the reports of combustion
Jira - there can be two types of projects
- Projects with a known scope of tasks (this happens), where combustion reports are applicable. Sometimes it happens.
- Processes: Processing Continuing Tasks
Projects
If the task pool is started, then we look at the completion forecast and take measures if the forecast is not comforting.
The processes
We look at the solved problems against incoming tasks.
Divided tasks are divided into external and internal (training, refactoring, etc.), we display only external ones on the chart.
How to read charts
There are three conditional graphs:
The reality of IT is that the labor involved in releasing tasks has a significant statistical spread (unless of course it is tasks like granting rights).
As a result, to ensure the necessary support SLA, resources must be planned with a margin, otherwise this will lead to the accumulation of tasks in the incoming task buffers, which will make the deadlines inadmissible. People will not always be loaded with incoming tasks, doing training or other non-core work during breaks.
In the process of product development, they try to prevent developers from downtime to ensure maximum development speed = making money. To do this, you must always have a supply of tasks in the backlog, which means that part of the task will most often not be done, and since tasks are gradually losing relevance, this means that tasks will never be done.
Option A
It’s normal if this is an implementation of features. More features enter the input than the team can digest.
If this is support (administration and bug fixing), then the situation is bad. The more errors, the slower their correction. The slower the correction, the more errors accumulate. Something is ticking under the barrel of gunpowder. Tick-to-tick-to-tick ....
Option B
If a team does exactly as many tasks as it comes to the backlog, then this means that
- either the backlog is maintained in another project / place and, as a result, you do not see future turnover in the reports and cannot make a decision based on reports on the importance of increasing the size of the team,
- or people invent tasks for themselves at the time of inactivity (on sensations and intuition, without custdev, market analysis, etc.); how many such tasks are unclear and this is alarming (what if there are already 90% of them),
- or the reports are faked.
Option C
OK if it's support. The team should have downtime so that it can quickly and efficiently solve problems and tasks.
If this is an implementation of features, then the situation is most often not normal. Once backlog of tasks was accumulated, which understands faster than new ones. Why could this be?
- For example, the team has been dramatically increased and it is analyzing the debt, but at the same time, the business needs are no longer growing. The business does not respond (did not manage to react) to the growth of opportunities or worse, the product has taken its place and stopped growing.
- Or the product stagnates and does not require development.
- Or marketing has stopped creating new opportunities.
Stage access security step
We catch tasks with links on the Internet to Google Dox. All documents must be inside the perimeter, we set the task of transferring materials inward
Analyst Control Step
Stages are made where?
Option A. Right in the fat.
Option B. In the employee’s personal Google Dox.
Correct option: A change in functionality should most often be accompanied by a change in the technical and working documentation in Confluence. How to control it?
We link the statement page to the task in fat (just insert the link, this will automatically lead to the creation of bidirectional links).
We build a report on page changes in confluence and summarize it on analytics with Jira reports on improvements with labor costs. All improvements with significant labor costs should correlate with changes to the articles.
Acknowledgments
Thanks to the active members of KiFB for the prepared materials and the organization of the discussion, and to all the people who participated in the discussion.