Entries for April 2008


Standardization offers the benefits of uniformity, predictability, interchangeability, and harmony. If this is not of interest to you, than there is little point in trying to participate in a standards program. But if you do wish to participate, understand there is more to implementing standards than to just say "that's just how it is going to be done." There has to be some sound rationale for their governance. In addition, you must address the enforcement issue. Standards will be adhered to by the degree of discipline instilled in the staff; If well disciplined, your chances for success are good, but if discipline is lax, automation is required to assure standards are being followed.


Did you know that you could make a positive impact in people’s lives by working as a Business Analyst (BA)? By describing data flows, writing use cases, creating diagrams, re-engineering current processes or mapping the system’s data outputs and inputs, you could make a change in somebody’s life. As impossible as it sounds, it is happening on a daily basis. Throughout the US the Business Analysts in the Healthcare industry work hand in hand with the Healthcare professionals in the hospitals, the insurance companies, the government, as well as regulatory and non-profit agencies and organizations to make the US Healthcare better.

According to the MS Encarta Dictionary, healthcare is defined as the “activities to maintain health; the provision of medical and related services, aimed at maintaining good health, especially through the prevention and treatment of disease.” The healthcare industry also includes the people performing these activities, their skills, and the tools and systems they use daily. The modern health care depends on an ever growing interdisciplinary team of professionals; and this includes the Business Analysts.

The Business Analysts in the Healthcare Industry are exploring many business processes, multiple use cases and alternative flows at every point of contact where the patient interfaces with the healthcare professionals. At the same time there are various software and hardware systems interacting with each other and a multitude of standards regulating every aspect of the data exchange. When you add the different vendors, the variety may become overwhelming.


I was recently asked by an "Agile" proponent if I thought our "PRIDE" methodologies were too rigid for today's fast-paced Information Technology world, that perhaps it was too bureaucratic. First, I pointed out that "PRIDE" was more of a way of thinking as opposed to anything else. You can remove all of the documentation associated with the methodologies, including the forms, and still produce a system for example. This took him aback somewhat as he had thought of "PRIDE" as an inflexible paper mill...

Discusses the implementation of a robust Systems Design Methodology.

Author: Tim Bryce


The pointy haired manager in Scott Adams' "Dilbert" cartoon has become an icon for management incompetence. Although Adams' character may seem like an extreme, we have all encountered various examples of the Peter Principle whereby people have risen above their level of competency. We see this not only in our companies, but also in the nonprofit organizations we are involved in. Basically, these are some very nice people who simply haven't a clue as to what they are doing and stumble through each day making bad decisions which drives their subordinates to madness.

Author: Tim Bryce


Yes I know this sounds harsh, but I am hearing these 3 items more and more from BA's with 5+ years of 'experience', and it's driving me crazy. I would expect to hear this from a junior analyst, but someone with 5+ years?

That's just plain crazy.

The article also covers 6 potential sources causing the Business Analyst to behave this way.


A lot of IT folks and or BA’s believe that if you create the requirements without the business, and then review the requirements with the business for confirmation, you can save a lot of time.

After all, creating requirements collaboratively just takes too long, and the business doesn't know what they want, anyways. In addition, we (IT or BA) know the system better than the business, so it just makes sense for us to create the requirements, and then let the business say yes or no.

Let’s see this concept in practice in the “Requirements for My New Car”: a fable.


Discusses the use of worker time and how it impacts estimating and scheduling in Project Management....

It's been a while since I've discussed the concept of "effectiveness" but I was recently up in Cincinnati and saw it in action again. This time, I happened to be visiting my brother-in-law who had hired a crew to tear down some dead trees on his property. I went outside to enjoy a cigar and watch the activity. There were three workers who tended to their own individual tasks most of the time; one was busy cutting wood, one was concerned with splitting wood, and one was responsible for hauling it away. When each tended to their own task, they were very productive, but when they grouped together to perform something collectively, I noticed their output dropped significantly as it seemed two watched one work.

Author: Tim Bryce



Copyright 2006-2021 by Modern Analyst Media LLC