Best Practice: Identify Multiple Validators for Complex Organizations and Have the Client Organization Resolve Conflicts

I was just discussing with some of our PMs some of the issues we have had with previous projects and one of the main issues is that customers which have complex organizations (most government departments are an excellent example) not being satisfied with the resulting SW products. One reason for this, we determined, was that we did not strongly enough enforce the need for formal customer validation and requirements gathering. In hindsight we saw that this was because of two reasons:

• The organization processes and workflows that the SW would affect or be deployed to were not used to identify and specifically request the client for organizational representatives with authority to validate requirements from these areas.


• The SW developed was assumed to be a clearly defined concept with little or no validation required. But once it was produced and deployed all sorts of effected people came out of the woodwork to complain about it.

A formal charter, vision, requirements and functional specification with signoff from the specific areas is the clearest way to make choices clear.

Often the development of the software will expose underlying operational conflicts between user types, or areas of the complex organization. The simpler the organization the less conflicts of this type. What needs to be made clear to the organization is that to resolve these conflicts is often outside the realm of the software development project. The danger is that the SW development project is blamed for the underlying organisational conflict.

For this reason many IT projects are associated with process re-design to clear up these issues before the SW project begins. The downside of this type of strategy is that it takes a long time for everyone to agree and one may never even get to start before the client gets tired of the whole thing.

Organizational conflicts can be visualized nicely with a conflict-resolution diagram often used in Theory of Constraints (TOC) for which I have been experimenting with flyinglogic which does a great job working with this type of diagrams (see above).

To sum our lessons learned:

1. Always identify the key organizational stakeholders and get them to be official “validators”. The identification of these key roles/individuals may come from a previous analysis of the client organization or may need to be elucidated in the vision phase of the project. In a complex organization each user type will normally have one validator. It is normally a bad sign if the project assigns only one individual to validate the project unless he is the CEO.


2. Get all the validators to sign off on the functional spec (and its sub components.)


3. If conflicts arise get the primary stakeholder to move the validators to accept the functional spec. You can’t make a move without them onboard. They must sign off on the spec.


4. If you really have to help them out so the project can move forward, one solution might be to make a TOC conflict-resolution diagram. You may present them with some interesting viable alternatives, some which might even be possible within the scope of the project.


5. Don’t let politics infect your organization. Stick to the formal organization and keep things validated formally before work is preformed.