In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management. These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.
These next two posts deal with the processes related to the fifth knowledge area of Risk Management that are performed in the Planning stage: 5.4 Risk-Adjusted Backlog and 5.5 Regulatory Compliance.
Risk-adjusted backlog was discussed in detail in the last post, but its content dovetails with that of the current process, Regulatory Compliance.
Risk-adjusted backlogs are a risk management practice where features that are prioritized are those that include industry best practice compliance, such as Six Sigma or Lean features, or regulatory compliance features.
Regulatory compliance features have the HIGHEST priority, because if they are not met, the product may not even be allowed into the market. From the end user’s point of view, that feature may have not any direct perceived value, but it has indirectly an EXTREMELY high perceived value, because it that regulatory compliance feature is not met, there wouldn’t even BE a product on the market for the customer to use.
These features require experts who know about these regulatory compliance features, and so the team may have to reach out to expertise outside of the team or even outside of the company.
But the fact that industry and regulatory compliance issues do NOT effect an individual company has two positive benefits for the company doing the project. First of all, the compliance issue effects the competition in the exact same way, so it levels the playing field, so to speak. Secondly, since it effects all of the products in a certain market segment the same way, if a company handles one set of regulatory compliance issues for a product, any subsequent product is going to face similar issues and therefore the learning done on the first project will transfer over to subsequent projects. You don’t have to re-invent the wheel, in other words.
Knowledge of these regulatory compliance issues will help the development team prioritize those features that are effected by them–they are “must have” features which must be dealt with first. Then, and only then, can the development team discuss features over which there is at least some degree of freedom.
After taking tomorrow off and discussing another topic, I will return in two days to discuss the next knowledge area of Communication and the processes related to this topic that are done during the planning phase of a project.
Filed under: Uncategorized |
Leave a Reply