Bottom line: Traditional "roles and responsibilities" blur accountabilities and authorities. Even if boundaries between groups are clear, the wrong kind of language can hamper performance. A better appoach is to define jobs as internal lines of business.

Here's an example of the challenge of role clarity:

The Applications Development Group

An IT organization recognized that its applications-development process was very confused.

Ostensibly, Aaron ran the applications development group.

But "business analysts" in Mark's group worked with clients to define requirements and develop high-level designs.

And "project managers" reporting to Jay (the PMO) were responsible for large strategic projects, as well as project management for Aaron and Mark.

CIO
|_ Aaron, applications engineering
|_ Mark, business analysts
|_ Jay, project management office (PMO)

There was a lot of friction, so the CIO instructed them to work out their respective "roles and responsibilities." The answer they came up with was something like this:

• Aaron was responsible for applications-development methods. Jay decided project-management methods. They promised they knew the difference.

• Mark's analysts were responsible for specifications and high-level designs.

• Mark then handed projects off to Jay's project managers (if they were big and "strategic") or to Aaron's group (for smaller projects). Jay and Aaron were both responsible for project delivery.

• Even for the big projects that Jay's PMO delivered, Aaron had a role. He supplied engineers to do most of the work.

• Aaron retained responsibility for maintenance and support of applications once they were deployed.

Accountability for Results

Confused? So was the CIO. He asked a simple question: "Who's accountable for project success?"

Mark looked away; it wasn't his problem, even though his analysts controlled two critical steps in the process.

But both Aaron and Jay raised their hands.

No one group was accountable for the delivery of complete solutions (in their case, applications).

Disempowerment

To make matters worse, neither Jay nor Aaron could control the resources they needed to meet their commitments:

• When business priorities changed (as they often do), Mark would shift his business analysts to a hot client request, causing Jay's and Aaron's projects to fall behind schedule.

• Jay drafted engineers out of Aaron's group to staff his big projects, leaving Aaron without a sense of how many people he really controlled.

• Sometimes Aaron would pull developers off one of Jay's projects to deal with urgent maintenance items, putting Jay's projects in jeopardy.

• Aaron's engineers (responsible for small projects) got little support from Jay's PMO staff who were busy with their big projects. So Aaron's project-management capabilities remained weak.

They were all set up to fail, without the authorities they needed to fulfill their accountabilities. And their overlapping accountabilities invited finger-pointing.

Aaron was especially concerned. He was held accountable for the long-term performance of applications. But he couldn't control all the decisions that impacted the quality of applications. Mark's business analysts made high-level design decisions, and Jay's project managers ran some of the projects.

Innovation suffered too. Whose job was it to explore new technologies, vendor packages, and development environments, and to develop technology strategies? It seems that should be Aaron. But his staff were farmed out to Jay for big projects or busy with small maintenance requests. Aaron said, "As an applications development manager, I am purely tactical."

The Clients' View

This lack of individual accountability for results wasn't just evident to the CIO. Clients didn't know whom to talk to for what.

Where were they to go to discuss their projects? First, it's Mark. Then, if it's less than 40 hours, they were directed to Aaron's development group. Anything over 40 hours was deemed a "strategic project" and clients were directed to Jay's PMO. But how can clients know how long it will take IT to fulfill their requests?

Whose job was it to keep clients informed about their applications? Aaron was anointed the primary client interface, but he didn't always know what Mark's business analysts or Jay's project managers were doing.

All three groups felt they ought to communicate directly with clients and attend project-related meetings. But none saw the big picture. As you might expect, client communications remained spotty and disjointed.

More Detailed Roles and Responsibilities (RACI)

When problems persisted, the CIO demanded better role clarity. The three managers agreed to try a process called "RACI." In an interactive workshop, they agreed on their respective "Responsibilities, to whom they were Accountable, with whom they had to Consult, and whom they kept Informed" (called the RACI model).

They went over each step in the development process, and decided who played each of these four roles.

This gave a clearer sense of what they should and shouldn't do. But it didn't define a single point of accountability for project success (the "one throat to choke").

In fact, nobody was accountable for results at any step in the process. They'd defined their jobs by tasks (what they do), not deliverables (what they produce).

Down-side of Jobs Designed Around Tasks

When jobs are designed around tasks, lots of problems occur:

• People execute tasks. They're not asked to think creatively about how to attain intended results. This wastes the insights of those in the best position to know the best way to get things done. And tedious jobs lead to boredom and degrade morale.

• Each group sub-optimizes (and perpetuates) its steps in the current process. And if the tasks don't add up to the intended results, nobody is in a position to fix it.

• The boss who coordinates all the tasks must plan every project in detail, monitor everyone's work, and adjust tasks when things go wrong. Busy managing tasks, the boss doesn't have time to think about the big picture or the future.

• If a project requires a new task, it may be nobody's job and hence the task may not get done. Of course, this puts the ultimate deliverable in jeopardy.

• When you sort tasks among groups outside the context of responsibility for results, there's nothing to stop you from accidentally separating accountability and authority, which disempowers staff and sets them up to fail.

• When disempowered people interact with customers, both parties will be frustrated. Customers will ask for results that task-focused staff are not able to offer. And staff will feel badly that they can't satisfy their customers.

• There have been cases where people believe they've done enough if they've put in the required hours and completed their tasks, whether or not the job is done. They go through the motions, without caring (or even knowing) whether those motions add up to the intended results.

• More broadly, roles and responsibilities don't define accountabilities for entrepreneurship -- for improving methods and tools, sorting out processes and relationships with peers, exploring emerging technologies, selecting and managing vendors, and developing strategies. It doesn't appoint leaders responsible for managing today's business and for planning tomorrow's.

This all adds up to unhappy clients and staff.

Who Sells What?

The truth is, organizations don't make money by going through the motions. They make money by producing results.

You can sort tasks in excruciating detail, and you still won't know who's accountable for delivering the organization's products and services.

The alternative is to define jobs based on the products and services people produce, not what they do to make them. In a business-within-a-business (BWB) organization, the boxes on the organization chart (groups) are defined as internal entrepreneurships.

Here's how it works:

For every project it's easy to know who's the prime contractor -- the one and only group that's in the business of selling that particular product line. That prime contractor is completely accountable for delivery of the project. Of course, he/she also has all the needed authorities to run the project.

If a prime contractor needs help, he/she can subcontract with peers for their products and services. And subcontractors, in turn, may "buy" help from others. The process of sorting out the prime and all the subcontractors is termed a "walk-through."

This is how the real world works. Your local grocery store subcontracts to distributors for inventory and to utility companies for power and water, but it's still fully accountable for having the right products available to you at fair prices.

This same dynamic, which works so well in the real world, can be employed within organizations.

By the way, dividing up results is actually a lot easier than sorting tasks. The list of an organization's products and services is far shorter than all the tasks people do and roles they play.

Applying the BWB Approach

Let's try this business-oriented approach in the IT organization described above:

Aaron is in the applications business. He's accountable for the entire portfolio of applications. That's that.

But before Aaron can sell an application to a client, the client has to be clear about exactly what he/she wants to buy. So, the client may get help from Mark's business analysts. Mark's group produces requirements definitions, not product designs (not even at a high level, since design is an engineering task and his doing so would disempower Aaron).

Once requirements are clear, Aaron delivers technical options, and then applications. In fact, he produces anything requiring excellence in applications engineering -- a repair, an enhancement, even major strategic initiatives. He's the single point of accountability for all applications.

Jay is an expert in project management, but that doesn't give him the right to take over Aaron's projects. Jay sells project plans, training, and project facilitation services. But whether or not Aaron's engineers use Jay's PMO as a subcontractor, they're still accountable for delivering projects, big and small.

Everybody knows what they produce, for clients and for one another -- i.e., who the prime contractor is, and what subcontracts with peers are needed. So roles and responsibilities (and hand-offs) are clear.

As to process improvements, every group is responsible for its own internal processes since it's accountable for producing its products and services. In addition, the prime contractor looks after the overall project and is responsible for teamwork and process improvement (coordination of his/her subcontractors) at the project level.

The BWB approach also makes clear who's responsible for innovation in each business (e.g., strategies, new products and skills, emerging technologies). Whether a group sells its products and services to clients or to peers within its department, it's responsible for running a business that's reliable, good value, and innovative. So, everybody keeps their own skills, methods, and product lines up to date.

"Abandon the cookie cutter roles and responsibilities in favor of deliverables. Much more satisfying from an employee standpoint."

Wanda DiPaolo, EQT Corporation

How to Know What Businesses You Own

The science of structure provides a framework of all the lines of business that exist within any organization. That can provide an objective way to define the business(es) under each group in your organization.

In just one workshop that begins with training in that framework, your leadership team can discuss and agree on the lines of business under each of them.

Translating your job descriptions from "roles and responsibilities" to lines of business is a powerful investment in your organization and your staff. In addition to clear individual accountabilities and reliable project delivery, the BWB approach builds an organization that's empowered, flexible, customer focused, entrepreneurial, team-oriented, and innovative.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....