he relationships dynamics model used by Nexbridge assumes that relationships are already set up and functioning. Relationships, in our models are typically between producers (developers) and consumers (users). Most often, teams will, in general, exhibit reluctance attributes. Our goal is to improve the relationship to and maintain it in a responsiveness state rather than letting it sink down to revolt. Time is usually not on the side of either the producer or consumer. As time goes by, inaction or inappropriate action causes the relationship to decay. This section introduces each of the R’s.

Responsiveness

Responsive behavior is characterized by being able to meet or have met real needs, and to communicate or understand needs in a timely fashion.

Reluctance

Hesitation or reluctance sets in when users are rebuffed or are told that changes cannot be made because the specifications have been locked down. Developers also become reluctant to have an open dialog with users for fear of new issues being raised.

Resentment

With repeated rebuff, and repeated issues coming up, both developers and users will inevitably develop resentment. Signs of this are users saying, “IT just isn’t listening to us” and developers saying “Those users cannot make up their minds.”

Resistance

Both users and developers become resistant to change after many change failures. Without adequate preparation, including training, even the best of systems will be met with resistance for fear that the mistakes of the past will be made again. Developers become resistant to making changes because of continual rewrites from wildly divergent specifications.

Rigidity

Rigidity sets in, as an extension to resistance, when users simply refuse to take new systems. Developers start using phrases like “The specification is frozen. We’re not accepting any new changes.” Another form of this comes across as apathy. Users will say “Yeah, whatever” when new systems are planned for deployment.

Revolt

At the end of the road is revolt. At this point, users will go to outside or different sources for their products. They will change vendors, throw out products, including hardware. It is very easy to get to this point, very quickly, if the relationship decay is unchecked.

The Result?

When projects fail, developers and users are mired in blood. Users are the ones who often end up offline. The next time an attempt is made to deliver anything, the expectation is that blood will be spilled.