Methodology Denounced
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.
3 Comments
Reader Comments (3)
Hey JP;
Interesting post...now where to start.
I think one reason for the current focus on the deliverables process as you describe it is because of the inability of many consulting organizations to deliver anything else. People naturally gravitate to what they know, and software implementations - including, and maybe especially ECM implementations - are notoriously poor at delivering results. Now a functional spec - that they know.
Another reason is as you say users' inability to go from the tacit 'what they know' to the explicit 'how we know this'. Agile development methodologies are designed to mitigate this phenomenon and I have seen paper prototypes work extremely well in this respect.
Finally, and you hit this one well out of the park: innovation is strongly discouraged. Documentum consultants - like almost all other ECM software consultants - are taught on pain of death that they must never, ever talk about functionality that is outside of the shrinkwrapped box. Clients that agree to 'try' to customize EMC software will burn their budgets and their credibility faster than you can say 'cash to ash.' To bring this full circle, even what is in the box is susceptible to the 'non-deliverable' deliverables catch.
Bottom line? When software is built like cars you will begin to see consultants that can connect the requirements (My car pulls to the right.) to the deliverable (Align the front end.) more reliably. Until then, go agile.
Thanks for your response, John. Part of what motivated me to write this was thinking about a new ECM project that I'm getting ready to start.
I've lost faith in paper prototypes. IMO, as consultants, I think we over estimate their effectiveness. Though they are good as a project management and scope control tool, I think they do a lousy job of communicating solution in a way that is understandable to the non-technical person, our audience, the end user. It is just too difficult to understand, to abstract.
For this reason, on my next project, I'm planning to spend very little time talking about requirements and move almost immediately to prototyping the solution. I want the customer SME's to interact with the technology as early as possible, have them experience what it like to use it, and build my requirements from the feedback that is elicited as a result.
I'm looking forward to what I hope will be a very dynamic start to our project.
JP
hi everybody
just registered and put on my todo list
hopefully this is just what im looking for looks like i have a lot to read.