I participate in several project management forums. A recent posting resurfaced some ideas that I find down right arcane.
- Projects have two parts - product and process. This is the antithesis of good Systems Engineering.
- Work Breakdown Structures are defined independent of their use. This is not very useful in practice and ignores the business process side of projects.
These two ideas come straight out of PMBOK-style thinking. Thinking that says there is a "body of knowledge" that can be applied across the board to projects from a variety of domains. Now I know that's not the literal intent of the authors of PMBOK, but the recurring theme is...
"we can talk about project management processes in the absence of a project"
If there is anything good that will come out of Agile Project Management it is that we must invert the conversation and start from the point of view of the project domain - business requirements for project management, NOT the project management processes independent of this business need. Otherwise project management is a solution looking for a problem, and ll problems look like the solution will solve them. This is an exaggeration of course, but exaggerating for effect is useful here. So to the point...
- Seamlessly integrating Process and Product is the role of Systems Engineering. Although systems engineering is not well known in the IT domain, it is the core operating process in aerospace, autos, and many other technology based business areas. The starting point for systems engineering information is INCOSE (www.incose.org)
- The use of a Work Breakdown Structure (WBS) as the ONLY description of work is not only ill-informed it is bad management. The current method of managing large complex projects is Integrated Master Plan / Integrated Master Schedule (IMP/IMS). The WBS is ONE element of IMP/IMS (it's a field in the IMS). But the WBS is a cost collection point, it does not represent the description of the work. The IMP and the IMS represent the work through their Program Events, Significant Accomplishments, and Accomplishment Criteria.
I've never really liked the PMBOK approach from day one and now I know why...one size does not fit all.
