This guide is focused on enabling better performance in company analysts and aspiring business analyst professionals. In this regard, I thought understanding the basics of project phases may be a useful read. Basically I'm hoping to touch upon the many different aspects of a technology project that achieves a particular small business outcome where business analysts play an essential function.

Why select technology jobs for business analyst debate?

Our world today is governed by technology. By the time we wake up in the morning to the time we hit the sofa in the night we are in a way ruled by technology. A business analyst function in a sense is better appreciated when there is technology demanded. As mentioned previously in my posts, anyplace within this world, that unites people, process and technologies would result in a problem.

When there's a business analyst, who is working exclusively on process with no effect to technology or with no facet of technology involved, then I would like to meet her or him. So coming to our topic - let's attempt to comprehend from a business analyst and consulting with stand point in a very simple way the different stages of a functional business endeavor that involves engineering.

Note - Please note that I'm refraining from getting into Software Development Life Cycle (SDLC) or Agile. I'd love to maintain the context of the article brief rather than specific to a specific project management fashion though what I do state would align to most methodologies.

Is a company analyst actively involved with the job sub phases?
Business job that entails technology are often divided into 2 large phases in the consulting world. The first phase is called Scoping and the next stage is called Delivery. These two phases contain multiple sub stages where a company analyst plays a very important role. We will look at them in detail.

The sub stages of a the Scoping phase of a consulting project are usually split into Scope Definition, Analysis and Functional Design.

The sub stages of a Delivery effort in a consulting mission includes Technical Design, Construction / Build, Test phase that includes System Integration Testing (SIT) and User Acceptance Testing.

Scope definition - From my experience, I have noted than frequently the scope definition of the project is prior to a business analyst being assigned to the job. Sometimes, the business analyst might get lucky and stand to be contained in the scope definition of the undertaking. But usually in this phase a project / functional manager, the program manager and subject matter specialists play a significant part. In some cases, this phase can be known as blue printing.

In certain cases the extent phase include the requirements gathering process while in some scenarios, it gets pushed to the analysis stage of the project.

Analysis period - Again although the term Analysis strictly describes analyzing the business requirements gathered, more often the requirements gathering process begin within this phase. The analysis phase of the project actively includes the business analyst interfacing with the stakeholder and collecting the business requirements and analyzing the prerequisites to better understand which requirements fit in the scope area defined and which doesn't.

It's a significant challenge that in some cases business requirements often exceed the specified project scope and may need to be identified with the business analyst and De-scoped. To the opposite in some cases, there's scope creeps and a lot of the company requirements are overlooked being recorded. The analysis phase is definitely an area in which a company analyst plays a crucial function.

Functional Design - In the consulting world, the design stage is split into practical design and technical design. The purpose design is the phase where design elements concerning data flows, requirements mapping to data flows, requirement functions which can be met through the design etc is going to be documented.

Technical Design - Technical layout as its name implies is the layout document that offers the technologies which defines the systems which will specifically be used to fit the operational business requirements documented by the business analyst. While the operational design document details the purposes that would be met as part of the design implementation, the technical layout sticks on to the technology used, kind of server to be used (Windows vs Linux), the type of database to used etc..

A whole lot of times in organizations these 2 documents are combined together to house one design document. The usefulness of the comprehensive design document is completely contingent on the methodology followed by the organization. In some instances, in which the company analyst is more functional some parts of the comprehensive design document becomes a challenge to understand.

A business analyst at the design phase plays the role of a solution expert. The company analyst is required to validate that the design record and the solution proposed meets the project objectives and the particular business requirements that were seized.

Build / Construction - While at a strict sense a practical business analyst function would be limited to demands planning, requirements gathering and documentation before hand to the IT teams, organizations today have a holistic perspective of the company analyst function. A business analyst may not play an extremely active role in the construction stage of the project. That surely does not mean that a company analyst moves on to another job at this stage or has a relaxing time. While the IT team operates on the construction phase of the job, a business analyst may be required to work on supporting the Testing preparation along with the job manager.

Apart from potentially supporting change management deliverables, a business analyst might be asked to assist drive reviewing the evaluation strategy, test plans, test scenarios, cases and scripts.

The CBAP handbook specifically calls out that producing design documents, test strategy, test strategies or implementing test cases is not considered as relevant work experience for CBAP certification. I'm sure most people would agree that no matter our likes and dislikes and what the handbook says, for many practical reasons, a business analyst typically ends up taking on these deliverables.

In my opinion getting our hands dirty on these deliverables is quite good because you'd no more be restricting yourself to the role of a company analyst however scaling up to be a management consultant.

Test Phase - I hate to break it to you, but testing is further split into sub components.

A business analyst might know that the systems integration test is more often the key to solving the majority of the problems and problems in a tech project. While in the build phase, the IT staff would ensure that they perform selected core testing on what they constructed, it more often becomes the role of a business analyst to support integration testing. The systems integration testing entails passing data through origin and down stream systems to frequently test the interface / information stream between the systems through predefined test cases/ scenario having a particular test result.

The User Acceptance Test (UAT) simplifies the systems integration evaluation. Within this stage, the testing is performed from an end-user / customer standpoint. It's anticipated that the testing from systems integration throws up a little of problems and bugs that will have to be solved prior to entering UAT. During UAT, the end-user or customer is given the flexibility to help choose the company situations they would like tested. The anticipated results (that should fit to the expectation of the consumer ) is frequently shared with the consumer to enable boost their confidence and sign off to the testing phase.

Testing is always done in a server environment out of the real-time production environment. Consequently, if you're in a meeting and hear people discussing about testing environments, do not be baffled. It is just a server environment which frequently reproduces the manufacturing environment but lets you make mistakes and fix them.

Implementation / Go Live - The implementation phase of the project is as soon as the codes and solution tried and tested through the other stages of this project are moved into the manufacturing environment. After the codes are moved into production and the systems are prepared to Go Live, together with the flip of a switch the changes are posted into creation and are live to be reflected.

As you would have noticed, the part of a business analyst is more than frequently exemplified in the initial phases of this project. Throughout the beginning stages of the job, there's a higher demand for the business analyst to interact with all the stake holders, collect requirements, document them, analyze requirements etc.. Hence a BA becomes the bridge between the business stakeholders and the IT teams making the role extremely important. At the exact same time, it's also important to get a BA's to understand the effect of their role and their work on other areas of the project.

For many aspiring BA's, I really do hope this article though lengthy, given you good insight into what happens beyond your role. Hope you liked it. Please feel free to talk about your comments.