Search This Blog
Monday, December 27, 2010
The BA Alchemist
It's probably as difficult as turning lead into gold and perhaps as valuable. A business analyst turns information into knowledge. Yes, the business and the users will tell us what information to collect, what order to display it, when to report it, and what calculation to use on it. However, the users don't always know the whole scope of the information that is available to them: information collected elsewhere in the company, information available floating around the internet, information that is collected ancillary to other tasks. The business analyst adds value to the organization each time he or she suggests a new way to turn raw information into knowledge. After all knowledge is the fuel of business nowadays.
Monday, November 22, 2010
Taking it at word value
We know what accepting something at “face value” means. On the one hand it has to do with crediting someone for the amount of money as shown on the face of the paper bill, or in other words giving someone ten dollars worth of goods for the paper in the person’s hand that shows a face value of ten dollars, the “face” being that of Jefferson. The phrase has also come to mean accepting what someone says without analysis or judgment. It is a statement of belief, that whatever you say I will believe, at least for now. It is a statement of trust that the face behind the words you hear is one that you trust and will therefore accept the words as truth or fact.
Accepting at word value is similar, without the belief and trust stuff. Accepting at word value is a way of validating the words as they are written (or said) and not making an assumption of what the words really mean. Accepting at word value is also a humorous game. For example, someone asks, “How does your April look?” meaning, of course, idiomatically, “what’s your availability in April?” However, taken at word value, the response might be, “Oh, it’s about thirty days long, usually on the warmish side, and typically has Passover and Easter holidays in it”. The humor is in taking the words literally rather than assuming the intended meaning.
If you were to read and review everything you write at word value, you will discover many instances of idiomatic expressions or included assumptions. This is OK for conversation where the responder can ask for clarification or make light of the expression. In written communication it can become dangerous when you include what you consider as an obvious allusion which the reader is not aware of. The primary assumption in writing, especially business writing and most especially requirements writing, is that the reader will interpret the words exactly as they are written, in other words, take them at word value. Exacerbating the issue is the “value” they may place on the word. Whereas the face value of a ten dollar bank note is always ten dollars, regardless of the actual value in purchasing power, the “value” or meaning of the word may differ from reader to reader and this brings up the issue of ambiguity, which is also a great source of humor.
Read your document at word value without reading your intended meaning into it. When you see a different meaning, don’t assume that “no one will interpret it this way. The real meaning of the words is obvious”. Instead change the word and increase the value, that is, make the value equal to your intention.
Accepting at word value is similar, without the belief and trust stuff. Accepting at word value is a way of validating the words as they are written (or said) and not making an assumption of what the words really mean. Accepting at word value is also a humorous game. For example, someone asks, “How does your April look?” meaning, of course, idiomatically, “what’s your availability in April?” However, taken at word value, the response might be, “Oh, it’s about thirty days long, usually on the warmish side, and typically has Passover and Easter holidays in it”. The humor is in taking the words literally rather than assuming the intended meaning.
If you were to read and review everything you write at word value, you will discover many instances of idiomatic expressions or included assumptions. This is OK for conversation where the responder can ask for clarification or make light of the expression. In written communication it can become dangerous when you include what you consider as an obvious allusion which the reader is not aware of. The primary assumption in writing, especially business writing and most especially requirements writing, is that the reader will interpret the words exactly as they are written, in other words, take them at word value. Exacerbating the issue is the “value” they may place on the word. Whereas the face value of a ten dollar bank note is always ten dollars, regardless of the actual value in purchasing power, the “value” or meaning of the word may differ from reader to reader and this brings up the issue of ambiguity, which is also a great source of humor.
Read your document at word value without reading your intended meaning into it. When you see a different meaning, don’t assume that “no one will interpret it this way. The real meaning of the words is obvious”. Instead change the word and increase the value, that is, make the value equal to your intention.
Thursday, November 18, 2010
Is the PM to blame when the team starts leaving?
While some might say that the most compelling evidence that a project manager is not doing well or has lost control of his or her project is when the team starts leaving, it is not true. There are many reasons a team leaves regardless of the job the project manager is doing. The best of project managers can only overcome low wages or the attraction of a competitor's higher benefits just so long before the team succumbs and leaves. The project manager may fight with upper management to get higher wages or better conditions to no avail. When upper management believes that project staff is interchangeable their response is "let them go, we can hire more", and the project manager is left with constant churn and deadlines missed. And it may also be the natural result of a recovering economy providing new job opportunities for the pent-up demand of employees who have been dying to leave for years, not just as the result of the current project.
Here's a positive spin on team members leaving. According to Tuckman, the fourth level of team composition is "Performing". Most teams, once formed and composed operate in the "Norming" mode and that is where the project managers wants them to be. Some teams (and I've been on them) move into the "Performing" mode wherein the members of the team pretty much act as one, sometimes to the exclusion of everything else but the team and the project. This is great for productivity and creativity, and the project manager need do nothing but watch since the team pretty much manages itself. The downside is that when, for whatever reason, a member must leave, the team disintegrates. They cannot achieve the same "high" they had while in the Performing mode, and each member typically leaves the team and usually the company in short order. Nothing can be done about it. It's just human nature. And the project manager previously watching the team perform wonders, now wonders what just happened. And it always happens. Sooner or later someone will leave - retirement, following a spouse to a better job, required transfer within the company, etc. The project manager cannot stop the team from sliding into Performance and cannot stop the eventual end, and can only hope the project end precedes the team end.
Yes, blame can generally be placed at the project manager's feet when the team decides to leave en masse over a short period of time without any outside instigation (such as a ten percent reduction in pay across the boards, or a requirement in IT for everyone to put in an additional ten hours overtime without compensation). The fault is usually in not listening to the team. Nothing will chase a person away faster than being not listened to which can be interpreted as lack of respect, a signal that the team member is not important, a sign of project manager arrogance, an indication that the project manager and upper management feels that the workers are just a cut above automatons and can't think for themselves, or all of the above. This condition occurs more frequently when economic conditions are in a down cycle and jobs are scarce so people put up with more just to keep their jobs allowing management to be more arrogant and demanding. When project managers mirror this attitude, they get what they deserve from their people.
Incidentally the definitive indication that a project manager has lost his or her project is when someone outside the project tells the project manager about something going on inside his or her project that he or she didn't know about.
Here's a positive spin on team members leaving. According to Tuckman, the fourth level of team composition is "Performing". Most teams, once formed and composed operate in the "Norming" mode and that is where the project managers wants them to be. Some teams (and I've been on them) move into the "Performing" mode wherein the members of the team pretty much act as one, sometimes to the exclusion of everything else but the team and the project. This is great for productivity and creativity, and the project manager need do nothing but watch since the team pretty much manages itself. The downside is that when, for whatever reason, a member must leave, the team disintegrates. They cannot achieve the same "high" they had while in the Performing mode, and each member typically leaves the team and usually the company in short order. Nothing can be done about it. It's just human nature. And the project manager previously watching the team perform wonders, now wonders what just happened. And it always happens. Sooner or later someone will leave - retirement, following a spouse to a better job, required transfer within the company, etc. The project manager cannot stop the team from sliding into Performance and cannot stop the eventual end, and can only hope the project end precedes the team end.
Yes, blame can generally be placed at the project manager's feet when the team decides to leave en masse over a short period of time without any outside instigation (such as a ten percent reduction in pay across the boards, or a requirement in IT for everyone to put in an additional ten hours overtime without compensation). The fault is usually in not listening to the team. Nothing will chase a person away faster than being not listened to which can be interpreted as lack of respect, a signal that the team member is not important, a sign of project manager arrogance, an indication that the project manager and upper management feels that the workers are just a cut above automatons and can't think for themselves, or all of the above. This condition occurs more frequently when economic conditions are in a down cycle and jobs are scarce so people put up with more just to keep their jobs allowing management to be more arrogant and demanding. When project managers mirror this attitude, they get what they deserve from their people.
Incidentally the definitive indication that a project manager has lost his or her project is when someone outside the project tells the project manager about something going on inside his or her project that he or she didn't know about.
Friday, September 24, 2010
The role of business analyst
I’m always in search of a concise statement that defines the overall role of the business analyst. Laura Brandenburg’s business analyst manifesto is a good one. I came across a quote by Doug Engelbart who, among other things contributed the mouse to the world. He was talking about technology as an augmenter of human intellect. I’m going to paraphrase his quote and apply it to the business analyst:
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.
Does that mesh with your understanding of the role of the business analyst?
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.
Does that mesh with your understanding of the role of the business analyst?
Saturday, July 31, 2010
Requirements in pictures not words
As I recall from Pysch 101 - taken in the 60s so my recollection may not be exact - human beings think in pictures and images rather than words. How the psychologists figured that out I do not know. Words, both verbal and written, are our attempts to describe those pictures in our heads. Using diagrams, drawings, models, etc. gets us even closer to the pictures in our heads. However, we also do not think statically. Our pictorial thoughts are in association with other images in our head, and tend to be more dynamic, that is moving. To accommodate this, we develop prototypes that show the data in conjunction with the interface in conjunction with the process of using both. Now our model gets really close to what we see in our heads. Working with information systems, however, the picture we have in our heads - at least in the users' heads - is somewhat foggy or vague since it deals with abstract and future reality, and really doesn't clear up until we see the prototype in action.
Now here's the kicker. The sufficiency bias says that we will be satisfied with something that satisfies our specific needs rather than to hold out for something better. This means that what we are looking at now becomes the picture of what we want in our heads. Later, we might see something else that changes the picture and expect the delivered system to have that something else. And round we go.
Isn't inexact science fun?
Now here's the kicker. The sufficiency bias says that we will be satisfied with something that satisfies our specific needs rather than to hold out for something better. This means that what we are looking at now becomes the picture of what we want in our heads. Later, we might see something else that changes the picture and expect the delivered system to have that something else. And round we go.
Isn't inexact science fun?
Thursday, July 22, 2010
Change and Transition
Many times we in IT discover as we are solving a business problem that the closer we get to implement 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.
The business analyst’s contribution
Perhaps the most important contribution a business analyst can make to the success of an IT project is to define the problem to be solved and determine what constitutes a successful solution to the problem. A simple question of the sponsor or customer or even users should accomplish the task. "What will you need to see or what will you need us to do to prove that we have solved your problem?" If they don't have an answer to that question, perhaps they don't really know what the problem is, or maybe they don't really have a problem, or at least one that you can solve. When we do get the answer to that question, we have the basic "why" of the project, and what our ultimate target is.
I believe business analysts are more than stepping stones, interpreters, translators, emissaries, documenters, or glorified administrative assistants. i believe business analysts are business problem solvers and the solutions do not necessarily have to be IT solutions (e.g. process improvement solutions). The outcome of a business analyst's work therefore is a solution document stating what the solution is - what the business needs to do to solve the problem, and it may or may not be a requirements document, or the total solution involving the change to business processes may include requirements.
I believe business analysts are more than stepping stones, interpreters, translators, emissaries, documenters, or glorified administrative assistants. i believe business analysts are business problem solvers and the solutions do not necessarily have to be IT solutions (e.g. process improvement solutions). The outcome of a business analyst's work therefore is a solution document stating what the solution is - what the business needs to do to solve the problem, and it may or may not be a requirements document, or the total solution involving the change to business processes may include requirements.
Tuesday, July 20, 2010
Drowning in the waterfall
During a recent exchange on a business analyst forum, a poster complained that he was “drowning in the waterfall”. Much of the "drowning in the waterfall" is really drowning in paperwork not the process. The waterfall doesn't in itself call for a mass of documentation; the paperwork is the result of the way the waterfall is applied in many organizations. Much of the paperwork that accompanies a development life cycle is not designed to assist or enhance either communication or the development process. It is there solely for control: for management to be assured that certain activities have been accomplished and they have a document that proves it; as a measuring device to demonstrate that phases or milestones in the process have been achieved; as a verification artifact that someone can use to check up on the progress at points along the way; to provide disinterested parties a glimpse at what is happening with the development; to give the auditors proof that the process is being followed; and so forth. Where possible try to turn permanent, persistent documentation into transitory documentation that you can throw away once the document has served its purpose. Write designs on white boards. Do status reports verbally in stand up meetings of no more than ten minutes. Communicate face to face rather than via documents. It saves time. It saves trees. And it keeps your head above water.
Subscribe to:
Posts (Atom)