November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
In some industries, or parts of companies, you may not be able to. Consider a software development department (or company) that both develops new features and fixes bugs for a product that has already been released. They have several customers. Their focus is going to be the next release for the majority of the life of the software. When a different team in the organization develops new software, it might be using either an adaptive or predictive approach, but the goal is still to release the product and then move into a regular cadence of releases.
Now consider one of their customers. The customer has an old solution and wants to change to the solution from this company. There's going to be process changes, custom configuration (no coding; it's SaaS), data migration, etc. The disciplines of project management and organizational change management will be needed for the implementation.
Six months later, there is a new release. Because the software is SaaS and the only customizations were in config and some fields in the database, the company doesn't need a project to run the upgrade; just a few people to validate the changes. They might not even need downtime to push the changes to production. No more waiting a few years to do a major upgrade due to how complicated and time consuming it can be.
Maslow is reported to have said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” Has Project Management become the hammer? Do we treat everything that looks like a project, or that once was ran as a project, as a nail?
I think the perceived issue you are talking about occurs in the field of software development. I'm not aware of any conflict between delivery approach and PM in other professions (but that may be just because I lack that broader experience).
If you are building a bridge or a skyscraper you will need a project manager. But building software is nothing like a construction project. With software it makes far more sense to focus on products rather than projects. If your product delivery process is sufficiently adaptable then you won't need project management to take over the reins. That's the reason for the tension you describe: invoking PM implies that the bigger picture product management is somehow not doing an effective job. In that case, fix your product management, don't introduce project management.
Hi @Aaron and Mr. @A,
Project managers find their sweet spot in their ability to manage and resolve issues and address concerns beyond the delivery approach layer. Are they concerned about the delivery approach? Absolutely, but once chosen from due diligence, they “manage to it” based on its heart-beat.
My strategic concern is the implied and explicit messaging that diminishes our profession. Are we losing the battle-of-the-narrative and/or do we need to adjust our tactics?
--- Maybe, I’m just a little too sensitive.
these are valid concerns and highlight the importance in project managers demonstrating value beyond the "mechanics" of the profession and more on their business acumen, judgment and other soft skill competencies.
Hi George, I liked the first paragraph the most.
"In a sense, project management is under siege, as our legitimacy is under attack by hyper enthusiasts, generally from the agile front. They do their best to associate project management and the PMP certification directly to waterfall practices, and since the “state of agile” has declared waterfalls extinct, well, what value does the PMP certification have?"
They are not hyper enthusiasts. They are the ones who think that all projects are like software projects, where changes are as easy as add/mod/delete some lines of code. It is not so, in streams like hard core engineering, procurement and construction projects. This aspect they miss out entirely and are not willing to understand.
If the only tool I have is a hammer, everything else looks like a hammer. Similarly If, one has exposure to only software projects, it is assumed that all projects are like software projects or product development. Hope they have not heard of the Burj Khalifa's and the Metro rails yet.
Is project management really "under siege" in, say, construction or manufacturing? I don't know. If so then maybe there are issues specific to those domains that are worth addressing. I suppose it doesn't necessarily indicate a general problem with the perception of PMs.
In the technology space it's true that the emphasis these days tends to be on product management, value streams and dev-ops style delivery. The role of what we have previously called project management is in decline. That is of course due to the nature of that work and the pace of innovation, moving beyond project management therefore makes perfect sense for technology products and technology change programmes. Many former tech PMs have adapted by taking on roles in product management or agile coaching instead.
You mentioned the "state of agile". Are you referring to the annual report of that name (stateofagile.com)? That report is almost exclusively about software and tech across various industries. I don't suppose anyone will interpret it as giving a view of the state of PM as a whole. Or did you have something else in mind?
The problem has been created in the market by the PMI itself
without proposing it. PMI has contributed a lot to create in the market two perception: 1-focus on process instead of solution. 2-software focus instead of generalistic focus. In fact, tha last one, is reinforced today with the push in DA, because if you read or asking to the leads of DA inside the PMI it is focused on software (while in my personal case I used it beyond software projects from long time ago). TIme ago PMI is trying to change it talking about things like "project economy" and things like that. So, what you state depends on you as project manager. About software, the problem is most of the people that talk about Agile really do not undersand about Agile. Why? The answer is here, in the Manifesto for Software Development itself: https://agilemanifesto.org/history.html
Management is the science of selecting the most effective approach, process and tools to deliver the objective within the constraints. Ideally one gets to adopt and adapt from numerous options rather than re-inventing the wheel. I got involved with PMI back in the late 80s as I was responsible for delivering projects and recognized that others were as well. I felt I was re-inventing the wheel
The nature of the project, and one's personal experience, may cause you to lean more heavily towards one "theory" versus another (Agile vs Waterfall). However, the objective is not to tailor a project to fit an approach but to tailor the approach to effectively deliver the project.
My experience is mostly with infrastructure initiatives (roads, bridges, buildings, cleanups, refurbishments, etc.) but that does not mean I can't take advantage of tools developed in the software delivery business. I will look for an advantage anywhere it may present itself.
My “under siege” reference is specifically referring to the software space, and the “state of agile” reference is metaphorical referring to those in the agile community who speak-out against practices not of their own. You can read my commentary on this subject area from my recent article: Danger: Waterfall Approaches
I’m interested in your statement that the “… pace of innovation -is- moving beyond project management.”
Can you provide more in-depth thoughts on this, that is, your basis for this belief?
I should have qualified my “under siege” reference to the software or technology-based space. Good points!
Please login or join to reply