Common Problems with Project Management (Web)
Introduction
I have been doing web development for 5 years now. During this time, it was necessary to make websites on a knee for a few hundred dollars and participate in fairly large projects. For the last year, the feeling of deja vu does not leave me. Somewhere I have already seen: nervous customers, angry managers, piled up with the work of developers and deadlines. At the same time, nothing has changed for me. There were all the same fuzzy, constantly changing demands, pressure, and not a single project submitted on time ...
And this, despite the fact that the “rake” was always the same.
Here I will try to describe the most frequent problems in the management of web projects that I have seen. Probably, much of what was said below can also be attributed to the development of software in general. However, my modest experience in serious software projects will not allow me to make such a generalization. I would also like to note that in all projects I acted as a developer.
So.
General relationship:
Most of my familiar web project managers grew out of developers. In this case, a number of problems often arise.
')
Not every artist has a focus on results. Sometimes, work is perceived as a process. Whereas, the manager, I think, must have a personal interest in the timely delivery of the project. And this should consist not so much in receiving interest, but in a certain mood, world view.
Excessive interest in implementation. That is, instead of managerial functions, the manager begins to dictate the rules of writing code or the formation of architecture.
I remember the case when the developer was promoted to PM. After a while, he looked into the code of the project he was managing and was horrified. “If you want something to be done well, do it yourself,” he said, and took up the coding. At the same time, he was and remains an excellent specialist. Perhaps it was his personal failure, because when the PM starts to deal with the code, it is distracted and loses control over the project.
The nature of the person also plays an important role. I mean the willingness to make decisions and take responsibility for them. Quite often, you can come across a situation where problems arise because of a phone call that was not made at the right time, or because of an unsent letter.
It is worth noting the general attitude to errors. It also happens that because of the fear of superiors, some problems remain unspoken. That after some time can lead to more serious consequences than if the problem was solved at an early stage. (The reflex “garbage raking under the carpet” was not noticed - well, okay.)
And the worst case: “The managers were chasing me, now I’m chasing”.
That is, we are not talking about management, but rather about self-affirmation. At the same time, it is forgotten that the main task of a manager is not to drive employees, but to create conditions for people to work and control the process (so that this functionality is implemented within a specified time frame, for a given budget). Insufficient control is also a common problem. Especially if the PM was a responsible performer.
It is very hard to work with managers who believe that people are a resource. And besides, both managers and developers are all the same employees, they just have different roles in the project.
Timing
Probably one of the most painful topics. Sometimes it seems that PMs live in some kind of their own world. It is clear that the web development market is saturated. And for each client it is necessary to fight, inventing and terms less and the prices are lower. At the same time, it remains a mystery to me, why over and over again to enter a development team in the state of a robbery at the very initial stage of work.
Sometimes there is another approach. The deadlines for performing tasks are specified by the performers. However, few people think about the adequacy of such assessments.
And, as practice shows, the complexity can be underestimated, at best by a quarter.
It also happens that the deadlines are imposed by the customer. This is not such a bad option as it seems. But only under the condition that the customer is ready to agree on the scope of work and adopt a budget (or vice versa).
No project plan
Of course, there is a plan. Only in the head of the manager and that vague. Although, this is usually not a plan at all, but a general understanding of the work required to complete the project. It seems to me that in project management the main task is to create predictability. That by this point in time it is possible with high probability to call the completed (and not completed) scope of work. In case of emergency situations, the plan can help determine the current state of the project, orient oneself faster, and make the right decision. Having a plan gives you another bonus as an opportunity to control the progress of work.
Requirements Management
It seems to me that any project should begin with the collection and analysis of requirements. How else to understand what the client really needs? The problem is that not every customer clearly understands what he wants from this project. When creating websites, this is a fairly common situation. Among the developers, at one time there was even a joke: “One manager comes to us the other day and says: Make me a website.” In this situation, there are two main solutions.
The first is to negotiate and determine the real requirements and the desired result from the creation of the project. Yes, it is not always easy. Sometimes negotiations alone may not be enough. However, with this approach, the likelihood that the customer will really get what he wanted to spend his money on increases.
The second solution is more popular. It is based on the installation “We know what you need.” When choosing this approach, a product made from ready-made modules is sold. For web development, this is probably quite important. Indeed, the regular creation of websites from scratch (if this is possible at all with a large flow of orders) is an excessive waste of resources. But in this case, the customer is imposed a number of restrictions that exist in this finished product. Accordingly, more often a situation arises when the project is ready, and the customer says: “But it turned out not at all what we wanted”.
In addition, the requirements collection process itself deserves special attention. Usually, it happens haphazardly. That is, the requirements are deposited in the memory of the manager, then in the e-mail, then in the ICQ logs. At the same time, it is extremely difficult to control their flow, if not impossible. Add to this the requirements voiced by phone and get the following problems:
Management of risks.
I did not observe full risk management in any web project. It is clear that they, in general, are the same: inadequate assessment of the scope of work and deadlines, delays in agreeing on TK or models, late delivery of equipment, and so on. Moreover, it is not clear why time after time, stepping on the same rake, these risks are ignored. When it is enough just to indicate the corresponding clause in the contract (if it is available, of course).
Yes, such reservations can frighten an ordinary client, who will run away to a competitor only because “these guys will do everything quickly and without unnecessary problems”.
This is also a risk. And regularly deadlines are not a risk to spoil the reputation?
Meetings
Conducting meetings on a web project is quite a rarity. In any case, if they are held, then they usually forget to prepare and send in advance the agenda. Naturally, with such an approach, about the drafting of a protocol in general, speech is not. The meetings themselves often come down to a pair of technical discussions. In the end, it turns out to be a waste of time: what was discussed - it is not clear what decisions were made - nobody remembered what to do next - is also not clear.
Bug work
Few of my acquaintances PM `s could tell me the number of projects in which he participated. The problem is not even so much in bad memory. How much is that few people analyze the results of the project. In the process of writing this article, I even conducted a survey , for the sake of interest. At the time of publication, the leading opinion was “I note it in my head, but I do not document it” - 25.32%. And from the same vote it is clear that only 35% of the respondents conduct a full analysis of the project.
It turns out that the experience of project management does not accumulate. Since, in the absence of the habit of drawing up relevant documents, the managers of the company will also leave their knowledge, which can not always be shared with the case manager. Accordingly, the development process in management can move extremely slowly.
Total:
Perhaps the main problem of web development is in immaturity. In this area there are a lot of young professionals without experience or special education. Many, having received this very initial experience, move on to more serious software projects, freeing up space for newcomers.
Sometimes the question arises, is it advisable to complicate the process of developing sites, introducing a serious project management. You can meet the conviction - “Do not think as better, just make this site. There will be the next project - there you will do everything in the mind. ”It is advisable if it allows to produce a better product in less time. That, accordingly, will lead to decrease in expenses. Plus, a bonus as a more relaxed, predictable work - and this, I think, is one of the keys to reducing employee turnover.
Or maybe the fact is that customers are not yet ready to pay several tens (hundreds) thousand dollars for high-quality development. And really, why, if familiar students do the same work, only for a thousand - one and a half ...
In spite of this, it is increasingly possible to meet technical specifications for creating a website, using User Stories to prepare for design, an iterative approach in developing ... I think this is a good sign that development is going in the right direction.
Original here
I have been doing web development for 5 years now. During this time, it was necessary to make websites on a knee for a few hundred dollars and participate in fairly large projects. For the last year, the feeling of deja vu does not leave me. Somewhere I have already seen: nervous customers, angry managers, piled up with the work of developers and deadlines. At the same time, nothing has changed for me. There were all the same fuzzy, constantly changing demands, pressure, and not a single project submitted on time ...
And this, despite the fact that the “rake” was always the same.
Here I will try to describe the most frequent problems in the management of web projects that I have seen. Probably, much of what was said below can also be attributed to the development of software in general. However, my modest experience in serious software projects will not allow me to make such a generalization. I would also like to note that in all projects I acted as a developer.
So.
General relationship:
Most of my familiar web project managers grew out of developers. In this case, a number of problems often arise.
')
Not every artist has a focus on results. Sometimes, work is perceived as a process. Whereas, the manager, I think, must have a personal interest in the timely delivery of the project. And this should consist not so much in receiving interest, but in a certain mood, world view.
Excessive interest in implementation. That is, instead of managerial functions, the manager begins to dictate the rules of writing code or the formation of architecture.
I remember the case when the developer was promoted to PM. After a while, he looked into the code of the project he was managing and was horrified. “If you want something to be done well, do it yourself,” he said, and took up the coding. At the same time, he was and remains an excellent specialist. Perhaps it was his personal failure, because when the PM starts to deal with the code, it is distracted and loses control over the project.
The nature of the person also plays an important role. I mean the willingness to make decisions and take responsibility for them. Quite often, you can come across a situation where problems arise because of a phone call that was not made at the right time, or because of an unsent letter.
It is worth noting the general attitude to errors. It also happens that because of the fear of superiors, some problems remain unspoken. That after some time can lead to more serious consequences than if the problem was solved at an early stage. (The reflex “garbage raking under the carpet” was not noticed - well, okay.)
And the worst case: “The managers were chasing me, now I’m chasing”.
That is, we are not talking about management, but rather about self-affirmation. At the same time, it is forgotten that the main task of a manager is not to drive employees, but to create conditions for people to work and control the process (so that this functionality is implemented within a specified time frame, for a given budget). Insufficient control is also a common problem. Especially if the PM was a responsible performer.
It is very hard to work with managers who believe that people are a resource. And besides, both managers and developers are all the same employees, they just have different roles in the project.
Timing
Probably one of the most painful topics. Sometimes it seems that PMs live in some kind of their own world. It is clear that the web development market is saturated. And for each client it is necessary to fight, inventing and terms less and the prices are lower. At the same time, it remains a mystery to me, why over and over again to enter a development team in the state of a robbery at the very initial stage of work.
Sometimes there is another approach. The deadlines for performing tasks are specified by the performers. However, few people think about the adequacy of such assessments.
And, as practice shows, the complexity can be underestimated, at best by a quarter.
It also happens that the deadlines are imposed by the customer. This is not such a bad option as it seems. But only under the condition that the customer is ready to agree on the scope of work and adopt a budget (or vice versa).
No project plan
Of course, there is a plan. Only in the head of the manager and that vague. Although, this is usually not a plan at all, but a general understanding of the work required to complete the project. It seems to me that in project management the main task is to create predictability. That by this point in time it is possible with high probability to call the completed (and not completed) scope of work. In case of emergency situations, the plan can help determine the current state of the project, orient oneself faster, and make the right decision. Having a plan gives you another bonus as an opportunity to control the progress of work.
Requirements Management
It seems to me that any project should begin with the collection and analysis of requirements. How else to understand what the client really needs? The problem is that not every customer clearly understands what he wants from this project. When creating websites, this is a fairly common situation. Among the developers, at one time there was even a joke: “One manager comes to us the other day and says: Make me a website.” In this situation, there are two main solutions.
The first is to negotiate and determine the real requirements and the desired result from the creation of the project. Yes, it is not always easy. Sometimes negotiations alone may not be enough. However, with this approach, the likelihood that the customer will really get what he wanted to spend his money on increases.
The second solution is more popular. It is based on the installation “We know what you need.” When choosing this approach, a product made from ready-made modules is sold. For web development, this is probably quite important. Indeed, the regular creation of websites from scratch (if this is possible at all with a large flow of orders) is an excessive waste of resources. But in this case, the customer is imposed a number of restrictions that exist in this finished product. Accordingly, more often a situation arises when the project is ready, and the customer says: “But it turned out not at all what we wanted”.
In addition, the requirements collection process itself deserves special attention. Usually, it happens haphazardly. That is, the requirements are deposited in the memory of the manager, then in the e-mail, then in the ICQ logs. At the same time, it is extremely difficult to control their flow, if not impossible. Add to this the requirements voiced by phone and get the following problems:
- The scope of work is growing, and not controlled.
- Dates change arbitrarily.
- It is impossible to carry out a full design with fuzzy requirements. This may affect the quality of the final product.
- At any time, the customer can refuse his words. As a result - lost time (at best)
- The general list of requirements is not consistent. Accordingly, the final product may not satisfy the customer.
Management of risks.
I did not observe full risk management in any web project. It is clear that they, in general, are the same: inadequate assessment of the scope of work and deadlines, delays in agreeing on TK or models, late delivery of equipment, and so on. Moreover, it is not clear why time after time, stepping on the same rake, these risks are ignored. When it is enough just to indicate the corresponding clause in the contract (if it is available, of course).
Yes, such reservations can frighten an ordinary client, who will run away to a competitor only because “these guys will do everything quickly and without unnecessary problems”.
This is also a risk. And regularly deadlines are not a risk to spoil the reputation?
Meetings
Conducting meetings on a web project is quite a rarity. In any case, if they are held, then they usually forget to prepare and send in advance the agenda. Naturally, with such an approach, about the drafting of a protocol in general, speech is not. The meetings themselves often come down to a pair of technical discussions. In the end, it turns out to be a waste of time: what was discussed - it is not clear what decisions were made - nobody remembered what to do next - is also not clear.
Bug work
Few of my acquaintances PM `s could tell me the number of projects in which he participated. The problem is not even so much in bad memory. How much is that few people analyze the results of the project. In the process of writing this article, I even conducted a survey , for the sake of interest. At the time of publication, the leading opinion was “I note it in my head, but I do not document it” - 25.32%. And from the same vote it is clear that only 35% of the respondents conduct a full analysis of the project.
It turns out that the experience of project management does not accumulate. Since, in the absence of the habit of drawing up relevant documents, the managers of the company will also leave their knowledge, which can not always be shared with the case manager. Accordingly, the development process in management can move extremely slowly.
Total:
Perhaps the main problem of web development is in immaturity. In this area there are a lot of young professionals without experience or special education. Many, having received this very initial experience, move on to more serious software projects, freeing up space for newcomers.
Sometimes the question arises, is it advisable to complicate the process of developing sites, introducing a serious project management. You can meet the conviction - “Do not think as better, just make this site. There will be the next project - there you will do everything in the mind. ”It is advisable if it allows to produce a better product in less time. That, accordingly, will lead to decrease in expenses. Plus, a bonus as a more relaxed, predictable work - and this, I think, is one of the keys to reducing employee turnover.
Or maybe the fact is that customers are not yet ready to pay several tens (hundreds) thousand dollars for high-quality development. And really, why, if familiar students do the same work, only for a thousand - one and a half ...
In spite of this, it is increasingly possible to meet technical specifications for creating a website, using User Stories to prepare for design, an iterative approach in developing ... I think this is a good sign that development is going in the right direction.
Original here
Source: https://habr.com/ru/post/11316/
All Articles