The development process was very confused....\n\nOstensibly, Aaron ran one of the applications development groups in this IT shop of 200 staff. But \u201cbusiness analysts\u201d (BAs) in Mark\u2019s group determined requirements and high-level designs. And \u201cproject managers\u201d reporting to Jay (the PMO) took control of large development projects, relegating Aaron\u2019s development group to a simple body shop. I asked who determines requirements? All three managers raised their hands.Who\u2019s accountable for project delivery? Aaron and Jay both raised their hands. Mark shrugged; it wasn\u2019t his problem, although he controlled a critical step in the process, one that could make or break project delivery.Staff stepped on each other\u2019s 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.\n\nTraditional Roles and ResponsibilitiesLooking around for help, George found a process that seemed plausible. In an interactive workshop, his managers agreed on their respective \u201cResponsibilities, to whom they were Accountable, with whom they had to Consult, and whom they kept Informed\u201d (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\u2019d have resolved the confusion. The answer they came up with was something like this: \n\nMark 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. \n\nAaron and the other development managers retained the primary relationship with clients for their applications, and they determined high-level requirements. Then, Mark\u2019s business analysts were responsible for detailed requirements definition and high-level designs. \n\nThe business analysts would hand the project off to Jay\u2019s project managers (if it were over 40 hours) or to Aaron\u2019s developers (for smaller projects), who\u2019d be responsible for project management\u2014including scope, project planning, schedule, budget, resource management and risk management. \n\nEven for the big projects that Jay managed, Aaron would supply developers who would do the detailed design, coding and\/or package integration. \n\nAnd of course Aaron\u2019s 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\u2019t do, staff and clients alike remained confused as well. \n\nWho Runs This Business?Who\u2019s responsible for project delivery? Jay accepted responsibility for big projects, and Aaron for small ones. But they couldn\u2019t 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\u2019s and Aaron\u2019s projects to fall behind schedule. Or Aaron would pull developers off one of Jay\u2019s project teams to deal with an urgent maintenance item, putting Jay\u2019s project in jeopardy. Aaron\u2019s developers, responsible for small projects, got little support from Jay\u2019s 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\u2019s less than 40 hours, they were directed to Aaron\u2019s development group. Anything over 40 hours was deemed a "project" and clients were directed to Jay\u2019s 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\u2019t always know what Mark\u2019s business analysts or Jay\u2019s 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\u2019s responsible for the quality of a project? Jay\u2019s project managers made key decisions that framed big projects, but Mark\u2019s business analysts made some design decisions and Aaron\u2019s developers were responsible for detailed designs. The answer was: No one group had overall accountability for the quality of results. More broadly, who\u2019s responsible for the long-term integrity of the applications? Clearly Aaron and his fellow development managers were held accountable. But they couldn\u2019t 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, \u201cAs an applications development manager, I am purely tactical.\u201d 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. \n\nWho Sells What?You may sort tasks among groups in excruciating detail, and you still won\u2019t be able to answer the question, \u201cWho\u2019s accountable for results?\u201d And when you sort tasks outside the context of responsibility for results, there\u2019s nothing to stop you from accidentally separating accountability and authority, which disempowers staff and sets them up to fail. The traditional \u201croles and responsibilities\u201d 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\u2019t determine who owns the business of producing applications and related services, or what specific products and services they produce. If you\u2019ve 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\u2019d define jobs in terms of the business each group is in\u2014that 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\u2019s the prime contractor\u2014the one and only group that\u2019s 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\u2019s 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.\n\nApplying the BWB ApproachLet\u2019s try this BWB approach out in George\u2019s 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\u2014a new solution, an enhancement, or a repair\u2014Aaron is your man. Clients know where to go for help, and they have a single point of accountability for all their projects.Aaron\u2019s developers are the primes and wholly in control of their projects. They may subcontract to Mark\u2019s business analysts for a requirements analysis if clients\u2019 needs aren\u2019t clear.Jay may have the project-management office. But that doesn\u2019t make him a project manager who\u2019s in control of Aaron\u2019s projects. If Aaron\u2019s developers want help on big projects, they may \u201cbuy\u201d services like project planning or training from Jay\u2019s PMO. But Aaron\u2019s 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. \n\nBenefits of the BWB ApproachThrough 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 \u201cpartnership\u201d and the \u201call for one, one for all\u201d spirit in which everybody steps on everybody else\u2019s 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\u2019 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\u2019re 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\u2019s 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\u2019s 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\u2019re responsible for running an entrepreneurship that\u2019s 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\u2019s 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\u2019s flexible, customer focused, entrepreneurial and innovative. \n\nIt\u2019s Not Rocket ScienceDividing 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 \u201csells\u201d what, you\u2019ll automatically know who \u201cdoes\u201d what in any given situation. \n\n 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 \u201csoft\u201d side of leadership. Contact him at email@example.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.