Scrnch.Me > URL Shortner

>>> Corporate Solutions

Friday, May 22, 2009

Why do Projects Fail???

Projects, across the globe, fail and waste million$ of dollar$ due to poor requirements definition – this brings into focus the role of a Business Analyst and competencies necessary.

How can  a Business Analyst - or anybody for that matter, be expected to perform when their required competencies have not been established?

Put very simply: A Business Analyst acts as a translator / liaison between the customer/end-user and the IT group (attempting to fulfill needs).

According to International Institute of Business Analysis (IIBA – http://www.iiba.com/ ), BAs are “responsible for identifying the business needs of their clients and stake-holders, to determine solutions to business problems – they elicit, analyze, validate and document business-organizational-operational requirements.”

For organizations to be successful, there are two sets of competencies that have to be clearly defined:

Firstly, there are competencies that are common to most jobs/positions – they identify behaviors required, for example, communication and collaboration skills. All participants / employees should possess these skills/competencies, and be able to contribute to the success of the organization.

Second, there are those competencies that address success for a certain job. These functional competencies identify an individual’s ability to perform a set of activities based on their job!

Competency consists of three components:
  • Knowledge (what is required to be done / achieved?)
  • Skill (how is it to be achieved?)
  • Ability (how much can be done / achieved?)
Competencies that a Business Analyst should possess are:
  • Eliciting Requirements: Requirements can be conditions, functionality, products or services for internal or external use - needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs of business, rather than the constraints imposed by technology. This means that the business analyst’s job has more to do with identifying the desired results than the actions or resources required to reach these results—that’s someone else’s job. The purpose of gathering requirements is to provide an understanding of the problem or opportunity before trying to propose the solution.
  • Creating the Business Requirements Document (BRD): It is an exhaustive written study of all facets of regulatory, business, user, functional or non-functional requirements and provides insight into both the As-Is and To-Be states of the business area.
  • Structured Analysis: is the art of Modeling. It is used to support and enhance text-based requirements, help identify and validate requirements, document & communicate requirements and, finally organize information into coherent ideas. Common models include business, process, data and workflow.
  • Object-oriented Analysis is the clear understanding of both process and data modeling techniques, including functional decomposition. It involves identifying the as-is, then developing activity diagrams, and finally designing to-be end-result – done in consultation business-users and technical personnel.
  • Testing involves validation whether requirements have been met – develop test-scripts, plans, scenarios, based on as-is as well as to-be models. Should be done in iterative stages to ensure that, by following the requirements, the desired deliverables will be met.
Testing lines of code, GUI (usage and appeal), speed and functionality – is another level. There are two methods that fall into this category:
  • Black Box Testing is essentially the “checks and balances”. Herein, the item is not visible, only objectives of the business are validated for, for example, time required to fill in a report, that report being approved/rejected, and fulfillment --- would be tested for.
  • Glass Box Testing is “looking under the hood”. In case of an IT-project, this would mean assessing the design, code and architecture.
  • End-user Support involves the participation of the BA in the training of the end-user, along with the Training-team. This helps the end-user and Training-team to fully understand business requirement and create appropriate manuals and reference material.
  • IT Fluency goes a long way in translating business-requirements that can be understood by the “techies”.
  • Business Process Re-Engineering is the phase in which BAs flesh-out problems, AND identify opportunities. BPR uses a variety of modeling techniques in order to look at the bigger picture, BUT still think tactically!