The BA Heartbeat

A software business analyst (BA) has one simple mission: Maximize software value to the customer.

This breaks down into smaller goals, of course, like conducting interviews, writing clear requirements, communication, facilitation, etc. The BA heartbeat, however, needs to be crystal clear so that we don’t get lost in all the project noise: Represent the customer.

Developers want to write great software, testers want to deliver quality products, and project managers want to hit deadlines and budgets. Others surrounding the project have their own missions and motivations, but they are all different from the BA. Sure, you can argue that the entire team should be focused on the same goal, but that’s corporate speak that doesn’t reflect the nuances of how team roles differ.

Every day the BA shoulders the responsibility of translating customer pain and desire into prioritized actionable requests that a software team can efficiently understand, design and deliver.

We patiently endure hours of meetings, ubiquitous customer desires to design things and the tedious writing of feature definitions. We counsel and cajole and pry into the mysteries of our customer’s business until we can nearly run it for them, so familiar are we with the functional operations.

We forge a bond with our customer that both we and they depend on. Through the laughter, the frustration and the smell of dry erase markers we carefully stitch together a relationship that becomes a conduit connecting need with capacity.

When someone on our team suggests that the customer does not need something that we have painstakingly defined, we suffer the setback emotionally, buffering the customer from this techno-rejection and we fight for them, wielding the best business case we can make so that they can prevail in absentia.

We bring perspective and balance to the tug-of-war that is software development. We strive for the ideal solution while staying rooted in the reality of our constraints.

We track every change flowing from the customer’s dynamic world into the tower of the software genius, minimizing the impact of change where possible and accelerating understanding through diagrams, narrative, emails, knowledgebase updates and *gasp* meetings.

In the end, when the bug lists are clean and the stress of the rollout is a distant memory, we take satisfaction in having delivered on the trust our customer and our development team placed in us — a charge to deliver the most valuable software we could, given limited time and money.

If you recognized your own heartbeat in the description above and you are not working as a business analyst, maybe you are carrying the wrong title.

Convert PDF to Word

Convert PDF files and paper into editable documents

Don’t retype information! Convert PDF to Word documents. Convert paper to Word documents. Use this fantastic optical character recognition software to reduce work and save time. It will even convert pictures into text and HTML to text. Have a slide presentation you want to write up? Convert Powerpoint to text and save cutting and pasting. Achieve new levels of productivity by eliminating the manual reproduction of documents. Re-use pictures, clip-art, graphics and charts within documents. Convert static images into documents that can be edited and searched.

Highlights

  • Convert paper, PDF, and images to documents like MS Word

  • Most accurate converter – over 99%

  • World’s best-selling OCR program (Optical Character Recognition)

  • Includes PaperPort 11 – desktop document manager

Time-saving Impact

Avoid retyping paper, PDF documents, or even pictures of text!

Learn more…

Projects don’t fail

Projects don’t fail. People kill them.

A bad project is put down like a vicious animal that threatens the children. Ok, actually stakeholders cancel them to relieve the pain. But what makes a project bad? More importantly, how can you keep your project from becoming rabid? This is not about blinding charts or brain-numbing statistics. We avoid tasks that are critical to our success for very simple, gut-level reasons.

Have you ever climbed a ladder to work on something like a light fixture, only to realize that you need another tool? I have. Why? Could I not take 30 seconds to think through the tools I might need up there? Am I not clever enough to use a bucket or canvas bag to put them in for a single trip?Let’s be honest. I didn’t make just one trip down and back up the ladder – I made several. Why do I do that?!

The answer is amazingly simple… I’m impatient. I want the instant gratification of “making progress” on this task and any semblance of planning won’t give me that. It feels like a delay. So up the ladder I go with a phillips screwdriver. Flat screws? Who uses flat screws any more? Oh yeah, my house is 25 years old.

When was the last time you rushed out the door and forgot the papers for that important meeting? Your umbrella on a rainy day? Your car keys?! It happens. We’re so focused on the destination that we forget about the process that will get us there.

Good software, like so many other things, requires planning. A little clarity of thought — and we all know this — prevents huge problems later in the game. We don’t do it because we can’t wait and we mentally skip ahead to the desired result.

What happens? The project runs off the rails. The project is full of rework. Users are angry about the project taking so long. The project becomes an anxiety-ridden, evil thing that needs to be put out of everyone’s misery. Eventually a new consultant comes along who says “Where is your blueprint for this project?” and everyone goes “Duh!”.  And the project starts over – this time with delayed gratification (planning) built in.