[In the "System Design Factors" blog series, Blake Deakin will be examining key design attributes and critical decision-making throughout the implementation life cycle. Each entry will dig deeper into specific concepts and introduce practical techniques for assessing and improving upon system design throughout the development life cycle.] There are many different challenges associated with implementing an information system of any kind. Garnering organizational support, securing budget and demonstrating business value are among some of the first hurdles that a sponsor must overcome in order to justify the time, expense and risk to drive the change associated with such undertakings. But what about challenges that might arise during the actual implementation or after the system has been pushed into production? How does a company ensure that the delivered system not only meets the requirements of the users, but also the business and the IT mechanisms that must continue to support a new system once it’s gone live? Conventional wisdom would dictate that the User Requirements Specification (URS) or some equivalent document should contain all of the normative statements required to implement a system appropriately. However, in practice, most people who have implemented systems understand that the URS does not necessarily dictate every single aspect of a delivered system.
Simply put, a URS will often determine the functionality of a system, but I will assert that there are many other design factors to a delivered system that must be accounted for and are often not explicitly addressed in a URS. Furthermore, these design factors are in some cases supporting or synergistic, other times neutral to one another, and in some cases conflicting. Identifying the relationships between these factors and considering them when selecting a design approach can make a big difference in the quality of the delivered system.
The challenge at hand is that even though these design factors are often identified in some way during scope definition and planning activity, they are almost never considered comprehensively and rarer still are they reconciled in a useful way. Consider the case where a sports equipment manufacturer is implementing a system and designs a data entry form for stationary bikes and treadmills; the need to support weight benches at a later time is not always considered and as a result design decisions are made which make expansion to this usage more challenging later.
Clearly, not all design factors are created equal, and the reality is that for each company (and in fact, each systems implementation) different ones will be emphasized and deemphasized. What’s the value of a design approach that focuses on ergonomics and enables a Customer Service Representative to process a record in 15 seconds instead of 30 seconds, relative to the ability to sustain 500 concurrent users vs. 250? These value assessments are not always cut-and-dried, but the good news is that more often than not it’s sufficient to simply identify how design approaches impact one another and make deliberate (and often obvious) decisions based on the context.
The goal of this series is to help identify tips and techniques to help identify cases where other design factors must be considered and how to put them in an appropriate context so that good, comparative decisions can be made. Over the coming months I will examine each design factor and specifically put it into the context of the others. By the end of the series, hopefully the reader will have picked up a few tricks for how to identify critical design factors early and make better, more informed decisions that deliver on core needs.