2.14 Address the Feasibility of Implementing Requirements

< Day Day Up >

As was stated elsewhere, this whole process is iterative, or nonlinear. In some cases, it will feel like you keep going around in circles while postulating requirements, getting a cacophony of response back from the stakeholder community, revising the requirements, and going through all this again. There is no way to avoid this if the degree of proposed change or level of complexity is high.

From a management perspective, it is also not easy to state categorically when certain things should happen. Evaluating the feasibility of a requirement certainly falls into this category. For instance, looking back at our hypothetical airport project, saying we need 300 gates may be acceptable to those who want that many people coming and going, but the cost, or working that many ports into a physical plant constrained by budget or other issues, may force a significant reduction in the number of gates later on in the discussion. Of course, such a change can have a domino effect and can force a review and rework of other design elements as well.

Having said this, however, does not excuse you from asking the feasibility question early and often. Let us go back to the ISDN project in which we were unable to deliver the fully automated provisioning system once envisioned. As the project progressed, we stumbled across a few showstoppers. For brevity's sake, I will look at just the worst offender. The most critical assumption we made was that three legacy production databases could be leveraged to:

Automatically populate new orders with data
Query network assets to validate service ability
Initiate the Central Office switch port configuration process

What we learned, however, was that the data rules were divergent enough from one database to the next that we could not use data pulled from one table to query the next one for additional information. Simply put, a customer address could be entered several ways, none of which could be accurately resolved with clever programming (i.e., artificial intelligence). Because the address was the key field in the majority of planned searches, the most important assumption underlying the system design was invalid.

I was made aware of this disconnect after I drew up the proposed system flow and e-mailed it to the project team. Unbeknownst to me, someone shared it with a database administrator. She sent me 20 pages of database printouts to document the problem. This is mentioned to reiterate the value in socializing key project data like dates, assumptions, risks, and dependencies because you never know what will pop up, or from whence it will do so.

During the initial requirement phase, no one ever challenged the assumption that the quality of the databases was such that we could not leverage them. So, of course, we did not look and, therefore, did not know that our cornerstone assumption was flawed. This, in turn, meant that the vision of a "down and dirty" implementation creating seamless and error-free automation was virtually impossible. Although our budget was not paltry, it was not elastic enough to address these issues in any meaningful way.

< Day Day Up >