Reinventing a pivotal role for IT

The Agile family of development methodologies is pushing business analysts into a new role, and the coming IT transformation is pulling them into it as well. The role? Analyzing the business, not the software requirements.

Agile isn’t a particularly new topic. It is, however, a particularly misunderstood one, thanks to far too many attempts to turn it into a collection of recipes — a process, when everything about Agile screams practice.

Here’s Agile in a nutshell: high levels of informal contact between developers and business users, paired with incremental delivery. If a project works this way, it’s using an Agile methodology. If it isn’t, it doesn’t matter if you’re following every step described in the Scrum, eXtreme, kanban, or LSD (“Lean Software Development” — and who coined that sorry acronym?) manual. You aren’t being Agile. You’re just painting by numbers.

Agile has become important for a seldom-admitted reason: Most business logic is simple (with one exception that we’ll get to it in a moment), but the challenge lies with user interfaces, which aren’t just complicated, but as matters of aesthetics, aren’t even verifiable.

Most of the effort that companies put into business applications goes into the user interface — into data management screens that retrieve or accept data, subject as many data elements as possible to validation logic, then update a database.

As a result, maximizing the usability of the user interface is a lot of what developers have to do. In fact, you hope that’s where most of the effort goes, because if that isn’t the case, it goes into system interfaces that have gotten out of hand. The system interfaces are where business logic most often gets seriously complicated — the exception mentioned above. The more they’re a collection of one-off programs, the worse it is.

While not everyone in IT considers investments in the UI to have a big enough payoff to warrant the required effort, it does dominate most application development projects. And given that a bad UI seriously impairs end-user effectiveness, there’s no substitute for picking up the phone, calling Fred in the Order Entry department, and asking him to come on down and look at what you have in mind.

But don’t stop there. Do this frequently. And don’t call in Fred alone; Fred and Susan might not agree on what will work the best.

Additionally, don’t just ask them to come on down. Asking them if you can come up so that you can see what they do is a pretty good idea, too.

It’s the ratio of UI programming to business-logic programming that’s made Agile important. Agile is reducing the importance of heads-down programmers who work from a specification and increasing the importance of programmer/analysts who can do the complete job.

It’s also half the story of why the business analyst role has to change — because developers no longer need translators when they have direct conversations with end-users.

The other half, as we’ve been discussing the past few weeks, is what the business needs but hasn’t been getting: help figuring out how to make things run better, including but not limited to how automation can enter the picture effectively. (See “Bad news for traditional techies: There are no IT projects” and “How to become the new business analyst needed in IT.”)

What does one need to know to become a successful “new business analyst” in today’s IT? We might as well choose a title to go with the new role, and as NBA sounds like a position where altitude is a bona fide occupational qualification (BOQ), we’ll use internal business consultant, or IBC for short.

The ABCs of IBCs

As is so often the case, there’s no shortage of technique out there that IBCs can profit from. And technique matters, once you’ve mastered the fundamental concepts. We’ve already hit the key concepts:

• IBC concept No. 1: Value

  What every project has to improve or there shouldn’t be a project — namely, revenue, cost, and/or risk.
• IBC concept No. 2: Optimization What “better” means with respect to a business process or practice — some combination of fixed costs, incremental costs, cycle time, throughput, quality, and excellence.
• IBC concept No. 3: Process vs. practice Understanding the difference between processes and practices — that processes extract as much knowledge and judgment as possible from inside employees’ heads and puts it into the process design, while practices rely on the knowledge and judgment that’s inside each employee’s head — is essential.

One other view of the difference between processes and practices: Processes generally improve quality while diminishing excellence because simplification and standardization are the most cost-effective ways to reduce variability. Practices, in contrast, generally increase excellence while making quality more expensive, because when no two work products are exactly alike, the only way to achieve quality is through inspection. Worse, “excellence” includes aesthetic criteria, which makes inspection itself a practice.

IBC skills and techniques — the DEFs Here are three of the most important entries in the list of techniques IBCs must master:

IBC technique No. 1: Facilitation. If an IBC can’t get people to talk with one another, understand what one another are trying to say, and bring them into some semblance of consensus, nothing else matters. Facilitation is top of the list for any internal business consultant.

When most people think about facilitation, they think about running meetings. That by itself isn’t a small topic, and no matter how good you are at it, there are always ways to be better. It’s a skill in which IBCs need to excel.

But meetings aren’t the entire subject. Facilitation is helping people listen, inform, and persuade each other, and that goes beyond meetings. For example, it includes getting developers and end-users to interact frequently and informally. (See Agile above.)

IBC technique No. 2: Process (and practice) management. Most of an IBC’s work will consist of helping managers throughout the company improve the effectiveness of their processes and practices. It will never happen if those managers don’t understand how to manage a process or practice, as opposed to managing the work itself.

As an internal business consultant, you’ll have to help them through what for some will be a radical change in how they think about their responsibilities. If you don’t understand the subject yourself, let me be the first to wish you all the best of luck. You’ll need it.

IBC technique No. 3: Culture change. While practices, including the single-actor practices we’ve been promoting in this space, are going to get increasing attention in the world of business, there will still be plenty of situations where process should be in the driver’s seat. “Should be” will never turn into “is,” though, if employees don’t share a process culture — one that has each of them thinking in terms of process and process improvement.

In America, in particular, this isn’t a natural culture because other names for “process” are “bureaucracy” and “conformity.” Process means following the instructions. It means coloring inside the lines. It simply isn’t as much fun as the alternatives.

Whether it’s better for the business really doesn’t matter if it’s against the business culture, which it almost certainly is unless “the business” — that is, you — hasn’t expended considerable thought, effort, and time building acceptance of process into it.

It’s never easy. It happens slowly, so progress is hard to see. There’s never an end to it.

You’re the adviser, not the doer — better get started.

This story, “Reinventing a pivotal role for IT,” was originally published at InfoWorld.com. Read more of Bob Lewis’s Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.