Translate

December 6, 2016

The Demise of the Project Leader in the DevOps world (Google Translated version)

Disclaimer: This is a translation by Google of the post "De Teloorgang van de Projectleider in de DevOps wereld", which is in Dutch. So bear with me when stumbling over tricky grammar and in case you can read and understand Dutch, head over to the original post by clicking here.

They are still, last week, I have seen one. A real project[manager]. The kind that, when you [ask] him or her, can show a certificate that clearly states that Prince2 course is successfully completed.

The project[manager] is a dying profession. At least, in Software Development. Fortunately, because they have absolutely no business. At least, in Software Development.

The question is why there still are so many project managers in the IT sector. A simple answer is no, but probably it's because we have so many project managers in other sectors. In the construction example, we have developers who realize projects which are then led by project leaders. And just when we compare make the fundamental error in the IT architecture by the IT architect with a 'buildings' architect [1], we do so with project leaders.

We think we need project managers in IT and that is mainly due to that damned waterfall method we used to see in our IT projects since time immemorial. Kolder course, waterfall method, there has never completed a project within the planned budget and completed in the scheduled time period something useful. Can not, because there is no single user that actually knows what he or she wants. Let alone that the user knows what he or she needs.

No wonder that we have our sights now focus on agile methods, the sweetest as they do in Spotify. In brief:


You define an idea, you develop software, you let the user whether it was a good idea and you go on to the next idea.


And so here it happens. This is what comes to light that the project does not belong in IT. Because if you think this cycle is a project, you'll miss it a lot. Also by the way if you think that some of these cycles form a project.

The fundamental problem of the project is that a project is finite. You start on a project and at one time the project is finished. We're ready when the project is finished. And that of course is nonsense for IT projects for IT projects are never finished. Haha, you think now, which is the well-known IT joke that projects always on time and on budget go. But it's not a joke, because when an IT project is completed, it all begins actually.

When the project is in fact finished, the software is used and only then we can work to make it usable it. we look at the project, his or her job done when the project is completed. The project will therefore only give the software to a user. Within time, within budget. Irrespective of the fact whether the software turns out to be usable.

The project thus focuses on what the user wants and not what the user needs. And that is the fundamental reason why IT projects are absurd, and why project managers are disastrous.

We happily watching for a while, so we have a few years ago started with agile. Apart from the agile manifesto [2] and the hype around Scrum, we're in IT for over 20 years, very active in the iterative development with the shortest development cycle. And therefore we are since then, until about 5 years ago, been busy with projects delivering software iteratively. Instead of long journeys waterfall project managers have divided their projects into small waterfalls. We see that iterative projects anticipate less in terms of time and money. But still the user gets what he wants and not what he needs. Or they naturally.

It should be clear; As long as software is developed by project-led projects, then that results in desired unusable software.

And then there was agile and Scrum, and since then the user gets what they need, not necessarily what he wants. By not from the outset to define what functionality the software should provide, but gradually adjust the scope and adapt existing functionality to something useful, we need agile projects that provide something useful.

The really good project managers know to think to this new way of working. It is the type of project that is not immediately shoot the stress is not clear what should lead his team. The scope of the project, but also the duration is thus determined by the budget. The project is over when the money runs out. The Project Manager will, if he or she has heart of the matter, therefore deliver the greatest possible functionality for that budget.

And therefore the project is no longer necessary. Because it makes no sense to scopes projects based on how much money is available. That should be clear.

Then there is another small, tiny, point of focus to work with new agile. Early on, namely as soon as possible, there, in a real agile project, something in production and is used by real users. That may have to be adjusted because it is not usable. And suddenly, the project manager is also responsible for solving production problems.

All, or at least too much, organizations have a galvanic separation between the project and operational management. Change-run organizations with clear, often indefinitely elaborate, hand-over procedures. Different responsibilities and often different budgets. [3] These organizations are full of silos that do the best work by itself, but together are far from optimal.

The Change-Run model does not work in practice. This is often denied. Especially by people who think the waterfall method works. And many of those people are project leaders who deny their demise and otherwise not recognize yet.

They be lost because organizations have projects in IT are extremely absurd. Of course there is a whole group of organizations that is just hip and do not understand why they are. A growing group understands the ups and focuses what is desirable and what is no longer needed.

IT departments transform themselves more and more from project organizations to product organizations. Organizations abandon Change Run divorce and move to DevOps [4]. Specialist teams are dissolved and multifunctional teams are appointed. No software projects to be done, but products developed software. Because there are no projects to be done there are no project managers needed. In any form. However, there are product requires owners. Unfortunately for all those without work-come-to-sitting project, a product owner is no such thing as a project manager. namely the product owner is the owner of a product that understands the product, and above all understand what is and is not usable. He or she is responsible for the product, cradle to grave, from the cradle to the grave so.

He, or she, has the mandate to the functionality offered by any means. Is also another budget responsible for the product. The product owner is not judged by the amount of features that will be hoisted into production in the time available and the available budget, but the value of his or her product for the organization. And that value can only be measured when the product is actually used.

But there is hope for the project. Indeed, there are quite a few product owners who do not understand it yet. They develop their products in a project that has quite a few puffs of a waterfall process. Or at least iteratively. And as long as product owners do not yet fully understand what an MVP [5], the project still work. The current crop of product owners are not sufficiently experienced in the delivery of a thing. The project leader, and certainly one with iterative processes is known, is therefore a big setback for. But for how long?

The tide turns namely, product owners understand more and more what is their role and how they can fill it the best. Organizations are finding that it is not wise to their project to schools to product owners. Apart from the odious Prince2, it also be that the project has sufficient knowledge and often no affinity with the product. That 'one thing' that an organization makes money with it. Product Owners then get out of the business and not like the project leaders from the IT. The project is unnecessary.

Thus the demise of the project is therefore inevitable. Not a matter of if but of when.

As always, thanks for reading this post and I hope that the post has put your thinking. I realize that I quite bluntly go and drop it all pretty black / white. And as with anything on the internet you should this article with a dose of common sense reading. Should you make the nuance. I want to invite you to do that last through the comments of this post. Likely that others also find it interesting to know how you think, and of course there is no doubt that I find it interesting.

PS: There are projects in IT that drop something then never come to more, or evolve. These are the projects that you might be comparing projects from the building. IT infrastructure projects that will be delivered something physical. In the best case will be completed in phases, so that it can be enjoyed quickly yields, but when completed can not really speak of further development. In these cases, a project still certainly useful. But in a world in which more and more infrastructure code is expressed is it rather than product development.


[1] But this article is not about, you want to know what's wrong with that, you can read my blog post about the architect. Which can be found here: https://itarchitectureandstrategy.blogspot.nl/2015/02/how-youll-fail-as-it-architect-when-you.html.
[2] Look at http://agilemanifesto.org/ the manifesto. Read it carefully before you draw your conclusions.
[3] Change-run organizations are the result of not understanding Taylorism. https://en.wikipedia.org/wiki/Scientific_management, like the agile manifesto.
[4] In a DevOps organization working Developers (Dev) and managers (Ops) closely. See also: https://en.wikipedia.org/wiki/DevOps
[5] A MVP Minimum Viable Product, is a version of a product with the minimum set of functionality to still create value for the user. See also: https://en.wikipedia.org/wiki/Minimum_viable_product