Mistakes are a natural phenomenon that we all face. There is not a single person who does not make mistakes. But all mistakes have different consequences. Some may even be positive, but more often than not a mistake has a negative consequence.
And if mistakes made by people and programmes have long been categorised, for some reason no one is in a hurry to categorise mistakes made by managers (including project managers). Yet it is the mistakes made by managers, project managers and product managers that often have the most serious consequences.
Below we will try to correct this injustice.
Why do we need error grading?
Well, first of all, people are used to classifying everything around them, because it is the scientific approach and comprehensive analysis that help us achieve results. Standardisation is the best friend of technical progress and science. It’s easier to document everything and therefore easier to pass on to the next generation.
But documentation is not the main thing. The accumulation of experience is more important.
Errors can be single or repeated, they can have absolute or relative consequences, they can have a direct or indirect impact on the project, and so on.
Systematising errors helps to predict the probability of their occurrence and thus to take all possible measures to minimise the consequences in situations where they occur, or to prevent them altogether.
In a large organisation, the process of dealing with risks and defects is called risk management, more on this in the article ‘Сorporate Risk Management System’.
By analogy, a management defect classification system (enterprise or project management system) can help.
If the errors are avoidable or have a non-critical impact on the business, those responsible can be penalised according to a predetermined scale — in terms of bonuses or write-offs.
The concept of ‘blame-responsibility’ is always relevant.
Classification of risks in IT projects
IT people and programmers like to detail and categorise more than anyone else. But when you are working with a new project, you have to be ready for anything. Despite the fact that many teams always test their products, and that in many agile project management methodologies (top 10 project management methodologies) defect control and detection is an end-to-end and continuous process, defects still occur. And they occur both during project implementation and after the project has been completed.
How can the handling and correction of errors be speeded up? It is logical to categorise them at the input stage (when receiving feedback from customers or end users), so that in the future the correction functions can be assigned to the people responsible for them, preferably those with the necessary qualifications and authority.
Within each team, there may be different groups of errors, depending on the frequency of occurrence and the specifics of the project architecture.
Sam Kaner, in his book Software Testing, gives the following general classification of defects in software products:
- Interface bugs (UX/UI).
- Error handling logic (to facilitate error detection).
- Computation errors.
- Data processing/interpretation errors (very close to computation).
- Initial and final state problems.
- Workload overruns.
- Rush situations.
- Hardware failures and incompatibilities.
- Identifier (process) control.
- Boundary condition errors.
But even this is far from a benchmark. With the advent of the DevOps approach, the logic of software operations has become much more complex. After all, you can have controlled and uncontrolled environments: network stacks, third-party services, etc.
How can project management errors be categorised?
The most effective system for classifying project management failures can only be developed with reference to a specific team and managers, and with reference to the current conditions of the project and various external factors.
The most universal approach to classifying errors is based on functions and tasks.
What are the Project Manager’s Responsibilities? Earlier we looked at the responsibilities of the Project Administrator, which in many ways overlap with those of the Project Manager (because the Administrator is the right hand of the Team Leader).
If we outline the general tasks, they boil down to planning, ensuring communication, providing the necessary materials and resources, controlling and analysing.
But the project manager does not act alone. They fulfil the instructions of the customer (sponsor, owner, client, etc. — more about stakeholders — those who influence the project in one way or another).
Groups of project management errors according to their source
Project Manager:
- Risk management problems or complete lack of risk management.
- Lack of management of customer (stakeholder) expectations.
- Incorrect assessment of resources available or required to complete the task.
- Lack of change management.
- Wrong communication and motivation system.
- Incorrect management style (e.g. haphazard, overtime, too rigid or, on the contrary, too soft control, etc.).
Client:
- Wrong project evaluation criteria.
- Exaggerated expectations.
- Misunderstanding of some of the project team’s internal processes.
The whole team (including the manager):
- Incorrect estimation of the implementation period (too optimistic, too pessimistic, atypical task that increases the level of uncertainty).
- Incorrect motivation (lack of commitment).
- Unwillingness to adapt to new tasks and goals, especially in the absence of a specific change management programme.
External environment:
- Unstable economic situation in the market or in a specific (important for the project) area.
- Changes in the conditions of suppliers (and even in IT projects there are suppliers).
How to reduce project management errors?
Firstly, the quality of the planning and organisation of the work is greatly influenced by the experience and qualifications of the project manager. It is the project manager who sets the tone in all areas of activity. Self-organising teams are virtually a pipe dream. Therefore, the whole burden of responsibility for any decisions within the team somehow falls on the shoulders of a public or private leader.
Secondly, all potential management errors should be identified (as in a risk matrix) and for each specific error the probability of occurrence and the impact of the consequences (the cost of the error) should be determined. In this way, you can anticipate potential problems and plan ways around them.
Thirdly, team members are equally important. You can formalise all relationships within the team, micromanage operations, but you will still not achieve the efficiency you need. In any team effort, the contribution of each individual is important.
Fourth, the management approach should be as standardised as possible. Everyone should know their duties and tasks, have a clear understanding of deadlines and responsibilities, and have sufficient freedom of action not to slow down the process.
And here we come to one of the most important points — the automation of routine. In order for the team to work, for the manager to plan, for everyone to communicate in a common format, and for progress to be traceable at all times for both the project client and the project participants, a special system of task distribution is needed.
If you want to read examples of typical mistakes in projects, we have a separate material — ‘Why Startups Fail’.
