Assumption Constraints, Constraints, Dependencies and Commitments in IT Project Planning The sixth edition of the PMP Training has included a large number of project assumptions and project constraints in the knowledge system, which are the content to be determined when formulating project plans and sub-plans.
PMP training program assumptions can be simply understood as strict and non-strict: Strict meaning is something or event at the current point in time that cannot be determined according to the various tools currently available, and these events will affect your project.
Your project was carried out under assumptions. Since the assumptions are uncertain factors, all assumptions for all projects are the risks of the project, but the severity of the risks is different, and the key risks should be converted into the risks of the project, and the risks should be analyzed and tracked in the follow-up. For example, if the project status quo is that there are no testers, you can assume that when the project enters the testing phase, it can recruit two testers who meet the requirements. At the same time, this assumption can be translated into a risk, that is, there may be a risk that testers will not be recruited, which will affect the test and the overall schedule.
PMP training in the non-strict assumption of the meaning of the assumption, for example, we often discuss problems with others like to say that the assumption that your statement is correct, this should be said to be a non-strict meaning of the hypothesis, because at this point at that time whether his statement is correct can be judged by other evaluation methods or tools, is a confirmation of things, And not a predictive thing that is not confirmed in the long term. So for a thing or event that cannot be evaluated according to existing conditions at the level of oneself or the organization. This can also be used as a hypothesis.
At the beginning of the project, we may not have a very systematic set of assessment and assessment tools to assess whether the skills of each of our project members meet the requirements, so we can make a hypothesis that each member of the project meets the skills requirements of the organization or the project. Constraints, on the other hand, mean that all internal or external factors that are restrictive to your project can be used as constraints. Constraints have technical constraints, such as the development of a system must be distributed, or constraints may be non-technical, such as constraints on the resources or costs of the project.
Constraints should be an objective factor that does not change in the course of the project, so for example, if there are new employee skills in the project that cannot meet the requirements, it should not be used as a constraint on the project, because this constraint is dynamically changing, and this constraint may not be established during the process of the project due to the improvement of the skills of new employees. In addition, constraints can also be converted into risks for tracking, such as the risk that a project may not be met by a constraint.
Project constraints, project dependencies and commitments are divided into project internal and external to the project. Dependence and commitment are inextricably linked.
Downstream processes rely on the output of the upstream process, and the upstream process needs to make a commitment at which point in time to hand over the work piece to the downstream process. The internal dependencies of the project can be reflected in the Gantt chart of the schedule, and after we sort the tasks and analyze the dependencies of the tasks, we can derive the key operations of the project according to the network diagram to arrange the project resources.
External dependencies are mainly supported by a task in the project that requires external outputs, such as a development phase task that requires a common component provided by another project. Because external dependencies are not reflected in the project schedule, and external dependencies are often beyond the control of the project itself, external dependencies should be tracked through a special tracking table, and more relevant communication and confirmation work should be done in advance.
The commitment within the project is an important part of the project progress tracking, the project manager issued a task to the project members, the project member accepted the project task on the default commitment to be able to complete the task at the relevant time point, the project manager needs to track and confirm whether the task can be completed on time.
The project's external commitments may be many, such as the project promises to give other projects a common interface at a certain point in time, and the project promises to officially release the version on which day. Whether it is a project's internal or external commitment, it is best to translate it into a project-specific task, so that the project can be tracked and controlled.
No comments:
Post a Comment