There is a problem that is festering in many IT organizations: the old maxim “think before you do” has been replaced with “do.” I suggest that part of the problem is that the computer industry has been a little too successful selling its products.
Rapid and rabid proliferation of PCs and PC software has given users a sense of mastery of the technology that is, in the main, unwarranted. Most drivers, when asked, will rate themselves “above average,” yet I wouldn’t want to run into them on a racetrack.
Likewise, many, if not most, business PC users have been lulled into a false sense of IT competence by virtue of their dalliances with spreadsheets, word processors, or database applications. In the past, the systems analyst had mystery on his or her side. Now, the combination of unwarranted competence plus rapacious cost-cutting pressure creates an environment of malicious acceptance if not explicit contempt for many trying to do systems analysis.
We have seen this phenomenon before in IT. Long ago, there was a technology called typesetting that was the arcane domain of tough-talking union pressmen who literally spewed hot lead. Then came the Apple LaserWriter, Adobe PostScript, and Aldus PageMaker. Suddenly, the world of typesetting was accessible to all. The result: an entire decade of typographical embarrassment as the unwashed masses groped about using powerful tools without any grounding in design or aesthetic theory.
Ultimately, the novelty wore off for many, others became more educated, and, graphically, things have calmed down a bit. We’ve watched the same phenomenon happen in audio, video, Web, and applications design. So the trend shouldn’t be a surprise.
At the same time, from the lyrics of National Lampoon: “The world continues to deteriorate.” The buzzy trends of outsourcing, offshoring, rightsizing, increased competition, and a generally crappy macroenvironment have instilled a sense of panic into our daily routine.
In this environment, “time to anything” becomes paramount. But along the way, we seem to have forgotten the time-tested rule of systems:
- You can have it right.
- You can have it fast.
- You can have it cheap.
- Pick two.
Technology might allow things to go faster — and the increased speed might allow things to be cheaper — but rarely does technology alone make things righter.
If the people writing systems requirements are not aware of these tradeoffs, or cannot evaluate them in a rigorous manner, then there is high probability that the resulting requirements will be defective. This begs the question of whether or not the specification will be extensible (which presumes that issues like system lifetimes have been addressed).
When we evaluate the merits of right versus fast versus cheap, we enter the world of engineering. At the requirements level of abstraction, the systems analyst is a key player in this drama. A good systems analyst knows how to model a system from multiple abstraction dimensions and can anticipate how to move functions and data across those dimensions to manage complexity while attempting to meet time, space, and cost goals.
The systems analyst is also at the interface of users and technology. This adds the burden of effective human communications to the analyst task. Many people stress this role at the expense of technology expertise, which results in the “analyst as glorified stenographer” job description. This is bad practice. A good communicator that can’t model is as useless a requirements analyst as a modeler that can’t communicate.
Let’s pile on, shall we? Users are generally busy putting out today’s fire, so they don’t like spending time with an “analyst” who doesn’t understand his or her job. So domain experience (or “really quick study” skills) are necessary for a good systems analyst to gain the confidence of users. In that case, why are so many just-out-of-school newbies given the title “analyst”?
In addition, in order to make the kind of tradeoffs I’ve mentioned here, it is usually helpful to compare the requirements under consideration to other proposed, implemented, or (sometimes best) failed systems. This kind of experience is rarely found in the user base, in new recruits, or in outsourcing or offshore partners.
Good systems analysts combine insightful analysis skills with equally powerful synthesis skills, effective human communications skills, and an appreciation for current technology. Great systems analysts add domain knowledge and a rich understanding of organizational and technical history.
People with these characteristics will help develop systems that work well over their projected lifetimes. If you don’t have such people, develop them. If you do have such people, cherish them.