User Centric Redux

A former colleague and current friend (well, until she reads this), Alice Toth, just published a fine blog on User Centric Design. She outlines the process very well (as I would expect) and she slyly doesn't tell you how its done (hey, we all gotta eat).

Alice was the assigned Information Architect on one of those 'projects from hell.' I was the Lead BA. Before I get started, I have always respected Alice's ability, genius and grace. Its too bad she didn't spend much time on our little venture into the third ring of Hell because she is always an asset. Pathfinder recognized this and promoted her to the second ring of Hell- she became a Project Manager while we of the third ring fried and sputtered.

Alice is a fabulous Information Architect (IA). After several discussions, She and I decided that BAs gather requirements and organize them in words, tables and diagrams, while IAs do the same using visual tools. A significant part of being an IA is to show up any wireframe I create in VISIO and they do freehand on a Mac. IAs are schooled in HMI (Human-Machine Interface) and the psycho-sociological uses of web browsers. Both do As-Is and To-Be workflow models (IAs call them scenarios). All in all, the two functions have many commonalities.

Alice was a superb resource when I had to create Best Practices and dovetail Agile Development with User Experience Design. And she can code. And it doesn't hurt that she's a genius without all that stepping on eggshells stuff one has to do around such folks. Very real and down to earth and a great friend.

So, it is with great reluctance that I take her to task for this statement on her latest Blog:

Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software.

Hunh?

BAs define actors as a person, system or sub-system that needs to do something (a defined goal) using or connecting to the application. While Alice and I were aligning the processes of a BA and an IA, we decided a Persona was usually a class of Actors (i.e. usually more than one person). A Personas usually brings more than one goal to a session on the 'puter. In the Iterative and Waterfall Worlds, these have to be broken down into discrete sets of actions and reactions...and they called them Use Cases. And the PMO say that it was good.

But only for a while.

That there web thingie screwed everything up. Instead of a defined, step by step defined workflow, users can now do pretty much what they wanted (within constraint) as they damn well wanted to and watch video, listen to audio and talk back, through their browsers! Actually, it's much more important to folks like Alice and me that the browser can transmit Credit Card Numbers and PayPal Account detail....but that's another blog.

All this stuff caused Use Case Hyper-inflation and forced the Fed to impose Agility.

OK, I lied- there were a LOT of reasons Agile methods were created. Do you really think the sudden appearance of Web 2.0 and Software as a Service (SAAAAAAAS)- [hyperbole and sarcasm intended] and simultaneous popularization of Agile is a coindence? I don't think so. I can see the guy in the sailor suit with pocket protector up there on the virtual grassy knoll right now.

So we BAs create a series of User Stories that supports the creation of the new or revised workflow we designed and got sign off for at the beginning of the project. We make sure the DevTeam can create each User Story within a sprint, or we break the User Story down some more. Repeat until feature is complete and end user is happy. We use the Actors to identify who does what in the smaller chunks of User Stories. Sorry, its a habit. And it works. And it's not inhumane- I have always worked in a shop certified by the Anti-Cruelty to Actors Society.

'Actor' isn't vague- I always identify them in a separate chapter of the high level requirements and then in thre User Story or Use Case or Specification, I re-identify them. And Alice know damn well I never, ever let the DevTeam dismiss my Actors.

What's that you say? You read the Agile for the Waterfall Lover book and it states categorically the business team member or end user is supposed to write the User Story? Dream on, dude. They don't have the time or inclination to do that unless its in a JAD (Joint Application Design) session and the boss pays for brownies and lunch. The BA or IA write them and verifies them with the appropriate authority (stakeholder, Subject Matter Expert and/or end user). Then the developer who gets the task can go to the person who approved it and start the discussions. Or ask the BA or IA (since they are the only end user advocates on the DevTeam) or the BA/IA can facilitate the discussion. See what I mean? Nuthin's easy.

I have two problems with Alice's declaration of war in the allegedly inappropriate use of Actor and User:

1. The use of the terms Actor and Usder are purposely vague. The whole idea of what a BA does is to abstract the entire work flow in order to define the function(s). This allows the Bidness Team and the DevTeam to read the dame stuff and envision the same thing. That's why they call it Functional Analysis.
2. The UxD (User Experience Design) folks can and do carry this Persona thing way, way too far. I almost worked on a project that had about a half dozen personas identified. The UxD Team (not ours, thank goodness) not only had names- they captured pictures of each persona, knew her husband and her kids, where she lived, what car she drove and what got her drunk the Saturday night before. While the UxD Team goes off on those tangents... DevTeam Members are looking at each other and wondering what the hell is going on. I understand what the UxD Team is trying to do, and it does help define workflows, users and actors. I feel silly and unprofessional when I invoke a Persona. I feel like I'm talking about a dead guy or at a seance. And let's face it folks, the word persona is defined as: a character in a play or novel; A person's mask or facade; or someone's perceived but not actual personality.

If personas help the UxD Team- great. Just don't impose them on everyone. I will not write:

Carrie Ann Johnson, the one from Freemont High School, not the one that graduated College third in her class, clicks <Search>

1. Browser sends search parameters to Search Engine. 2. Search Engine performs search and returns matches. 3. Content Manager and Web Server send results page to the browser.

This Blog brought to you by that little old troublemaker....me (remember those TV wine commercials?).

Powered by ScribeFire.

Thoughts about Mary Travers

When I mention folk music to any non-folky, it immediately creates two thoughts to that person:

• Kumbaya- The African rendering of a Lutheran Hymn taken from missionaries and 'folk processed' back to the English speaking world. Its simplicity made it a huge hit during the Folk Scare of the 60s and has boomeranged to be an example of a bad song at a bad time. In the class of Dominque by the Singing Nun or Chop Suey by whatever his name was. If you aren't old enough to remember those, how about Yummy, Yummy, I Got Love in My Tummy or Winchester Cathedral, or anything by The Archies? Us cool 60s and 70s DJs called them "Bubblegum."
• Peter Paul and Mary (PP&M)- like the Kingston Trio, this seminal trio popularized roots music (See That My Grave is Kept Clean and Three Ravens come immediately to my mind), Singer-Song Writers (They had the hit of Bob Dylan's Blowin' In The Wind and introduced us to Tom Paxton [Marvelous Toy and Yuppies In the Sky] and to Canadian Gordon Lightfoot- after fellow Canadians Ian and Sylvia grabbed some of Gordy's Gold (the trio covered Early Morning Rain), their own writing (Peter Yarrow wrote Puff The Magic Dragon and Day is Done, Noel Paul Stookey wrote the legendary Wedding Song and Right Field and Mary got a co-writer credit for Come and Go with Me).

We all lost Mary Travers yesterday (September 16, 2009), apparently as a result of complications from chemotherapy. She announced two years ago she had Leukemia. Sadly, the bone marrow transplant worked and she was in remission. The same disease took Steve Goodman (City of New Orleans and Dying Cub Fan's Last Request). I'm so terribly sad.

She was part of a seminal group. Like the Kingston Trio, PP&M popularized real folk music and encouraged gifted songwriters. PP&M always had a political agenda, but it was never hidden, never mean and always inclusive. Many of us agree with and support the politics, the philosophy and the duty to humanity to this day.

But it was the music that got us.

I don't know about you, but I could go to a zillion churches, synagogues and mosques. I could ooh and ahh at the architecture and obvious reverence. But they never, ever filled me with any sense of spirituality or connection with others.

I found that in song circles, open mikes, concerts and sharing riffs with other players. I also got it when I was doing a Folk Music radio show in suburban Chicago for a few years and got to ask Noel Paul Stookey some questions (as well as quite a few more musicians of considerably more talent and technique that I have. And they all shared and continue to share. Mary Travers was part of that tradition. And much of her and her partner's music is spiritual- at least to me.

We will never hear Mary's kind and knowing song poem to her young daughter- her sultry voice in Noel Stookey's Comic Racing Routine (Peter Paul & Mary, In Concert album), her deft harmonies or her belting one out of the park with her superb instrument... live. At least we have the recordings, the PBS specials and documentaries. We are also comforted by Peter and Noel's statements on the PP&M website. But we're losing the performers, writers and singers we love. Just recently, we've lost:

• Mary Travers
• John Stewart (part of the second Kingston Trio and a wonderful singer songwriter)
• Erik Darling (Filled Pete Seeger's slot when Seeger quit The Weavers, Leader of the Trio which had the first Banana Boat Song hit in the late 50s and the leader of the Rooftop Singers [Walk Right In]) and whose Child, Child album I listen to every month or so to get new and fresh ideas I can steal....um Folk Process...for my own band)
• Travis Edmonson (the Travis of Bud & Travis)
  

So, yeah, I kinda resent PP&M being thought of as irrelevant and old. These folks haven't listened to the arrangements, harmonies and guitar work. And they performed at the Washington Memorial at the 1964 March on Washington for Jobs and Freedom...and were standing right behind Dr. King when he gave his speech.

I'm a proud fan. I am sad we lost her. But I think I'd rather celebrate her artistry and her life. And help keep her music alive.

Powered by ScribeFire.

Why You Need a BA (Me) On Your Team

In my Do Business Analysts Need Computer Programmer Skills? blog, some comments seemed to reveal that many project managers, developers and business folks never had a Business Analyst on the team. Interesting. I think the Agile Teams who have never had a BA on a Team should be considering such folks (me! Me! ME!) for several important reasons.

Since they didn't have BAs, I have to assume the Project Manager and Lead Developers usually handled BA duties...with the top developers getting the requirements (User Stories) and helping define the tests. But only high level developers can really handle this interfacing and talking to 'real' users. The purposes, skill sets, orientation- even language are very different in both worlds. Am I saying developers shouldn't talk to users? Absolutely not- that discussion should positively take place- but there has to be a coordinator, translator and secretary to perform all these duties:

• Learn the business- its processes and needs to develop the very best product under the constraints imposed.
• Create the As-Is and To-Be documentation to begin modeling the project and processes.
  
• Create the high level functional requirements to explain the project, the reason for the project and what technologies may be used in the project.
  
• Act as the stakeholder and end users' advocate.
  
• Gather the business requirements and business rules.
• Design and help model the application with the business team and the DevTeam.
• Plan and coordinate iterations or sprints and road maps with the business team and the Project Manager.
• Translate techno-jargon to biz-speak and vice versa throughout the project.
• Test each build to avoid glaring error and/or to prepare the business for skeletal interfaces and features.
• Create, document and communicate temporary workarounds for identified issues.
  
• Create UAT scripts, run the sessions, compile the issues and comments and create a suggested priority of repair/change list.
  
• Reproduce, manage and test issue repairs (and explained to stakeholders and end users why a repair is delayed or may not be repaired.
• Create User Stories (yeah, yeah, I know, the business is supposed to do this- of course, when was the last time you saw this happen unless you were in a JAD session?), specifications (essentially all the stuff that would have been in a Use Case), wireframes, project documents and business cases.
• Handle or coordinate Change Management (them applications you guys are creating are typically going to raise hackles all over the business because you're changing things and people are change resistant.
• Perform or coordinate knowledge transfer from the DevTeam to the Help Desk and/or Admin and or DBA team(s).
• Write user training manuals, help files and doing 'train the trainer' session for large applications when required.
• Keep Scrum/Stand-up Meeting Minutes and disseminated them to the team.
• Help coordinate and communicate implementation schedules and requirements with the business and IS folks.
• Assist in creating and implementing the Risk Management Plan.
  
• Manage the Issues Tracker, the wiki (making certain business questions and comments were promptly and appropriately handled)
• Provide/create and transmit frequent status reports.

Well somebody has to do all this stuff. And those of you without BAs are probably doing a hit or miss job and know it- your time, resources and costs are cut to the bone, or you are working 10-16 hour days- which is nuts. You know this sort of assistance would reduce risk, improve team productivity and improve the communication with the business- thereby reducing the chance of rejected features/functions.

We do the things the Project Manager doesn't have time for and free up Developers to do much more productive things in terms of skill set and interest. And really good reasons why a BA is still an essential role on an Agile Team. You can also use an Information Architect (IA) for this stuff and you'd get better designed wireframes, screen themes and controls but not as much written detail (which isn't necessarily a bad thing for an Agile Project- depending in the business expectations). IAs do pretty much the same thing BAs do, but they do it visually and usually aren't as technical as a BA. But, we both get the job done for the team.

That's pretty much why I think most projects need a BA and why the BA is typically the Deputy, Associate Assistant Project Manager.

Powered by ScribeFire.

Gamesmanship

One of the dirty little secrets they don't tell you about in school is about the recruiter. Yes, 97-99% of them are professional, work hard and are ethical.

But that one to three percent are real pieces of work.

They call you and ask the basic questions to qualify you for the 'requirement.' 'Requirement.' It's a job listing, job ad or job order. It includes a list of requirements. Arrgh!

Anyway, the Level One Recruiter (like the Level One Help Desk Analyst whom we all hate) then tosses your resume over to the "Account Manager." This is a sales job, not a management gig. Like the fact that everyone who works in a gas station or movie theater is an Assistant Manager.

This Account Manager thinks s/he knows exactly what the client (i.e. the company and people for which you might be working) wants. Usually wrong, but OK, they have the contact or prime vendor account and I don't.

Every once in a while, s/he wants you to 'tweak" your resume.

I'm all for writing to your audience (second rule of writing) but a few times in the last several weeks, these "tweaks" included:

• Changing 'Senior Business Analyst' to "Senior Business Architect." Now, I did it because I figured this was HR title inflation. I sent the resume back and the Account Manager immediately responded- "Can I turn Technical Writer into Business Architect/Technical Writer?" I said, "Hell yes." I thought the person who designed and build a business was the owner or the sales manager. I've never heard of a Business Architect. The 'requirement' read exactly like a Senior Business Analyst's role. I thought he was kidding. Even though I was a good boy and was biting my tongue through the entire process, didn't even get a phone screen.
  
• Bringing out the fact that I've managed people. Which I have and expect to do again. In radio news, my highest number of reports was 35 (all news radio station), but I've always been on small teams full of really smart people. Anyone familiar with software development will tell you the BA typically acts as the Deputy, Associate, Assistant Project Manager. How do you bring that one out in a resume without it turning into a Vitae (a book length listing of every time you walked your boss's dog, the number of Cleanest Cubicle awards you've received and junk like that)? I've been a professional writer in a wide variety of media and I have no clue. Didn't get a phone interview for that one either.
• Lying. One person was very careful to mention the job needed programming skills. My programming skills are, uh, nil. The last time I coded, there were still line numbers and you used crappy editors like Edlin. And, if it didn't work the first time, I quit doing that program. It should work the first time. I once did a program in C+ that converted dates into base 64. The only thing I remember about that program was the fact it had a bazillion recursive If-Then loops and if it didn't work the first time I ran it, I was going to quit my job. I didn't do it. I once had a really great job for three weeks. They had six, count 'em six interviews where I told them I was a tech writer and knowledge manager, not a programmer...although I suppose if you put a gun to my head I could probably figure something out within 6-10 weeks. You know what my first (and only) assignment was? You guessed it. They wanted me to convert web content into Lotus Notes databases. I was flabergasted. A. Didn't you listen to me the six times I said I wasn't a programmer? B. There's a programming language for Lotus Notes? Then why doesn't it ever work the way you want it to? C. Lotus Notes? Why the hell aren't you on Exchange or Zindus Server?
  
• Fill in the gap. You see, I haven't worked since October 2008. I'm in a protected class (those 40 and above, which sucks) and I used to make way too much money according to the large corporations here in Chicago. As soon as the bottom dropped out of the economy, these bastards started pushing down BA, Information Architect and Project Manager salaries and hourly contract rates. It's going to boomerang and hit them in the ass in a couple of years. Anyway.  There's a gap in my resume. Him: What have you been doing, Scot? Me: I've been looking for work more than full time ever since my last project crashed. Him: We need something else, to show you were doing something. Me: I just told you what I was doing Him: Nope, need something better. Me: Tell them I was researching a book about how a Business Analyst fits into an Agile Project as well as a few domestic engineering jobs. Him: That'll work.

And none of them, not one of them (except for three or four astute, personable and caring recruiting companies) tell you anything unless the client company wants a phone interview or you hound them with e-mails. And then they're your very best friend... until the process craps out on you.
 
I dunno. Maybe I should have stayed in radio news. I could easily be making $37,000/year in one of the three or four news jobs left in the industry. Or I could be a disc jockey...saying the same thing over and over and over and over and over...

Powered by ScribeFire.

Discovery Zone

I interviewed with an attorney this week. Her company dumped what might turn out to be a major IT project in her hands. She talked to one of my best friends who recommended she talk to me.

The first phone call was frantic... for the attorney and for me. As is typical, her mind was down at the field and controls level and I had to a. figure out what she was saying and b. make it look like I knew what I was talking about.

After about a half dozen questions, I realized where she's at and why she's in trouble.

This company gets sued a lot, I guess, there are a lot of in-house attorneys and, to use her words, "...hundreds of Outside Counsel."

Legal Discovery

Unfortunately, the legal profession uses the same word we IT folks use when we start a project: Discovery. Seems that in a civil lawsuit, Discovery occurs when someone sues someone else. Both sides have to give copies of relevant data (documents, spreadsheets, e-mail, etc.) to the other side. Turns out my new friend's company does this manually. In this day and age!

Thankfully, the company is throwing some resources her way and we may be able to solve her problem.

The company is adding some enterprise tools- but these tools aren't connected to anything in the current plans. Yep. No data store, no way to search, no history of use, no ability to browse using a taxonomy and no way to create and send a digital package of documents/data to opposing counsel, much less e-mail confirmations and an audit trail.

So the poor lady has two problems: where do we put all the nicely tagged and redacted data items and once they're there, what happens?

She has 3 Terabytes now. How do we get disparate databases connected (including non-company hosted systems) and then once all that stuff is properly stored in a data center somewhere- how do the other attorneys find and use the documents.

She was mostly concerned about the data store and what she kept calling "the index." She's right. The search engine needs to be able to pull records based on a lot of metadata. At least the metadata tagging will be automated!

Her IT Department has no resources to help her. Its been ravaged by lost and unfilled positions caused by the economy and several company reorganizations.

No wonder she was going nuts. Heck, if I was facing that and didn't know anything about content management, data mapping, batch ETL (Export/Transform and Load. No? It means connect all the databases and make them work nicely together) and the ways and means of attacking and solving the problem (project management and business analysis) and designing a solution (at the abstract and the wireframe levels, certainly), I would have been much more upset than she was. Hey, I can't write a brief or represent someone in court for money...why would her company expect her to be able to do what I do? I don't.


IT Discovery

Here's what the Project Discovery Phase looks like from my perspective- the Business Analyst:

The goal of this phase is to find the new system's boundaries (this will help define the Scope of the project), gather and organize functional requirements and settle on technology and architecture. Once the deliverables (the stuff I hand the client when that part of a project is completed) are in, the customer/company/client then has enough information to intelligently deal with how it wishes to proceed.

I advise and suggest while the company does everything except figure out how to pay for it and decide whether its going to do it. I guess they think that stuff is proprietary and private. OK by me.

I'm a sort of combination resource-subject matter expert-adviser. The Project Manager (if we have one) and I are what's called 'client-facing.' This is a silly term for: we talk to the client/customer.

I usually go in with a Project Manager (if we have one) but much more importantly-- a really smart technical architect or Lead Developer. We grab as many Word Docs, Excel Spreadsheets and paper, passwords, user ids and network paths as we can.

Then we sift and read. I then draw what the company is doing now (called an As-Is Decomposition)  and a proposal for automating one or more processes (called a To-Be Decomposition). The architect and I are beginning to design a possible solution. I start setting up interviews or meetings so I can ask questions and define the high level requirements. The architect is doing a parallel study for the technology (development languages and basic coding standards) and architecture (identifying the likely service layers and a beginning of the database table design).  We constantly confirm and reconfirm the validity of the existing process and what the stakeholders tell us the business needs (business rules).

I write my functional (functional - that means a description of what it does, not how it does it) requirements, a few fancy pictures (remember I told you Technical Writers to always have one graphic in color in anything you write that's more than two pages? The company folks you're working with need as many diagrams and pictures as possible top help them sell the project- preferably in color).  I usually add a couple of 'artist concept' wireframes of a basic interface and a lot of diagrams. 

The architect is writing up his/her technical document. If it's going to be written in .Net, there's a lot of cutting and pasting from the Microsoft Development Network website onto our wiki- I never watched where the J2EE architects steal, sorry, borrow their documentation from but I assume its on the Sun site somewhere or maybe at SourceForge.net.

I then edit the technical document because I have yet to see a developer, even at Microsoft, who knows how to write. I'll also help here with any diagrams or flow charts the architect wants (which I 'suggest' forcefully, see the parenthesis two paragraphs up).

From these two documents (and maybe a Business Case), the company can count function points, bid the project or put everything on hold. Hopefully, the last option doesn't occur because I usually....no...always need the work.

For some unknown and mystical reason, my company gets the contract for the Functional Requirement Document I just wrote. every time. How do you like that? Amazing streak of good luck, no?

My new friend wanted a proposal in plain English. This sparked friendship. I hate lousy writing. But she wanted complete explanations. So I spent most of yesterday evening and this morning writing it. It was seven pages long. I thought I went overboard. But my original friend said I didn't so we'll see what happens.

I think the two color flowcharts and the lovely Activity Diagram will help, as will the seven PowerPoint slides with animation and reuse of the graphics.

I ain't no dummy.

Stay tuned. Let's see if the winning streak continues.

Powered by ScribeFire.

Is The Economy Heating Up?

As I see the one year anniversary of my last paycheck coming up, I've begun to see more and more BA ads on LinkedIn, Dice and the others.

But the requirements remain huge, unrealistic and stiff as a board.

You still don't know what's important- especially for a couple of recruiters. The recruiters know exactly what the client wants, but doesn't put it in the listing (when did a job ad become a 'requirement?' and why didn't anyone ask me before marketing idiots destroyed another phrase?). I keep applying for jobs that appear to be spectacular matches...only to receive the same canned e-mail in return:

Boy, you look really good and thanks for the time and effort you put into it. Sadly, you're not qualified. I can't tell you why because I received over 200 resumes from people who want to be BAs. I'll give this to my secret...um....Administrative Assistant and archive it so if anything comes in that matches your basic and untidy "qualifications,"  I can give you a call.

In the meantime, if you use the link in this e-mail and drop $30 on a resume blasting scam, I stand to make $7.50, making that deluge of 200 resumes pretty profitable if I get a 10% return.

You can bet if that firm ever calls me, I'll be right there for it- bright eyed and bushy tailed.

A couple companies now have my resume. They SAY they have BA roles and I'm pretty hopeful. They're all contract and a year or less...but hey... I'd rather not actually make that one year anniversary. That would suck. Big time.

Powered by ScribeFire.