One of the bigger issues in the world of business analysis nowadays is the wearing of multiple hats. The business analyst is asked to prepare a business case for a project and then when the business case is approved is asked to take over as project manager, and, incidentally, also perform the expected business analyst duties. Coming from the other direction, the project manager is assigned a project team without a business analyst and told to take care of the requirements as part of the project manager job. I call people in these situations, "slashes", as in "Business analyst / project manager".
Why does this happen? Mostly belt tightening. Organizations have to cut corners and save expenses so they combine roles. And on smaller projects this might work fairly well depending on the business analyst or project manager who is awarded the "slash". However, any project of depth, complexity, length, size, or visibility is going to be in grave danger of failure with one person trying to do both roles. The danger specifically to the business analyst is that ALL the responsibility for the project will end up on the "slash's" shoulders. There is no one else. One hopes that the combination of the roles is not simply a ruse to gain someone at which to point fingers.
In upcoming blogs I'll talk about the issue of the "slash" and how you can handle the situation, short of dusting off the resume, and turn it into a break even if not an outright success.
Saturday, December 3, 2011
Sunday, October 30, 2011
Business analyst: Best Practices for Success
It looks like the book is finally a reality. We're in Buffalo, NY, on a trip that included a few days in Syracuse earlier in the week, and now on our way back home. There we will get our first look at the actual book which arrived while we were gone. The book hits the book stores on November 8, but can be ordered now.
I'm popping over to the other side of Florida on Tuesday for the BBC conference in Fort Lauderdale. It's my first conference of this nature and apparently won't be my last. Hopefully I'll see some of you there.
So I'm celebrating the book's release by starting the new book which is going to deal with being an agile business analyst at the center of the organization.
I'm popping over to the other side of Florida on Tuesday for the BBC conference in Fort Lauderdale. It's my first conference of this nature and apparently won't be my last. Hopefully I'll see some of you there.
So I'm celebrating the book's release by starting the new book which is going to deal with being an agile business analyst at the center of the organization.
Wednesday, August 31, 2011
Gathering or eliciting requirements
If you gather requirements, you are assuming the business people or users know what the requirements are and can give them to you - that is, they can express the requirements for their system or enhancement clearly and concisely. Gathering implies that something is already there to gather. It is a rare circumstance when the users or stakeholders or anyone in the business has a clear understanding of the detailed requirements that will solve their problem. It's hard enough to find business people who can even state their problem concisely and clearly.
Eliciting is gathering information with understanding. The business analyst asks questions and more questions and analyzes the information gathered to produce the requirements - what is necessary to solve the problem. Investigation might be a better word for what business analysts do.
You gather apples or wheat.
You elicit information which you then analyze into requirements. That is the business analyst's forte. We are after all, analysts, not gatherers.
Eliciting is gathering information with understanding. The business analyst asks questions and more questions and analyzes the information gathered to produce the requirements - what is necessary to solve the problem. Investigation might be a better word for what business analysts do.
You gather apples or wheat.
You elicit information which you then analyze into requirements. That is the business analyst's forte. We are after all, analysts, not gatherers.
Saturday, August 13, 2011
Salute and March
"Salute and march". This is a somewhat pejorative term, even in the military from whence it originates. While on the positive side it may imply unwavering devotion to a leader and unquestioning faith in the leader's sense of direction, the phrase has come to mean failure to think for oneself and simply following orders to stay out of trouble. The epitome of this behavior was in Paris Island in the 60s when a Drill Instructor marched his troops at night into a swamp where two recruits died. Marine Corps policy was changed after that.
"Salute and march" is the negative side of being overly polite and meek. (Excessive politeness that is not assertive leads to meekness in perception if not in actuality.) Unfortunately, much of the business, especially marketing and mid-level management, who may be more concerned with their own image, career path, and reputation, expect business analysts to accept their solution and make it happen without a need to expose the business analyst to the real business problem and let the business analyst do their job (for example coming up with a better solution). The business analyst in turn faced with a senior officer in the company (someone in other words outranking them) will "follow orders" and go get the requirements. The business analyst will do so politely and conscientiously. It all works out as long as the solution implemented is in fact the best solution. When it isn't as so often happens the business manager blames the business analyst (and therefore so does everyone else). The business analyst may be perceived as being "meek" for simply following orders.
When the business analyst fails to do their job of communicating and analyzing because they are afraid of hurting someone's feelings, being impolite, crossing swords with higher authority, or they are simply afraid for their jobs, the business analyst is not doing their job. (Of course there could be other psychology at play as well. For example, some good old passive aggressive stuff: "We'll just do it their way and when it fails then they'll see how good my solution was and they'll be sorry!")
The business analyst always has the right to ask questions and more questions. The business analyst always has the right to ask what the real problem is behind any proffered solution. The business analyst has the right to challenge a solution that is flawed or doesn't go to solving the problem. And this can be done quite politely. I submit that failing to do this when the circumstances call for it might well be considered weak, ineffectual or simply "salute and march". While this may win points with the business manager who gets his or her way without challenge, it certainly is not the best for the overall organization or for the business analyst's peace of mind.
"Salute and march" is the negative side of being overly polite and meek. (Excessive politeness that is not assertive leads to meekness in perception if not in actuality.) Unfortunately, much of the business, especially marketing and mid-level management, who may be more concerned with their own image, career path, and reputation, expect business analysts to accept their solution and make it happen without a need to expose the business analyst to the real business problem and let the business analyst do their job (for example coming up with a better solution). The business analyst in turn faced with a senior officer in the company (someone in other words outranking them) will "follow orders" and go get the requirements. The business analyst will do so politely and conscientiously. It all works out as long as the solution implemented is in fact the best solution. When it isn't as so often happens the business manager blames the business analyst (and therefore so does everyone else). The business analyst may be perceived as being "meek" for simply following orders.
When the business analyst fails to do their job of communicating and analyzing because they are afraid of hurting someone's feelings, being impolite, crossing swords with higher authority, or they are simply afraid for their jobs, the business analyst is not doing their job. (Of course there could be other psychology at play as well. For example, some good old passive aggressive stuff: "We'll just do it their way and when it fails then they'll see how good my solution was and they'll be sorry!")
The business analyst always has the right to ask questions and more questions. The business analyst always has the right to ask what the real problem is behind any proffered solution. The business analyst has the right to challenge a solution that is flawed or doesn't go to solving the problem. And this can be done quite politely. I submit that failing to do this when the circumstances call for it might well be considered weak, ineffectual or simply "salute and march". While this may win points with the business manager who gets his or her way without challenge, it certainly is not the best for the overall organization or for the business analyst's peace of mind.
Sunday, July 31, 2011
words
The business analyst's world is about words. Words make up the requirements. Words occupy interviews and meetings to obtain information. The information itself is usually words, occasionally interspersed with pictures or diagrams. Much of our analysis is done by analyzing words. Words are variable and ambiguous and vague and many times describe the wrong things. They even lie. They are, however, what we have. We tried pictures once, and discovered that drawing pictures, while less ambiguous, was also much less efficient as a means to communicate.
With all this emphasis on words, and the corresponding frameworks of grammar, punctuation, oration, and exposition, is it any wonder that technologists trained in the black and white world of bits and bytes have difficulty navigating the verbal ocean? Technologists want clear, unambiguous, concise expressions of solutions, wants, needs, and the like so they can convert the words into software and applications. In the role of translator, that's what the business analyst does: play word games of reduction, precision, and exactitude. The business analyst takes a vague notion of a barely conceived idea and turns it into a model and a plan that will eventually become a best selling web site or an innovative medical device that saves lives. It's all in the words.
With all this emphasis on words, and the corresponding frameworks of grammar, punctuation, oration, and exposition, is it any wonder that technologists trained in the black and white world of bits and bytes have difficulty navigating the verbal ocean? Technologists want clear, unambiguous, concise expressions of solutions, wants, needs, and the like so they can convert the words into software and applications. In the role of translator, that's what the business analyst does: play word games of reduction, precision, and exactitude. The business analyst takes a vague notion of a barely conceived idea and turns it into a model and a plan that will eventually become a best selling web site or an innovative medical device that saves lives. It's all in the words.
Wednesday, May 18, 2011
The Business Analyst as Innovator
One of the agile precepts is the build it as you go approach. Regardless of the size of the final deliverable, the product is created and delivered in small releases, each release adding some value for the customer or product owner in an iterative process. The decision of what should be developed each release is done by listing all the features and functions a customer wants and then carving out those features the solution team can implement in the next iteration.
There is an underlying assumption here which is rarely true: all the innovation and capture of new ideas for the product has already been done before the implementation effort takes place. I'm wondering where that innovation took place and who did it? The solution team innovates, but the team innovates in terms of software development process improvement (a standard mandatory element of the Scrum process, for example) and technology. But who is providing the business innovation: the new product that will eclipse the competition, the variation in service offerings that will increase the efficiency of business service delivery, the internal improvement invention that will reduce the overall cost of doing business?
While agile does not address this issue with its focus on development of working software, someone needs to do it. The product owner is focused on getting the defined features implemented to solve the immediate business problem and then getting back to work. Who addresses innovation? The business analyst. The very role the agilists have claimed should be removed from the agile equation.
Perhaps it is a better and more valuable role for the business analyst in the overall organization to be focused on innovative ways of improving the businesses processes thus directly returning value to the bottom line. A higher calling, perhaps. So when the business analyst role is summarily excised from the agile development cast of characters and product owner is not an option and scrum master doesn't seem to fit, perhaps Corporate Innovator or Business Process Improver might be the role to pursue.
There is an underlying assumption here which is rarely true: all the innovation and capture of new ideas for the product has already been done before the implementation effort takes place. I'm wondering where that innovation took place and who did it? The solution team innovates, but the team innovates in terms of software development process improvement (a standard mandatory element of the Scrum process, for example) and technology. But who is providing the business innovation: the new product that will eclipse the competition, the variation in service offerings that will increase the efficiency of business service delivery, the internal improvement invention that will reduce the overall cost of doing business?
While agile does not address this issue with its focus on development of working software, someone needs to do it. The product owner is focused on getting the defined features implemented to solve the immediate business problem and then getting back to work. Who addresses innovation? The business analyst. The very role the agilists have claimed should be removed from the agile equation.
Perhaps it is a better and more valuable role for the business analyst in the overall organization to be focused on innovative ways of improving the businesses processes thus directly returning value to the bottom line. A higher calling, perhaps. So when the business analyst role is summarily excised from the agile development cast of characters and product owner is not an option and scrum master doesn't seem to fit, perhaps Corporate Innovator or Business Process Improver might be the role to pursue.
Saturday, April 16, 2011
the BA and the PMO
Down in Sao Paolo this week for a BA Congress I heard a lot of talk about the PMO. Since it was a BA Congress the talk centered on the role of the BA when there is a PMO. One of the interesting answers, one that is being implemented by many companies in North as well as South America, is positioning the BA as the information gatherer for the PMO decision making process. The business analyst defines the real business problem and the conditions and impacts of that problem so that the PMO can make a reasoned decision about whether the problem should be solved. Sometimes the business analyst authors the business case and sometimes the business analyst participates in the creation of the project charter, both of which may be used as decision papers. When the business analyst is assigned to support the project and assist in defining the solution, the business analyst is also keeping an eye on the business to make sure the problem still needs solving so that the organization does not get a zombie project (a project that has lost its life in terms of useful return to the organization, but still continues because no one wants to stop it).
In many of these instances, the business analyst works directly for the independent and objective Project Management Office rather than for IT or some specific business unit. I like the concept.
In many of these instances, the business analyst works directly for the independent and objective Project Management Office rather than for IT or some specific business unit. I like the concept.
Saturday, April 2, 2011
The Business Analyst as Producer
In the theater, both live stage and movies, there is a role called "producer". In many cases, the producer is the financial backer of the movie or play, and may be silent having no further interaction with the project other than signing checks. Most producers are actively involved with the making of the movie or staging of the play. The primary goal of the producer is to oversee and deliver a project while preserving the integrity and vision of the film or stage production.
The business analyst does not usually finance a project. However, the business analyst is responsible for the integrity of the solution and the approval of the audience, namely the business community.
The producer starts work by obtaining the rights to a work to be transferred to the screen or stage or approves a script for production. This then is the problem statement: the script is not a movie. The business analyst starts work by defining the business problem. From there the roles are fairly similar.
Wile it is the director who works with the actors, the stagehands, the cameramen, the extras, the stuntmen, the makeup and costumers and so forth to implement the production, the producer interacts with marketing and potential audiences and publicity and all those factors that influence the final result outside the sound stage. It is the project manager who performs that role with the business analyst, directing and managing the solution team of programmers, testers, data base analysts, architects and so on. The business analyst provides the feedback from the audience - the stakeholders and business community - and keeps the project aimed at the target of solving the business problem.
Perhaps in these days of agility when the business analyst who only defines requirements is considered to be superfluous, recasting ourselves as IT producers wedded to organizing the entire product from problem definition to solution in the business environment might be a valid compromise.
The business analyst does not usually finance a project. However, the business analyst is responsible for the integrity of the solution and the approval of the audience, namely the business community.
The producer starts work by obtaining the rights to a work to be transferred to the screen or stage or approves a script for production. This then is the problem statement: the script is not a movie. The business analyst starts work by defining the business problem. From there the roles are fairly similar.
Wile it is the director who works with the actors, the stagehands, the cameramen, the extras, the stuntmen, the makeup and costumers and so forth to implement the production, the producer interacts with marketing and potential audiences and publicity and all those factors that influence the final result outside the sound stage. It is the project manager who performs that role with the business analyst, directing and managing the solution team of programmers, testers, data base analysts, architects and so on. The business analyst provides the feedback from the audience - the stakeholders and business community - and keeps the project aimed at the target of solving the business problem.
Perhaps in these days of agility when the business analyst who only defines requirements is considered to be superfluous, recasting ourselves as IT producers wedded to organizing the entire product from problem definition to solution in the business environment might be a valid compromise.
Friday, March 25, 2011
Why don't the customers know their own problem?
Clients and business people are typically too close to the problem to be able to really see what it is. That is why a business analyst can be so valuable. A BA can ask the right questions, step back from the symptoms, and see the real problem. Many times the client really doesn't know what the problem is, just that there is a problem. Our job as business analysts is to help the clients identity the real problem and make sure the problem is worth solving (aligned with organization strategies and goals, high priority in the scheme of things, cost beneficial to solve, etc.).
The requirements are what is necessary for the business to do both from a business perspective and technologically. Consider this: if the client knew what the problem was and the requirements - what to do to solve it - what would the client need you for?
The requirements are what is necessary for the business to do both from a business perspective and technologically. Consider this: if the client knew what the problem was and the requirements - what to do to solve it - what would the client need you for?
Saturday, March 19, 2011
When agile arrives move up
So management has decided to change software development processes to a more agile approach. And that means you, the business analyst, need to adopt a product owner role, or perhaps a scrum master if that's the way they go. In any case, your old rituals of gathering information, analyzing it, and producing an extensive set of requirements amidst negotiation, mediation and lots and lots of meetings are no longer going to be needed. So what do you do? Step up.
Someone has to evaluate whether the problems the product owner wants to solve are aligned with organizational strategies and goals. Someone has to verify that the solution that comes out of the iterations will not adversely impact other departments or processes. And someone has to coordinate, on the business side, with the other projects that are in process at the same time.
And that someone is the business analyst. Who better?
Someone has to evaluate whether the problems the product owner wants to solve are aligned with organizational strategies and goals. Someone has to verify that the solution that comes out of the iterations will not adversely impact other departments or processes. And someone has to coordinate, on the business side, with the other projects that are in process at the same time.
And that someone is the business analyst. Who better?
Saturday, February 26, 2011
Has it come to this?
There is a thread on a LinkedIn business analyst group entitled "Are most BAs useless?" It is not the idea of the thread or the comments, both for and against the general concept of a business analyst's role in the organization; it's the word "useless". It is hard for me to even consider the words "business analyst" and "useless" in the same sentence referring to each other. There are business analysts who merely take orders, that is they perceive their job is to collect requirements from the user community, rewrite them into a requirements template and turn the requirements over to the solution team. No analysis. No evaluation. The customer is always right. I do not believe these types of business analyst are representative of the profession. I also do not believe they are useless. Clearly management of the organization in which they work believes they are performing a service even if all they are doing is keeping peace between the business and development communities.
Other business analysts see their job as intermediaries who call meetings, facilitate requirements sessions and generally spend their day with groups around conference tables. Again as unrepresentative as I may believe their activities are, they are still not "useless". I could go on.
I suppose there are business analysts who would be considered by any standard as "useless", especially by agile developers or pundits. But I submit that there are programmers or developers that are equally useless based on accepted standards of programming efficiency and effectiveness. I knew some. All professions have members who might be considered useless as a practitioner of that profession. It may be that they are simply in the wrong profession.
What a comment like that tells me, especially since it engenders a lot of comment in support with ample examples of "useless" business analysts, is that the advent of certification and the high demand for business analysts has produced a wave of new comers to the profession who may be here for the quick buck, or to avoid layoffs affecting whatever profession they are escaping from. People whose heart, mind, and soul are not in the career of business analyst. And that's a shame. Every profession I'm sure suffers from the same malady of hangers-on or pretenders at the profession. I just didn't think it would happen here, and so soon.
Other business analysts see their job as intermediaries who call meetings, facilitate requirements sessions and generally spend their day with groups around conference tables. Again as unrepresentative as I may believe their activities are, they are still not "useless". I could go on.
I suppose there are business analysts who would be considered by any standard as "useless", especially by agile developers or pundits. But I submit that there are programmers or developers that are equally useless based on accepted standards of programming efficiency and effectiveness. I knew some. All professions have members who might be considered useless as a practitioner of that profession. It may be that they are simply in the wrong profession.
What a comment like that tells me, especially since it engenders a lot of comment in support with ample examples of "useless" business analysts, is that the advent of certification and the high demand for business analysts has produced a wave of new comers to the profession who may be here for the quick buck, or to avoid layoffs affecting whatever profession they are escaping from. People whose heart, mind, and soul are not in the career of business analyst. And that's a shame. Every profession I'm sure suffers from the same malady of hangers-on or pretenders at the profession. I just didn't think it would happen here, and so soon.
Saturday, February 19, 2011
changing advice
Never think of what you are doing in terms of requirements, or systems, or software, pr even processes. Always think of what you are doing in terms of change. You are changing the organization. You are solving a business problem and bringing about a change, small or large, it’s a change. And the success of the change is not necessarily in the pizzazz of the software or the efficiency of the system, but in how the people affected by the change will accept and adopt it. Knowing this in advance and letting it infuse all you do will increase the chances of success in each of your endeavors.
Thursday, January 13, 2011
What is an agile BA?
Recently there was a discussion on the Agile BA Linkedin discussion group about the difference between an agile business analyst and a traditional business analyst, if there is such a difference. One group held that all the attitudes, behaviors and activities that were attributed to an agile business analyst in the discussion are actually attitudes, behaviors and activities all business analysts should have or do agile or not. The discussion was mostly theoretical and philosophical. So here is another more pragmatic view of the difference and I am not making this differentiation as a declaration of some agile business analyst manifesto, only to perhaps clarify thinking by presenting two extremes.
When the business analyst is focused on producing a single approved requirements document at the end of a long period of structured elicitation, investigation, analysis, review and approval, and the document is passed on to the development team with or without interacting with the development team, then the business analyst is acting in a traditional business analyst role.
When the business analyst elicits and analyzes the information to produce just enough requirements for the development team to produce at least a rudimentary version of the result and then continues to revise the requirements as the business stakeholders, development team and business analyst learn more about the system delivering the final requirements document describing the system in production at the same time as the system goes into production, then the business analyst is acting in an agile business analyst role.
When the business analyst is focused on producing a single approved requirements document at the end of a long period of structured elicitation, investigation, analysis, review and approval, and the document is passed on to the development team with or without interacting with the development team, then the business analyst is acting in a traditional business analyst role.
When the business analyst elicits and analyzes the information to produce just enough requirements for the development team to produce at least a rudimentary version of the result and then continues to revise the requirements as the business stakeholders, development team and business analyst learn more about the system delivering the final requirements document describing the system in production at the same time as the system goes into production, then the business analyst is acting in an agile business analyst role.
Saturday, January 8, 2011
When are requirements done?
A question came up recently about when requirements are done. When can you say that you have completed the requirements and there is nothing left to add?
The answer is probably never. Given unlimited time and resources there will always be more information that you can obtain that will change the requirements you have specified, or add new ones, or delete old ones, up to and including changing the entire solution. Had you started a project in 1992 and planned to have the software requirements finished in a year with the target platform being a CICS 3270 terminal. You might have found yourself redoing all the requirements the following year when Windows 3.1 was announced, and then again a couple of years later for Windows 95 and the web and Java (all came into commercial use in 1995.
The bottom line is that the requirements are always complete and correct, assuming you've done proper analysis, based on the information you have gathered and confirmed up to this point in time.
However, a guideline is still demanded. So, here goes: when you have a solution to the business problem and have specified everything the business needs to do to solve the problem, the business requirements are done. When you have specified everything that is necessary from a technical perspective, the system requirements are done. And when you have specified everything that needs to be completed for the project to be successful the project requirements are done.
That doesn't mean frozen or unchanging - just done at this point based on the information you have at that time.
The real answer is that the requirements for the system or change that is implemented are done when the system or change is in production, and subsequent requirements become subsequent changes.
The answer is probably never. Given unlimited time and resources there will always be more information that you can obtain that will change the requirements you have specified, or add new ones, or delete old ones, up to and including changing the entire solution. Had you started a project in 1992 and planned to have the software requirements finished in a year with the target platform being a CICS 3270 terminal. You might have found yourself redoing all the requirements the following year when Windows 3.1 was announced, and then again a couple of years later for Windows 95 and the web and Java (all came into commercial use in 1995.
The bottom line is that the requirements are always complete and correct, assuming you've done proper analysis, based on the information you have gathered and confirmed up to this point in time.
However, a guideline is still demanded. So, here goes: when you have a solution to the business problem and have specified everything the business needs to do to solve the problem, the business requirements are done. When you have specified everything that is necessary from a technical perspective, the system requirements are done. And when you have specified everything that needs to be completed for the project to be successful the project requirements are done.
That doesn't mean frozen or unchanging - just done at this point based on the information you have at that time.
The real answer is that the requirements for the system or change that is implemented are done when the system or change is in production, and subsequent requirements become subsequent changes.
Subscribe to:
Posts (Atom)