This is the title to a piece a friend wrote that appeared in the mar/apr 2011 Interactions mag from ACM. I'm fond of this piece because it calls out the centrality of human group processes as an important factor in project success and the danger of an approach that is too narrowly linear and deconstructionist.
In this piece Friedland/Yamauchi also give voice to another process truth I had also read about and feel must be true. While a waterfall approach assumes we explore the problem space and come up with a statement of need that is then fixed and forms the basis for the exploration of the solution space, it is clearly not the way it happens in practice. If it were so, we would not have chestnuts like "to a man with a hammer, everything looks like a nail." Our tools (using this in the broadest way possible) shape how we at least conceptualize, if not see, the problem at hand. The exploration of the problem space is done relative to the solutions we know about. This allows us to quickly dismiss solutions that appear completely unworkable and focuses our attention on the gaps between the prior successes and the current challenge. It becomes more of a survey to continue exploring the contours of the solution we know we can build to see where the problem fits or does not fit that contour.
This parallel activity of refining the problem statement while holding onto prior successful solutions helps me come to grips with a dysfunction I have seen far too often in practice. Very large products often have sufficient plasticity that they can solve problems outside the domain in which they were designed. A case in point is an insurance policy administration system I worked with that was sold to senior management as a solution for both a travel product, a membership product and as an enterprise billing and payment solution. My immediate reaction was, yes, it CAN do that. But SHOULD it? The argument that ultimately won the contract was the simplification of the relationships that needed to be managed to complete the project, the operational simplicity of the finished product and the cost savings that would accrue to the organization by that decision. The vendor had developed enough good will that they were judged to be someone who could be trusted to deliver. The project was generally successful in those high risk areas but I have never found that solution optimal.
What I take away from this is how senior management must deal with exceptional levels of complexity and they are as inclined to abstract their cognitive model of the organization as a programmer is to abstract large collections of code. Clearly concerns like the cost savings of consolidated operations and products can more than compensate for minor inefficiencies of using products that are not necessarily the best of breed. However the trade-off point is hardly an easy one to analyze and argue with hard facts. These decisions either come down to management fiat or they happen because of persuasion from a committed staff member. Sometimes these arguments are won by pure salesmanship.
A major insurance company I worked for had a large installed base of Sybase databases and had negotiated a very favorable contract with Sybase for new licenses. This made the financial justification for new projects very easy when there was a database component to the solution. As far as I can tell, Oracle was able to convince the most senior management that Oracle databases were their future despite the lack of any clear functional superiority to the product. Even worse, the favorable pricing for marginal licenses was lost and many projects that could be economically justified under the old schedule became economically unfeasible with the new schedule of pricing. Even worse was the cost to the organization to convert the existing databases, a process that would take them many years to complete and at a cost that would exceed any immediate short-term savings. Perhaps it was someone's bonus for the year that was saved but it was not the right long-term solution for that company.
So to get back to the article, the conclusion emphasizes the importance of imbuing the organization with a "designerly way of knowing." I don't disagree but I don't find peace in this statement of the conclusion. What I feel happened is the release of energy that became possible when the staff was empowered to build the environment they wanted instead of the one that was designed for them. Most often, a designed environment is constraining and not empowering. A particularly stark example of this is how Frank Lloyd Wright approached his buildings. He attempted in some cases to not only furnish a structure but the furniture that would go into them with floor plans that virtually dictated where everything would be. This can be acceptable design for some people and some homes. But to inspire maximum creativity for a staff this is anathema. You would never put children into an environment that gave them no options for play. The mind must be free to assemble the pieces in experimental ways, ways that can fail as much as succeed. I see the lesson learned here as one that creates the right environment and empowers the staff to modify it as they need. But I know I am only playing with the semantics here.
No comments:
Post a Comment