Reflections on Hiring Practices

Well, it took almost 13 months, but I found a job with some folks that not only get it, they see through the smoke and mirrors. I start on Monday.

Over the last 13 months, I have seen the craziest, outlandish, silly, stupid and counter-productive people, practices and processes ever.

Don't get me wrong. There are some people who know what they're doing. But they're so few and far between. And in all but a couple of circumstances, economic necessities forced them to cancel the gig.

When IT was booming, companies had to go to recruiting firms to get the people needed for projects and work. The company's HR recruiters didn't know how to talk to an IT professional or assess his or her background. I remember when I wasn't in IT and the College of DuPage gave them about 50% more than I was for the same level job- which is one of the reasons I got into IT. Fine. I get that. But that was 15 years ago. Do you think that after that length of time the HR Generalist curricula could address this? It must be me.

Now you have recruiters working on commission that barely speak the language. I'm not impolite, usually, but after asking someone four, count 'em, four times to repeat their company's name, I hang up. Why would I want to work with or through a company that bad in screening their people or those who consistently use the subjunctive case in recruiting e-mails? I am not anti-immigrant. I think Lou Dobbs is an idiot and a bigot. But if you're in this country, learning the freaking language! I did when I went to your country.

And its not a requirement. It's a job. The requirement(s) is/are part of the job posting.

One recruiter called me to ask me not to apply at his firm anymore! Seems his software saved all applicants and he was spending extra money having a clerk scan my resume into his system every time I applied for a job. He says it cost him about $10 each time. Since I'd apply for four or five openings about twice a month, I was costing him $50 a month. He then assured me he'd have a job for me within six months- in fact, Scot, just last week your score almost reached the top in my system and I almost called you. Yeah, I'll wait around for you. You bet. Like anyone with such a system wouldn't check for dupes. It's me, right?

I 've sent out at least  2 thousand resumes. I know the companies are inundated. Excuse me, but isn't that part of the cost of doing business? And aren't you looking for the best possible candidate?  I know they're allegedly scanning stuff into databases all over the world. But they don't know how to use the technology.

On no less than 15 occasions, a recruiter called me about an opening and had no clue: 1. my information was already in his system and 2. I'd already met with one his firm's recruiters (in person).

So, I'm real impressed with all the Taleo and Brass Ring reminders that my information will be kept on file for 12 months and if anything comes up, they'll contact me. I'm holding my breath.

And how about that Taleo snag that demands you enter a source for the job listing, but there's no source field...much less a pull down. I'm thinking we can either use this as a 'what not to do' for User Experience Design students or have your manager apply for a really cool gig...and then snort and chortle for the rest of the day. It's on a gazillion company-Taleo sites now.

And I couldn't get work.

Once in a while you see an ad on Craig's List that looks pretty good. Then you see there's no e-mail address and they want paper submissions. This is for an IT gig. And they want paper. Right. I'll get right on that for you.

Of the 2,000, most of the job sites wil acknowledge receipt. Then the ambiguous black hole. Am I in? Am I out? Nothing, Nada, Zip, Zero, Zilch. You have no phone number or e-mail for the contact (because you went through a job board) and no recourse.

Meanwhile, commission recruiters are calling you for the McDonalds, Sears, Allstate or JP Morgan gig you applied for through Dice- but one recruiter says her firm is a preferred vendor (does that mean they get to drink in a cool special area at the airport before heading out to the Bahamas for a 'business meeting?'). You figure maybe they'd be able to get your resume to the right person, so you say yeah.

Just then. an HR Representative at McDonald's activates the database for the first time since they moved it over from the IBM Mainframe on DB2 to SQL Server 6.0. And your resume pops out. Two resumes and therefore at McDonald's. Sorry, we can't hire you because you applied twice.

Hunh?

At least they replied. I appreciated companies telling me when an opening closed. I could take them off my list. But they rarely tell you anything other than "we decided to go a different route," (d we just get on a bus?) or "we found a better qualified candidate" (give me a hint, better qualified how?) or "we really liked you but <fill in a platitude here> so please continue looking at our website so we can double the sting and humiliation of rejecting you in a couple of weeks when the turkey we just hired quits or we fire her and that's why you've seen this add three or four times."

Or, the HR gamesmanship. The company wants to promote someone from inside to the gig but its EEOC numbers are skewed. Have HR post the job and ignore anything that comes through on #BA34262.

Then there's the recruiting firms that sweet talks you and offers to 'submit' you after you've spent six or seven hours doing three or four resume 'tweaks.' Then, nothing until you call.

When you call, they say that had no feedback from the client. What they don't tell you is your resume was sent over with five or six hundred others in the recruiting company's bid to strike the hiring manager with its ability to generate numbers and a wide selection of lovely parting gifts. Which wastes my time and the hiring manager's time.

On one direct application, I made it to the phone screen and didn't hear squat until I'd left the six message on the HR Rep's voice mail. The next day I got an e-mail saying they were gouing a different route (which is strange since they're right on an expressway). Which is fine, but tell me why and how I can improve my presentation the next time. The reply was "it's our policy not to provide feedback." Wow. Either lawyers and liability issues are now into self-improvement or that phone screen went horribly wrong and I didn't know it.

Then there's the one thing that may turn me into a Libertarian.

My name is Scot and I'm in a protected class. In the 1970s, the U.S. Government stopped companies from firing highly paid, experienced workers in favor of lesser experienced and more poorly paid workers. The idea was to help us old farts keep our jobs. The idea was great. But being protected, I have to assume, got in the way of most of the gigs for which I applied.  Companies get nervous if they hire you and can't fire you without a reason or as part of a larger lay-off. Never mind that I've never brought suit or that I understood each time I've been laid off its because the sales guys didn't do their jobs well enough.

And even if it was because of my previous salaries, I never got the chance to tell the employer I'd be willing to take a salary cut to get work for a company that might provide future growth. Either that, or the now required salary field on the website automatically disqualifies us older, experienced folks.

Let's assume I'd jump ship when the economy came out of the crapper. You'd rather have a kid just out of school who's never faced a pissed off client than someone experienced? You'd rather do a web application design three or four times rather than right the first time? You wouldn't want to employ someone with extensive skills and abilities that you can pretty much slap into any slot you need because you're worried I'd leave in 1-2 years instead of using me? No wonder the economy tanked. I wouldn't want to work there anyway with that kind of group think.

And let's discuss this process everyone seems to be using to "get the best person for the job."

Our applicant and his/her recruiter spend an inordinate amount of time 'tweaking' the applicant's resume (which is, in my experience, adding lies and hyperbole).

The resume is supposed to get me the interview (I know because my Mom was a job counselor in the 70s and I read What Color Your Parachute, which is probably the dumbest books I've ever read). I'm told I won't even get the phone screen if it isn't perfect. Sounds to me like the hiring manager is hiring off the resume, folks. And no matter how many superlatives the recruitering company's Account Manager sticks in my resume, if there's no immediate fit or interest, there's no immediate fit or interest.

Then we get either the HR Generalist (who doesn't know the difference between a Use Case and a Crank Case) or a technical sort on the phone with the applicant. The idea here is to separate the men from the boys. TMy trick is to step on my tongue and not interrupt, have one really good question about the company and answer the tech questions as competently as possible. The interviewer then mulls over all the audio and selects two or three to come in for a face to face interview... sometimes more (if the Director/VP is having lunch with a friend and left early and didn't tell the hiring manager so you're gonna have to come back if we're interested). Then the same questions are reapplied to the process because once wasn't good enough.

And from all that 'information,' the person making the hiring decision makes the decision.

Then there are the downtown Chicago companies which; a. don't have the slightest idea about the difference between a BA and a Business Systems Analyst, b. figure its a buyers market and take advantage of everyone by putting the kitchen sink into the competencies/certifications and experience necessary for the job, c. Use the economyas an excuse to cut pre-2008 contract rates by 40-60% (while accepting government stimulus money), d. the financial whiz kids who decided an hourly rate wasn't good enough for its newest consultants and not only cut the rate, but imposed a 'weekly rate' that allowed it to work consultants 10 hours a day for five days before any recompense kicked in, and e. the huge company that wanted you to work for $25/hour as a BA/Tech Writer/Project Manager- of course, that company always wanted to pay you less than $30/hour for your work.

Not once during this process did anyone test the Business Analyst to see if s/he could do the job. Smart companies do that with developers and pretty much make the hiring decison based on the test result and whether the applicant didn't tie his shoes together or had tomato sauce on her blouse.

In the 13 months I was looking, I took one test. At a recruiter's office. Very low level test. The recruiter had me take two parts over again because no one had ever scored that high in so short a time. I say this not to impress you with my credentials, but to underline hiring manager expectations.

At Geneca, I helped develop a quick and easy test. We had the applicant take 20 minutes or so to create a Use Case- not a complete Use Case, but enough to check writing skills and familiarity with the concept. Then we'd ask the applicant a question that forced him or her to give us a good estimate about something we assumed they knew nothing about This gave us an idea of how well the person could abstract, deduce and describe the process. That was to see how they thought and how well they through on their feet.

The other great test I took was for a web-based company, It had all its applicants write requirements for a simple feature. I got through to the phone screen. But it was with a developer and I didn't make it to the end.

To those others, I gave the url to my profile website with real, honest to gosh work product (cleaned up of proprietary detail, of course)- Use Cases, User Stories, Iteration Feature Lists, QA Management, Project Management, flow charts, diagrams, wireframes and more. I think I got 3 or 4 hits until the last folks to interview me kept going up there and downloading pretty much everything that was there.

So. You tell me. Software scanners, keyword hits (actually 'buzzwords'), phone screens and face to face interviews? Or a screening test of actual knowledge and ability followed by a real face to face interview about the real job?

Even if it's contract, I'm glad to be back to work. This job hunting's for the birds.

Powered by ScribeFire.

Ubuntu 9.10: Not Bad, Not Bad At All

Everyone else is installing Windows 7.0. Now I've been in the Microsoft World long enough to know the old saws:

• Never, ever install the first version of a Microsoft Operating System.
• Wait until after the second Service Patch.
• Odd numbered patches will destroy your machine
• The even numbered patches fix the odd numbered patches.

Since I've been out of work for quite a while, I decided to install a dual boot- WinXP and Ubuntu 9.10 (Karmic Something-or-Other).  The installation routine automatically and perfectly partitioned my hard drive (sectioned off- one part for Windows, the other for Ubuntu Linux), found all the drivers (does Linux have Drivers?) and made my stuff work.  It's rock solid, includes a free version of every Microsoft Office application except one (one I use a lot- VISIO and there's no Open Source equivalent yet).

I had 9.04 (Jaunty Something-or-Other...this cuteness crap has got to stop) on an IBM T-23 ThinkPad and it worked grandly. No issues at all. So I held my breath the day after Win7 came out and installed  9.10 Desktop, the latest and greatest version of the Ubuntu line on my T-61 Lenovo ThinkPad.

So far, the only things I haven't been able to do (excluding VISIO- and I'm trying to figure out how a Windows emulator called Wine works and how I can use it) are:

1. Install the software to synch my SmartPhone (Windows Mobile 6.1) with Thunderbird's Lightning add-in. I followed all the instructions to download and install the USB connection software, but it refused to install. I think its because I'm on the latest Ubuntu Version and the developers only have the last stable version up on their server.
   
2. Recognize and connect to servers on my home network (probably because I haven't really tried yet).
3. Figure out whether I want to use Evolution or Thunderbird as my E-Mail Client/Calendar/PIM (Personal Information Manager).
4. Install the latest Thunderbird Beta because I have no idea how to install non-Ubuntu applications ('packages' in Linux-speak). I download the tar file (a compressed file similar to *.zip files in the Windows World) and double clicked it like the wiki told me. All it did was open the Archive Manager (which was nice to know, I didn't even know it had one) which just displayed the files in the compressed *.tar, so I decompressed the sucker and started double clicking all over the place. Nothing.
5. Move my mail and passwords from my Windows partition to the Ubuntu version of Thunderbird. I suspect this is a Mozilla problem (Mozilla makes Thunderbird) rather than Ubuntu's. Which is why I wanted the latest beta...I know where the mail files are and thought I could simply move them into the Linux machine, but I was using the latest Thunderbird Beta in Windows because the Lightning Calendar Add-in was crapping out all the time and the latest Beta uses a different database for mail and calendar items. But Birdie Synch doesn't work with the latest Betas (obviously- that's why they're Betas). Oy.
   

Unlike earlier versions of Ubuntu, 9.10 automatically detected my T-61's display and the external monitor I use, detected and walked me through my Wi-Fi and Bluetooth connections, found my external, USB connected hard drive. All effortlessly, cleanly and professionally. Laurels for the Ubuntu Team.

But.

You knew this was coming, didn't you?

The documentation designed for brand new computer/unsophisticated Windows users moving into the Linux World (Ubuntu is a flavor of Linux) or folks who've been running Linux command line stuff for 15 years. There's no middle ground. As a professional writer (and technical writer at that), I know that user documentation has a multiplicity of audiences- and the Ubuntu documentation does not. There may be a market for this as Microsoft returns to its every three or four year OS (Operating System) upgrade cycle.

Bottom Line:

1. Yes, I would install Ubuntu on my Mother's machine. The interface is very Windows-like, the on-line help is fabulous for the unsophisticated user who simply wants to use e-mail and surf and maybe write a letter or two...mebbe a couple of games.
   
2. No, I would not install it on my wife's machine- she's a programmer analyst would still be content to work in DOS.
3. I would install it on my daughter and older son's laptops. They are sophisticated users and would role into this OS like butter on bread.

Advantages:

• It's free
  
• It's applications are free (Open Source)
• The interface is as simple or sophisticated as you wish.
• Peripherals connect and work just like a Mac- immediately and without fuss.
• It's rock solid.
• It's fun to use and experiment with.

Disadvantages:

• Sophisticated Windows Users have a learning curve- it's short (I'm thinking less than a week), but its there.
• Documentation could be better for task oriented users- How do I synch my Windows Mobile to my PIM, how do I create a permanent connection to my son's laptop so I can read his comics and he can read mine, etc.  (this may be my issue and not the documentation). The simple explanations, while valid, only take one so far.
• While the software is 'free,' the new Ubuntu Software Center (sort of like Window's Add/Remove Programs) has a less than complete description of each product. But it does tell you whether Ubuntu will automatically update it or whether you need to do it manually. Yeah, I know the websites are always listed, but that made selecting a media player a lengthy process- so I kept the defaults and they work fine. 

Overall Grade (so far): A-.

Linux, Ubuntu 9.10, Open Source, Technical, Desktop

Powered by ScribeFire.

TeamClock- Tastes Just Like Chicken

FaceBook has attracted pretty much the entire Class of 1973 for Rich East High School (Park Forest, IL). So I found the student director of the Spanish National Honor Society play I was in, only two suburbs away.

Steve Ritter is well and living in Elmhurst. Or Lombard. One of those two- the ones you can't get there from here.

Steve was one of the cool guys in high school, pretty much fit in every where and everyone liked him. Including me.

On re-connecting, we cautiously approached the other. Just to make sure the other guy hadn't weirded out. We're children of the 60s, remember.

Didn't happen.

So I invited him over for a music jam. He plays a mean guitar, much better than me- he's a little better than me on mouth harp and I'm a better singer- but he's the better overall musician. He politely refused the offer to join Acme Plumbing and Music (now called West Wind- I don't know what it means either and it's not half as funny as the original name...but I digress). Turns out he has his own band. Go figure.

Anyway...

Steve's doing a lot of consulting and has his own firm. He's even URL'ed himself: Steve Ritter. If I did that, my wife would stomp me. The best I can get is a subdomain: www.scot.witteweb.com.

It's my blog.

I can shamelessly promote myself if I want to.

Steve's been researching a book on team excellence. It comes out November 12th.

Now, I assume it's not a dreary textbook from his promotional tweets. It sounds much more like a cross between a motivational speech, The Agile Manifesto and a Team Dynamics For Dummies Book.

Tell me I'm wrong:

• Anyone still interested in following my tweets should begin following me at TeamClock. My work on breakthrough teams will be featured there.
  
• "Strong teams not only accept change, they expect and manage it in a proactive manner." (p. 53, Team Clock: A Guide)
• How, specifically, would you invest in your team if you wanted to increase trust and promote cohesion?
• Good enough or amazing? Breakthrough teams reach beyond the comfort of good enough to find new ways to invest, trust and innovate.

Steve hasn't sent me a review copy, and I'll have to wait until I get a job and bring the finances into alignment with the Age of Aquarious (it still is the Age of Aquarious, isn't it?), but it looks like Steve's years of research is going to support most of what we know and do in Agile Methodology:

1. We produce business solutions, not paper and documentation.
2. We find the hidden requirements by putting the product right in the business' hands so they can tell us what they want.
3. We expect and manage change up to and including implementation. Heck, sometimes we do it afterward even if we don't have a real iteration going.
   
4. Every member of the team is empowered to repair, suggest, assist and even clean up the war room.
5. The end of each requires the team to reflect and suggest changes to improve the process and the product.
6. Each team is self-managed. The Project Manager or Scrum Master's job is to remove obstacles from the team's way- not to manage. This eliminates a lot of chickenshit.
7. Agile development is test-driven. Our developers, business team members, design team members and management know when a feature is complete or issue resolved. It's done if it passes the tests the business imposes (and later on, the integration testing- after all, when coders change stuff, putting it all back together may create a new problem). This eliminates scope creep and finger pointing.
8. Agile team members 'parallel program.' That is, two developers grab a feature or part of a feature and work together for at least part of the workday. This isn't just a bonding experience- it enforces the sharing of knowledge and improves the end product. Heck, even us members of the Design Team (Business Analysts, Information Architects and Web Masters/Designers) can parallel program on GUI, wireframes and functionalities.
9. This may be the one place I'm betting we won't agree with Steve: Agile does 'good enough' development and documentation rather than superbly done. That's because the other methods have resulted in thousands of failed projects. Since we use working code and stakeholder/end user requirements from the beginning, small and medium sized projects are more likely to succeed, And if the business really wants 'superb,' we can do it, but we'll point out that two sides of the Project Manager's triangle will be out of proportion: Time and Money.

'Course I'm guessing what Steve's come up with and won't be able to read it until the 12th when he starts selling it.

But I'd watch his tweets if I were you. And buy his book when it comes out. Demand a copy at your local bookstore.

Steve's pretty damn smart.

I know.

We went to the same high school.

Powered by ScribeFire.

Lesson Learned: Hidden Requirements

I spent four months in the Discovery Phase of a major project.

It had some of the most complex business rules I'd ever run into. The idea was to build a data platform to move the company's data from third party vendors into a custom data warehouse. That's where it started. As you'd expect, the scope blossomed like a mushroom cloud in 1950s Yucca Flats, Utah.

I concentrated on the original concept since others were dealing with the side projects. I created a matrix of coupon-mailer-product and took a week to write some pseudo code to demonstrate the machine logic required (it wouldn't fit into a single Use Case- the best I could do is add my 15 pages of 8 point pseudo code to the 53 pages of the rules and walk the developer through it). The SMEs approved it. It was like pulling teeth. You'd get smiles and words of assent, but some of the folks I was dealing with were playing company politics and pretty much ignored the Use Cases for their multi-million dollar data application/framework.

About a week before I was scheduled to leave (real old school - using Iterative Methods). I chanced to talk to a director about something else in the Smoker's Lounge. Nice guy, very knowledgeable. He politely asked me how we were coming and I outlined what I'd done to date. "You mean you're not creating coupons when xxxxxx occurs? We've been doing that by hand for years."

Turns out there were twice as many business rules and decision trees as I had.

The rules and logic were in someone's desk drawer. He thought we had a copy. Even though I'd asked him for the rules at least four times. "Yeah, you mean I forgot to mail it to you?"

I left the project three days later. Blamed for the failure.

The poor development team would have to do it from the original  material which had been amended about four or five gazillion times since it was written in 1856.

Here's what I should have done and have done ever since in Waterfall and Iterative Methodologies:

1. Identify each and every stakeholder and find the possible politics that can impact the project. Make sure it's in the Risk Management Plan with mitigation strategies. No seriously. Doing that would have saved the first phase of the project.
2. Identify every document passed to me (I was swimming in that Project from Hell, but I didn't catalog each piece of documentation). I could have identified gaps with a simple spreadsheet.
3. Draw more pictures, tables, graphs and diagrams. I used to think a multi-million dollar project was probably worth reading the Use Cases. Silly me. Pictures. Color. Arrows. Boxes. The third or fourth rule of technical communication: make sure there's at least one graphic in each publication and if the document is in color, it's more important than one in black and white. You think I'm kidding, doncha? I'm not. Its true- ask any tech writer.
4. Always, always look for evidence of hidden requirements. And then look again.
   
5. Keep asking polite questions and reflecting what the SME says back to him or her until I'm certain I understand what s/he is saying.
   

This project is the reason I love Agile Development Methods. There are no hidden requirements in an Agile Project. When you deliver working code the the SMEs, Stakeholders and end users , they can play with it and tell you what's wrong and what they think they need. And the politics/See-what-we-can-get-fer-free mentality is eliminated- the business is on the team and controlling each sprint. We don't point fingers, we find causes and improve our quality. There are no long and boring Use Cases. Instead there are 3-4 line User Stories from which I can create a Technical Specification for the developer to use in coding. Everybody gets to weigh in on problems and ideas for improvements to increase quality and increase throughput.

Best of all, we create software without games or gotchas.

Powered by ScribeFire.

No SAP for Me

Well, I thought about it long and hard. I'm giving up on SAP Data Warehousing and Business Intelligence.

I took four lessons on how to do it. I wanted the big-time cash promised in a recession proof endeavor.

So here's what I found out:

• They told us we could really screw-up our client's data by doing the wrong thing. Me? Screw up enterprise data with an inaccurate click somewhere? I have my own problems without adding to them.
• Does it scare anyone else that no one, SAP Engineers included, know everything there is to know about SAP? Sample question supporting the thesis: How do you create and perform boundary, integration and regression tests when you come out with new stuff?
• I get there are four basic import routines for the stuff we were doing. Non-SAP data sources, Flat File and two, count 'em two SAP Data Sources. Hmmm. One for non-SAP and two for SAP sources. Is anyone else confused on how SAP abstracted the import (Extract), cleanse (Transform) and use (Load) processes?
  
• SAP creates words that have nothing to do with function, I'll be generous and say its because the software is written in Germany by ex-IBM engineers (like there aren't any native speakers of English in the U.K. or here in the U.S. that can test terms with users and suggest better ones). I do not believe that just because we did it this way for x number or releases, its the best way to do it. An example (i.e. one that I was able to figure out): There's an object called an InfoProvider. So I spent an hour finding out that an InfoProvider isn't a non-SAP data source (which is still another SAP object) but is an internal SAP Object that provides data to the modeling and reporting tools. Oh yeah, some of the term definitions change between SAP revisions. It's no wonder SAP needs to certify users. As a goof, look up the word 'replicate' in an SAP 7.x version ETL (Extract, Transform and Load) Manual. It's not what you think it is.
• Because of the bullet point above, I was confused. It was like Algebra in High School. It made sense while I was watching, but when I tried to do it, I was lost. Couldn't internalize the stuff. Labeling is important to me and when you start changing definitions willy-nilly, I get rattled. I couldn't tell the difference between the objects. Relational Databases have been using really good terms for a couple of decades now. For what we were doing, SAP abstracts the data and de-normalizes it (data delivery is not the goal- data manipulation is) from the key fields so it can pretty much let you do anything you want. I worked with something similar in a data intensive application where all the data goes into a single, two column table (just like SAP) and it used four other tables to identify, and if required, normalize the data- SAP uses an intermediate table with what's billed as a really cool feature, but is, in actuality nothing more than an automatic, system-assigned GUID (Global Uniform Identifier) table for data look-up and intermediate/abstracting tables and data. I just explained it to you in less than ten sentences with only a couple of jargon words. I guess that's why SAP can charge a gazillion dollars.
  
• What's the most basic data import anyone ever does? Yes. Import a flat file. It took me over a week to figure out how to do it. The book (written by SAP) pretty much had nothing to do with the interface I was using. The latest version of SAP makes certain steps optional when importing data. Not by my sights. I had to create about 123 Objects four or five times each until I could do the import and there's no freakin' way I could replicate what I did and in what order.

Working with bean counters, executives and managers day in and out over the specifics of reports for weeks on end would be torture for me. I've seen others do it and do it well. I have all the respect in the world for them and am glad when they're on my team. I just can't do it. I'm much more interested in team dynamics, technology, helping folks to solve problems, improve processes and stuff like that.

To thine own self be true.

So I found out the State of Illinois might pay for PMP (Project Management Professional, i.e., a certification telling the world I can be what I've been doing for about ten years- be a project manager) and ITIL Foundation(I had to look this up on Wikipedia- it's a framework for software development, like this is hard) AND it'll pay for the test(s) andf first year membership in PMI (Project Management Institute, yeah, sounds dumb to me, too and its a really pain in the a^& to re-certify. Seems like a major gimmick to me). I have an appointment Thursday to begin figuring it out.

I talked to the wife and we both decided this stuff really wasn't in my line, just not a good fit. She's a developer and teacher. She's been trying to teach me .Net stuff for a long time: a. yeah, I can do it, b. it should work the first time I run it and c. stay away from me when I'm debugging, bounds and integration testing. No really. Stay away from  me.

We agreed I'm an IT BA, perhaps there's a decent Project Manager underneath the requirements gathering top veneer, but that's pretty much it. I know how stuff works, I have good communcation skills and can explain it to the business, developers, QA and end users. I can gather requirements, design/mock-up reports and am a pretty good jack-leg Information Architect. And I have a particular propensity for governance and process (in other words, I like systems analysis and I can help others learn different methodologies). And yes, I like using the word propensity. When I was on radio, it took the chief engineer an hour to clean up after me when I said on the air.
 
It was almost as satisfying as saying goodbye to a long tern, 'challenging' client.

I appreciated the chance to try. Right clicking on SAP objects over and over and over would drive me up a wall. I'm already a squirrel, so I see no advantage.

Powered by ScribeFire.

Differentiation Isn't Enough

One of the places I used to work is just about ready to go belly up. I'd always hoped when the economy turned itself around, I could go back there (and I'm still cheer leading for it to succeed). The company treated its people as they wished to be treated and attracted really smart and sharing people. Seriously. They did. That bred a LOT of loyalty in me and I'm sure a lot of the others that have had to leave over the last few months.

I'm not really sure what the business model was. The executives never invited me into the discussions.

But it appeared to me the company was selling itself by differentiating itself from the rest of the boutique development firms based on two things:

• User Experience Design and Testing
• Agile Development Methods

A couple of years ago, I'd have told you that was enough- nobody was doing either. None of the contracting firms I knew about anyway. A few if them would call in a design firm for the "look and feel stuff," but none of us hardy Development Men (strains of Stout Hearted Men should be starting up in your mind right now) really cared much. That was for sissies.

It was really bad for us to think that way, especially with some of the interfaces we came up with. Ugly. Counterproductive. Silly.

But soon, both terms became buzzwords and the economy crapped out. Bad thing, these buzzwords. I remember a manager got his job by spouting buzzwords at about four buzzwords per sentence in his interview- and he got the job. Since I was the guy that had to do all the stuff he talked about in his interview, I quickly learned he knew nothing. I didn't resent it, part of anyone's job is to make your boss look great to his/her boss. I just realized that buzzwords mean nothing.

Today, everybody says they're Agile and say they use appropriate UxD (User Experience Design) standards. And it ain't true.

They don't use Information Architects who create work flows (they call 'em scenarios, whatever) and design for the end user with the latest HMI Design Standards...that's Human-Machine Interface Design. Nor do they test GUIs (Graphical User Interfaces) and ask end users how well something works or doesn't work.

And they've never read the Agile Manifesto, else why is the Project Manager (PM) running the show without any input from team members? Or no test-driven development? Or no parallel programming? Or keeping documentation to a minimum and letting the team run itself with the PM's role changed to removing obstacles (with the BA, of course). Nope. Not Agile. They put silk purses on sows' ears.

So when the company I worked at was trying to drum up business, it got lost in the shuffle because its perceived expertise was allegedly shared by every other company. There was no differentiation.

Frankly, companies pulling in development consultants:

• Don't care about methodologies. They care about results. And its way too easy to oversell Agile's working code paradigm.
• Don't care about the end user much. If they did, they'd have mastered this years ago. The Mac has been out how many years? They should care, because ease of use significantly increases productivity which translates to dollars and cents....but when my former company 'educated' potential clients, we had little impact because of the lack of front-end buy-in. Just do it and write the cost into the bid.
  
• Want the consultants to have the answers. The customer, allegedly, don't have time to supply a team member with enough clout to actually make iteration decisions nor provide a great deal of time as Subject Matter Experts (SMEs) to the BA/Developers...they have to do their jobs you know.

I wrote some marketing white papers. Not once did I mention UxD or Agile. I told the hiring firms about the very real advantages my company offered and how that would impact the budget after implementation. It would have helped a lot if I had some real figures I could use. I don't think they were ever used because our Marketing Director went back to her specialty of media relations.

And some clients are necessarily Waterfall organizations. I worked at one retailer on an application that touched everything in the building and all of the stores. Neither my company nor the customer had a clue about what Agile is or is not. They created a 'War Room' where a lot of IT people sat, but they required Use Cases and High Fidelity Wireframes- I mean, I was using VISIO and PhotoShop to create wire frames. I was told we were using 'Modified Agile." Right. All Agile projects use modified and pragmatic methods. Neither company knew how to scale an Agile Project with Iterative/Waterfall components. So the whole thing blew up in my company's face after it moved back to Waterfall with some minor iterative design work.

Add the distinct lack of domain knowledge for vertical markets (we do Health Care, no- we do hosting, no- we do education, no-we do UxD, etc. etc.) forced the BAs, IAs and Developers to learn new domains for every project. Domain knowledge is the stuff you'd know if you worked five or more years in Insurance or Bakery Goods. It's the business, its regulations/regulators and very basic requirements. For example, I have a lot of domain knowledge about IT, software development, journalism (electronic and paper) and direct marketing (I've worked two projects in that area). The company I'm rooting for is about ready to go belly up because its pretty much bidding on anything that came in the door and has been doing that for several months.

Instead of concentrating on customer's needs and wants then specializing in a particular area, my former company blew it. I hope they get a contract soon so the business won't fold and it could rehire a lot of us.

But I'm not holding my breath.

Powered by ScribeFire.

SAP: The Highs and Lows So Far

So I'm using this blog to increase my visibility for potential employers. If I was them, I'd like to know who I'm getting.

They don't seem to be reading this, so, I'm going to add SAP busisness intelligence/business warehousing (that'd be BI/BW for those of you with TLA [Three Letter Abbreviation] Scorecards out there...and BO (that's be Business Objects without a scorecard) which SAP got a hold of sometime last year and is integrating it.

Or maybe they are and are steering clear?

Anyway, a very smart company is training me to to a. gather the reporting requirements, b. find the data elements somewhere in the spaghetti that is any database and c. actually create the reports. Apparently, this will save the SAP owners a boatload of cash by hiring one person to fill two roles- even by paying us a lot of cash. Us out of work BAs get jobs at what recruiters tell me are obscene hourly rates. I can live with that.

But I still need a short to medium term contract gig to pay bills and make sure I don't lose my house.

Companies (HUGE companies, Billion dollar plus) buy SAP and its various 'modules' (think up-selling, like they do at Radio Shack [Need a microphone with that tape recorder, Mister? How about some cassettes and an extra battery to go with that power supply?]) to run the company. Some former IBM-Germany Software Engineers tried to sell IBM on it in the late 80s or early 90s. IBM took a pass (would you expect less from a company that now sells Lotus Notes, AS400s, r6000s and WebSphere?).

With all that data lying around in DB2 and Oracle databases (think really, really big databases, here), someone got the idea of 'warehousing' the data in one place and generating reports from that data. Enter Data Warehousing. At least three other companies offer it and two others offer reporting and data mining skills. But single, soft serve (pun intended) service from one provider seemed like a great idea. It probably is.

And just what kind of hat does a data miner wear? Hard hat for when the boss starts throwing things? A beanie with a propeller to reinforce the stereotype?

So I've taken two whole days of training so far. I've been taught and think I understand the stupid object names (totally confusing- I need to look up the difference between InfoObject and InfoProvider). So....I figure loading a flat file (think spreadsheet with a half dozen columns and a half dozen rows) ought to be a piece of cake- after all, I've designed and specified this ability along with the required field mapping GUI a dozen times for both .Net and J2EE applications.

It took me three and a half days (seven half days) to figure it out in SAP. And I'm not really sure it's there because we haven't gotten to the report making stuff yet.

Actually, I didn't use SAP. The data warehouse and reporting tools aren't in SAP. And SAP isn't SAP. SAP used to be known as R3 and is, in this latest edition, called ECC. I used is a Java-based tool called NetWeaver. So far, the only reason  I need to know that is to find useless information in the SAP help website. Otherwise, no one seems to use the term.

What I've learned so far:

1. SAP needs someone to come up with better and more intuitive terms and phrasing for this future user. I dunno- maybe have a native speaker of the language eliminate the ambiguity and increase the uniqueness of the object names for starters?
2. SAP is so big and does so much and is so granular that no one knows even everything to know about modules. It supports TWO, count 'em TWO application languages (the proprietary ABAP and Java).
   
3. Connecting a series of optional and mandatory objects probably should defined somewhere, step-by-step, and then explain SAP Module and other database connectors and options.
4. SAP's 'Star Schema' isn't new or unique- I've had Technical Architects design exactly the same thing for data rich environments to speed queries and system response time. It just makes Query creators who know SQL and typical RDBMS (Relational Database Management Systems) crazy.
5. There's a reason anyone with SAP knowledge commands a premium wage.
6. I'm really glad about #2 and #5. I spent way too much time satisfying my ego in Radio News before I got smart and moved into IT...and two lengthy lay-offs (after the NASDAQ crunch and this depression) I just might be able to retire after all.

This is so exciting that I'm almost ready to stop using a very low grade tranquilizer to get to sleep- all I have to do is imagine the NetWeaver interface and creating an InfoCube....zzzzzzzzzzzzzzzzzzzzzz

Powered by ScribeFire.

Agile Job Hunting

I'm getting calls and e-mails from IT professionals with a job opening who think they understand Agile (they don't, but it's the latest buzzword and process) and are asking me questions about it.

It's no wonder the economy's on the rocks. How can you hire someone when you really don't understand what you do and how you do it?

To wit (pun indended):

• One manager at a large company north of me said 'RUP/UML is an Agile Method.' I suggested it is not, but it is a precursor process and is valid unto itself, depending on the circumstances. I should have kept my mouth shut. The manager said, "I went to school about this and it is an Agile Method." I responded (stupidly and because I thought it was a test) the Agile Manifesto demands test-driven development, self-organizing teams, very short sprints, creating usable code from the first and a lot of communication between team members, end users and stakeholders- Iterative does not. I didn't get the job. Shame on me. On the other hand...if I got the job and the manager was that stupid, how satisfying would it have been?
  
• Another company sent me a questionaire. I filled it out. The big thing they wanted to know is when the BA would 'let' developers talk to the business side. I said it depends- in the Scope/Planning Phase, not at all since we need to define the scope of the project, basic architecture and very high level requirements (I like going in with a Technical Architect or Lead Developer and a Project Manager/Scrum Leader if I'm not acting in that role). Later on, it pretty much depends on the developer and if s/he can talk to business people. If they can't, I'd have to facilitate and translate. I didn't get the job. If they have developers talking to Champions and Stakeholders even before the scope is settled, how good could the process be?
  
• One company I worked for, said it was Agile. The organization it was working for was Waterfall. I suggested it was not- they didn't allow the BAs to talk to the developers (!), the daily Stand-up took an hour and allowed yelling back and forth between the customer and the Lead Developer. I saw the mis-match immediately but couldn't find anything quick enough before the ax fell. They called it 'Modified Agile.' Right. I lost the job. With several other folks.
  

Then a couple of weeks ago, a small but very cool start-up advertised for an Agile BA. Instead of a silly technical phone screen- the first thing it wanted was for applicants to create User Stories for a test feature. Finally. I could demonstrate what I could do and they'd actually answer my questions as though it were a real feature. I spent a whole hour on the story and then another hour to create a couple of wireframes and sent 'em in.

A week later, we set up the phone screen! I'd passed the first step.

They had a developer call me. He wanted to know what a BA could do for two developers and a UxD (User Design Experience) professional on a working e-Commerce and Collaboration site. Cool.

I think the interview went well. The company sold me in the ad- they have very smart people working there and I want to be part of it. Next steps are a couple of hairy face-to-face interviews and then a 'team lunch.' My fingers are crossed.

Even if I don't get this one, I have a lot of respect for this company- they think things through and the hiring process actually measures if the person can perform to the level the company needs. Not glad-handing, coming up with silly answers to stupid, predictable and trite questions (which measure your interviewing ability rather than work skill set). Finally! No games. Grown-ups. Adults.

Cool.

Why the hell can't the others learn what the buzzword means and find a good way to hire like minded/trained folks? It's not like its hard...you just gotta think. 

Hmmmm.

Powered by ScribeFire.

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.

Taking Advantage of BAs Because They Can

There are a lot of BAs who were working (and deserved) low six figure pay before Wall Street idiots did what they did. Most of us worked as consultants because that's where the cash was. Now we're seeing:

• Ridiculous job requirements/software backgrounds in areas other than Health Care, Insurance and Financial- those I can understand- specialized domain knowledge. But database cleaners? Portals? (everyone seems to be moving to SharePoint and this seems to be a real big deal requiring years of experience with the tool- right- you're telling people who can create custom Portals with dozens of interfaces and multiple layers with extensive User Profile functionality doesn't directly relate? Balderdash)l E-Commerce or Basic Business Intelligence? Gimme a break.

• 10+ Years of Experience: Who are these people? There wasn't any such thing as an IT BA in 1999, the concept was just starting to spread with the use of requirements documents (Use Cases). BAs back then were what we tend to call Financial or 'Real' BAs today- the ones who can look at market data and prepare forecasts and other magic stuff accountants and actuaries do. But can they describe how their PC is supposed to connect and how the User is suppose to work the actuary engines?
  

• Demand 6 months or less since the last job: I got a call from a recruiter yesterday- "Scot the job's a perfect fit with your background- what have you been doing since October 2008?" I said, "Looking for work." The recruiter said he was sorry, but the longest gap this company would accept is six months. I laughed, silently (yuh never know if the recruiter might do you some good later). I told him to tell the company I was researching and writing a book: How BAs Fit in the Agile Method. No dice. Well, Dice.com, but not for this job. I figure they lost a tremendous resource. Me.

• Demanding Salary Requirements or Back Salary Levels: I used to make a lot of money- at least as far as most of Chicago's Companies are concerned. They want all the ridiculous requirements and pay $20-$30 per hour. Now, I know I'm going to have to take a salary hit, but these HR people are filtering people out for high pay because they think higher paid people will leave when the economy straightens out. Um, genius, why wouldn't you want a bargain between now and then? If it were me, I'd hire the person, knowing that as long as salaries were low, I was getting a bargain and work the bejesus out of me then shake hands like a mench at the end. Nope- they'll hire a lesser experienced or newly minted BA instead. Is it any wonder some of these companies are in trouble??? I put either $5/year in the field (freakin' developers made the fields number text since my last job search) or leave it blank if I can. Mebbe I can tell them I'd take $45/hour with a smile and a sigh of relief and you'd have a friend for life.

And the silly HR keyword searches, uploading resumes created in Word and the parser screwing every little thing up. I'm sorry the HR people are being inundated- but they are filtering out some great people with superb skills and extensive experience. 350 resumes for a single position? When I was looking for people I would have killed for those numbers so I could get the best person I could.

And the Hiring Managers? Please. Why would you search for a new resource without the gig budgeted and approved? Why are you asking me questions that have absolutely not relevance to what you said the job was all about on the phone? Manhole covers? Why are you wasting your time and mine? I had to pay cash money to come here and talk to you- money I don't have because I make all of $317 a week unemployment.

You can't blame all of this on the economy. A friend and fellow BA twittered this: Why are there so many idiots working and so many really good people looking for work?

The system's broke. We need to fix it.

Powered by ScribeFire.

BAs in Transition

I feel like singing an old Bee Gees Song, I Started A Joke (which I can sorta do on my guitar). I wrote a blog about this sudden need for BAs to write Code. Before writing that Blog, I used to think requirements gathering and coding needed a Business Systems Analyst or Systems Analyst to do, and and far as I was concerned, those folks were worth the extra 10-20K a year.

I didn't realize this would raise so much thought in the LinkedIn Agile Alliance Discussion board (the link won't work unless you're a LinkedIn Member and are in the Agile Alliance- which is full of really good and really smart people).

The discussion is great because it raises my visibility (and visibility may = potential job) and good for you who comment (same reason, but you can scratch and bite and kick and scream, but I have to be gentlemanly and kind. It hurts.). It may also elevate the state of the art, which is never bad.

But the drift I'm catching is one that's bugged me for three or four years: What does the BA do in an Agile Project? I think I started to answer that question in a Blog earlier this week titled BAs, in an Agile Project?

And there are two ancillary issue floating around the Agile Ether and I name them here:

• The reason the BA role was created still applies. Even in Agile: translating jargon/goals and managing  expectations by identifying, documenting and testing requirements and business rules.

• There are two BA 'tracks' in IT- the Developer who wants the big bucks and become a Project/Product Manager (not realizing how little your actual hourly rate will be) and the Technical Writer Track- Writers who watched kiddie BAs grab fists of money. We said to ourselves, "I could do that." We read the Use Case Books, learned RUP/UML (artifact? gimme a break, how old do you really think I am?) and then read the XP, RAD and Agile books and talked amongst ourselves. Rhode Island isn't really a road and certainly isn't an Island (say Rhode Island out loud- it's an audio joke).
  

I don't think either BA background is better than the other- the Developer BA is more technically inclined and can handle Objects, Services and Web Applications better than the Tech Writer BAs. But the Tech Writer BAs have better business acumen (dunno why, but I think 'acumen' is a cool word), change management, client-facing and documentation skills. Both can abstract, both can write User Stories/Use Cases and other project documents (but the TW's documents will be more coherent, grammatical and prettier) and both can fill project voids as the SDLC runs its course.

The comments show that some folks have never had a BA on their team. That's a real shame because somebody still has to do all the things a BA does. Which usually means the Project Manager/Scrum Master (that ridiculous title- almost as stupid as my Six Sigma 'Green Belt-' these metaphors are sooooo silly) and or the Lead Developer have to do them. Which means a project is a Sprint rather than a Marathon and something is going to get short shrift. Kinda like my first bullet point? Some shops have come full circle.

I love Michael Duncan's comment that a waitress doesn't have to know how to cook- spot on Michael with a great analogy!

Powered by ScribeFire.

Do Business Analysts Need Computer Programmer Skills?

I've been reading the How Do you Get Business Analysts Domain Experience blog series from IT Career Coach since it started. The first one was cogent, intelligent and pretty much in line with my own thoughts about being without work for so long.

The latest and final blog, Do Business Analysts Need Computer Programmer Skills? is almost on the money. IT Career Coach argues the IT Analyst does need to have programming skills because a. that's what the market is demanding and b. the BA role has "evolved" to include programming.

Balderdash. Ptoooi. Wrong.

In a properly run project, the BA and the Developer are going to be needing every second performing their respective roles. Otherwise, dear reader, the sprints will extend, the iteration will be late and the implementation team (probably composed of the developers and the BA and the PM and the Infrastructure Team....) will get the code late.

These ads IT Career Coach is referring to are a bid by companies to 1. lower development costs by lowering salaries, 2. adding as many domain and application requirements as possible so their HR scanners don't have to work so hard and 3. forcing us to guess what the real job requirements are.

Do I think the blog's thrust is wrong? No.

An IT BA needs to know programming logic to write abstract use cases, user stories and specifications, which often contain pseudo code. In other words, to talk to the developers, the BA needs to be able use and understand phrases like 'loop,' 'data layer,' 'IDE' and 'COM.'

The IT BA needs to keep up on .Net, J2EE, SAP, J.D. Edwards, Ruby on Rails, Ajax and other technologies' capabilities for design, specification and testing. In other words, the BA needs to know, at the abstract level, what the technology can do, other the BA can't design or specify, much less set up a functional description of what should happen.

By the same token, how many of your developers can talk to the business side without a. raising expectations, b. creating misunderstandings or c. not understanding that business pushes the project, not elegance or the 'gee whiz' factor?

That's why Agile projects demand high level, experienced folks in key positions...like Developer, BA, Project Manager, etc. In a small to medium sized project, this isn't an issue. But in larger or off shored projects, Agile isn't known for scaling. It can be done... but a few Waterfall and Iterative practices needs to be added to the Project's Governance and Process- with Agile's means of revising things that don't work into things that do.

I'm thinking of getting a couple of SAP certifications. Then I might be able to find a job.

programming, business analyst, IT, process

Powered by ScribeFire.

BAs, in an Agile Project?

Books, websites and consultants are telling us to move to some form of Agile- and, once the consultants get a hold of it, it's going to morph- which it has. Since when is Scrum a method? It's a meeting and project management tool. ARGH!

Now, the Agile Manifesto says two things that I've never seen:

1. Business People and Developers must work together daily throughout the project.
   
2. Face-to-face discussion is the best communication tool we have.

I've not seen this happen- have you?

• Item: Business people seem to have overflowing plates and are too busy to allocate a fraction of time to a development project every day.
• Item: We're lucky if we get a user to a demo or five minute play session in the sandbox environment much less regular face-to face meetings.
• Item: When was the last time you saw a member of the business team actually write a User Story? A Specification? Comment on an existing Story or Spec? Thought so. The only good thing about a Waterfall Shop is the Stakeholder actually reads the Stories and Specifications. Badly, inaccurately, but they read 'em.
• Item: And who's had the business team member actually empowered to make real decisions? Not in a consultant-client governance project and certainly not in an organization that is, necessarily, a waterfall shop moving to Agile.

Enter the Business Analyst:

...the guy or gal the Agile Book Writers either ignored, blew off on a simple process flow diagram or forgot existed. Bad move, Scrum Master/Project Manager/Team Lead.

If you really have top developers who can pull requirements from users, you still need the BA to introduce them, set up the meeting, attend the meeting to translate the jargon on both sides and provide a written record of what happened to eliminate the finger pointing later.

If you don't have top developers and are heading smaller teams with your best and brightest, who's getting your requirements? You're wasting time and resources if you grab the requirements in a demonstration or from comments/issues generated from your sandbox environment. Oh yeah- the stakeholders and the end users loose faith in your DevTeam because they didn't get it right the first time (Agile takes a while to settle into everyone's mind). Once you've lost faith, you've lost the project.

Scrum or Stand Up Meetings

I learned this system at Pathfinder Development under the tuteladge of CTO Dietrich Kappe.

We're assuming a two week sprint schedule here. The BA is working one sprint or iteration ahead of the current development work.

Each day, the team meets in a Scrum or Stand-up meeting. Only the DevTeam and Design Team participate. The Business Team provides support and listens for status changes. Each DevTeam member answers these three questions:

• What did you do yesterday?
• What problems did you face?
• What are you going to do today?

The BA records the answers. The Project Manager and (to a lesser extent) the BA prepare an obstacles list and begin removing those obstacles.

Requirements Gathering

The first couple of days, the BA generates a proposed list of Features and Issues (Fixes) for a sprint. The BA gets preliminary approval from the business team, architect or lead developer and the project manager.

The BA then meets with Subject Matter Experts, end users and stakeholders to gather enough detail to write preliminary User Stories for the list. After they're written, the BA returns to make sure the stories and tests are accurate. Once the BA has preliminary approval, the BA writes a more detailed specification. It may include data maps, wireframes, interfaces, flow charts, step action tables- in short, everything the Developer should need to code the item.

The BA then presents the stories and specifications to the Stakeholder (to verify accuracy and need) and to the Architect/Lead Developer. This check helps the BA and the DevTeam Lead to:

1. Make certain each item is technically do-able.
2. Make a preliminary judgment on whether the item can be done within a single sprint or needs to be split into components.
3. Confirm dependencies.

Testing, Reading and Reviewing

The current sprint ends. The Agile Manifesto says Agile Projects are test-driven. The developer does the usual boundry and smash tests. Guess who does the Alpha testing? Me. I use the minimal tests in the User Stories to create scenario-driven Test Cases (and usually test scripts since 99 times out of 100 I'm going to add the script to User Acceptance Testing later). This is sort of the reason I usually handle issues management. We don't want the client/customer to see really ugly stuff.

One- three days are scheduled to allow the Developers to read the new User Stories and Specifications, ask questions and begin deciding how complex each item may be. The BA either answers the questions or properly routes them to the Business Team.

The entire team meets for a review session of the most recently completed sprint. The BA records Best Practices, Suggestions and Proposals for Change.

The Kick-Off Meeting

The new sprint starts with a Kick-Off Meeting. Each proposed Feature or Issue is brought to the table and the DevTeam can ask the Business Team or the BA questions. The DevTeam then assigns a complexity rating on each item. Ballpark hourly estimates are awarded to each complexity level and then everyone can see if all the items can be done in the time allocated. If it can, great, the developers start coding and the BA starts the next sprint's proposed list.

If not, the BA and the Project Manager negotiate with the Business Team about additions and deletions to the list. A proposed list is given to the DevTeam. If accepted,  great, we're off. If rejected, we re-negotiate.

Change Management and Scope Creep

Any changes made or requested during the sprint has to go through this process, at least informally, because the DevTeam is responsible for each item on the list. Idf the business team wants something new, something old has to go off the list. If the DevTeam is having a problem with an item, after root cause determination and proposed mitigation planning, the Business Team needs to make a decision on continuing or stopping development on that item.

Demonstrations and Communication

I've worked mostly 'distributed' Agile projects. I was with the DevTeam in our offices and the client/customer was somewhere else with the Project Manager. This sort of made me Assistant-Associate-Deputy-Vice Project Manager, doing what the PM needed done.

Typically, if we had a test environment, I create an e-mail list of all appropriate folks to tell them a. what's been changed and b. what the user should expect.

If there was no test environment (usually very early in the project), one of the developers will run a demonstration and let the demo meeting attendees play with the software.

I got all the issues, suggestions and complaints. I loved this part since Agile allows us requirement gatherers to ignore the bane of all BAs, IAs and Project Managers: Hidden Requirements. There are non by definition since the end user is playing with the actual product. That means we can change on a dime and make UAT Test Cases and Scripting easy.

Governance

1. The project needs to support the business. Gee-Whiz Stuff can either be pushed into the backlog or eliminated.
2. The business controls the functionality, prioritization and resource allocation.
3. The DevTeam designs, adapts or creates new business processes, researches technology and presents code to the business.
4. The DevTeam Leadership describes expected or potential outcomes from a decision as well as providing the business with options and a recommendation. The business is responsible for the decision (see #2).
5. Like any other project type, software development is controlled by time, resources and scope. If anything changes within a sprint, a release or an implementation, the business makes the decision.

Powered by ScribeFire.