Leadership & Management

Can the same business rule be enforced differently in different contexts? The answer – an important one for re-use of business rules – is yes. This article explains. It also outlines what business analysts need to know to specify contexts of enforcement for a business rule effectively.

When you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking - I know this from experience. It's like driving a racing car - you have to push close to the limits but any error can throw you completely off the track.

How far can you take requirements elicitation in a project? Clearly, no one knows the ultimate answer. It would be very costly (if even possible) to capture all requirements, assumptions, rules, relationships, and hidden connections associated with a solution being built, so how do we know when we are done?

Many organisations hire external consultants with no experience of their business to shape strategies and propositions. In doing this, they are unconsciously ignoring internal resource with exactly the same skills but additional knowledge and experience of the business – namely their Business Analysts. BAs have a unique skillset, offering holistic insight, analysis and recommendations.

In many organizations, Centers of Excellence, PMOs (Program/Project Management Office) and PQA (Process & Quality Assurance) teams use a variety of manual techniques to vet documentation that are time consuming and manual; leaving room for unintentional mistakes, missed steps and delays in catching errors with regards to governance and best practices. In the spirit of delivering the project on time and under budget, many times these quality review processes are rushed and reduced to cursory checks. Like ensuring documents exist with the right naming convention, rather than reviewing the internal contents of documents and ensuring the contents are of high quality.

I believe the Problem Pyramid™ provides the appropriate structure for guiding effective business analysis, both for initiating and carrying out projects, whether for what BABOK® v2 calls projects or for topics that truly fit within Enterprise Analysis.

Yes, the world is flat, and the reality of today’s global economy is that business analysts (BA) from all corners of the earth – North America, South America, Europe, the Middle East, Africa and Asia Pacific – often work with one another. But they don’t always understand how business efficiency is impacted by the comprehension of their inherent differences. There are fundamental philosophical and behavioral differences between professionals across the world that impact business success. If BAs aren’t readily capable of adapting to the environment in which they work, they are most certainly setting themselves up to fail.

For many business analysts (BAs), the IIBA Business Analysis Body of Knowledge (BABOK®) Knowledge Area that is the least familiar is Enterprise Analysis (EA). In some ways, this may be a mixed blessing. On the one hand, the BABOK® Version 2 (v2) EA area describes important topics and techniques that BAs should be conversant with: defining business needs, solutions, business cases, and project initiation. On the other hand, I have issues with the ways BABOK® v2 treats these topics, especially how it portrays business needs and considers defining them as only part of EA.

In I.T., are we really spending too much time on "maintenance"?  Within any systems development organization, there are but three types of work effort: new systems development, maintenance, and modification/improvements. A mature development organization will spend approximately 5% of its time on new development, 10% on maintenance, and 85% of its time on modification/improvements.

Business Analysis is a term that covers a wide range of different disciplines, which has grown in scope over the past 10-15 years. BAs can become involved in a variety of different activities, depending on the organisation and the particular project that they are working on – these can range from very technical to very business focused activities.  So if you're working as a Business Analyst, or working with a Business Analyst, what can you expect?
 

“I may not know much about art, but I know what I like”. This famous punch line to a Monty Python sketch about a fictional conversation between a disgruntled Pope and innovative Michelangelo (who wanted extra disciples, multiple messiahs and a kangaroo in his first draft of the Last Supper), can also be seen to satirize our own modern fixation with creativity, feedback and the idea that ‘the customer is always right’.

Whether it is in software development, business analysis, portfolio management or business strategy, everyone wants to be Agile - and nobody wants to admit they aren't Agile. But what does it really take to be Agile? What is the state of Agility like?

Like it or not, every business analyst will have to stand up in front of a group and present. The group might be your business clients, the project stakeholders or just your fellow team members but for many people, one of two things will happen: it will frighten the life out of them OR they’ll umm and ah their way through, sending the audience to sleep.  Why is this so?
 

If you work with other business analysts, you are fortunate. Together with your colleagues, you can experience greater effectiveness than you could have achieved on your own.  Additionally, your colleagues can provide you with a diverse and convenient pool of expertise from which to draw.

What we have witnessed in the last 25 years is a series of programmes of change failing to achieve their intended outcomes. Customer Care, ISO 9000, TQM, ABC, BPR. All the research and experience show that the latest panacea does no better than its predecessors. Over and over again improvement programmes are thwarted by commonly-known but illusive forces. The problem is labeled as ‘organization culture’, which typically leads to rationalizations like ‘change takes time’, or ‘each programme is an element in the total change programme’.

Rationalizations prevent learning.