Any view of project management is always subjective. In this text, I tried to form a comprehensive view of management methods in development, based on the experience of implementing projects in my company – for clients of different areas, budgets and structures.
There are many methodologies, because it is beneficial for the authors
In the modern world of development, there are a large number of different project management methodologies and new ones appear periodically. They can prove to you with foam at the mouth that Scrum is not kanban, agile is not a methodology at all, but confusing waterfall with the V-model is the height of unprofessionalism. In part, these people will be right, because each school has its own unique characteristics, and some are different in nature. However, it should be noted that the release of new works on this topic often aims to earn popularity for the author and does not always carry real semantic value.
In addition, the introduction of new, relevant frameworks is a kind of fashion among the top management of Russian companies, and each new technique sweeps through the corporate world as a wave – first startups, then larger businesses, then large corporations and, finally, state structures. And often we are talking only about the introduction of names, without any changes in the principles of work.
According to the practice of real projects, the main methodologies are two
At the same time, based on real experience on projects, we can say that two approaches are used as the main ones. You can use different terms, but we will conditionally call them Classic (Waterfall in all manifestations) and Flexible (all iterative methods). Their main difference, in the general case, lies in the understanding of the final result. In projects where it is formalized and unchanged, the classical approach is used. In this case, there is usually an artifact that fixes and describes what this result should be (technical task, functional requirements, technical project, etc.). In all other cases, when the outcome of the project is difficult to formalize, it is more logical to use Flexible Methodologies. In such projects, metrics, customer paths, and commercial indicators often serve as benchmarks.
Waterfall is for B2G. Agile – for the product
It can be conditionally considered that of the two main approaches, the first is more suitable for custom development projects, for which tenders are usually held and contractors are hired. It is valuable for performing a specific task – automating a certain process (or several), refactoring legacy systems, systematizing data sets. And the second looks harmonious in product development projects, more often implemented with the help of an internal team. Often in such projects there may be no tasks, but only directions in which it is worth moving in search of a commercial result. Just don’t think of agile methodologies as a way to automate chaos. This task lies outside the development world and is not solved by any of the methodologies 😊
When methods are friendly
However, there are cases when methods intersect, and this intersection can be different:
Often, classical approaches borrow tools from flexible ones and vice versa.
For example, it’s hard to imagine a traditional waterfall development project without daily short status meetings and regular (every 2-3 weeks) demonstrations of the functionality to the client.
On the other hand, often in a product iterative project you can find a schedule (in which case it can be shamefully called a “sprint plan”) – a fundamental artifact of classical project management. It is worth noting that in both cases this is just a loan of instruments, the general principles remain unshakable.
It happens that within the framework of one project, one contract and one customer (even a government customer) there may be different levels of maturity of business processes. For example, for one process there is a certain established practice, regulatory framework and legacy system. And for the other there is only an understanding of its necessity and nothing more. At the same time, the TOR may describe general requirements for automation that are not detailed to the level of specific steps. In this case, you will have to combine approaches. And, perhaps, even within the same team, manage development in different ways. For the first process, to have a consistent schedule of the “analytics-development-testing” format, and for the second, to implement fast delivery of intermediate results to the customer, constantly recording feedback.
It is also impossible to deny the manager the right to radically change the management rules. If there is an understanding that the current paradigm is not leading to the goal in the right time, this can be justified.
For example, when working on an agile methodology, after a certain number of iterations, there is an understanding of a specific goal, as well as time and resource constraints. This can happen for various reasons – the success of RnD, a change in leadership, a lack of budget. Then, for the implementation of the same project, it makes sense to change flexible methods to classical ones in order to come to a modest but real result. And vice versa – when a specific TOR is implemented, new legal acts suddenly appear, the company’s strategy or the purpose of the business process changes. In this case, continuing to work according to the schedule may be useless and switching to an iterative system will greatly increase productivity.
Standards are good. They make it possible to work according to a template if there is not enough experience. They help manage large project offices. They serve as a core and a guide in non-standard situations on the project. But the key competency of a project manager is a skillful combination of methodologies, tools and approaches depending on the needs of the project. That is why it is important not to get carried away by following the standards, but to evaluate the significance of different configurations online. Rule the standards, don’t let the standards rule you!