The Hidden Requirements
The job of the implementation core team and program lead is to deliver the success criteria. But, for some, that is not enough. It’s not enough because they also have to ferret out the hidden success criteria for the project to be truly called a success. Hidden success criteria can be obvious but not shared – for reasons we will discuss. Or they can be less obvious, owned (but not shared) by a stakeholder (usually a detractor), and slightly more insidious.
The first cause of hidden success criteria is often overlooked requirements that are obvious to everyone but, for some reason, did not get written down anywhere. This is usually due to a lack of thoroughness in requirements gathering, not mal-intent. Examples are usually related to core functions that are so routine that they are often simply forgotten – like documenting breathing. The best way to identify these is to know the workflow you impact inside and out. When mapping the workflows, it’s hard to hide the obvious. Unless, of course, how you map the workflow is the problem. If this concerns you, have an outside person review your workflow to validate.
The second cause of hidden success criteria is usually carried by a stakeholder resisting the change initiative or implementation. In another post, we referred to this person as Zed. This stakeholder usually withholds this requirement to maintain power and control in this situation. They use secreted knowledge to keep the cards. In short, it’s a power play. When you think you have a detractor stakeholder, it’s vital to discover what requirements have not been included intentionally. The best way to do that is to understand their work regarding the active implementation. Usually, their use case is lacking or completely missing because their participation has been lacking. Double down on discovery for their use case and remember they will not be compliant – so you’ll need to dive deep and continue to drive to completion.
Once you have the use case and have identified the hidden requirements, the core team and the program lead have regained power. When the detractor attempts to go around this team to complain about the lack of completeness in your implementation, they’ll think they have the upper hand – but won’t because you delivered beyond the defined requirements to circumvent the powerplay. Delivery is fun, but sometimes evil delivery is the best, like delivering intentionally hidden requirements to take back power. Relish shutting Zed down.