I've never been comfortable with the concept of "Man Hours," not that it's a gender issue, but rather it implies ignorance of how time is used in the work place and fumbles away some simple management concepts needed to run any business, namely accountability and commitment. Actually, I thought the "Man Hour" concept disappeared with the passing of the 20th century, but it appears to be making a comeback.

Given the economic downturn, "cheaper, better, faster" seems to be a universal mantra in business. To stay competitive, organizations must continually strive to be more agile and develop higher-quality solutions more quickly-despite obstacles such as geographically distributed teams, limited budgets and resources, quick delivery times, language barriers and government regulations. These challenges require teams to consider new ways of doing business so they can be more responsive to frequent business changes.

While Business Analysts are in demand, only the best will do. We investigate quintessential business analysis professional competencies, with a discussion of how academics and application can work together for your success. Key planning and preparation insights for CBAP certification are also uncovered.

I began my career at Cap Gemini Ernst & Young where doing business analysis and implementing large scale systems was my job. At that time, I just thought everyone intrinsically knew you had to understand the business and all the requirements before you begin designing a system (whether custom built or off the shelf).

We are witnessing a marked increase in both the importance of and focus on the work of the business analyst that is directly proportional to the depth with which cloud computing services are utilized. What's more, we are experiencing a shift in the tools and skills that our analysts and those of our customers are required to utilize.

As the process of capturing and documenting business requirements matures, there is often a watershed moment when an organization must decide whether to perform traceability of requirements as part of that process. Most companies involved with a formal methodology for software development utilize some degree of traceability; but those not familiar with it could be put off by the overhead of requirements management (RM), of which traceability is a component. Therefore, it helps to understand some of the value aspects of instituting traceability.

Anyone perusing the computing rags (or their online equivalents) will no doubt have noticed that this year's big thing for applications development is a combination of Cloud Computing and Software as a Service (SaaS). I'll talk about Clouds in a future blog, as I want to concentrate on the SaaS phenomenon today.

Businesses cope with manual, repetitive tasks to get the job done. Email, conference calls, and "walking the cubes" are too frequently the process for requesting information, getting approvals, and checking project status. Time and resources are wasted, errors abound, and everyone is less productive.

Automating these everyday business processes is the way to improve productivity and gain efficiency. Traditional Business Process Management (BPM) systems can provide a solution, but the cost and complexity to implement simple processes is often too expensive for many business units.
 

For almost every analyst, the day comes when you write a set of requirements that causes engineers to bemoan a recent development project that they just coded. "If only we'd known that you wanted to build this, we would have made the last project more flexible. Now we've hardcoded in changes that will take days to rebuild."

The title of "Business Analyst" is one of the fastest growing in the IT industry. In fact, the United States Department of Labor projected a 29% increase in computer systems analyst employment by 2016. There are many resources available that explain what a business analyst is, often in terms of comparing the responsibilities of an analyst to those of other team members we're more familiar with, like project managers, software testers, and systems architects.

A long time ago, before Business Analysts existed, it was believed that people in the business would be able to define their own requirements.  When a business department wanted to have a new piece of software, they would go to the IT department and the developers would ask them what they wanted. The business people would express this as best they could by writing down lists of things and having meetings to explain them, and then the IT department would build or buy whatever they seemed to want.
 

Systems work is not as hard as you might think. However, we have a tendency in this business to complicate things by changing the vocabulary of systems work and introducing convoluted concepts and techniques, all of which makes it difficult to produce systems in a consistent manner. Consequently, there is a tendency to reinvent the wheel with each systems development project. I believe I owe it to my predecessors and the industry overall to describe basic systems theory, so that people can find the common ground needed to communicate and work. Fortunately, there are only four easy, yet important, concepts to grasp which I will try to define as succinctly as possible.

The business analyst's job has changed this year -- and so have the critical skills that companies demand. New research shows that while communication is still key, knowledge of Lean and Agile methods is a must-have as well.

In Part 1 of  this article, I talked about the new skills and attitudes business analysts need to bring to agile development... Now it's time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let's take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.
 

Although it may seem obvious that the User Interface (UI) directly impacts usability, and therefore satisfaction, Business Analysts often find themselves focusing on functional requirements to ensure end user satisfaction. Mainly, this is due to the non-functional requirements, like usability, being dictated by existing technology or process within the organization. However, research into mobile user interfaces is placing the focus back on the usability requirements as the main driver of user satisfaction.