jump to navigation

May 1, 2008

Posted by andrea in the IA/BA world.
Tags:
add a comment

I wrote this back in June 07, when I was having problems with an Agile dev team… plus a large dose of comments in italic from the present (and grammatical-tense changes…hmm,never realized the double meaning of “tense”…am I mis-spelling it?)….

I’ll use the old “house building” analogy: My role was to be the table saw on a construction crew – use it when you need it, and then turn it off. Worse, I became the tool who needed to anticipate when one of the carpenters blindly threw a piece of wood in the air, and I was expected to catch it, cut it to size, and hand it back…so they continued on the “real” work. Who, honestly, wants to work like that? Could you find someone who’d be happy being THAT disengaged from their end product? (I know, how Marxist of me).

The only bright spot of the project was the client – he and I had wonderful, thought-provoking conversations, and traded ideas, and wrestled with direction, and thinking. I valued his insight, and I like to think he mine. There hasn’t been another person to challenge me in the way I need to be challenged (aside from answering questions on-the-fly and having had to refer people back to my documentation – that’s another story). I grew, and learned, and worked with some amazing people who are open with their ideas, kicked my butt and pushed me further where I need to go. And to go backwards into “just do some wireframes, you” is a situation that isn’t challenging anymore.

business analysis and analysts are not your waitstaff…taking orders of the next piece of technology you think will work. Um, we are business. analysts. We offer an analysis. of your business. We are insane, in our de-construction of concepts and ideas into achievable goals, for a reason. We like matrices (ahhh). We seek connections, and flow. Our favourite question is “why?” We ask it of each other, and ourselves, all the time (it’s a total meta-BA thing when I post). We want a logical conclusion to *everything* we do.

I’m at a place now where I think I do have this intangible geek knowledge – experience, insight, and large dose of humility, and goofiness. People seem to want it, or recognize it. I’m really lucky. Not a joiner: not a developer, not a creative, not a PM, not a sales dude – i’m a little of everything. Which explains why I can’t join anything, including a dog-walking group.:-)

slowly percolating epiphany July 3, 2007

Posted by andrea in the IA/BA world.
add a comment

After a very lovely and fruitful conversation with one of my Collective Leaders (uh, don’t know what else to call them, actually), it dawned on me that maybe, maybe, the way I need to work is not to massively drag myself through the documentation process, and make it all pretty, and readable and such is that I let it trickle out…dribs and drabs at a time, when it’s relevant. Of course, I need to do all the thinking, and planning beforehand, but maybe I don’t need to have it all “finished” when the features get into development. Only the features that the dev team is going to be working on in the next two weeks, maybe that’s enough. Huh – total head shake.

Caveat: only for teams trying to do a weird-ass version of Agile, but trying to have some direction when they plan their sprints, I guess.

Truism (from what I know): developers typically don’t read documentation beforehand (or, um, ever). Why should they? Do I? (um, yes, but I’m weird that way).

Me (with newthinkTM): next week, when we start discussing a pretty big concept, I will stay at the big level, talk about the overall site and user and business goals, and NOT walk through tons of wireframes, which everyone is only half-listening to at any rate. Then prepare the minutiae (sp?) for what I think/hope will be scheduled in the next two weeks, to work on. Like the boring wireframes (don’t get me wrong, I KNOW they’re boring, and I wish to god they came with singing and dancing and a lighting spectacle, but they don’t) and the business rules, and the constraints and all that stuff.

Context is king: if I can provide what the developers need (after all, they are my first users, of the docs), in context, then maybe the docs will be more meaningful.

It’s quite a change for me, going from “here’s everything” to “here’s a digestible piece”, but I am going to do my best to respond.

It might even help our clients, to see the progression from discussion to wireframe to live functionality, quickly.

It’s a bumpy road, but I think that I serve three sets of users: end-users, business owners who want to see project progression, and developer users who need just-in-time docs (and even, not too many of them…just enough).

Wish me luck. 🙂

the “why” Part I June 19, 2007

Posted by andrea in the IA/BA world.
add a comment

they are not order-takers, like a waiter…”oh, okay, so some Flash app, and social networking, but on the side”

From the IIBA: “A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.”

Funny, nothing about implementing technology in there.

I heard earlier this week “we don’t need you as a process guru, we need you as a leader”. Huh. Leader of what? If I’m outside the process, the only leadership I can provide is non-contextual, and there’s (I feel) little use in that – it’s called cheerleading. If I’m inside the process, then naturally my leadership comes from knowing the context, and the problems, and suggestions how to (hopefully) help improve the process, or what we can do to fix the issue at hand.

Analysts think too much…that’s what we’re good at. Mulling stuff over, this and that, why not try this…oops no go; that type of thing. To be handed a list of directions (that sometimes do not make actual business sense) is the shudder… Why? is the reason we’re around, and always the pain-in-the-ass person at the meeting.

I will keep being a pain in the ass – I’ve done it all my life, why stop now?

What I’m more conscious of, and try to keep in mind is when to let go. When to realize that for all your good intentions, and trying to make a business prosper, sometimes there are obstacles that are not worthing “falling on your sword” for. That is my biggest recommendation to the “newbies”.

I, back in the day, fought everything…more out of not being separated from my work. If they dissed my work, they dissed me! Now, I hope and try to maintain the idea of actual collaboration – give and take. It’s not about me – it’s the cumulative minds on the project that make it see the light of day.

I still ask “why?” a lot, and am probably very impolitic when I do so, but I just want to know what’s going on, ’cause then just maybe, when it’s brought to light, me and many others, can help fix it.

Standing on the outside, with no insight, doesn’t help anyone. Which, I think, is why BAs are at a crucial point in their development, as a discipline. I went to a great workshop in March, where the leader encouraged us to keep focusing our minds and skills towards the business, and to resist being “just the order taker”.

documentation…conjunction junction, what’s YOUR function? April 6, 2007

Posted by andrea in the IA/BA world.
add a comment

I’m often asked what I do, like everyone I suppose, who lives in T.O. It’s easy when it’s someone in “the industry”, not so much when it’s my parents’ friends, or my friends’ parents. Or other people, like my husband, when we first met. Now, of course, I’m the beep-whirr-beep girl, as far as he’s concerned (even though his business is the “go to” metaphor when talking about this stuff…he renovates homes).

me: I, uh, work in the web industry, making websites and online applications
pf/fp: oh, so you build websites? Our nephew does that.
me: no, I don’t actually “build” them
pf/fp: oh, so you design them? you’re a designer!
me: um, no, I don’t know how to make anything beautiful, sadly.
pf/fp: ???
me: I….create a lot of paper, and documentation, that helps the people who CAN do those things do them. Like, blueprints, after the zoning commission is through with them.
pf/fp: ?? Websites need architects??
me: (quietly) um, yes. Now, I think I have to turn my chair THIS way. Or go refresh my drink.

This is from an email that I sent to a lovely project manager I worked with, and who got it, but needed the arguments to sell BA stuff to the client:
IA is tangible, design is tangible, code is tangible. BA stuff isn’t, really. You know the metaphor of IA being the house’s blueprints? BAs are the zoning commission, the soil engineers, the forestry supply and demand, and the House & Home magazine that the customer dreams about, and wants to make happen, even though their 600 sq.ft. loft doesn’t resemble an English manor. Kind of.

Yep, one sort of BA grew out of a need to understand the rules and policies of a business. They’re usually geeks who understand a particular industry really really well. Like property and casualty insurance. They know the ins and out of policy administration and can tell you why and how the “rules” of whether or not you get jack squat when your house burns down are driven. Sometimes, they really understand software development, too. Sometimes. Some business analysts, conversely, come from software development – where their thing is what systems do, and what certain types of systems do – workflow, benefit administration, document management, etc. Sometimes those people are a nice, balanced combination of industry and development.

But..they’re missing a piece: users. Oh yeah, those people who will or will not adopt a new system, or make the whole business process faster or slower? Yeah, them.

Traditional systems development (enterprise or app specific) still has a long way to go to understand users. Why should they? The users they build for are usually a captive audience, who have to use the new software if they want to keep their job. Who cares about them? Which is why you get training that sucks, and employees who have a flurry of post-its around their monitors, so they remember what they can and can’t do when they’re trying to process a bill payment over the phone.

I’m working on a project right now, where I asked my main admin user to walk me through how she sets up an online community. She laughed, and said she couldn’t really, because she has 30 pages of notes that she has to have in front of her when she does that. Egads. I just want to give her a hug.

Web development is probably harder, but ultimately more innovative than regular system development. Like Morag said (and as soon as I find her wonderful explanation of “whither the BA?” I will post it – it’s beautiful), Web sites aren’t just pages anymore, or very few of them, and a lot are actually useful in peoples’ lives – online banking, online shopping, online dating – anything where you can do something virtually. I renewed my driver’s licence online – huzzah! Web sites are applications in and of themselves, AND we have the opportunity NOT to make the same mistakes that traditional systems development did.

The Web is way out in front in that respect. Web users don’t have to come back to a terrible site, they’ll abandon it. So we have IAs who understand and watch and note what’s working and what doesn’t in the screen for real people. And keep them in mind when crafting a user experience that makes sense, to the users. But all the arcane rules and reasons why you can only make 4 payments a month exist. And if the IAs have that kind of knowledge communicated to them up front, it makes their design job more comprehensive in the beginning. Harder, but I’ve yet to meet an IA worth their salt who doesn’t relish the challenge.

The rarest BA is one who understands that there’s a dance between system development, business drivers, and last but not least that there’s a real person at the end of the screen – there, you’ve got something really cookin’ now. Wow – user goals and needs.

There’s a really good diagram of how much it costs to fix the “oops, we didn’t tell you before” stuff during design and development. For every change made in a project: it costs $1 to fix it in requirements, $10 in design (IA, technical, or creative), $100 in development, and $1000 in QA.

I know I’m basically preaching to the converted here, but it’s something that comes up again, and again. Thousands of Dilbert comic strips back me up.

requirements, the orphan child of a business March 31, 2007

Posted by andrea in the IA/BA world.
add a comment

I know no one reads requirements documents. I’ve had I-don’t-know-how-many-people tell me this, and yet I persist. Do they need to come with a light show, perhaps animated characters? Clearly, I need to “sex up” my documents…but honestly, there’s only so much you can do. Except, sadly, take your group by the figurative hand, and keep up a steady “come along, Hobbits!”

Ideas? I’m looking into software, interactive dance, and the device they used in Men in Black to erase memory. Instead, it will instantly infiltrate the subject’s brain with an understanding of the requirements of the project (and its new add-on – currently in development – to approve them!)

Anyone out there with “the way”? The one that makes business feel inspired, and implementation feel like they got the whole deal?