business analyst

Oct 26 2009   10:00AM GMT

Five ‘must-have’ skills to be a Business Analyst

Posted by: Jaideep
business analyst, business analysis, Project Management, Software Project, software, business process, business rule, customer requirement, software requirement, quality, process, Development, business knowledge, technical knowledge

As stated in my previous post, a Business Analyst is a quite powerful role that establishes the base of a project. It is the first visible pillar for a project which involves communication, leadership, writing, technical and functional skills together. A business analyst has to have a great depth of knowledge of the business on one hand, a sharp understanding power, strong writing skills, great communicator, and a good influencer. Let us see what are the ‘must-have’ skills without which a business analyst can not survive? And why are those skills so important to be a business analyst? Without any relevance to the order in which they are mentioned (as all are equally important) these skills are:

5. Business Knowledge: A good amount of experience/ exposure/ knowledge of customer business are very important for a business analyst

4. Listen and Understand: A business analyst has to be a good listener and with a sharp understanding power without which all the discussions with customer will be fruitless.

3. Technical Knowledge: There will be quite a few technical discussions at customer site. The BA has to be quite conversant with the technologies and methodologies present at his organization.

2. Communication: A business analyst has to be a strong communicator. During the customer meetings, if he does not communicate well about his organization’s capabilities to build up the trust and confidence, probably customer may not gel well with his ideas.

1. Writing skills: Very important skill required for documentation and for conveying the right messages across the board.

Sep 23 2009   10:00AM GMT

Quality of documents says it all about the health of the project

Posted by: Jaideep
Project Management, project manager, Software Project, business analyst, coder, programmer, tester, quality

A software project has to undergo various stages before reaching the final stage of customer sign off. At each stage of the project there are certain set of documents that are maintained by the project team for internal or external purposes.

These documents are prepared by various team members – by business analysts, by coders, by project manager, by testers and by other managers.

The Quality and maturity of documents straightaway tell about the health of the project, the team, the management, the product and the progress. It tells clearly about the intentions behind the documentation – that if it is merely a formality or it is really meant for helping the project progress.

And it is not difficult to ascertain the intentions after going through the documents maintained or being maintained during the project.

Jul 17 2009   10:00AM GMT

Why hit the people? Hit the process if there is a failure in a software project

Posted by: Jaideep
Quality Assurance, Software Project, Project Management, people management, HR, QA, QC, Q-tag, developer, quality, quality control, quality culture, quality building, product, stakeholder, business analyst, project manager, project team, development team, testing team, implementation team, product build

People are not wrong, processes are. People in an organization do what they are told to do. Organizations who hit on people at the time of failure are not doing the right thing. It is the process that is to be blamed not the person with Q-tag. As long as quality is considered to be the child of people with Q-tag in the organization, and the culture is so around, the non Q-tag people will keep themselves enjoying building a product without quality. Why not blame the developers for developing so many bugs along with the requirements building. Why not blame the analysts who could not understand or translate the requirements correctly. Why not blame the management for not putting the right people and process at right place. This blame game itself is merely a scapegoat in any organization until the focus shifts from people to process enhancement.

Analyze the failure as a team involving all the stakeholders. Management, business analysts, project managers, project team, development team, testing team, implementation team have to sit together and brainstorm. Failure is to learn and not fail again. Mainly failure can occur due to following three factors:

Teams do not work and deliver in desired fashion – required innovation, awareness, training, cohesiveness, team building, and collaboration
Wrong people in the team – HR and management has to play a major role and look into the recruitment process.
Failed to build right product – needs training, demonstration, pairing, indentifying right people for right job.

Jul 15 2009   10:00AM GMT

Who owns the Q-Tag in a software development company?

Posted by: Jaideep
Quality Assurance, Q-tag, quality control, Software Project, Project Management, stakeholder, project methodology, project management framework, project implementation, software build, software implementation, product approval, Quality-tag, project team, development team, implementation team, testing team, team, QC, QA, business analyst, re-testing, testing, Bug, bugs report, test report

In any software development and implementation company there is always a need of quality assurance and quality control people who own the responsibility of setting the right methodology and framework for development and implementation (QA), bugs identification and product approval (QC). Usually everyone in the organization has an inherent feeling that the quality is the responsibility of only these few persons belonging to this Q-department of the organization. Business analysts understand the customer and business requirement, hand it over to development team for building the product. Development team develops the product, and hands it over to QC team. QC team tests the product, finds out the bugs, and submits the report to development team. Development team fixes the bugs and returns the product to QC persons for re-testing and verification. After few exchanges between development and QC team, the product is declared as defect free and is released or launched for implementation.

If top management, development team, business analysts, implementation team and all other stakeholders think that quality is just the responsibility of only the persons belonging to quality department, they all are wrong. If Q-tag is limited to only a limited persons belonging to Quality department among all stakeholders, a product can never be built with great control on quality aspect.

Q-tag has to be on each of the stakeholder in a software project. When each and every person wears a Q-tag – the analysis, building, testing and implementation will be more justified. Otherwise there will always be a big question at the time of failure of a product build – that who is responsible?

Jun 10 2009   10:00AM GMT

Ten Reasons of getting into pitfall of leaving a scope of software development at customer site

Posted by: Jaideep
Project Management, Software Project, change management, project organization, developer, project sponsor, project director, project manager, key user, implementer, technical lead, business requirement study, business analyst, business analysis, requirement analysis, requirement gathering, implementation phase, project phase

In the previous post we learnt what all could a software project could lead to in presence of higher scope of software development at customer site during implementation phase. Let us see what all factors are responsible of insufficient requirement gathering during business study phase of a project.

1. Incompetent team (vendor): Any project calls for a project team. A good team at both ends is important. Both teams have a substantial role during a project. If key users selected at customer site for delivering process knowledge to requirement analysts (vendor), there are higher chances of wrong information driven. The key users chosen should rightly be the actual process owners not essentially be at the higher level in the organization.

2. Incompetent team (customer): A right selection of project manager and analysts is equally crucial. The team has a short duration stipulated for gathering requirement information and understanding business processes. And mind it, this is not an individual race, it is a relay race, and weakest link will decide the overall result of the project.

3. Non commitment (customer): Well the process owners are the key users, but if are not serious or have not received the right message from their management may not be seriously committed to the vendor team. A non committed team will not be able to impart right knowledge, processes, practices and information required critically for a project.

4. Non commitment (vendor): A team of good committed project manager and analysts is equally crucial for gathering information. The previous experience on business domain and success factor definitely counts in.

5. Lack of time (customer): Key users identified if are engaged in other important projects running in the organization will be always short of time for providing right information to vendor project team.

6. Inappropriate discussions: In a limited timeframe of business study, there will be limited discussions. So all discussions should be crisp, purposeful, well driven and result oriented.

7. Improper documentation: Well explained requirements if not documented properly may lead to a wrong, incomplete product. Right people with right business and process knowledge have to acquire a good documentation skill also to lead the project to right direction and grand success.

8. Top Management involvement (customer): If customer management thinks that providing key users completes their job in the project, they are wrong. Their involvement in all important meetings is as important as the business is.

9. Project Organization: A right architecture of project team is very important. The project sponsor, project directors, project managers, key users, developers, implementers, technical leads from customer and vendor respectively should be the right mix of people.

10. Change in requirements: Any change in business or process during or after the requirement study phase has to be communicated to vendor team well in time, so that by following the change management procedure, the changes are taken care of properly.