Monthly Archives: August 2014
Process. The collection of business requirements is an art unto itself that requires experienced practitioners and facilitators. Your business analyst should have a general familiarity with the problem domain, as well as good interpersonal skills. The analyst should come prepared with a “tool kit” of templates for methodology, process and deliverable work products. The process of eliciting requirements may take the form of written questionnaires, individual interviews, holistic brainstorming seminars, focused workshops or any and all of these techniques. Depending on the scope of work, you may have a single analyst or a whole analyst team sited on your premises. The results of the requirements elicitation process should be documented in work product templates, and classified according to the work methodology.
2 Comments | tags: Business Analyst, Business Requirements, Interviews, Problem Domain, Process, Questionnaires, Requirements Elicitation, Scope of Work, Templates, Workshops | posted in Business Analysis
“No matter what, the operating moral premise of information design should be that our readers are alert and caring; they may be busy, eager to get on with it, but they are not stupid. Clarity and simplicity are completely opposite simple-mindedness. Disrespect for the audience will leak through, damaging communication.”
—Ed Tufte
So, in my interpretation, the best way to avoid stupidity is for oneself to not be stupid in the first place. That is, stupid is as stupid does. Or, in other words, acting stupidly invites further stupidity.
Leave a comment | tags: Clarity, Communication, Information Design, Simplicity, Stupidity | posted in Hearsay
Preparation. First, it helps if you are prepared. You already understand the general need or issue that your business must address. Establish your time constraints and budgetary limits; and be ready to discuss those with your business analyst. If you are unsure of the size of the project, commission a smaller feasibility study or situation analysis to examine the general scope and solution parameters. Draw up a contract that defines the work to be delivered, as well as the project parameters and constraints. Also, compose a mutual nondisclosure agreement and sign it with your analyst. Additionally, give your business analyst access to your staff members and their explicit cooperation.
Leave a comment | tags: Budget, Business Analyst, Contract for Services, Feasibility Study, Nondisclosure Agreement, Preparation, Project Constraints, Scope, Situation Analysis, Solution Parameters, Solutions, Time & Budget, Time & Money | posted in Business Analysis
But what, in general, should you expect from a business analyst whom you hire? You yourself set the overall expectations, of course. You already know the outcomes you desire, even though you may not understand all the implementation details. You might also need an objective validation of your business strategy. Knowing your expectations, the business analyst can then begin activities to meet your expectations. For convenience, these activities are divided into three areas: preparation, process and performance.
Leave a comment | tags: Business Analyst, Business Strategy, Expectations, Performance, Preparation, Process | posted in Business Analysis
The business analyst job description is very broad. It covers any number of tasks ranging from collecting smartphone customer preferences to designing major IT data centers. An analyst might seek the causes of poor business unit performance, or map the integration of major new operations software. Generally speaking, business analysis focuses on gathering business requirements and then proposing solutions to meet those requirements.
Leave a comment | tags: Business Analyst, Business Requirements, Integration, Performance, Solutions | posted in Business Analysis
Transformation is not complete until each task has been executed AND verified. Verify each task independently based on your same requirement statements. Verification planning and execution can easily eat up 60% of your transformation budget, so be careful. Verifying task outcomes is not necessarily about massive regression testing programs, but more about selectively performing the correct tests.
When you engage a business analyst to advise you on a transformation, what should you expect? What work will be performed and what tangible work products will you receive as the result of that work? That’s the next topic.
Leave a comment | tags: Budget, Business Requirements, Execution, Planning, Testing, Verification | posted in Business Analysis, Business Transformation
“Life is what happens to you while you’re busy making other plans.” — John Lennon (1980)
“A life without plans results in aimless inefficiency.” – Waite Phillips
“Such plans got altered by events as often as not, but I’d found that no plan at all invited nil results. If all else failed, try plan B.” — Dick Francis
“Life is what happens to us while we are making other plans.” — Allen Saunders (1957)
“Life was a process of finding out how far you could go too far, and you could probably go too far in finding out how far you could go.” – Terry Pratchett
Leave a comment | tags: Living, Planning | posted in Hearsay
Each requirement statement can be turned directly into a task statement for inclusion in the execution phase plan. Insert your task statements into a project plan, determine which tasks are subordinate to the main ones, establish task interdependencies, and link the tasks together for orderly completion. Then estimate task completion times with costs, and assign your change agent resources to perform them.
Leave a comment | tags: Business Requirements, Change Agent, Execution Phase Plan, Interdependencies, Project Plan, Requirement Statement, Task Statement | posted in Business Transformation
Jump the Spark! 