Solution definition..or Requirements Refining..or Both?
The key to successful requirements is to be true to the project goals, to define a requirements strategy and to stick to it as I mentioned in my last entry. In a package implementation the trinity of the business owner, the implementation team and the package vendor need to be aligned with the program vision and timelines.
However, quite often project teams treat requirements as etched in stone. The requirement by itself is just a means to an end. In a package implementation, it is not easy to state the requirements in terms of the package being implemented. We were implementing SterlingCommerce MCF(Multi Channel Fulfillment) and SterlingCommerce Call Center application to replace the client's legacy OMS and call center application. The business requirement owners were new to the package. For the first few sessions, we played an attritional game of "This is what the requirement wants, but this is what the package does". It wasn't going anywhere. There was heartburn and conflict.
At this juncture, as a project team, a decision was taken that the implementation team would also explain what the product does and the why behind that. This led to a longer timeline, but better utilization of the time. Slowly this became a game of "If this is what the package does, how does it meet my overarching requirements". And while the solution was being given shape, the requirement owners restated their requirements in terms of what the package does.
There is a subtlety here. It was not as if the requirement owners rolled over and wrote a product quide. They restated their requirements to match the product lingo, and in terms of what the product does. Of course, there were instances were the requirement was not met by the product. In such cases, we had intense negotiations with the product vendor to include the feature in the product or we had to plan to custom build that feature.
So solution definition became a form of iterative requirements definition phase. The requirements were refined by the requirements team in alignment with the package. And, the solution definition started taking on the shape of a solution requirements document.
Based on this experience, I would recommend that during solution definition, teams collaborate on an integrated requirements document. This document would be the starting point for both the solution design document and the business test plans. The integrated requirements should state the business requirement in product terms. It has to be a cross over document that conveys requirements to the business users and to the implementation team. Is there value in having two different documents as the solution definition and requirements or merge them into one document as the single source of what is required off the solution?
Beyond solution definition, the most critical phase of a SterlingCommerce implementation - Solution Design...