Most consulting methodologies constitute theoretical exercises designed to generate hours and ameliorate risk but are they the best way to discover optimal usage, transform process, and teach people how to work in different ways?
As we all know, discovering optimal usage starts with understanding requirements and mapping them to solution capabilities but how can people really know the requirements for how they will use a technology application they’ve never seen or used? How can they know that they’ve discovered the best way to do a process before it has been transformed and experienced?
The classic method of systemization of requirements and logical definition of design that is the hallmark of most consulting methodologies fails to be transformative because discussion and documentation only partially captures what people need and want. Since so much of what we do, how we work, make decisions, and interoperate with others, cannot be easily explained key elements are left out. Process performers struggle to explain what they do and often revert to passively answering questions posed by consultants intent upon completing required documentation.
Because the typical engagement is constrained by time and resources, consultants tend to focus on gathering the basic information required to produce a deliverable that demonstrates that valid billable work has been performed. In many ways, innovation is discouraged. To do so, one runs the risk of stepping outside the boundaries of what constitutes the defined scope of a project which can result in doing work perceived as unjustified and/or expanding the project beyond budgetary boundaries. All of this is triggered by a simple dynamic which, if changed, has the potential to significantly alter how we perform the implementation effort and the value of an implementation’s result.
Simply put, consulting deliverables should focus on what was done and not what will be done. The effort of moving from requirements definition to designed solution must be experienced based. For example, the first reaction to a set of defined requirements should not be a requirements document but, rather, a proposed solution. Training should not start with the creation and presentation of a training document but with the users using the system. Solution discovery is a product of solution experience. Best practices and refined process spring from use.