Business Analyst – What Do They Really Do ?

Wrote this note to myself so I would not forget what it is that i’m supposed to do when i wear this hat. ‘This hat’ refers to the duties of an analyst of business problems. In the field of I.T., these people are the ‘big-picture’ thinkers and planners. They may, from time-to-time, live in an ivory tower and from that vantage point, they have a unique and, some would argue, a surreal view of the innards of a business. A really good business analyst should be able to do their thing without reference to anything more complex than a pencil and paper. Their investigations will lead them through a mountain of paperwork and a valley of obstacles. Their powers of investigation should surpass the inimmitable Mr. Sherlock Holmes, he, late of 221b Baker Street. From my deductions, Watson, they would possess powers of deduction beyond the mortal man. The principal points they should cover for any investigation would include :

=======> Project Start <================

===== terminology ===========

  • BPM – business process management
  • BPMN – business process model notation
  • BPEL – business process model execution language
  • Six Hats – De Bono’s approach to problem solving

======== initial phase =========

identify parties
identify their roles
identify key employees / stakeholders
identify subject matter experts
locate documentation
gather business records, reports, samples
gather operating manuals
locate and collect business guides, industry practices
identify and where necessary gather external information such as rules, guides, tax and regulatory documents

======== preparation =========

document project life cycle / scope of effort
analyze business records
analyze operating manuals
read business guides
examine external documentation
decide how to proceed

======= investigation ==============

conduct interviews (the rack is an effective tool)
key employee questionaires (apply thumbscrews where necessary)
elicit common domain knowledge
capture required info
document general systems designs
identify target processes
construct IT definitions
examine existing process documentation
map process workflows using TaskMap or similar tool
document data flows in and out for each process
identify steps within a process
produce missing process documentation

======= change process strategy ==========

decide how to proceed (Can you walk backwards too?)

conduct negative brainstorming sessions (Well, she would say that, wouldn’t she?)

review results (Right mates! Down the pub time!)

design change strategy

conduct brainstorming sessions (Ok, Boris, now remove the frontal lobe)

construct new / revised procedures
propose new / revised procedures

lead jad workshops (Light saber approach)
conduct rad workshops – iterative jad (Slay it again, Sam)
whiteboard walkthrus
gain concensus (Sign this, or granny gets it!)
amend proposed change
construct formal plan of action

========= develop approach (‘Hello Beautiful‘) ================

identify gaps of new functionality over existing processes
devise general systems revisions
identify and document changes to existing processes
develop alternate / additional processes (How bout we use pencils?)
design processes to close the ‘gaps’ (The ‘velcro’ approach)
recommend deleting obsolete processes (Tea trolley lady gets it)

==== acceptance (Yes,yes I’ll tell you everything – just not the thumbscrews!) ====

negotiate with clients / stakeholders (‘See this pistol?’)
gain consensus and agreement for signoffs from stakeholders
stakehold signoff
construct / agree time tables / milestones / deliverables / resource requirements for implementation
gain “buy in” from teams / participants

======== implementation ==========

deliver process modification proposals (Anyone seen my wheelbarrow?)
co-ordinate process implementation with systems analyst / development staff
recommend external help where appropriate
monitor budget vs actual resource constraints
guide implementation
produce feedback to implementation steps
develop UAT test plans where appropriate
perform UAT testing of new processes, and regression testing on existing processes
gain key employee approval
identify show stoppers (Bruce Forsyth, of course)

====== post implementation =========

develop acceptance test plans where appropriate
perform model office testing of new processes, and regression testing on existing processes
produce feedback to implementation steps
gain stakeholder approval
identify show stoppers

====== post acceptance =========

create user documentation
hold training sessions
assist QA assessments
coach users
perform training duties as required on model office environments
suport CRM staff

produce feedback on estimates vs actuals for resources, funding, manpower and timeframes

=======> Project Completion <================

=========== necessary skills =============

good analytical skills, keen eye for detail
thorough in nature
good conversationalist
converse well with others at all levels of organization
clear and concise
good comprehension skills
good presentational skills

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s