A Few Items to Mention
Business Analysis is a discipline based on project planning required for every project, regardless of the size of the project: regardless if a single developer works on a website or an entire team works on a scalable multi-platform system architecture. There is no set limit on how much analysis can be done, and so this can reflect on the size of the project. When no Business Analysis is performed we usually see the following penalties:
Project Risks: Unforeseeable circumstances may cause the project to fail
Project Costs: The poor management of resources cause additional project costs
Project Duration: The poor management of overlapping tasks cause projects to take longer
Business Analysis has a foundation of widely accepted best practices which will be discussed in this article. However, it is not an exact science, and there are some conflicting opinions in regards to some of its practices. Most organizations which rely heavily on Business Analysis may even refine their own practices that work best for their industry.
Business Analysis is an intricate discipline, and cannot be thoroughly covered in a single article. Rather, this article contains several carefully chosen topics aimed for those with little to no experience with the discipline, and aimed for businesses researching whether the practice is right for them (hint: it is).
Who Should Perform Business Analysis?
It is rare that an organization has a person dedicated to Business Analysis. Rather a business Analyst is someone who can wear many hats, and can include one of the following:
Although a business Analyst can be almost any member of a project, it is essential that the person has a fair amount of technical knowledge as a technical solution is the end goal of Business Analysis practices. In larger projects, a Business Analyst may not be able to have an understanding of all the technologies involved and may consult with other software engineers involved in the project.
What Tasks does a business Analyst Perform?
There are many activities performed by a Business Analyst, however the most basic and widely accepted best practices include the following activities:
Gathering Project Goals
Creating a Project Scope
Refining Project Scope into Project Requirements
Refining Project Requirements into a Project Technical Specification
These tasks are broken down into more details in the following sections.
Activity 1: Gathering Project Goals
This is the first task a business Analyst must perform, and unfortunately it seems so simple that its difficulty is oftentimes underestimated. In this activity a business Analyst must obtain a clear list of project goals that the project will be built upon. The analyst must discover the real business needs in order to eventually propose a solution that satisfies these needs instead of implementing a guess solution.
Here are some common mistakes that novice Business Analysts will make in this step:
Talk to the wrong person: Project goals can only be obtained from a person who has the authority to set the scope of the project. The goals should not be obtained from another project team member, but ideally from the client or organization which is funding the project.
Ask the wrong questions: At this point in an analyst is focused entirely on obtaining the scope of the project. The business Analyst should not gather any project goals that are oriented towards a specific solution or technology, unless this is a direct project constraint imposed by the client.
Poor organization of project goals: When written down, project goals should be written down in atomic form to be easily referenced (ideally by a numbered list). Business Analysts avoid compound sentences or writing down more than one goal in a sentence.
Incomplete project goals: A Business Analyst must double check and triple check that the Project Goals indeed consist of all the goals that the client requires. It is often without exception that the goals are not properly collected which results in the client attempting to introduce them in the project while it is in the development stage.
Activity 2: Creating a Project Scope
In order to fully ensure that the Project Goals are complete a Project Scope document is created, which contains the full scope of what the project solution will contain and what the project solution will not contain. This is the first form of risk management performed by a Business Analyst, as it ensures that the client and project development team are on the same page in regards to the project tasks that must be completed. If the client does not agree with the Project Scope at this stage in the project, then the Project Goals must be refined and a new Project Scope must be created.
Activity 3: Refining Project Goals into Project Requirements
Loosely put, a requirement is a capability to which a specific part of the project should conform. When specifying Project Requirements, a Business Analyst must take the Project Scope and create an enumerable list of specific tasks that the final project solution will be required to perform based on the scope (however the analyst should not specify how to implement these requirements, as that is the next activity). A Project Requirements document allows software engineers to easily translate a requirements specification into a software technical specification (which is actually the next activity discussed).
There are two types of important Project Requirements:
Functional Requirement: A requirement that specifies a specific behavior or function. Broadly, it specifies what a system is supposed to do.
Non-Functional Requirement: A requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. Broadly, it specifies what a system is supposed to be.
Requirements are beneficial because they are written in plain English, without technical jargon, and can be understood by higher level management who may not have IT experience. Thus, requirements are the essential cornerstone to communication between business management teams and it development teams. On top of the list of requirements refined in his activity, a Project Requirements specification may also utilize several techniques and tools that can help facilitate the communication of requirements, such as:
Use Case Scenario Modeling
Entity Relationship Diagrams
Finally, Project Requirements actually serve as another means of risk analysis because they specify exactly what the final project solution will do in minute details, even though a technological blueprint has not been completed yet. If there is a problem with the project solution, then it is identified early in the project life cycle before system development has begun.
Activity 4: Refining Project Requirements into a Project Technical Specification
In this activity a business Analyst will (often with the help of other software engineers) specify a thorough technological blueprint for the final project solution. This will include all technologies and business processes involved in the creation of the solution. A substantial amount of software engineering will go into this activity, and so it can also be seen as the first activity of the software development lifecycle, even though nothing has been implemented at this point.
Theoretically, if two qualified Business Analysts performed Activities 1, 2 and 3 for a specific project, then they should obtain similar results. However, the Technical Specification in Activity 4 is a specific solution to the Project Requirements defined in the previous step. The possibilities for this solution are many, and so a Technical Specification should also provide a clear argument for why the specific approach was taken.
This is also the last form of risk management that the analyst will utilize, by guaranteeing that the approach taken is the most optimal solution to satisfy the functional and non-functional requirements. The specific technological implementation for the project solution should guarantee the following:
Business processes are improved with maximum efficiency through automatization or other means.
The technologies chosen satisfy the functional requirements in such a way that results in: faster development, cheaper software costs, or most reliable solution. At a point some compromises will be made, and those will have to be argued.
The software engineering approach provides a unique and efficient solution to the specific problems outlined in the requirements.
Business Analysis contains a lot of theory, and we barely scratched the surface. The discipline should be performed by someone who truly enjoys taking ideas and transforming them into practical IT solutions. Fortunately Etanova does just that! Please do not take the risk of having your project fail before it even starts. Etanova’s Business Analysis Services are part of a complete business solution available for your project.
Etanova creates custom web based systems for organizations looking for professional IT services without having to deplete their budget. We are a company based in Vancouver, Canada and we apply it best practices in all aspects of project development. We also operate an office in Oradea where we outsource much of our work in order to ensure value-for-money.