Skip to content

Requirements Management Requires Flexibility

Integrating commercial software into your enterprise can be a daunting task. Hopefully your project is interesting enough that the solution is complex. At the same time, you hope that the product you purchased isn't confounding. In the case of integrating Connections into McKesson, I found that exact situation -> the products are complex, but not confounding. They are architected in a well thought out manner, although I found each of the modules to have their own personality.

Along the way, we were presented with a lot of challenges, not the least of which was managing the project requirements. The original project was blue sky in nature. We knew we wanted to bring in content tagging, group discussions, and ways of identifying expertise in the organization, but Lotus Connections was in release 1.0 when the project was conceived and still relativley young (2.0) when the project received funding and started to get off the ground. An outside firm conducted interviews and discovery of a cross section of employees and added their own touch to what the end result of the project should be.

At that point, there were plenty of opinions about what was a must-have for the project. We were also convinced from a technology perspective that Connections would be a great foundation to integrate and build upon. And thus, the rub was created.

When you buy software, you are not only buying something that has been thought out to work today, but you are typically buying something with a future. You want the product to evolve and expose new feature over time. You also want the product to look like it is part of your enterprise and integrate with other systems (HR, LDAP/AD, Finance, etc). Add on top of these basic needs the desire to transform it and you have a recipe for future headaches. These integrations and customizations need to be done in a way that your upgrade path is not broken. This is where flexibility comes in and your job as a software architect or engineer transforms into that of the diplomat. At the end of the day, you need to be the gatekeeper of maintainability and extensibility and ensure that the message is clear to your stakeholders. And hope that they are understanding and flexible.

No comments yet

Leave a Reply

You may use basic HTML in your comments. Your email address will not be published.

Subscribe to this comment feed via RSS