Posts Tagged ‘business analysis’

I’m in the process of getting through the PMP Exam Cram. I did this as I venture deeper into a career which is focused on helping companies achieve greater success with their IT projects. My approach started with a focus on more of the BA side of things – requirements elicitation, use case composition, overall requirements process structures, etc. I was interested in understanding the PM role and I found some interesting overlaps.

A lot of the BA and PM material I read seems self-aggrandizing. Does anyone else get this sense? It’s as if the authors are selling the value of the position to the very people who have already been sold on it. In this instance, as well as the IIBA’s BABOK, I’d say a good 20% of the material is “which is why your role as a [BA/PM] is so important.”

I’m guessing one way of really understanding how the roles overlap is by asking, have you ever been in a situation where your role as a BA or PM has conflicted with someone else in the opposite position? Or have you seen such conflicts?


Read Full Post »

I was reading a fun book on public speaking, Scott Berkun’s “Confessions of the Public Speaker,”, and he referenced a TV series he contributed to, CNBC’s The Business of Innovation, so I checked out some youtube for it.

During the first few moments, one of the experts declares it’s all about getting the Business People and the Scientists on the same page. I agree, we need to amend to this “without violating those individuals’ personal 80/20 rule.”

The more you force business people to understand tech, and tech people to understand business-speak and bottom lines, the more you pull them away from the essential activities that make them valuable. You need a good communicator who can focus on both in the middle. It’s much easier for 3 people to run a relay marathon than 2.

Read Full Post »

I remember going golfing once with my father and a couple of buddies. I had reached the first green in three with a two-foot putt for par. This was a rare occurrence. I’m consistently good for a bogey 5 off a first-hole par 4. I don’t have the talent to grab a par and there hasn’t been enough evidence for my inevitable frustration to come forth and push me into a double bogey. As I approached the green, my mind started flailing. It was slightly uphill, not really a straight putt. I considered jamming it in vs. trying something delicate and thoughtful. It didn’t help that my friend was egging me on. “You got that! Tap it in! Come on! Clean it up!” At that instant, I attempted to fool myself into relaxing by forcing a little lackadaisical in with my routine. I took a whack at it. Sure enough, 4 inches to the right, and 2 feet beyond the other side. My buddy, who had been chanting, “You got that,” now quipped, “Nope,” and laughed hysterically. Trying to get out from under the embarrassment, I hurried the next one and tapped it off the mark. More laughter. I finally pushed it in.

Everything I needed to make that putt was right there. I had the equipment, two arms, a brain and my eyes. Some luck may have been at play, but to a much larger degree, my mental approach had made the proverbial mountain from the mole hill…albeit a mole hill with an awkward slope. This experience has me wondering about our sour economic situation. Is our mental attitude contributing to our sour circumstances, or certainly exacerbating? If an economy falls in a forest, or improves, does anyone hear it?

How many companies are pulling funding on projects simply because they’re afraid to make the putt? Afraid of failure?

How much of the economic crisis is mental?

Read Full Post »

Is your company using a consistent practice of writing use cases? Are there a lot of power struggles between developers and team leads, between clients and product managers? Is there a lot of arguing going on? Are people nervous or disgruntled? These are symptoms of ambiguity. Create clarity.

On a recent assignment as a developer, I was part of a team creating an interactive website for a major client who serviced Fortune 500 customers. Although a requirements document was present, and the phrase “use case” was used at least once, my first experience with an actual use case came when one of the testers sent me her detailed analysis of an error she was encountering. Something along these lines:

  1. User logs in to the website
  2. The user home page is displayed
  3. User requests to view current discount information by entering dates
  4. System crashes, displaying nasty .NET error message

Of course, my obvious question was, “what should it do?” This produced a different sequence, beginning at Step 4.

4. System displays a list of discounts for which user is eligible to participate.

At this point, I asked “what has to happen in order for discounts to be there?” We established the preconditions, or eligibility. I then asked, “What is it the user wants to do once they see this list of discounts?”

“They need to enroll in the program to get the discount,” she explained.

“That sounds pretty important. Are there other tasks they perform when they get to this listing?” I asked.

“Sure. They can request the payout from receiving discounts, and they can sort and filter the list to print out the programs that are important to them.”

Voila. We had established a “View Discounts” use case, which needs to be separately broken out as its own use case because it is an action that serves as the basis for multiple tasks. We had also established “Enroll in Program”, “Request Payout”, and potentially “Print Programs List.” I say “potentially” because the ability to print lists has become a standard and technologically easy. It certainly doesn’t mean that the requirement shouldn’t be written somewhere, including the non-functional elements of how to implement the printing in the user interface.

I whipped up some basic use cases using a template from Karl Wiegers’ site. In less than an hour, the developers knew – and would continue to know – exactly what the website needed to do, without needing to meet a dozen times to clarify. Of course, we had to say “get it done as it’s written, then we’ll talk about the basket of questions or issues that may come up.” This is a production-oriented, or daily build mindset. If a ton of questions or issues come up after the use case is fully completed, then your style needs to be adjusted, or the use case needs to be accompanied with more non-functional design requirements. If the client had signed off on the use case prior, then these additions become change requests and garner the ability to charge money.

The management had an exact idea of the effort required to produce the functionality. In addition, they understood what the “use case” links in their requirements software were for, and the tasks listed in that software became pointed and relevant, because they were connected to an actual use case! It became harder for developers to drag their feet in an effort to extend their contracts. Instead of standing up in the morning and answering, “I’m working on the discount listing display,” five days in a row, the need to answer the more specific question – “what part of the discount listing display are you working on?” – became more readily apparent. If that answer isn’t changing daily, resources can be shifted.

Of course, in this scenario, this project arrived at the need for use cases and specific requirements after the product had been released to the client and errors were being encountered. This reactive position makes it difficult to manage the project and client expectations. But even in this defensive position, simply establishing some use cases throws floodlights on all aspects of the project. Developers know what to develop, testers know what they are testing, management and clients have consensus on what is being done, what gaps arise and why, and the process becomes less argumentative, more collaborative and cooperative, and ultimately productive.

Read Full Post »