Why Project Management?
Do agile software development projects require the application of classic project management methods? And if so, in what cases?
With the agile developments of recent years, the question arises what about project management, which is also referred to as "classic". It seemed to get on a sidetrack. But still it doesn't appear to have been completely written off. You can see this, among other things, when you look at the market demand for freelance project managers. There and in various publications you often see the term “hybrid project management” within this context. This means the combined application of agile and classical principles and methods.
First a clarification: Agile methods such as Scrum or Kanban are mainly software development and less project management methods. For example, Mike Cohn, one of the pioneers of Scrum, speaks of "software development using Scrum" as opposed to "project management using Scrum".
Scrum does include management aspects, for example by making suggestions for the organization of meetings (daily/stand-up), planning (incremental, sprints, backlog) and leadership (facilitation, self-organising). Nevertheless, technical development aspects are of great, if not greater importance. These are principles and practices such as continuous integration, continuous improvement, pair programming, less pre-documentation and instead more user interaction, design for change, test-driven development and focus on test automation.
The 'traditional' project management in no way excludes these practices. In fact, it does not make any statements about this, because it is not a development method after all.
Of course, you can use Scrum in projects that include software development, but also excellent in situations that are not projects, but rather operational maintenance situations; then, not every software development is a project.
Project or not? Where is the difference?
A project is best characterized by its uniqueness. It has a clear goal, limited in time and content. The team is/was composed solely for the purpose of achieving this goal and most likely comes from different organizational units or even companies. It is clear in advance when it will cease to exist. The project result is of strategic importance to the organization. It could even be a milestone in its history. It is not just one of the many steps, but the completion of a journey that ideally originated from a clear vision.
In short, PMI expresses this as follows: "a temporary endeavor, undertaken to create a unique product, service or result" (2)
In an operational situation, there is a permanent team whose lifespan is not explicitly defined. It works in a kind of factory mode where one release after another is produced - seemingly indefinitely. The development activities of such a team support the (strategic) organizational goals, but apart from the individual sprints and releases do not in themselves pursue a goal defined in terms of time and content.
Sometimes one comes across situations where people speak of a project, but which, on closer inspection, can rather be characterized as operational maintenance. For example, this is the case where a new CRM system was developed and launched as a project several years ago, the team has survived and produces new releases with new features over the years.
Often there is, of course, a certain gray area in the distinction between a project and operational situations.
Back to the original question: why project management? Or in other words; when is project management useful?
It should be clear that project management has little added value in an operational situation. On the other hand, using a development methodology like Scrum can be tremendously useful in such a situation. The Management elements contained therein related to scheduling and tracking tasks is fully adequate here.
Scrum has brought many improvements here in recent years, especially for organizations that previously used to work without a defined methodology or attempted to misapply project management by treating every system change, no matter how small, as a "project".
Now let’s talk about "real" projects:
Is project management useful here? Or is the application of a development method such as Scrum sufficient here too?
The answer is: it depends
From an entrepreneurial point of view, every project is an investment, in other words a targeted use of scarce resources. Scarce in the sense that these resources could have been used elsewhere as well. When making the conscious choice to carry out the project, the company considers the chosen application as the most cost-effective.
This decision-aspect in the case of a project and the fact that it assumes certain assumptions and expectations are elementary. Because the essence of project management lies monitoring how this decision works out respectively in implementing the measures that make sure the client's entrepreneurial expectations (return on investment) will be met. It repeatedly checks whether the investment decision is still valid or perhaps should be revised, meaning to say, the project should be dissolved and the funds re-allocated.
The question of whether and, if so, how much project management a project needs, mainly depends on the considerations of the clients.
• Do they actually see the project as an investment decision? Or do they rather consider it to be without alternative?
• Do they monitor their investment decisions very explicitly and consciously or rather roughly?
• Do clients use precise calculations when making decisions? Is there a culture of comprehensive and highly accurate spreadsheets, budget accountability and reporting?
When do you not need it?
In some cases, the above questions are answered negative.
Within this context, PMI also refers to the influence of the organizational structure on projects and makes a distinction between project-based and non-project-based or functionally structured companies. Both are displayed in a matrix (2):
Organizational structure influences on projects (Source: PMI)
Projects that take place in functional or 'weak matrix' organizations and where the project manager is given little authority will typically require less project management methodology.
Sometimes the client puts his focus purely on the time aspect and sees project management only as all that is the person who makes sure that "all tasks are done". Under certain circumstances, keeping a task list can be sufficient here.
When do you need it?
There are three types of circumstances where applying project management practices makes sense:
Monitoring of investment
Management of strong external dependencies
Self- and teamorganization
1. Monitoring of investment
Situations in which accurate investment monitoring is required call for project management in the classic sense. In concrete terms, this means that the well-known "project management triangle" is essential:
Content (quality)
Time
Budget
The customer's investment decision is accompanied by an expected return based on a certain assumption about the substantive result (content), when it will be delivered (time) and how much it will cost (budget).
These three dimensions of the project must now be balanced in such a way that the expected return is achieved; the core task of the project manager.
It should be clear that this is not something static, but that it continuously considers dynamically changing circumstances along all three dimensions. The central point is that at all times the client must be able to take a well-considered decision about continuation of his investment from a, albeit continuously changing, planned situation. This depends on well-founded and realistic estimates and planning and a continuous planning process during the course of the project.
The situation described above will mainly apply to organizations that In PMI terminology are characterized as "projectized" or "strong matrix".
2. Management of strong external dependencies
But even if no investment monitoring is required, using classic project management methods can be beneficial. This is the case, for example, when there are critical external dependencies that require a thorough and extensive monitoring of time and content (less budget).
For example, with the completion of a project, which processes are automated, staff reductions are planned. Sometimes there are legal requirements regarding implementation.
A merger of two companies and their full IT-integration can create a massive complex of dependencies that require precise planning and project management to ensure compliance.
3. Self- and teamorganization
Applying project management methods is not only useful because it provides the client with control and decision-making capabilities or monitors essential dependencies, but it also helps the project manager himself and therefore his team, especially in complex projects.
For example, it can be useful to create a status report, even if no one reads it (anybody not familiar with this?) because its creation forces the project manager to think about his project, to get status information on various matters, set priorities (problems) and to anticipate problems (risks).
A well-designed project plan provides a project team with orientation and motivation; it meets the needs of those involved who want to know where the journey (beyond the upcoming sprint) is going.
Last but not least, project management methods provide good starting points for managing programs and project portfolios.
Are agile methods and 'classic' project management mutually exclusive?
It should be clear from the explanations above that this is not the case. Both serve different needs and complement each other; Every software development project needs a development methodology in one way or another; that much is clear. And there is currently a broad consensus that agile methods, especially Scrum, are the tool of choice here.
Depending on the client's expectations or the circumstances of the project, as explained above this can/should be supplemented with "classic" project management.
Literature:
1. Mike Cohen: Succeeding with Agile - Software Development with Scrum, Addison-Wesley, May 2010
2. Project Management Institute (PMI): Project Management Body of Knowledge (PMBOK)