Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Project Requirements
The requirements for this project were developed in-house by all project stakeholders. Project management conducted an audit of existing functionality, in coordination with the individual business units and the product development team. That stage led to the creation of a giant matrix of functionality in a spreadsheet. Internal customers and the project team reviewed the matrix and pared it down to what actually drove the business. The result was developed into a VSD consisting of detailed specs with pictures outlining the requirements of individual areas of functionality and, if appropriate, how they would be integrated into the back office.
When moving to the new servers, the team says luck helped. A few non–publicly accessible sites needed to remain unchanged on the legacy architecture, for the short term. This fact allowed the team to run the sites in both the existing J++ environment and on the new .NET servers in parallel, until they were able to run them through the QA process.
Informit and Exam Cram were launched about a month earlier than the other partners due to a contractual situation, so the team ran both platforms in production for a period of time. The other sites eventually migrated to .NET.
So there were no changes to requirements during the process, right? Wrong. Hughes says there were plenty! "Considering the number of stakeholders we had, our change management process had to be flexible, to say the least. We ran each request for a change past our development and human factors people to make sure that it was feasible; then we ran them by representatives of each business unit to get a consensus sign-off. Sometimes changes survived that process; others didn't. When they did, our product development team would revise and redistribute the requirements doc as appropriate," he says.