Few SWOT Analysis Examples

View blog reactions

SWOT Analysis

SWOT analysis is done in strategic planning before the phases of SDLC. SWOT stand for Strength, Weakness, Opportunity, Threats. Basically we analyze our company, project under these four headings.

I suppose its nothing more than a structured form of brain storming, but because it is simple, it a great way at the start of the project to encourage people to think 'out of the box'.

That means, it is better to look into the industry where we are and then identify the threats and opportunity of the industry, not of our company but of the whole industry that we are in.We need to consider the competition right away,than we can identify company's strength and weakness.

The logic behind the SWOT analysis is to align company's strength and/or weakness to the opportunities of industry. This way we can attack the industry with the current company's strengths or we may remove the company's weakness to confront the threats of industry.

There are lots of tools in market to get templates for SWOT analysis like smartdraw, mindjet, etc.

These are some examples of SWOT analysis done by viewers.

View blog reactions

Business Analyst

The term 'Business Analyst' has different meaning in different organizations. To some, the business analyst's job is specifically limited to defining information, usually in terms of IT system requirements. For an increasing number of organizations, however, the business analyst has a wider role that examines the environment in which the IT system operates, to ensure that the identified requirements are justified.

The reality is that if you ask ten hiring managers what a business or systems analyst does you are likely to get ten different answers. Job titles and descriptions for analysts vary widely between organizations and the professional analysts may have titles as diverse as: Business Analyst, Systems Analyst, Business Systems Analyst, IT Specialist, Requirements Analyst, Consultant, Programmer/Analyst, etc.

A Business Analyst is a business problem solver, capable of analyzing the business to identify problems and/ or opportunities and to define solution characteristics. A Business Analyst can be a liaison between the business and technical worlds, but is not intoxicated by technology, and not the end user. They provide the process, questions, and techniques to efficiently extract the information needed from the Business Users for successful application development projects. A Business Analyst can also be an integral part of strategic planning, business innovation, or re-engineering effort to help select the right projects and/or facilitate the analysis of what needs to be done to bring the business to a desired future state.

"The Modern Analyst bridges the gap between the Business and the Technology"

The Analyst is the primary liaison between the business community, technology organization and external partners for all project requirements during the analysis phase of a project. He or she is responsible for proactively conducting interviews with all project stakeholders to elicit functional requirements, modeling those requirements in an organized manner, then managing and communicating those requirements throughout the project life cycle. Upon establishment of the requirements baseline, he or she will address change management issues and assist in test planning.

In order to be effective, today’s Modern Analyst must understand “The Business”. He must have an intimate knowledge of the business processes and needs of the organization they are working for.

At the same time, the Modern Analyst must understand the challenges of technology and the needs of the development team. He has to realize that technology, while a great advent, it’s not easy to employ – and it requires highly specialized technical skills and resources.

A Business Analyst performs one or more of the following activities:

1. Scope the system. During the initial phase of a project, often called “iteration zero” or simply the inception phase, BA may be the only “development staff” assigned to the project. At this point they will work with key project stakeholders to formulate and communicate the business vision, to envision initial requirements, and to scope the project. Their fundamental goal is to get the project focused early by translating the initial high-level vision into something realistic. They may also help to identify potential areas of automation and even to aid in re-engineering the underlying business process.

2. Translate business needs. A major responsibility of BA is to work with project stakeholders to translate their requirements into something that developers can understand as well as to translate the resulting questions that the developers have into something the stakeholders can understand. This is an iterative process throughout the project.

3. Translate technical issues. A BA also explains technical/architectural complexities to project stakeholders, such as why your HTML-based application can’t have as slick of a user interface as a Visual Basic application. BA's often explain what the developers are doing and why they need to do it, including explanations of the basis of schedules and estimates.

4. Model and Document. BA often works with project stakeholders to identify, model, and then document their requirements and business domain details.

5. Act as a communication broker. BA typically have very good connections within the business community and therefore are in a position to help development teams find the right people to work with.

6. Political mentor. BA often help project teams through the political minefields within their organizations, particularly when the BA has worked within the same organization for several years.

7. Test and Validate. BA work with project stakeholders to validate their requirements and analysis models via techniques such as reviews, walkthroughs, and play acting. BA often aid in writing User Acceptance Test (UAT) test cases and act as a liaison between project stakeholders and your testing organization during UAT.

8. Represent stakeholders. When project teams don’t have direct access to their project stakeholders, clearly not a good situation, BA act as “stakeholder surrogates”. Typically developers treat a BA as the “customer” from which requirements, domain information, and business priorities are provided. The BA in-turn work with the stakeholders to obtain information and to verify decisions.

Learn more about the qualities of a Business Analyst.

View blog reactions