If I understand your question correctly, you are asking at what WBS level one should carry out Risk modelling. My experience has shown that this is best carried out at level 3 or 4 of the Project Plan, which is not necessarily (and often not) the same as the WBS level. Often the project concerned can start at WBS level 5 or lower!!! For example an company I have worked for has WBSlevel 1 at corporate level, the project plan starts at WBS Level 4 and we are modelling the risks at WBS level 8.
Too high a level and one loses the interactions between activities, too low and risks counteract each other unless a high degree of correlation is incorporated. As a rule of thumb I tend to model at the Plan Level 3,or Level 4 if more granularity is required
Member for
21 years 3 months
Member for21 years3 months
Submitted by James Darnell on Sun, 2004-07-18 04:35
Hi Mehdi, For many aerospace projects that I have been on, per government contract requirements, you must breakdown all work tasks to WBS level 4. Usually the customer will specify a summary WBS at level 3. Then the contractor would break down work packages and cost accounts through WBS level 6.. for example level 1 is at the aircraft, aircraft support and operations level. level 2 may be broken down into either major subsystems or functional discipline/department and level 3 breaks that down into the next layer. The risk at this point is that your customer is telling you how you should organize your business operations or else how you allocate technical performacne parameters to subsystems and components which might not accuratley reflect true overall systems performacne when the numbers are rolled up to the next higher WBS. Cost and schedule monitoring and variance analysis will be inaccurate. The customer should be cautioned that this overspecification will most likely add unneeded cost and schedule becuase of poor operational efficiencies. The customer should keep organiozational and systems definitions loose’ and easily adaptable to allow vendors flexibilty in project organization and using realistic performance parameters to gauge true progress of development.
Member for
20 years 11 monthsRE: Risk level on WBS level
If I understand your question correctly, you are asking at what WBS level one should carry out Risk modelling. My experience has shown that this is best carried out at level 3 or 4 of the Project Plan, which is not necessarily (and often not) the same as the WBS level. Often the project concerned can start at WBS level 5 or lower!!! For example an company I have worked for has WBSlevel 1 at corporate level, the project plan starts at WBS Level 4 and we are modelling the risks at WBS level 8.
Too high a level and one loses the interactions between activities, too low and risks counteract each other unless a high degree of correlation is incorporated. As a rule of thumb I tend to model at the Plan Level 3,or Level 4 if more granularity is required
Member for
21 years 3 monthsRE: Risk level on WBS level
Hi Mehdi, For many aerospace projects that I have been on, per government contract requirements, you must breakdown all work tasks to WBS level 4. Usually the customer will specify a summary WBS at level 3. Then the contractor would break down work packages and cost accounts through WBS level 6.. for example level 1 is at the aircraft, aircraft support and operations level. level 2 may be broken down into either major subsystems or functional discipline/department and level 3 breaks that down into the next layer. The risk at this point is that your customer is telling you how you should organize your business operations or else how you allocate technical performacne parameters to subsystems and components which might not accuratley reflect true overall systems performacne when the numbers are rolled up to the next higher WBS. Cost and schedule monitoring and variance analysis will be inaccurate. The customer should be cautioned that this overspecification will most likely add unneeded cost and schedule becuase of poor operational efficiencies. The customer should keep organiozational and systems definitions loose’ and easily adaptable to allow vendors flexibilty in project organization and using realistic performance parameters to gauge true progress of development.