Consulting IT projects in the style of Agile?
Probably, no one needs to talk about what Agile is. And especially about Agile in projects where there is a problem statement and software development. This is all well talked about many times. Another thing is when these are consulting projects, where it is, as we all have been taught, talking about “processes, people, technologies”. In such projects, we do not just set the task for the developers, but they give the correct and quick result. We also carry out organizational changes, design processes, work a lot with people, transfer knowledge to them.
Hewlett Packard Enterprise consultants carry out similar IT management projects: ITSM, project and portfolio management, monitoring at any level, etc.
Over the past couple of years all over the world, we are faced with the fact that customers are increasingly asking or actively insist on applying the Agile approach to the implementation of such projects. Already in Russia, there are such precedents.
')
It is clear that for many years the approach to the implementation of consulting projects in the field of IT management has been worked out in HPE for "five plus". Thousands of completed projects around the world, a huge number of lessons learned and a rigorous methodology that says how to correctly. And this is all, of course, in the format of waterfall. That is, “Project start”, “Design”, “Creation”, “Deployment and trial operation”. "I came, I saw, I won."
Everything is simple here - the customer needs the result as quickly as possible. Judge for yourself. Take almost any Russian company of medium or large scale:
1. Budget planning starts somewhere in August:
2. At the beginning of the year, we take the budget and play a tender - the procedure is entertaining and where it is not so fast.
3. In March, if you're lucky, we start work.
4. The results must somehow be issued at the end of the year, because all KPIs (both on the side of the customer and on the side of the contractor).
Total: the life cycle of the project from the initiative to the results of the project - about one year and a half years. It is too long.
There are several reasons for this situation, but at least:
The customer must understand that to allocate money for solving specific problems is the last century. The formulation of tasks, as we have already found out, manages to change frequently during the implementation of these tasks. Therefore, money should be allocated for the development of some mainstream areas (in the case of consulting projects that our company does - for ITSM, portfolio and project management, for monitoring infrastructure or services, etc.), setting a specific development vector, but not specific requirements and results. Of course, this will require a change in the way of thinking, the restructuring of internal procedures, but without this, nowhere.
In addition, you need to ensure the smooth passage of organizational changes, changes in the ways people work. In many organizations, we are faced with the fact that people are accustomed to rapid and numerous changes - usually the result of "manual control" at one or another level in the organization. It is necessary to use the best practices of management of organizational changes - MoC, Management of (Organizational) Changes - including to show people that these changes are not chaotic, but provide the very vector of development that was set earlier.
Finally, if we are talking about consulting projects, then we at HPE use the so-called “sandwich model”:
As you can see, we wrap Agile on two sides with waterfall, which allows, on the one hand, to make releases and give value to the customer more often, on the other hand, due to the start and end of the project, close to the waterfall approach, the project looks like that has a beginning and an end. This is necessary, in particular, because customers very often want to implement even Agile projects under the fixed price scheme, and not under the time & material scheme.
This topic seems to us very promising, and quite a lot of projects are already being launched in this format. For example, there is a large project in a company operating around the world, where between releases the product owner collects up to 200 key users of the system from all over the world, they are shown the results of work, and they collect feedback and use them to add new items to the backlog. This is just a small stroke showing the possible scale of such projects, because traditionally Agile lives well in small teams. However, when we talk about the level of the enterprise, SAFe, which we have already told, comes to the rescue.
Summing up, I would like to say the following: consulting projects in Agile or “almost Agile” format are possible. We even make them. We will be glad to hear questions and comments on this topic, including taking into account the specifics of domestic companies and organizations.
Hewlett Packard Enterprise consultants carry out similar IT management projects: ITSM, project and portfolio management, monitoring at any level, etc.
Over the past couple of years all over the world, we are faced with the fact that customers are increasingly asking or actively insist on applying the Agile approach to the implementation of such projects. Already in Russia, there are such precedents.
')
It is clear that for many years the approach to the implementation of consulting projects in the field of IT management has been worked out in HPE for "five plus". Thousands of completed projects around the world, a huge number of lessons learned and a rigorous methodology that says how to correctly. And this is all, of course, in the format of waterfall. That is, “Project start”, “Design”, “Creation”, “Deployment and trial operation”. "I came, I saw, I won."
What for
Everything is simple here - the customer needs the result as quickly as possible. Judge for yourself. Take almost any Russian company of medium or large scale:
1. Budget planning starts somewhere in August:
- we form initiatives
- they are evaluated and “screened” through a sieve of economic efficiency,
- turn into projects
- then someone writes detailed requirements for them,
- and the corresponding line appears in the IT budget.
2. At the beginning of the year, we take the budget and play a tender - the procedure is entertaining and where it is not so fast.
3. In March, if you're lucky, we start work.
4. The results must somehow be issued at the end of the year, because all KPIs (both on the side of the customer and on the side of the contractor).
Total: the life cycle of the project from the initiative to the results of the project - about one year and a half years. It is too long.
What's wrong
There are several reasons for this situation, but at least:
- Budget and tender procedures “to win” (to shorten their terms) is difficult. After 4-6 months from the appearance of the initiative to the results of the tender, the requirements of the customer may change, even if within the framework of the same topic. We need a tool for flexible re-prioritization of tasks.
- Within the framework of the project, the customer, of course, was also used to work on waterfall. And it is written in all its internal regulations, standards for project management, etc. But waiting for the results of 6, 9 or 12 months is very boring. Again, during this time a lot can change during the project implementation. But even if it has not changed, I want to get the result in parts and immediately use it in my work.
What to do
The customer must understand that to allocate money for solving specific problems is the last century. The formulation of tasks, as we have already found out, manages to change frequently during the implementation of these tasks. Therefore, money should be allocated for the development of some mainstream areas (in the case of consulting projects that our company does - for ITSM, portfolio and project management, for monitoring infrastructure or services, etc.), setting a specific development vector, but not specific requirements and results. Of course, this will require a change in the way of thinking, the restructuring of internal procedures, but without this, nowhere.
In addition, you need to ensure the smooth passage of organizational changes, changes in the ways people work. In many organizations, we are faced with the fact that people are accustomed to rapid and numerous changes - usually the result of "manual control" at one or another level in the organization. It is necessary to use the best practices of management of organizational changes - MoC, Management of (Organizational) Changes - including to show people that these changes are not chaotic, but provide the very vector of development that was set earlier.
Finally, if we are talking about consulting projects, then we at HPE use the so-called “sandwich model”:
- At the beginning of the project, the initial backlog of tasks to be implemented is formed. We can consider this a “micro-design”, similar to how we design the processes and functional requirements for the system within the framework of the waterfall approach.
- This backlog is prioritized, as ordered by us, for example, ScrumXP. Next, we work in Agile mode, the requirements can be adjusted and changed. Of course, tough discipline and the presence of appropriate roles (product owner, scrum master, etc.) are necessary. In parallel with the development of the code, we are writing the necessary documents, preparing organizational changes (by the way, within DevOps there is the mantra “everything is code”, which transforms the minds of process consultants very well).
- We still will not get rid of the concept of the project when we work in a “customer-contractor” bundle. A project, by definition, is a time-limited activity. Therefore, at some point, Agile history needs to be summarized, and the result of the project must be handed over to the customer (possibly providing it with the necessary additional bureaucracy). By the way, this does not mean at all that the work is completed - the customer, having become accustomed to the fact that he regularly receives new releases and new value in the middle of the “sandwich” (p. 2), he will be ready to take care of the continuation of work and on the allocation of new funds.
As you can see, we wrap Agile on two sides with waterfall, which allows, on the one hand, to make releases and give value to the customer more often, on the other hand, due to the start and end of the project, close to the waterfall approach, the project looks like that has a beginning and an end. This is necessary, in particular, because customers very often want to implement even Agile projects under the fixed price scheme, and not under the time & material scheme.
This topic seems to us very promising, and quite a lot of projects are already being launched in this format. For example, there is a large project in a company operating around the world, where between releases the product owner collects up to 200 key users of the system from all over the world, they are shown the results of work, and they collect feedback and use them to add new items to the backlog. This is just a small stroke showing the possible scale of such projects, because traditionally Agile lives well in small teams. However, when we talk about the level of the enterprise, SAFe, which we have already told, comes to the rescue.
Summing up, I would like to say the following: consulting projects in Agile or “almost Agile” format are possible. We even make them. We will be glad to hear questions and comments on this topic, including taking into account the specifics of domestic companies and organizations.
Source: https://habr.com/ru/post/302686/
All Articles