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.

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 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 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.

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.

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.

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?