A white paper sharing some knowledge on different methods for business process validation.

All companies conduct projects to improve their processes or products, or to develop new ones. These projects can situate in any part of the company including HR, Finance, Facility Services, any business units and IT departments. One of the common elements of all these projects is a set of business requirements, which is supposed to be realized as the outcome of the project. When I say ‘project’, I mean any organized work that includes initiatives, programs, services, product development and alike.

We have a specialty and a role called Business Analyst (BA). This role is supposed to manage and execute requirements elicitation and analysis as well as to communicate analysis and requirement review results to those who have to implement them. We have special education programs and certifications where Business Analysts are trained on methods of gathering and analyzing requirements. Actually, I have never seen specifications for different training for a Business Analyst in the business domain versus technology but it is a minor obstacle in the context of this white paper.

Beside business requirements (BR), there is one more common element across all types of projects – it is a statement of business needs called ‘project objectives and goals’ (POG). Ideally, BR should be in sync with the POG but the methods of requirements elicitation that are taught to Business Analysts do not guarantee such an integrity. The synchronization between them is addressed as an intangible task associated with the Business Analyst’s skills, experience and creativity.

Please login to continue reading or download this ebook by Michael Poulin.