10. Technology: Ensure that you are starting with the latest technology, as even the latest technology will be a little older by the time you complete the product.

9. Concept: Ensure that you do not start building a product that has several variants already in the market. Beat the drum to give the world a new beat.

8. Keep the air in your bag: Let the concept not leak out until you are ready to launch the product. Launch it with a bang. Advertise, blog, press conference, and whatever you feel appropriate for the launch. But ensure that your team confide in you in this exercise till you are ready to shout.

7. Convince, build trust: Convince yourself that you have chosen a right path even if it is risky. Demonstrate your management about your idea and the way you want to design/ launch it. Build trust among your team in giving a real shape to your dream.

6. Risk Management: It is very essential to jot down the risks involved, and ways to mitigate them depending on their severity.

5. Incentive: Let your team know what incentive they are going to get once the product and project is successful.

4. Project Sponsor: Mostly in such type of projects your management will sponsor the project, so all risk lies inside the house. Your stake is quite high in such projects. Equally important is the success of such projects.

3. Project Methodology: Adopt the right methodology and adhere to its requirements.

2. Project Plan: Ensure that such projects cannot tolerate much deviation in terms of time or money. Since in such projects all risk is yours, don’t let it increase at any cost.

1. Definition of successful project: Building a beautiful product in this case is of not any use if there is no buyer at the time of launch. Your total investment in the project can return only if you are able to find out a buyer.

Most common mistake that is made during the complete lifecycle of a project is not formally giving documentation (required at various stages) in project plan by assuming that documentation is not that prime. It is presumed that either the documentation will be done at the end or it is taken too casually and told to be done by everyone without assigning a proper ownership.

Both – Quality of Software and Quality of Documentation play a lead role in project management. Compromising with any of the two leads to increased cost, loss of customer satisfaction, delay in implementation or revenue loss.

What should be done in this sort of scenario?

The project manager privately updated me about the situation and asked for my help to get him out of this situation. I told him if he carries out in the way he is – he will never be able to finish his project.

I advised him to have an emergency meeting with his client and share his pain with them. Make them clear that you are not saying No to their requirements but there is a need of a boundary line drawn with mutual understanding. Cater to so far documented requirements as phase I. Finish it off. Get it signed off. Whatever new requirement or changes come from the customer – document it, analyze it. Any requirement that is asking for more than 4 hours of efforts, put it in phase II of the project. As soon as you finish off the phase I, finish off Phase II, sign off. And so on.

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.

For a software company having various new development projects a business analyst has to understand the existing business processes, methodology, rules etc. of the customer, document it (which itself is a specialized task) and hand it over to development team to embed the customer requirements into the software to be built.

For a software (or IT) sales company a business analyst has to sit behind the sales/ business development teams – understanding their current process of acquiring new business or sustaining current business and bring out a better approach, methodology, process to enhance business in terms of new business and holding current business.

For a manufacturing company a business analyst has to understand the process, re-engineer it to enhance the production, product yield, thereby increasing customer satisfaction and reducing defects or rejections.

A business analyst ‘s various caps thus include – business process analyst, business strategy analyst, business methodology analyst thereby becoming a backbone to business process managers, sales teams, management, development teams , product teams, quality teams etc.

The same applies to project also. Irrespective of its size, client, and customer requirements, each project has to be a success if in turn the organization has to achieve success. For that purpose performance management becomes a great tool. There has to be a performance management methodology clearly defined for that organization so as to assess the performance of each individual of the organization involved in the project directly or indirectly. A performance methodology should very clearly define the process of measuring performance. The process should be transparent, acceptable, measurable, and simple. Any cumbersome process is good for document purposes for difficult to adhere to.

The methodology should be universal for all the employees at all levels as it is very clearly evident that a project is like a relay race. The overall performance is highly affected by the weaker links. Even if there is a weak member in a very strong team, it is high risk for the overall project. As each member has to perform their individual task, in today’s scenario of recession, lean and low costs, each member’s performance keeps overall organization’s performance at stake.

You can do that with the help of your bug reports so far you have submitted back to the programmer or development team. Just pull out your last ten bugs reports produced from the code written by the same programmer. Check for a specific number of lines of code how many bugs were found. Based on this one report’s bugs were from how many lines of code. Do the same exercise for all other reports. Take an average for all ten reports.

Based on the number of lines of code, this way you can easily predict the number of bugs that will be there in the fresh set of code submitted by the programmer for testing.

Collaborative, Participative, and Interactive: The information flow should not be one way. It should comprise of praises, shouts, appreciations, arguments etc. Let each brain contribute in making it a success.

Be Demonstrative: Lead the project. Demonstrate by actions what you want from other members. Use fewer words and more actions, especially in case of crisis or a problem.

Identify the lazy goat: If there is any lazy goat that is bound to spoil the show, indentify it at an earlier stage so as to avoid higher risk at a later stage.

Keep a set of your customer shoes with you: Borrow a set of your customer shoes, and keep it with you during the project. Put off your shoes frequently, wear your customer shoes and then have a look at the project pace, progress and status. It will definitely give you a different perspective view.