An ongoing discussion of sorts takes place on the New Grange forum regarding the PMBOK view of Product Scope and Project Scope. This is an old discussion based in the 1996 version of PMBOK. I work in a program/project management world where PMBOK is not our frame of reference. Systems Engineering is the paradigm.
Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. [INCOSE 2005]
This is a broad definition, but one of the outcomes is that the product scope and the project scope are the same thing. Product development (usually a single flying machine for us) and the project activities that manage that development is indistinguishable. Not because they are the same work activities. Planners plan. Propulsion engineers design propulsion systems. Risk analysis engineers analyze risk. No, they are not separated because its not good for the program to separate them. The term "integrated" is not only operative it is a critical success factor to the program.
I work in planning, there is not the singular concept of "project management." There is a Program Manager and his Deputies, but planning plans. Cost analyst analyze cost. We all have our individual jobs on the program. But in the end it is an integrated team, usually led by the Chief Engineer and the Systems Engineering, Integration, Test (SEIT) team.
The SEIT approach provides "roles" for the participants. This roles approach blends product and process into a project or program. Making distinctions between product scope and project scope is a "manufacturing" paradigm, based on the processes of the late 80's and early 90's. It's also a paradigm that serves well those teaching project management, since they can talk about the project scope management process independent of any product or business scope processes. The trouble is of course that when product and project are blended together they don't have much to talk about.
What came out of the posting exchange (besides the usual, "PMBOK says this and therefore it must be correct") is the realization that the Systems Engineering approach is a super set of Agile Project Management. The 12 roles of Systems Engineering is a good starting point. As well, any papers by Sarah A. Sheard are worth the search, since the paradigm of systems engineering has much to say about how Agile Project Management can evolve into a mature process, leaving behind the artificial separations required by PMBOK. Focusing instead on the holistic approaches of Systems Engineering and Agile Project Management.
