Hypothesis constraint dependency and commitment in IT Project Management

Original article: http://blog.sina.com.cn/u/493a8455010003ko
Source: Mythical BLOG of man and month

The hypothetical constraint dependency and commitment in the project are the content to be determined during the preparation of the project plan.

Project hypothesis is strictly and non-strictly: strictly means things or events that cannot be determined at the current time point based on the various tools currently in place, and these events will affect your project. Your project is implemented with the assumption that the conditions are true. Due to uncertainties, all the assumptions of all projects are project risks, but the risk severity is different. The key risks should be converted into project risks, conduct risk analysis and tracking in the future. For example, if there is no tester in the project, you can assume that when the project enters the testing stage, you can recruit two qualified testers. At the same time, this assumption can be converted to a risk, that is, there may be a risk that testing personnel cannot be recruited, which may affect the testing and overall progress. In addition, we also want to talk about non-strict assumptions. For example, when we often discuss issues with others, we love to say that your statement is correct. This should be a non-strict assumption, at that time, whether his statement was correct or not can be determined by other evaluation methods or tools is a confirmation, rather than a forward unconfirmed prediction. Therefore, a current thing or event that cannot be evaluated based on existing conditions of itself or organization level. This can also be used as a hypothesis. At the beginning of the project, we may not have a systematic evaluation and evaluation tool to assess whether the skills of each project member meet the requirements. Therefore, we can make a hypothesis, assume that each member of the project meets the skills required by the organization or project. Constraints refer to any internal or external factors that are restrictive to your project. Technical constraints. For example, system development must adopt distributed technology. Constraints may also be non-technical, such as project resource or cost constraints. Constraints should be an objective factor that will not change during the project process. For example, new employees in the project cannot meet the requirements, which should not be considered a constraint of the project, because the constraint is dynamic and changing, this constraint may not be applied due to the skill improvement of new employees during the project. In addition, constraints can also be converted to risks for tracking. For example, a project may be stored in a risk that cannot be met by a certain constraint. Project dependencies and commitments are divided into external projects within the project. Dependency and commitment are close. The downstream process depends on the output of the upstream process, and the upstream process must make a commitment at which time to hand over the workpiece to the downstream process. Dependencies within the project can be reflected in the Gantt chart of the progress plan, after sorting the tasks and analyzing the dependencies of the tasks, we can draw the key processes of the project based on the network diagram to arrange the project resources. The external dependency of the project is mainly because a task in the project needs to provide relevant output for support, for example, a development task requires a public component provided by another project. Because external dependencies are not reflected in the project schedule, and many times the project itself is unable to control external dependencies, external dependencies should be tracked through specialized tracking tables, we need to do more relevant communication and confirmation work in advance. The commitment within the project is an important part of project progress tracking. The tasks assigned by the Project Manager to project members are as follows, when a project Member accepts a project task, the default commitment is to complete the task at the relevant time point, and the project manager needs to track and confirm whether the task can be completed on time. The project may have many external commitments. For example, the project promises to provide a public interface to other projects at a certain time point, and the project promises to officially release the version on which day. Whether it is the Project's internal or external commitment, it is best to convert it into a specific Project task, so that the Project can be tracked and controlled.