DEFINING INTERORGANIZATIONAL ROLES

If the organization s leadership and process focus people are strong, tenacious , and courageous, the organization can eventually define, implement, and institutionalize roles and responsibilities for individuals. Doing so will reap tremendous, measurable benefits in operational efficiencies and also progress the organization forward in terms of CMMI process capability and maturity. The organization can stop there, but the job is really only half complete. The real benefit comes from defining interorganizational roles and responsibilities and this task is much more difficult than doing this work for individuals within one organization.

In the postmodern world of business, there really is no such thing as an organization operating independently of other organizations. Some people maintain the illusion of the organizational island, but it doesn t exist. In our world today, no matter what type of business we re in, there are almost countless relationships between our organization and others. Most of these relationships can be characterized using words such as dependency, constraint, provider, customer, codeveloper, and collaborator. And it is possible to identify, define, and get agreement on the interorganizational roles and responsibilities; it s just very hard work and that s probably why most people don t do it.

The rewards of defining interorganizational roles and responsibilities are pretty good, but the cost of not defining them is high. In my consulting business, we experienced a classic case of the high cost of poorly defined interorganizational roles. We were consulting two different organizations, both which were providing some similar engineering services to a common customer. In isolation, each organization drew the system engineering life cycle and then divided up the life cycle phases according to what each organization thought was their domain and responsibility. Guess what happened when someone finally got copies of both mapped out, cut-up life cycles and looked at them side by side? Yep ” anger, defensiveness, protectionism, fear, and offensive posturing. How dare they say they do X X is our job!

Why do organizations practice this type of territorialism? You know the answer: money. In the case cited above, the stakes were high. The more work each organization could lay claim to, the more they could bill the customer. Who doesn t try to expand their business in this manner? Fortunately, there are many other ways to expand the business ” innovation, increased value, increased service ” and all of them are easier and more cost-effective than fighting with another organization over a piece of the pie. The lesson learned is that when organizations define their role and responsibilities independently of other organizations with which they have relationships, one of two situations will eventually occur:

1. Two or more organizations will lay claim to the same work, causing time and money wasted on political fighting.

2. None of the codependent organizations will claim responsibility for a piece of work and that work will not be performed.

The relevance and importance of interorganizational roles and responsibilities to CMMI-based process improvement are that the definition of such roles determines in large part how an organization defines its processes and standards. Let s say that an organization defines its processes for requirements management with the assumption that the customer is responsible for clearly defining the requirements before giving them to the system engineering organization. The requirements perpetually come into the system engineering organization poorly defined. The engineering organization does its best to define the requirements, but usually ends up not satisfying some of them with the deliverables. The customer complains and the engineering organization tells the customer it s the customer s fault for not clearly defining the requirements. The customer claims that requirements definition is not its responsibility. The leadership in both organizations feels that it s more important to be right than to fix the broken relationship, so the situation continues release after release.

Interorganizational roles and responsibilities can even be viewed from within a single organization. The processes say that the Project Management Office (PMO) is responsible for project planning. When representatives from PMO ask engineers for help in estimating work, the engineers say, planning is your job; I just follow your plans. Inevitably, PMO tries to put together plans without estimates from experts and then the technical team complains that the plans are unrealistic .

There are some guidelines an organization can put in place that can mitigate the high cost of ill-defined interorganizational or interfunctional roles and responsibilities.

Collaborative Roles and Responsibilities Definition

When your organization begins defining its internal roles, responsibilities, and processes, invite representatives from other organizations with which your organization has relationships to participate. Tell them they are stakeholders in your organization s internal processes and standards and be ready to explain to them why and how they are stakeholders. Let them know that your organization doesn t want to unilaterally define roles, responsibilities, and then processes that might somehow affect their work without getting their input. Sometimes you ll get takers using this approach, but sometimes you won t. At any rate, you will have the clear conscience (and record) that you asked.

Identify and Work toward Common Goals

One proven way to bring two or more organizations to work together in collaboration is to find or define common goals or objectives which would not be obtainable by any one organization. If another organization understands that its success in a particular endeavor is dependent on the success of your organization, then the two organizations are far less likely to work against each other because doing so would be counterproductive to the success of each. For example, let s say a systems engineering organization and a testing organization ostensibly work together to deliver a system to a customer, but there is always strife and finger-pointing between the two organizations. The testing organization misses defects, but blames the engineering organization for not implementing the requirements. Engineering points fingers at the testing organization and says the testing is inadequate. To resolve this, the two organizations could form a joint working group to codevelop the test cases. This way, when things work and defects are removed in testing, both organizations get the credit. When things don t work, each organization has mutual responsibility for the failures. The successes and failures of the two organizations are now inextricably codependent and their mutual fate is based on continually maintaining the health of the symbiotic relationship.

Get Your Own House in Order First

Let s say your organization has done due diligence in trying to get other organizations to work with it to collaboratively define roles and responsibilities or has attempted to establish mutual goals with other organizations, but the other organizations just won t play. Your organization still has a goal to improve its processes and that s exactly what it should do. In this situation, the organization s process focus and process definition people should just go ahead and define the standards and processes as best they can with the available information. At a point where a process connects to an external organization, the process definition should clearly and overtly state that it continues into unknown territory in another organization. Document the requests for participation and the refusals to participate from other interfacing organizations. At some point in the future, someone is going to ask all involved why they re not working together. Your organization needs to at least be able to show that it tried and that it had no choice but to make progress without input from the connected organizations.