How do we get the focus “off of delivery approaches” and “back on project management” in our profession?

Hi George,

What makes software unusual is that many modern organisations expect innovation and change of their software and data assets to be a continuous, business-as-usual activity rather than something achieved only under the temporary remit of a project. If you need to switch to project management mode in order to accelerate technical change then that suggests your delivery practices may be insufficiently mature and scalable. That's why software development tends to focus on continuous delivery and product management instead of project management.

Suppose you are already achieving daily release cycles that are continuously adjusted to match business priorities and value streams, then what does switching the focus to project management actually mean in that context? "Project" by definition means something temporary but the question in the CIO/CDOs mind these days has to be why would you want to make *temporary* improvements to the way software is delivered rather than permanent improvements?

David,

Thank you for the background to my additional question on why you believe that the “… pace of innovation –is- moving beyond project management.”

I’ve been in the software development industry for four decades, and understand the mindset that you are portraying that “organizations want innovation and change of their software and data assets to be a continuous, business-as-usual activity.” I understand it because part of my mandate is to deliver just that; however, this mindset (in my opinion) does not negate or lessen the value or purpose of projects (i.e., a temporary endeavor purposed to …) or project management.

For example:

• When an enterprise capitalizes its software development (i.e., turns the software into an asset that gets depreciated over time), there must be a structured, thought-out program with a beginning and an end (i.e., a project). Otherwise, accounting for the cost and legitimacy of said development and withstanding an audit’s scrutiny is unlikely. In this situation, the delivery approach is not material to this capitalization question, only that a product/asset is objectively delivered and adopted into the organization.


• Even when expensing (i.e., not capitalizing) software development, enterprises want accountable programs that define the objectives and goals of a product and provide means to measure and track it, including whether the delivery of said product met the stated objectives and goals. Again, the delivery approach is not material to this question of delivery accountability.

I have never known an organization that does not (at some level) have a milestone that states a demarcation line between Delivery and Maintenance/CI. The line may purposely be fluid, but accountable practices demand a milestone, which I would define as an “end,” although it may not feel that way to the development team who continues in their circular life-cycle pattern.

Project management is all about accountability (stated simplistically for purposes of my point), and I would additionally add that this accountability is “separate” from concerns related to delivery approaches. Yes, the project is concerned with the delivery approach, but its purpose and value rise way above the delivery practice concern.

So, I understand your statement and recognize its validity, but firmly believe that it has NO incompatibility with project management principles and its value proposition.

George

This is a good topic, and I have to agree with a few earlier people that this is mostly a self-inflicted wound from PMI and project managers. We've done this in a few ways.

First, because of the obstinate insistence that "Agility" is a new type of project management. It is not. But I can scan this forum every week and find discussions about the "Agile Project Methodology" or something similar, despite decades of corrections from people inside and outside PMI. This naturally leads to the exhausting "Agile vs Waterfall" debate, which should not exist.

Another way we create this problem is by focusing on software projects at the expense of all other types of projects. A few people have mentioned this. I'll be the first to say that there are lessons learned from every industry which we could potentially be applied to projects in other industries. Software developers didn't invent business agility, they applied lessons learned over decades of R&D and manufacturing. I think we can take some of the principles they practice and apply them to other projects. But we've become so obsessed with managing software projects that we ignore other industries, and I fear this has damaged PMI's brand and reputation. I know there's a lot of money in IT, but I think it would be a good strategic move for PMI to step back from IT and reclaim their position as the leading authority on project management as a profession across all industries.

Closely coupled with this is the mad dash to get on board the certification bandwagon. PMI owns the PMP, which is one of the most widely recognized and respected certifications relating to project management. Others are nice to haves, but I believe they've become a distraction. Look how many ad nauseum Agile certifications exist in some form or another, and PMI is adding to the noise and confusion. We should partner with respected Agile authorities, not simply buy our way into the market so we can hunt more certificate shoppers. And PMs, you're the cause of this. The reason there are so many worthless so-called "certifications" out there is because there are so many so-called "project managers" who are willing to throw good money at consultants who will show you a PowerPoint and sell you a certification, all so you can add more alphabet soup characters to your crowded resume.

Other people see these things and recognize them for what they are. That's why they get such a bitter taste in their mouths for all things project management. We're not under siege, we're experiencing the effects of a bad reputation.

Sorry for the rant. All criticisms should come with recommendations, right? PMs, continue to learn and adapt, but do so to grow your craft, not to add letters to your resume. In fact, you should only list 2 or 3 certifications on your resume, and one of them should be the PMP. If you don't have the PMP, make that your focus. PMI, you need to retain what you've learned about software development and continue to make room for Agilists, but not at the expense of the brand that you've built as the leading authority on the PM profession. We're not a software organization, we're a project management organization.