Reverse Dodge Ball No matter how you look at it, the business analyst’s role is to be in the center. I sometimes describe the business analyst’s role as that of a reverse dodge ball game. When I was in grade school a common recess pastime was the game of dodge ball. Some kids would be chosen as “it” and stand in the middle of a circle. Those around the outside of the circle threw a soft red ball about the size of a small soccer ball at those in the center. If you were hit by the ball, you left the center and joined the outside circle, and the one who threw the ball got to go into the center. The object was to avoid being hit by the ball and stay in the middle longer than anyone else. Being a nerd and evaluating the logic of the game, I figured it made no sense to be in the middle where kids were throwing balls at me and purposefully trying to hit me, so when I was chosen to be in the middle I’d stick my hand out to get hit and join the outside circle where I got to throw the ball at others.

And that is the business analyst: stuck in the middle, catching the slings and arrows of outrageous business fortune along with the balls thrown in all directions from all participants of a problem solving effort. The business analyst cannot duck or leave the center. And when the blame throwing starts what better target than the business analyst? Both sides can blame the business analyst instead of each other. It’s not an easy job.  ¶ 4:42 AM 0 comments

  The user is always right? Most of the forums and lists, both agile- and traditional-development related, have resident experts and contributors who have years of experience in their chosen area of software engineering. Questions are asked relative to a problem someone is having either technically or with a process. At some point in most discussions someone providing answers asks some variation of “what do the users want?” This is a reliable fall-back to any software development issue based on requirements. Ultimately, we are producing a solution to a business problem voiced by those users.

It got me to thinking about whether the user has or should have such absolute power over what we create and deploy.

Forty years ago there was no input from the users except to identify what they wanted on reports. Formatting was up to us as programmers, and input definitions (on punch cards) was also up to us. Users certainly didn’t specify how they’d like their punch cards to look.

When the users were introduced to monitors, they still didn’t have much to say about the appearance. It was green-gray scroll mode only. Ask a question, input an answer.

From the mid-70s on, or about the time we started doing prototyping on minicomputers and the like, the users held sway. Even though the interface didn’t appear logical to us, when the users said they wanted it a certain way, they got it. Of course, we didn’t have much in the way of user interface to play with: fixed input or display screens of black and white separated by menus. However, the final and ultimate word was always that of the user who would be staring at that screen day in and day out.

Nowadays, of course, it’s all different. The user, however, still appears to control the interface. This leads me to wonder whether the user experience analysts and experts, the information architects and the human factors analysts should control the interface instead.

Is there a line between a user’s power to dictate his/her own interface and the knowledge and skill that a specialist has to make the interface more efficient and the users of that interface more productive? Where is that line drawn?

Who draws the line when two (or more) users agitate for different interfaces to perform the same activity? It could be a simple color difference or a different way of viewing the flow of entry. Certainly code could be written to accommodate all users’ peccadilloes. Where then is the line between the extra code written and subsequent cost of maintenance to accommodate all the users? Does one user get preference over others? Majority wins? All users are created equal, just some users are more equal?

Finally, and it’s a shame to bring this up but that is the reality of business today, there is the misalignment of process and product. A user, in this case perhaps one with authority, specifies changes or a new feature that might benefit him or her personally, or perhaps his or her department, and it isn’t within the overall corporate strategy. Since upper level management does not always have checks and balances in place to coordinate tactical projects and strategic initiatives, who draws the line when the user’s request isn’t in line with corporate strategy or mission? I developed a slick system for a Vice President that did everything he wanted and more, and was delivered on time and under budget. Before we could even commence the celebratory party the VP was sacked and the system shelved because it didn’t fit in with the corporate strategy. We also built a neat system for a telecom company hitting all the early release dates and preparing for another five releases to improve the system based on user feedback, only to have the company sell off the entire system and division to another company, something that was in the works from before we started. We were then told the system wasn’t right because the purchaser didn’t like it.

So where is the line between finding out what the user wants and delivering something that may be better than what the user requested, and aligned with the corporate strategy?  ¶ 6:53 AM 0 comments

  The agile flaw and the BA to the rescue In the agile world there is a lot of talk about the business analyst being superfluous, unnecessary in an approach that calls for the development team to relate directly with the customer. The business analyst is considered on more layer of miscommunication between the problem and solution.

One basic flaw in the agile approaches is their dependence on the customer for all direction, evaluation, and approval. This is good from a theoretical perspective and clearly follows the expectation that IT is driven by the business. However, there is a somewhat naïve expectation that the business will provide the appropriate customer and that the business knows what it wants. The mitigation that agilists use to accommodate the customer not knowing what they want is that the risk of delivering the wrong solution or having the customer change his mind after delivery is small since the timeframe for delivery is small. What happens though when the customer does not realize the problem is not getting solved until four iterations’ have passed? That is a big expense. The agilists say, “it’s the customer’s fault for not knowing and not evaluating correctly. We did our job right.” And they are right. But that still does not resolve the issue. What is needed is someone or some process – and here, of course, we are talking about the business analyst and the business analyst process – to assist the customer in defining the problem and what is needed to solve it before the Scrum sprints begin. Then the agile approach makes exquisite sense. When the business analyst can work with the business and the assigned customer, and the emphasis is on “with” rather than “for” or “on behalf of”, the customer is better able to understand the issues around the business problem and also how to express those issues to the development team. The risk of heading down the wrong solution path is minimized.  ¶ 6:05 AM 0 comments

  Differentiating between the requirements analyst and the business analyst From what I've observed, the difference between business analyst and requirements analyst is the depth of the resulting solutions document, and the length of time spent on the project. Requirements analysts appear to create a specifically formatted document in a more linear development process, a document that is as complete as possible and drives the development, while a business analyst has more flexibility in document production and can work in any of a variety of development environments. The business analyst can function successfully in circumstances where there are no specific requirements, for example in a process improvement effort where the business analyst is observing and recording the business process and pointing out improvements to be made which may or may not end up as requirements for a development project

The requirements analyst also appears to complete his or her job when the requirements are completed and signed off. Some of the requirements experts, notably Karl, state that the ultimate goal is to gain the sign-off. The business analyst stays with the project to make sure the resulting product still solves the problem when delivered and makes sure the business transitions to the new system or process successfully which means the business analyst has responsibilities even after the project has ended with acceptance of the software.

That said, most organizations are not aware of the differences in the two positions, and job titles do not appear to reflect the actual roles being played. I've seen business analysts who only do requirements and then leave the project, and others (in one US government organization) who only do testing. I've worked with companies that have split their business analysts into business business analysts and technical business analysts. It's still the wild west out there in business analyst land.  ¶ 5:27 AM 0 comments

  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.

Labels: documentation, software development processes, waterfall

  ¶ 9:33 AM 0 comments