5

If a design document e.g. software, IT infrastructure, etc details risks, how are these generally addressed as part of the project?

Do these risks also reside with the project?

For example, i have a design document that notes (one of several), that disaster recovery is not in scope. From an operational and business perspective, this introduces a level of risk.

Improve this question
1

1 Answer 1

Reset to default
3

If the design document you refer to is the design document for a project delivery, and in that design document risks are raised, then those would be drawn into the risk log for the project and managed in the same way as risks raised in any part of the project.

However you appear to have made an assumption that the design document ruling DR out of scope for the solution design is an operational or business risk. That does not automatically follow from the information you have provided. A definition of scope defines what is within the scope of the project (and also out of scope of the project). In this case, stating DR is out of scope of the Design Document merely says that the design document does not cover any elements of DR (and by extension the project itself does not deal with any aspects of DR). That is only a project risk if a goal or objective of the project is to deliver DR (or perhaps it is an infrastructure refresh and the refreshed infrastructure needs to introduce DR or continue to maintain a DR component).

Whether or not it is an operational risk or business risk is irrelevant if it is not in scope of the project you are referencing. Only you know whether that is the case or not. You seem to be expecting a hard and fast ruleset about what is or isn't considered a project risk- you will not find that ruleset anywhere because projects cover a vast (probably infinite) range of activities and deliveries. What is a risk in one project will be out of scope in another project and, as answered in another of your questions, a project risk is one that could impact on your project goals (and objectives).

EDIT: When posting further questions it might be useful if you preface the question with a (very) short description of the actual project. This will help people to advise you on what is and isn't part of your project risk profile. Just saying.

Improve this answer
7
  • If I understood you right, you said: Risks out of the projects (written) scope should be ignored? I don't agree to that. The defined project scope might be incomplete or did not foresee something (scope updates are possible during the projects runtime). Identified risks beside the project scope which might have an impact on the project should be put on the risk list also. In this case, if someone could formulate a negative effect for neglecting DR within the design document, this aspect should be considered and tracked as risk.
    – Tob
    Aug 18, 2015 at 14:35
  • @Tobias So will you raise a risk in the log that your project scope might be incomplete? If you admit that you should log risks outside of your project scope (i.e. things that don't impact on the project goals and objectives) you are going to have a very long list. You are mixing terms- scope, in this question is about whether DR is in scope of the project. If it is not then lack of DR cannot, by definition, be a project risk in and of itself. If you can show that lack of DR might negatively affect the project then of course it should be on the log.
    – Marv Mills
    Aug 18, 2015 at 14:41
  • @Tobias If scope changes within a project that is a clear and immediate change management issue. You don't just switch to a new scope- you run through a change request cycle, determine the new costs/risks/budget, seek approval from the stakeholders, reissue the PID and gain signoff. All of that gives you a new scope against which to assess risk, and at that point the previously out of scope risks would come into scope, and be managed on the log in the usual ways.
    – Marv Mills
    Aug 18, 2015 at 14:47
  • @Marv Mills I agree to most of your comments. But I state that aspects might impact project goals and objectives that are outside the project scope. Obvious might be updates in law and regulations. This will result in a long list fore sure. The qualitative risk analysis will then reduce the list and identify the (hopefully) few risks to focus on. If DR is agreed with the customer to be out of project scope, but you know your customer will handle crucial data with your software, you could rise a risk pointing this out: Customer might loose date due to missing DR. This might lead to a CR.
    – Tob
    Aug 18, 2015 at 15:04
  • @Tobias I disagree. Advising a stakeholder over what you see as problems in their requirements etc. is clearly fine, we all do it, but that doesn't make it a project risk in my view. The OP states the lack of DR raises Operational and Business risks; I am sure they are correct. My point is that is not automatically a project risk. Point it out to the stakeholders, sure, and if that changes scope then manage that. But, IMO, too many people treat the risk log as "The Universal List of Bad Possibilities" - A risk is only a Project risk if it impacts on something within the project scope
    – Marv Mills
    Aug 18, 2015 at 15:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.