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

Over the last four decades I have met a lot of Systems Analysts in a lot of different industries. Some impressed me greatly by their knowledge of their business and the systems they designed, but I have also met a lot of duds along the way. When I think about the better ones, I consider the attributes they share which I can narrow down to three areas

In its simplest form, a Feasibility Study represents a definition of a problem or opportunity to be studied, an analysis of the current mode of operation, a definition of requirements, an evaluation of alternatives, and an agreed upon course of action. As such, the activities for preparing a Feasibility Study are generic in nature and can be applied to any type of project, be it for systems and software development making an acquisition, or any other project.

So you want to be a Business Analyst?  “Analyst – analyse thyself….”

This is what Business Analysts do in the real world when embarking on a new project: they analyse… 

So – as any good BA should do when undertaking a new project – analyse what are your objectives in wanting to move to a new career as a Business Analyst.
Put another way, how will you know (once you have done it) that it was a good move to make?

The difference between an art and a science is subtle but significant. An art form is based on the intuitiveness of the person performing the work, something that is difficult, if not impossible, to pass on to another human being. For example, apprentices serving under an artist may try for years to emulate the master, but may never attain his level of skill and creativity. In contrast, a science is based on a governing body of concepts and principles and, as such, can be easily taught to others.

Having been involved with the systems methodologies field for over 30 years I have been occasionally asked what percentage of time in a project should typically be devoted to a specific phase of work, for example a Phase 1 Feasibility Study, Phase 2 Systems Design, etc. Basically, the reason the person wants to know this is to use it as a means for estimating the remainder of the project. For example, if I were to say Phase 1 represents 10% of the overall project, they would simply multiply the amount of time spent in Phase 1 by ten. This is an unreliable approach for estimating which is why I usually balk at giving out such figures.