Dependencies are the bane of a project schedule, or as one of the developers in a team told me, dependencies and other risks are the reason that a team needs a Project or a Program Manager. I have had informal discussions with some of the senior members of the team, as well as the members of the management team, and there is a lot of discomfort in handling the various dependencies that bedevil a project; as well as doing all the negotiations that are required to mitigate the risk of a dependency, or when the dependency causes a problem to the project.
What am I talking about ? Well, consider the fact that in today's world, most projects have a lot of dependency on items outside the control of the core team. You may be getting some work done from outside the core team by an external team, you may be picking up a component that has been created by an external team (which can be somebody who you pay for delivering the component, or you may be picking up a component that is being done by a open source type of team which produces a component and you pick up the component as and when it is prepared).
However, anytime you are using an external component, you are exposing yourself to a dependency and to a high amount of risk (actually the risks depends to the extent on which the dependency can screw your project). Let me list down a few examples:
- You use a component that is fairly stable (say, being done from another team in your organization). The component is fairly stable, and even though new versions of the component are released from time to time, there is no major necessity of picking up a new version of the component. The dependency is there, but the risk is low and so the mitigation required is also low. Even if there is a problem with the latest version of the component, you can stay with the version that you already have.
- You use a component where there is a bug fix that is needed for solving a problem in your application. In such a case, the risk to your product or project schedule depends on the critical nature of the defect in your application. If the defect is critical to your application, then you have a high amount of dependency and need some mitigation plans. If the component has some problem, then you have to consider the impact on your project and have mitigation plans accordingly. If you are able to survive with the defect in your software, then you would not imperil your schedule if there is any problem in the delivery or the quality of the component.
- Now consider the case of a component that is critical to your product, or delivers a functionality that is critical to your component. For example, when you consider the Adobe Camera Raw and the products that incorporate it, one of the critical advantages that a new version of the Camera Raw provides is support for new Digital SLR's that have been released. So if you were releasing a new version of Photoshop
or a new version of Lightroom
, it is important for them to integrate the latest version of Adobe Camera Raw because of this support for new cameras. In such cases, if a component is delayed, it causes significant problems for the product schedule and needs a high degree of mitigation. In this case, the mitigation that is done by these products is by enabling this component to be updated later. However, the mitigation strategy for every such component or dependency may not be so easily solved, and the team needs to ensure that there is a lot of thought to how to mitigate these problems.
What am I talking about ? Well, consider the fact that in today's world, most projects have a lot of dependency on items outside the control of the core team. You may be getting some work done from outside the core team by an external team, you may be picking up a component that has been created by an external team (which can be somebody who you pay for delivering the component, or you may be picking up a component that is being done by a open source type of team which produces a component and you pick up the component as and when it is prepared).
However, anytime you are using an external component, you are exposing yourself to a dependency and to a high amount of risk (actually the risks depends to the extent on which the dependency can screw your project). Let me list down a few examples:
- You use a component that is fairly stable (say, being done from another team in your organization). The component is fairly stable, and even though new versions of the component are released from time to time, there is no major necessity of picking up a new version of the component. The dependency is there, but the risk is low and so the mitigation required is also low. Even if there is a problem with the latest version of the component, you can stay with the version that you already have.
- You use a component where there is a bug fix that is needed for solving a problem in your application. In such a case, the risk to your product or project schedule depends on the critical nature of the defect in your application. If the defect is critical to your application, then you have a high amount of dependency and need some mitigation plans. If the component has some problem, then you have to consider the impact on your project and have mitigation plans accordingly. If you are able to survive with the defect in your software, then you would not imperil your schedule if there is any problem in the delivery or the quality of the component.
- Now consider the case of a component that is critical to your product, or delivers a functionality that is critical to your component. For example, when you consider the Adobe Camera Raw and the products that incorporate it, one of the critical advantages that a new version of the Camera Raw provides is support for new Digital SLR's that have been released. So if you were releasing a new version of Photoshop
or a new version of Lightroom, it is important for them to integrate the latest version of Adobe Camera Raw because of this support for new cameras. In such cases, if a component is delayed, it causes significant problems for the product schedule and needs a high degree of mitigation. In this case, the mitigation that is done by these products is by enabling this component to be updated later. However, the mitigation strategy for every such component or dependency may not be so easily solved, and the team needs to ensure that there is a lot of thought to how to mitigate these problems.
No comments:
Post a Comment