Sorry Mr. Mossberg: A Little Push-back,
July 15, 2007 § Leave a comment
A few posts back I provided an example highlighting Walter Mossberg’s, assertion that IT Departments can be The Most Poisonous Force in Technology, not only a barrier to end-users’, but a barrier to the organizations they are charged to support. In my example, I mentioned several key requirements defined by, not technologists, but those end-users who actually provided the “business service” of teaching on-line; faculty, instructional designers and academic coordinators.
In that example, a new architecture for a learning management system was recommended based on the unique business processes within the university system and on each campus (module/simple sequencing, Learning Design, centralized hosting and support, cross-campus enrollment, common course catalog, off-line development). The final technical design was based on the end-users’ needs (as described through current business processes), exemplifying Mossberg’s ideal; what could be called user-driven design.
However, just as IT departments have a responsibility to user-driven design, where individuals can explore and implement the technology products best suited to their own needs, end-users (and their organizations) also have responsibilities. One particular responsibility, often ignored or deferred (often, ironically, to the IT Department) is requirements gathering.
Working again with my LMS example, the final “product” was defined through the following process:
- Identify current business processes for on-line learning
- Develop business requirements to enable business processes
- Develop functional requirements that provides for business requirements
- Develop technical requirements.
A Business Process is a collection of interrelated tasks, which solve a particular business issue, service or goal.
There are three types of business processes:
- Management processes – the processes that govern the operation of a service.
- Operational processes – these processes create the primary value stream, they are part of the core business. Typical operational processes are Manufacturing (Teaching and Learning?), Marketing (Recruitment?), and Sales (Admissions?).
- Supporting processes – these support the core processes.
A business process can be decomposed into several sub-processes, which have their own attributes, but also contribute to achieving the goal of the super-process. The analysis of business processes typically includes the mapping of processes and sub-processes down to activity level.
Business Requirements constitute a specification of simply what the business needs to perform its tasks. This is usually expressed in terms of broad outcomes the business requires, rather than specific functions the system may perform. Specific design elements are usually outside the scope of this document, although design standards may be referenced.
Functional Requirements describe what the system, process, or product/service must do in order to fulfill the business requirement(s). Note that the business requirement often can be broken up into sub-business requirements and many functional requirements. These are often referred to as System Requirements.
Technical Requirements pertains to the technical aspects that the system must fulfill, such as performance-related issues, reliability issues, and availability issues. These types of requirements are often called quality of service (QoS) requirements, service-level requirements or non-functional requirements.
Note above that the process begins with “identify” not “develop.” “In fact, a true [service] should only have services with a direct counterpart in the business; otherwise they cannot possibly be modeling a business process.” (Dan North. “A Classic Example.” Better Software, May 2007: 30-35) I have often come into an organization where there is no clear understanding of their current business practices, policies, services, etc; that is, the business unit cannot “identify” their business processes. Many organizations actually choose to implement a technology with the hope that the new application/system will either provide uniformity in, or even create missing, business processes! This is completely backward!!!
What this obviously leads to is an environment where an unassociated software provider dictates business practices due to the fixed functionality of the system deployed (Mossberg’s chief complaint!). As business processes and their interactions become more complex, organizations end up adapting to meet the needs of their systems, not their market (the campus and their faculty, staff and students).
Here is an example from real life. Housing management systems allow an Office of Student Life to open up housing enrollment to students on-line. This is a great benefit because it can replace the manual processes used to identify and match students based on personal attributes (male/female, smoker/non, clean/messy, etc.) and roll up student requests (roommates, meal plans, etc.) just to name a few. When one first learns of these systems, they may seem like a perfect fit.
However, how the system works (features, functionality, work flow, data requirements, outputs, etc.), and how the office works may not be aligned. Will the work flow for students and staff currently supported by, admissions, financial aid, enrollment, student life, etc. map to the new system? That is, because this system is going to offer students a way to sign up for a dorm room, even a roommate, the system will need to know each student exists. Not only that they exist, but they have been admitted, AND that they are have paid their tuition, AND they have paid their housing deposit, etc.? When is the student record considered complete (tuition paid?, enrolled in class?, holds/fines cleared?, counselor approves?, etc.) so that it can be processed by the housing management system (how does a new student get notified of their UID and pw?)?
All of this information is usually stored and managed centrally by the IT department as part of their “Enterprise Resource Planning.” So here in lies the conflict Mr. Mossberg laments: end-users want specific functionality for individual needs, IT needs to manage and integrate data. Yet, both end-users and IT would benefit from a real effort to undertake a requirements gathering process that begins with an organizations current operations, processes, services, etc., rather than from their own reference points.
In another example, ten years ago Scott McNealy former CEO of SUN Microsystems, wrote, “It is so clear how many person-centuries are tied up futzing with our computers and creating documents where a little ASCII email would have been just right.” His point here, from 1997, was that end-users spend too much time using features of an application (specifically Microsoft Word) that do not enhance the end product.
How many people need to communicate with co-workers, develop documentation, etc.? Probably everyone. How many features are needed to do this? Probably not many. I am sure everyone reading this has used Word to communicate with co-workers and develop documentation. But how many have used Word’s Visual Basic Editor to communicate with co-workers and develop documentation? Not many I guess. How was Word identified as the solution that met the business processes involved with communicating with co-workers and developing documentation, when simple ASCII text would have been fine?
McNealy continued, “If you give somebody a word processor with 4,000 features, the implicit instruction is: This is a tool. I bought it for you. You work for me. You go learn it and learn as much of those 4,000 features as you possibly can because we don’t want all that money we spent to go to waste.” (Scott McNealy. “The Killer App.” Forbes.com ”)
In the example of the housing management system, many of these systems come with “4,000 features,” such as, email services, financial services, judicial services, etc. and thus the implicit instruction is: This is our housing management system. Go learn it and learn as much of those 4,000 features as you possibly can because we don’t want all that money we spent to go to waste. However some features (email) may conflict with current services, some may alter current business processes for other units (financial) or even create new business practices where there was no need expressed before (judicial).
Mr. Mossberg would like to create an environment that allows individuals to explore technology products best suited to their own needs. And I agree. Because the investment in either commercial applications, or the development of open source applications, is resource intensive, thoughtful consideration must be undertaken to make sure the new system will enhance the service, not hinder it. End-users should really be focused on identifying technology that enhances their business processes, not identifying technology that can create them, or even worse technology for its own sake.
I would highly recommend the above requirements gathering process for those individuals who wish to identify technology products best suited to their own needs.