September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
I have no insider knowledge, but it seems that one of PMI's big challenges is that project management (as a profession) spans such diverse domains. Projects could be managed very differently in construction, healthcare, R&D, manufacturing, engineering, or software development, etc, and yet the PMBOK needs to accommodate all of these.
Yet this can be one of PMI's greatest assets, as a bridge between diverse industries. Modern software development practices didn't simply emerge from nowhere, for example; they borrowed (and continue to borrow) heavily from manufacturing and research practices. Now, other industries are studying the way software is developed and delivered to see if there are principles and practices that can be adopted. The Project Management profession could be a significant enabler for this sort of inter-industry dialogue, and facilitating these conversations will allow us to stay relevant as practices continue to evolve (or as in many cases, practices are re-discovered).
A major gap is guidance on tailoring the approach to project management to best fit the needs of a given project balancing control and delivery objectives.
The last edition of the PMBOK Guide is starting to provide some of that, but there's a long way to go...
Since the only thing constant is change, I think we can always keep learning and growing in our professions. I'm always amazed at how I can learn things in one domain area that wind up having a useful application in places they were never even considered.
On the PMI side I think the PMBoK could use a tune-up. I see that some entropy has crept into the use of language and their models of process groups. More significantly, I think there is work to be done where the project and product views intersect. I like your term "architectural awareness" on the topic, and I see no end of discussions of the PM role and the importance of technical knowledge. Whenever I'm looking through the PMBoK itself, I have to remind myself that the product development is out of scope, even though it's critical to the project, while when I have my Systems Engineer hat on, it's the product level view that's central and the PM view supporting.
To piggy back on Keith, I think it behooves us a project manager to recognize that our project outputs change the organizations receiving them. To that end, we should add more focus on organizational change management. I know PMI has a practice guide but we need a lot more. I would love to see a PMI-CMP accreditation.
The PMBoK’s purposeful abstraction of the product development view is its strength as a generic body of knowledge, and its "Achilles heel" for those looking to bridge the gap on technical and delivery questions. At least PMI listens and adapts to keep itself and our profession relevant, as they have done in extending itself in the area domain knowledge via the Talent Triangle and other initiatives. Maybe not as fast as we would like to see, but the ship does turn.
From a practice point of view, I personally reconcile a hybrid approach of processes and techniques from PMBoK, Prince2, and Agile for my projects, of which purists from each camp would likely find fault. However, it meets the “Product Development” requirements I have when I’m wearing (like you) my systems engineering or architects’ hat.
The profession does not require tuning , the individual needs to tune their practices to make the profession provide more impact to themselves and the firm they represent.
Please login or join to reply