How to Define Roles and Responsibilities for Maximum Productivity

The development process was very confused….

Ostensibly, Aaron ran one of the applications development groups in this IT shop of 200 staff. But “business analysts” (BAs) in Mark’s group determined requirements and high-level designs. And “project managers” reporting to Jay (the PMO) took control of large development projects, relegating Aaron’s development group to a simple body shop.

I asked who determines requirements? All three managers raised their hands.

Who’s accountable for project delivery? Aaron and Jay both raised their hands. Mark shrugged; it wasn’t his problem, although he controlled a critical step in the process, one that could make or break project delivery.

Staff stepped on each other’s toes and tensions arose as people contended for control of the development process. And when clients asked who was the single point of contact for their applications projects, the answer from IT was muddled. George, director of applications development, recognized that he had to straighten out this mess. So he set about to define roles and responsibilities.

Traditional Roles and Responsibilities

Looking around for help, George found a process that seemed plausible. In an interactive workshop, his managers 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.

In other words, George and his managers tried to clarify who does what. Then, they believed they could define the hand-offs (where the output of one step became the input to the next), and they’d have resolved the confusion.

The answer they came up with was something like this:

Mark was responsible for the definition of the systems-development life-cycle method (SDLC). Jay, on the other hand, defined the project-management method. They promised they knew the difference.

Aaron and the other development managers retained the primary relationship with clients for their applications, and they determined high-level requirements. Then, Mark’s business analysts were responsible for detailed requirements definition and high-level designs.

The business analysts would hand the project off to Jay’s project managers (if it were over 40 hours) or to Aaron’s developers (for smaller projects), who’d be responsible for project management—including scope, project planning, schedule, budget, resource management and risk management.

Even for the big projects that Jay managed, Aaron would supply developers who would do the detailed design, coding and/or package integration.

And of course Aaron’s development group would retain responsibility for maintenance and support of their applications.

Confused? Me too!

And while staff had a better understanding of what they should and shouldn’t do, staff and clients alike remained confused as well.

Who Runs This Business?

Who’s responsible for project delivery? Jay accepted responsibility for big projects, and Aaron for small ones. But they couldn’t control the resources they needed to get the job done.

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. Or Aaron would pull developers off one of Jay’s project teams to deal with an urgent maintenance item, putting Jay’s project in jeopardy.

Aaron’s developers, responsible for small projects, got little support from Jay’s PMO who were busy with their own projects, so their project management skills remained weak. Overall, big and small projects alike continued to suffer delivery problems.

Well, you might say that a bit more work on resource planning and governance could solve these problems. But there were deeper issues.

Where were clients to go to discuss their requirements? If it’s less than 40 hours, they were directed to Aaron’s development group. Anything over 40 hours was deemed a “project” and clients were directed to Jay’s PMO. But how can clients know how long it will take IT to fulfill their requests? They just wanted someone to talk to. Confusion remained.

Clients complained that IT was unresponsive and slow. But whose job was it to fix that? Mark decided the SDLC that slowed projects (perhaps for good reasons); and Jay decided the project-management method (that also slowed projects, again generally for good reasons). Meanwhile, all of them shared responsibility for the overall development process, but none had the power to fix it.

Whose job was it to keep clients informed about their applications, or to attend client meetings? Aaron and the other development managers were anointed the primary client interface, but they 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. As you might expect, client communications remained spotty and disjointed. Who’s responsible for the quality of a project? Jay’s project managers made key decisions that framed big projects, but Mark’s business analysts made some design decisions and Aaron’s developers were responsible for detailed designs. The answer was: No one group had overall accountability for the quality of results.

More broadly, who’s responsible for the long-term integrity of the applications? Clearly Aaron and his fellow development managers were held accountable. But they couldn’t control all the changes to their applications. They felt set up to fail, without the authority they needed to deliver their accountabilities.

Whose job was it to keep the IT product line up to date (exploring new technologies, vendor packages and development environments) and to develop technology strategies (like service-oriented architecture and object-oriented modularity)? On the surface, Aaron and the other development managers were responsible for their applications, but their 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.” No one short of George, their common boss, was in a position to drive innovation.

After all their work on roles and responsibilities, many critical problems remained unresolved.

Who Sells What?

You may sort tasks among groups in excruciating detail, and you still won’t be able to answer the question, “Who’s accountable for results?” And when you sort tasks 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. The traditional “roles and responsibilities” approach to job definition is flawed in that it defines what people do, rather than what they sell (whether or not money actually changes hands). It doesn’t determine who owns the business of producing applications and related services, or what specific products and services they produce.

If you’ve been following Beneath the Buzz, you know I always turn to the business-within-a-business paradigm (BWB) for guidance. What would you do if each group were a business chartered to sell products and services to peers within IT and to clients?

You’d define jobs in terms of the business each group is in—that is, job descriptions would define what products and services staff sell, not what they do to make them. Then, you can look at any project and 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 authority 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. This is how the real world works. Your local grocery store subcontracts to distributors for inventory and to utilities for power and water, but it’s still fully accountable for having the right products in stock and available to you at fair prices.

This same dynamic that works so well in the market as a whole can be employed within organizations.

Applying the BWB Approach

Let’s try this BWB approach out in George’s applications development organization.

Aaron, the development manager, could be given the applications business (or a piece of it, as defined by a specific suite of applications). If you want to buy anything related to his applications—a new solution, an enhancement, or a repair—Aaron is your man. Clients know where to go for help, and they have a single point of accountability for all their projects.

Aaron’s developers are the primes and wholly in control of their projects. They may subcontract to Mark’s business analysts for a requirements analysis if clients’ needs aren’t clear.

Jay may have the project-management office. But that doesn’t make him a project manager who’s in control of Aaron’s projects. If Aaron’s developers want help on big projects, they may “buy” services like project planning or training from Jay’s PMO. But Aaron’s developers are still the project managers for their applications projects, big and small.

As prime contractors, applications developers may subcontract for many other things as well, like logical data models, network and server expertise, technical writing, and installation into production (including physical data modeling). Like the grocery store, they buy from peers just what they need for each project, while retaining accountability for the end result.

Benefits of the BWB Approach

Through subcontracting with peers, teamwork automatically flows across the entire organization. Since people only buy what they need, teams comprise just the right people contributing to each team just the right deliverables at just the right time.

This is a far more effective approach to teamwork than vague words about “partnership” and the “all for one, one for all” spirit in which everybody steps on everybody else’s turf and no one is really accountable for the end deliverable. In the BWB approach, individual accountabilities are clear, as is the chain of command.

Resource management and strategic alignment also become more reliable. Clients determine priorities when they decide which projects to fund. Once clients buy a project from the prime contractor (e.g., a developer), the prime contracts with any needed subcontractors. These internal contracts represent commitments that are not to be broken. Instead of each manager independently setting priorities for his/her staff, clients’ priorities automatically ripple across the entire IT organization.

Note that the challenge of project management gets a lot easier in a BWB organization. Instead of one person trying to direct the work of an entire project team, the prime contractor simply subcontracts with peers for sub-deliverables. Then, the subcontractors manage their portions of the project. Since everybody is a project manager for their own deliverables, the job of prime contractor no longer requires an individual with super-human project management skills trying to direct the work of every individual on the team.

With this businesslike approach, accountability and authority always match, the essence of empowerment. Whether you’re a prime or a subcontractor, you are accountable for your deliverable and empowered with any authorities you need to produce it (including the right to buy help from others). 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 at that 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 you sell your products and services to clients or to peers within IT, you’re responsible for running an entrepreneurship that’s reliable, good value and innovative. Everybody keeps their own skills and technologies up to date. But these entrepreneurs work together to ensure that their respective product lines fit together, because that’s how they satisfy their internal customers and maintain their market share. In addition to clear individual accountabilities, improved teamwork, empowerment and more reliable project delivery, the BWB approach builds an organization that’s flexible, customer focused, entrepreneurial and innovative.

It’s Not Rocket Science

Dividing up lines of business is actually a lot easier than sorting out tasks in the traditional roles-and-responsibilities exercise. There are a limited number of lines of business within any organization. The list is relatively short (compared to all the tasks people do and roles people play). This makes it relatively easy to determine who owns each business.

Once responsibility for each line of business is clear, roles and responsibilities fall in place. By defining who “sells” what, you’ll automatically know who “does” what in any given situation.

Dean Meyer helps IT leadership teams design high-performance organizations. Author of six books, numerous monographs, columns and articles, he brings innovative systematic approaches to what others consider the “soft” side of leadership. Contact him at dean@ndma.com or visit his website for information that can help you implement these ideas, or with suggestions for other buzzwords to analyze in future columns.