Suppose what makes a profession is simply a series of accoutrements such as a Manifesto or a Bill of Rights or a set of Principles? After all, doctors have the Hippocratic Oath. Politicians have the words that they agree to when they are sworn in (defend and uphold…). Lawyers have…well, they have something. Agile software developers have the Programmer’s Bill of Rights written by Ron Jeffries.
So I propose that we have some statements of purpose and goal and principles that will govern and guide our profession.
Since a Manifesto seems to be the rage nowadays, let’s start with a Business Analyst Manifesto. This Manifesto was created by Laura Brandenburg
Out of chaos, we create order.
Out of disagreement, we create alignment.
Out of ambiguity, we create clarity.
But most of all, we create positive change for the organizations we serve. 
Doug Engelbart a computer pioneer and inventor of the mouse among other innovations, may contribute our statement of purpose (paraphrased):
The business analyst increases the capability of the organization to approach a complex problem situation, to gain comprehension to suit the organization’s particular needs, and to derive solutions to problems.
I might add a Bill of Rights and Empowerments that I posted several years ago: 
As a business analyst you have the right to:
- Ask questions
- Understand the problem and problem domain first
- Make sure you are solving the right problem
- Challenge the business
- Challenge the solution team (to explain why they are choosing to solve the problem in a certain way)
- Come up with solutions
- Define the problem domain
- Solve the problem
As a business analyst, you are empowered to:
- Ask questions
- Challenge the norms, the “way things are done” both on the business side and on the development side
- Try new techniques, methods, and processes to perform your job
- Suggest new methods or ways of executing business processes in the organization
- Analyze instead of accept
- Get and understand information first before committing to a solution
- Ask more questions
- Do the good quality job for the organization as a whole instead of only individual organizational entities
- Define and solve the business problem
While these are three years old, they still apply to today’s challenging environment, and are perfectly applicable to an agile development approach as well.
Finally, we should have some principles or guidelines to follow, some large scale best practices which unify and coalesce what we do. I submit that we can collectively perhaps assemble applicable principles amongst us. I will humbly step into the gap with some principles that might be adopted:
Principle 1 – Focus on the Product
The business analyst focuses on the product not on the project
Understand what a solution is worth to the business
While the project manager focuses on the project to make sure that the project is on time, within budget and delivers everything required, the business analyst focuses on what is to be delivered to make sure the real problem is solved and there is a discernible benefit to the organization when the project is complete.
Principle 2 – First Define the Problem and Then the Solution
Paraphrasing Davy Crockett: Be sure you know what the real business problem is and then go ahead.
Too many times business analysts assume that a statement given to them by the business is a problem when in reality, the business provides a solution. That solution may not be the most efficient or effective solution; in fact that solution may not even be right. And when the business complains that their problem is not solved even though you implemented their solution, you will likely be blamed for the failure. Spend the extra time up front to make sure that you are dealing with the real problem that needs solving.
Principle 3 – Users Do Not Have Requirements
Users do not have requirements; stakeholders do not have requirements – they just have information The business analyst seeks that information and analyzes it to produce the solution document containing the requirements.
Starting with the assumption that the requirements only exist when the business analyst analyzes them into existence is a good starting point for solution development. Taking the opposite assumption – the users know exactly what they want and what the technology can do to solve their problem – is a recipe for long meetings, continuous turmoil and change, and consistent conflict resolution.
Principle 4 – Focus on Information Not Individuals
The problem in elicitation is not finding the right individuals to talk to; it is finding the right information regardless of source.
Too many times the business analyst is told to go get the requirements from certain individuals. Those individuals may not be available or may not know they are supposed to be the repository for all answers. Sometimes Subject Matter Experts aren’t. The best approach for the business analyst is to determine what information the business analyst needs so that the business analyst understands the problem and can create a solution, and only then determine where that information is located. If some individuals cannot be accessed, most likely the information still can be acquired through other sources.
Principle 5 – Separate Elicitation from Analysis
When eliciting information, do not analyze; when in analysis, do not create information.
When you analyze while gathering information the responders interpret the analysis as judgment on the information provided or on themselves. This stems the flow of information. To keep the information flowing, keep the judgment and analysis out of the interchange.
Similarly when you are analyzing the information, and you add new information not obtained through elicitation, you are making assumptions about that information. You are weakening your analytic conclusion. Turn any supposed information not based on elicitation or deductive conclusions into questions that require further elicitation.
Principle 6 – Improve the Process First then Add Technology
Evaluate non-IT solutions first before resorting to computers and software to solve the business problem. Focus on the business, and how IT can be used to improve and enhance the business’s status quo
Constantly review and appraise the organization’s processes and operations to determine where changes can be made that will add value to the organization
Our job, as business analysts, is to add value to the organization by solving business problems. Suzanne Robertson puts it this way, “The job of a business analyst is to identify what people need so that they can improve the way that they do their work and to communicate those needs to people who can implement solutions””  In other words, determine what will make things better for the business then determine what the technical solution might be, if any.
Principle 7 – Do not let documentation substitute for communication and collaboration
Requirements describe the solution to a defined, understood and approved business problem
Over the years the emphasis in the requirements process of software development has been on the production of a requirements document. Whole business analyst teams have been organized around the creation of said document. It becomes a project is and of itself. And while it may well be a good idea to treat the definition of the solution as a project, it is not a good idea to replace solid communication with a document. Remember that the document should be the recording of all the communication that has occurred beforehand, not the communication itself.
Principle 8 – Gain Acceptance before you gain Approval
Acceptability of a solution is not the same as approval of a solution. There are different dynamics at play.
All sorts of problems occur when the person who has the authority to approve is in the same meeting as those who need to confirm that the solution will work for them. Separate the confirmation or verification process from the approval process. Get the solution definition confirmed by those who are eventually going to use the solution in real life: “Yes this will solve our problem!” and accepted by those who are going to implement the solution: “yes, we can do this within the project constraints!” before passing the solution to those who need to authorize the funds or resources to implement the solution.
Principle 9 – Make Sure the Business Community is Ready for the Product / Solution
The business problem is not solved until the solution is being used in the business environment.
You can have the best solution, a Nobel Prize winning solution, and have it never used because the business people who have to use it don’t use it for whatever reason. Perhaps they are not ready for it. Perhaps they really like their work-around. Perhaps they have had too many changes in the recent past to be able to assimilate this one. The business analyst needs to lead the Transition from the current process to the new, improved process. Not only does the business analyst need to make sure that the new process and / or system is ready for the users, but that the users are ready for the new process and / or system.
Principle 10 – Communicate, Cooperate, Collaborate
Keep communications flowing in all directions
Live on the Feedback
Above all, communicate. Never let a day go by without an interesting discussion or provocative dialog. Turn conflict into cooperation. Turn contention into collaboration. Eliminate uncertainty and risk by the exposure of new information.. Never be a bottleneck of information. Learn. Teach. Spread the information and expand it. Know more today than you did yesterday
So there are ten principles to start our Principles of the Profession. I am sure there are more that you can think of to add to our list.
Don't forget to leave your comments below.
 Brandenburg, “The Business analyst Manifesto”, Bridging the Gap, 12/17/2009
 Blais, “Business Analyst Rights and Empowerment”, Bridging the Gap, 4/29/1020
 Pullman & Archer (ed), Business Analysis and Leadership: Influencing Change, Kogan Page, Ltd, London, 2013