Dec 012009

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.


Lou Mazzucchelli

Lou Mazzucchelli is a Fellow of the Cutter Business Technology Council and a Senior Consultant with Cutter's Business Technology Strategies practice. He specializes in consulting with C-level executive on IT and management issues.


  4 Responses to “Analysis by Amateurs: Nurturing Good Systems Analysts”

  1. avatar

    Mr Mazzucchelli is right. Sadly he is just repeating what many others have written for a long time.

    It is difficult to combat the problem because most IT development occurs in departments that have no sense that having some specs, some owner, some reviews, etc. (almost normal engineering practices) is the only way to build anything – physical or logical.

    If analysts could resist as a tribe the urge to answer the question, “When can I have something to do something?” with the reply, “I don’t know. Give me some more details and I’ll give you an estimate.” then we might make some headway.

    Sadly, many of those called ‘analysts’ have very inflated egos and are rarely held to explain themselves when ddevelopment takes time or turns out badly.

    Much more can be written, but it already has.

    Dick Swenson

  2. avatar

    I agree, the profession suffers from some alarming enthusiasm to take the title spontaneously.

    But, not to be forgotten, we have the enabler and the willingfull pretender, it takes 2. So, you can be an analyst if someone pays you to do so. So what is an analyst ? And what is NOT an analyst ? The payer might know …

  3. Wow. Amen. Amen. Amen. To the author and commenters. But:

    This problem percolates throughout all roles in the IT software industry — serious roles, with professional knowledge base, practiced by relatively unskilled, unschooled warm bodies.

    Could you imagine a “hack” driving your Airbus from LGA to LAX? Could you imagine a “hack” ripping open your abdomen to remove an inflamed appendix? What in our industry is different than theirs?

    We, as an industry, have allowed this to happen by not paying attention to who works beside us, above us, and below us. Both of the aforementioned industries developed standards of practice and certifications to eliminate hacks from their midst. Standards of practice and certifications ultimately form the basis for liability law, which is what really accelerates the expungement of unskilled “seat-fillers”.

    I am not eager to see certifications take hold, but really see no alternative. Keep in mind that certifications in both health care and aviation aren’t just “tests” — they require demonstration of practical skill to an assessor with even more training, experience, and generally skill (if you’ve ever watched a CFI grab the yoke/stick and correct a landing about to go bad, you’ll know what I mean). The assessor, by certifying someone as capable, has made himself part of the liability chain — that’s sobering. And that is what helps keep out the unskilled.

    Are these other professions perfect? No. But compared to the software industry, the ability of these other professions to select, train, and keep current its practitioners, with new knowledge as it becomes available, make us look like, … well, hacks.


  4. Indeed these all are concerns, but the issues are more complex. I’m from a family of physicians and am making neither excuses nor apologies, but it was not so long ago that bloodletting was the accepted standard of medical practice. At the time, anyone who suggested the possibility of germs surely would not have passed industry muster. I contend that business analysis conventional wisdom has similar fundamental issues; but I’m not so confident that it will find its way to the maturity medicine has. Certification has value, but also limitations, even and especially when governed by the views of “skilled practitioners.” Describing the challenge from a somewhat different perspective, I too used the stenography metaphor in a Requirements Networking Group featured article, “Should BABOK Include Shorthand?” at

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>