Up until now, we’ve just been talking about general tools that can be used to help with program / project management. But today, I want to talk about a real life situation that occurred at one of our clients and is probably relatively common in large programs. In this case, the program consisted of 8 separate components that had various integration points. These points included XML messages and reports being exchanged between components to support an end to end flow. Each component had received a requirements signoff, not only from their primary stakeholders, but also from the leads of the other components.

In theory, this meant that the requirements should have matched across all of the components. In reality, the client got to the testing stage and started to notice small discrepancies between the requirements of components that were required to talk to each other. The discrepancies were relatively minor, required fields for one component were optional for another, data required for one component to complete downstream processing was never even gathered at the upstream system, etc….

The result was delays in testing, change requests needing to be filed for both components, and a fair amount of confusion, email exchanges, and conference calls trying to track down the discrepancies.

In theory, these discrepancies should have been caught by the peer review of each component’s requirements by the other component leads. In practice, each component lead was so busy locking down the requirements for their own components and getting development underway, that they only caught major mismatches between requirements. And when you are dealing with requirement documents that have hundreds or thousands of requirements, that is understandable.

So how do you avoid the problem? There are a few things that will help.

• Ensure that each component’s requirements document has a section dedicated to the interactions with each of the components it talks to. This will highlight the areas that the other component lead & BA will have to focus on when reviewing the requirements document.
• Have a Program BA assigned to the project, whose responsibility is to reconcile discrepancies between component requirements before they are even sent for signoff. Especially with programs that have systems with a lot of interactions, this is a critical role.
• Define End to End test scenarios early on in the process. This will help define interdependencies between the components that need to be focused on.

If you follow these steps, you may not eliminate discrepancies that show up in testing, but you will certainly reduce the odds of finding them.

If you’ve got a real life scenario that you’d like advice on how to remedy or avoid, please post a comment and I’ll consider it for a future blog post or respond to you privately.