PARKSON.US
Friday, June 26, 2009
No Documentation before its Time
Over the years management’s attempt to impose control over and visibility into the sometimes foggy and usually opaque world of software development has resulted in a mass of documentation and artifacts punctuating the process. In turn this has resulted in a revolution in the ranks of software developers who point out that they are spending more time documenting their work than in actually working. Similar protests may be heard from the ranks of business analysts who sometimes claim they are nothing more than documenters.
The issue is not really that there is too much documentation, or not enough, or perhaps more appropriately, not the right documentation for the effort being documented. The issue is what the documentation means to the people preparing the documentation.
Documentation is not a substitution for communication.
Too many business analysts become subject to the requirements document delivery syndrome. Their goal is the delivery of the Business Requirements Document or the Functional Requirements Specification rather than the definition of a solution to the business problem. Information gathering session become a means to fill in missing information in the document rather than to collaborate with the business community to define the current business processes and determine the best solution to the problem. Discussions with the solution team and other technical resources become a back-and-forth debate about what is included in the document and whether it is correct rather than a conversation about what information is necessary to understand the problem and create a solution. The business analysts focus their attention on creating the document rather than keeping the lines of communication open among all parties.
The document created as part of the information gathering or analysis process should be the distillation of the communication that has gone on before. Agreements are recorded, completed activities logged, conclusions posted for posterity, results reported. In all cases the document only provides evidence that the communication has been successful. A document created before communication is complete and final only serves to confuse communications rather than clarify. Once a document has been created, the focus is no longer on the communication, but on the document.
The issue is not really that there is too much documentation, or not enough, or perhaps more appropriately, not the right documentation for the effort being documented. The issue is what the documentation means to the people preparing the documentation.
Documentation is not a substitution for communication.
Too many business analysts become subject to the requirements document delivery syndrome. Their goal is the delivery of the Business Requirements Document or the Functional Requirements Specification rather than the definition of a solution to the business problem. Information gathering session become a means to fill in missing information in the document rather than to collaborate with the business community to define the current business processes and determine the best solution to the problem. Discussions with the solution team and other technical resources become a back-and-forth debate about what is included in the document and whether it is correct rather than a conversation about what information is necessary to understand the problem and create a solution. The business analysts focus their attention on creating the document rather than keeping the lines of communication open among all parties.
The document created as part of the information gathering or analysis process should be the distillation of the communication that has gone on before. Agreements are recorded, completed activities logged, conclusions posted for posterity, results reported. In all cases the document only provides evidence that the communication has been successful. A document created before communication is complete and final only serves to confuse communications rather than clarify. Once a document has been created, the focus is no longer on the communication, but on the document.
Labels: communication, documentation
¶ 1:36 PM 0 comments
Saturday, June 20, 2009
We do not need business analysts – the users can define their own requirements
Despite this position, a common statement in the agile community, the business analyst position and role is not going away. Perhaps members of a solution team can meet across a table with the users directly and garner the requirements from them. That implies the following:
The users know what the problem they are solving is,
The users know what the information system requirements are that will solve their problem,
The solution team technicians can understand the entire business process when many process workers only understand their part of the business process,
The people sitting at that table are able to gauge the impact of the changes they are introducing on other constituencies in the business,
The people at the table collectively can determine the actual increase in value to the organization by making this change.
The people at the table know enough about the entire organization to understand the related impacts to other departments and units in the business and adjust a solution accordingly
When all of these conditions are met, the results of the development will satisfy the business community, add value to the organization, and not cause a negative impact elsewhere. This is not impossible, or even improbable. Such a meeting might require a moderator or facilitator to assist the business and solution team to understand the problem and come to the valid solution. That moderator or facilitator is the business analyst. Eventually it might be possible for a group of department level business people to meet a group of developers and clearly and completely define the solution to a business problem such that the developers can implement the solution to the organization’s satisfaction. At that point the business analyst is no longer needed in that meeting. Then the business analyst can move on to more fulfilling activities such as defining improvements to the business processes. ¶ 6:41 AM 0 comments
The users know what the problem they are solving is,
The users know what the information system requirements are that will solve their problem,
The solution team technicians can understand the entire business process when many process workers only understand their part of the business process,
The people sitting at that table are able to gauge the impact of the changes they are introducing on other constituencies in the business,
The people at the table collectively can determine the actual increase in value to the organization by making this change.
The people at the table know enough about the entire organization to understand the related impacts to other departments and units in the business and adjust a solution accordingly
When all of these conditions are met, the results of the development will satisfy the business community, add value to the organization, and not cause a negative impact elsewhere. This is not impossible, or even improbable. Such a meeting might require a moderator or facilitator to assist the business and solution team to understand the problem and come to the valid solution. That moderator or facilitator is the business analyst. Eventually it might be possible for a group of department level business people to meet a group of developers and clearly and completely define the solution to a business problem such that the developers can implement the solution to the organization’s satisfaction. At that point the business analyst is no longer needed in that meeting. Then the business analyst can move on to more fulfilling activities such as defining improvements to the business processes. ¶ 6:41 AM 0 comments
Wednesday, June 10, 2009
Why Business analysts work better in a team than as a Lone Ranger
To start with, the business analyst function works much better in a team environment rather than as a solitary effort. Business processes combine many disciplines, skills, talents, experience; the successful solution will also be a combination of factors and applications. Business analysts should not work in isolation. They must synthesize information garnered from a large number of people within the business, such as business constituents, the solution team and other technicians, and upper-level management, as well as those who interface with the organization such as customers, vendors, government agencies, and business partners.
A compelling reason to work in teams is the synergy obtained by working with business analysts who have other business experience. There is also the enhanced view of the bigger picture obtained through the input of various different business analysts representing different business elements that assists in determining the impact of any new solution.
As Christopher Koch says, “Being social animals we identify with our own group – whether it is our families, friends, colleagues, or our ethnic or national group. These loyalties are strong and deeply embedded in our evolutionary background…The reasoning is simple: left alone in the jungle, a chimp will die. The group bond is more important to their [monkeys’] survival than the individual bond. It is hardwired in us.”
It is not only the social aspect and the natural tendency for working in groups that should drive business analysts to work together. A business analyst requires a wide range of skills to be successful, and not everyone has this vocabulary of technical and business knowledge. Combining two or more business analysts with different backgrounds, knowledge, skills, and temperaments fills all the holes and creates a powerful combination. This does not imply that every project needs to have several business analysts assigned to it. Each project may only have one business analyst. The business analysts, however, work together behind the scenes to increase each other’s performance on every project. Whether informally, a weekly get-together as a New England insurance company does, or formally through a Center of Excellence or some other organization-sponsored entity, a group of business analysts tends to be stronger than the sum of its members.
A compelling reason to work in teams is the synergy obtained by working with business analysts who have other business experience. There is also the enhanced view of the bigger picture obtained through the input of various different business analysts representing different business elements that assists in determining the impact of any new solution.
As Christopher Koch says, “Being social animals we identify with our own group – whether it is our families, friends, colleagues, or our ethnic or national group. These loyalties are strong and deeply embedded in our evolutionary background…The reasoning is simple: left alone in the jungle, a chimp will die. The group bond is more important to their [monkeys’] survival than the individual bond. It is hardwired in us.”
It is not only the social aspect and the natural tendency for working in groups that should drive business analysts to work together. A business analyst requires a wide range of skills to be successful, and not everyone has this vocabulary of technical and business knowledge. Combining two or more business analysts with different backgrounds, knowledge, skills, and temperaments fills all the holes and creates a powerful combination. This does not imply that every project needs to have several business analysts assigned to it. Each project may only have one business analyst. The business analysts, however, work together behind the scenes to increase each other’s performance on every project. Whether informally, a weekly get-together as a New England insurance company does, or formally through a Center of Excellence or some other organization-sponsored entity, a group of business analysts tends to be stronger than the sum of its members.
Labels: business analyst, teams
¶ 12:25 PM 0 comments
Sunday, June 07, 2009
Change and Transition
Many times we in IT discover as we are solving a business problem that the closer we get to implementing the solution, the less enthusiastic the business community appears to be about the upcoming change. The same people who were anxious to get started and get the problem solved and remove the pain or extra work they were going through, now seem to erect roadblocks and obstacles to the incoming changes. It is very frustrating to spend time writing the software and preparing the system only to find the process workers resistant to the solution. The symptoms are late stage changes, reversals of choices, the sudden appearance of new authorities in the mix, an unexpected change in the guard, and a seemingly unending focus on minor details and testing.
Daryl Conner explains it this way, in Managing at the Speed of Change: “some of the strongest resistance occurs when we get exactly what we asked for – if what we asked for causes a significant departure from our expectations.” Clearly, coming into a new system or way of doing things is going to vary from a process worker’s expectations. The closer we get to the delivery, the more concerned and fearful of the change the process workers become. That’s when the business community, consciously or unconsciously, invents various strategies for slowing up the changes. Business analysts recognize the syndrome and work to make the transition easier for the business. Keep the focus on the benefits of the new system or enhancement, be honest about the risks and obstacles facing the changeover while being open about what is being done to overcome them to make a smooth transition. Primarily, business analysts keep the communication flowing among all parties removing as much of the mystery normally associated with technology as possible.
There will still be natural resistance. This resistance, however, can be made positive by listening to the opposing comments which may identify new obstacles that can be overcome. In the end, the change is inevitable, and the business analyst can do much to make it easier for those being changed.
Daryl Conner explains it this way, in Managing at the Speed of Change: “some of the strongest resistance occurs when we get exactly what we asked for – if what we asked for causes a significant departure from our expectations.” Clearly, coming into a new system or way of doing things is going to vary from a process worker’s expectations. The closer we get to the delivery, the more concerned and fearful of the change the process workers become. That’s when the business community, consciously or unconsciously, invents various strategies for slowing up the changes. Business analysts recognize the syndrome and work to make the transition easier for the business. Keep the focus on the benefits of the new system or enhancement, be honest about the risks and obstacles facing the changeover while being open about what is being done to overcome them to make a smooth transition. Primarily, business analysts keep the communication flowing among all parties removing as much of the mystery normally associated with technology as possible.
There will still be natural resistance. This resistance, however, can be made positive by listening to the opposing comments which may identify new obstacles that can be overcome. In the end, the change is inevitable, and the business analyst can do much to make it easier for those being changed.
Labels: business analyst, change agent, transition
¶ 8:37 AM 0 comments
