As with software engineering, there is a great deal of overlap. Depending on the environment and organization, the two disciplines can be disjoint, partially intersecting, or one can be seen as a subset of the other.
While there is no standard relationship, the project manager and the systems engineer encompass the technical and managerial leadership of a project between them, which requires the enterprise of each project manager and system engineer to work out the particular details for their own context.
These sources describe the importance of understanding the scope of the work at hand, how to plan for critical activities, how to manage efforts while reducing risk, and how to successfully deliver value to a customer. The systems engineer working on a project will plan, monitor, confront risk, and deliver the technical aspects of the project, while the project manager is concerned with the same kinds of activities for the overall project.
Because of these shared concerns, at times there may be confusion and tension between the roles of the project manager and the systems engineer on a given project.
As shown in Figure 2, on some projects there is no overlap in responsibility. On other projects, there may be shared responsibilities for planning and managing activities.
In some cases, particularly for smaller projects, the project manager may also be the lead technical member of the team performing both roles of project manager and systems engineer. Regardless of how the roles are divided up on a given project, the best way to reduce confusion is to explicitly describe the roles and responsibilities of the project manager and the systems engineer, as well as other key team members. The PMP is the master planning document for the project. It describes all activities, including technical activities, to be integrated and controlled during the life of the program.
The SEMP is the master planning document for the systems engineering technical elements. For example, in the INCOSE Handbook on Systems Engineering the crucial tasks of defining and refining the scope and requirements for the work are regarded as technical processes rather than a project management process. We will look deeper into the particular issue of requirements management later in the article. The cross reference matrix shows that apparently no Systems Engineering processes are dedicated to cost management.
Instead you will find cost management covered as follows:. This framework itself is created in the Project Management domain.
The idea of recognizing the two domains as two different mindsets is supported by the joint studies of INCOSE and PMI on better integration of program management and systems engineering [11].
When comparing numbers of sections and pages spent on requirements management in the PMI and INCOSE handbooks respectively a difference in approach for the two domains emerges: Much more effort is being put into requirements in the systems engineering domain. Clearly the System Engineering domain considers requirements definition and refining as crucial processes and keys to success.
This is probably one of the reasons that many practitioners sometimes feels that this mindset is easier to connect to and apply in daily project work than the more management-oriented approach found in the Project Management domain.
The idea of requirements management being the link between the two domains is supported by Forsberg et al [12]. The main principles of the V-model is that you keep tracking and checking your requirements refining and translation into specifications iteratively as you proceed vertically along the lifecycle, and for each level of detail in the design process you have to consider the horizontal alignment requirements and design with the final verification and validation processes.
A simple, easy-to read description of the model can be found in [16]. In figs 4 and 5 is shown a "generic" graphic presentation of the V-model, clear of specific software development terminology:. The horizontal alignment is an important feature of the model which facilitates a constant internal refining of the understanding of and sharpening of the definition for the requirements.
It also supports the tendering and commissioning processes by ensuring that the acceptance criteria for the individual components and deliveries are thoroughly thought out and aligned with the baseline user requirements. First of all, models like the V-model provides the project management practitioner with i. Although the V model is borne within domain of complex software and hardware engineering there is no reason why it should not be applicable for other types of project, e.
A number of tools for managing particular types of requirements exists, see e. What the V-model can do for us in this case is to help us manage and facilitate the defining and refining of these requirements constantly focusing on the final verification and customer satisfaction, see examples of steps in fig 6 below:. Many project management practitioners struggle everyday with projects which in neither size nor complexity are nowhere near the iconic mega projects from which the Project Management and the Systems Engineering professional standards and methods are developed.
And many do not have the resources available to conduct textbook Project Management or Systems Engineering. What the practitioners really need are advice on how to scale down the management task into something remotely accomplish-able, and how to pick the best concepts from both domains.
As shown in this article the two domains are in fact a bit different in their approach and mindset, and each of them would probably appeal to different kinds of project practitioners, depending on their professional upbringing and working context. For the devoted engineer in charge of integrating a new high bay storage system in an old building on a tight time schedule the Project Management approach may just be superficial management-speak creating little practical value.
A multi-purpose practitioner would argue that both views are wrong, of course. Those who argue that project management processes are "just waste of paper" are sometimes the ones who have not themselves been up to thinking through their own project! And all projects can benefit from the mindset of Systems Engineering, in particular a practitioner will argue the commitment to requirements definition and refining found is this domain.
Requirements Management is the field where engineering meets the human factor, and where the project manager realizes that all projects originates from basic needs and ideas of humans.
And that in translating these requirements into engineering entities, the project management practitioner must never lose track of these baseline requirements for the system to function as a whole. As a lot of the recurrent calamities in projects e. In particular the V-Model seems to be a good choice. Jump to: navigation , search. Developed by Klaus Pallesen Contents. Namespaces Page Discussion. Views Read View source View history.
0コメント