Design Age - Part 3

In this installment of the series on the Design Age I'm going to describe further the Traditional and Emerging problem solving methods. The previous parts one and two I dealt with the definition of the issue surrounding the new Design Age and the issues of solution complexity and scarcity of resources to deal with these seemingly insurmountable problems. These are truly the "wicked" problems of our day.

For some of you reading this have probably thought 'why deal with this issue at all?' Just look around at any of the forum posts on any of the general design centered or AEC centered forums and you will see a host of questions clustered around several large topics such as Integrated Product Design or Building Information Modeling (BIM) and how to use this new class of software and process as it applies to design, construction and building maintenance. How does the supply chain become involved and a host of other issues? These questions have been bandied back and forth for over five or six years and no single answer seems to solve the issue. No single tool or process seems to completely define a singular solution. How can it when the problem is so large and has so many variables to work with?

This is not to say any one of the current partial solutions available as a process, methodology or software tool is wrong or is not effective, it is rather an issue of series of partial solutions as suggestions or viewpoints as to a method to address only a portion of the larger problem. For this reason, such a singularly large and complex problem cannot be solved by a singular problem solver. We hope and dream for such a solution, but the chances of it happening are just too small when we look at the interrelated variables connected to the problem.

Traditional Solvers, Those of the Scientific Method Persuasion
So let's look further on the basis of the two problem solving methods we have available to us today. One is the traditional singular subject matter expert using the scientific method. A master of the problem domain, with significant experience and practical knowledge across a wide area of issues. Even to the point of being a da vinci.

  • Existing and well known paradigm is comfortable.
  • Works well for technologically and data-driven solutions and methods
Best used when you have
  • Controlled environment
  • Controlled Scope
  • Singularly understood goal
  • Single language and meaning

A single person acts as the originator and choke-point for all solutions. This is the model of the lone designer, scientist in the lab and painter in the lonely room. Now don't get me wrong. For centuries this method has worked well for many of the problems we used it on. The Scientific Method has led us to some remarkable discoveries and bettered the lives of billions of people over the world. But this method intentionally limits the problem viewpoint to a controllable set of variables. Results are often partial and the best research scientists often admit in their findings that their results are only partial and at best, are only indications of a possible event or finding due to this artificial limiting of variables. When I see these disclaimers in research work I often think maybe their work needed a bit broader view and more input from other, often unlikely sources would have served them well. But this kind of scholarly work leaves no such opportunities if the traditional scientific method is to be followed.

Non-Traditional Solvers, Those of the 'Wicked' Persuasion
Enter the complex or "wicked"problem, where the  problem demands a network of designers and subject matter experts, often from a multitude of information domains. When a problem is posed to a group such as this, many times the supposed issue is only a symptom of a deeper issue not even realized in the original problem statement. Now there is an issue of redefining the problem through the lenses of the various information domains and the melding of multiple languages into a singular understanding. Often a new language idiom is defined so all the members can clearly communicate. Even the social dynamic of new alliances across differing information domains complicates the discussion of issues and possible solutions. This really gets messy for a while until some form of equilibrium is reached.

A whole new set of methods and techniques and skill sets are needed in this context. The soft 'people skills' now become as important, no more important than the technical knowledge and experience of each participant. For, if the group cannot put aside at least most of their egocentric universes nothing will be produced. A collective consensus is the goal here, not a democratic majority. Acceptance of the possibility of a predetermined outcome by consent, many times by only a plurality is the direction of the collective solution. Just as with the Scientific Method, there will be unintended consequences since not all variables surrounding the problem are accounted for. But this time there is an acceptance that those unknowns exist and will create some unknown result. And the realization that this is not the only answer possible, it is just an answer out of the millions or billions of possible answers, all with a different set of outcomes, some anticipated and others unanticipated.

It is a mess, but it is an informed mess. A mess of decisions made in light of the best information known at the time by a group of invested stakeholders. Stakeholders that are seeking the best answer they can find, given the filtering lenses of their experiences, information and resulting consensus. Horst Rittel said that this is almost an insane act to involve yourself in this process knowing there is no definitive solution and out of the infinite possible solutions your collective will pick one and it might not, in fact most likely will not, produce the result you intended.

Social planners, urban designers, transportation planners, even physicians and physicists all live with this set of paradoxical positions. Yet, if we are to move forward, some brave souls have to dive in, inform themselves, look at a problem from every possible viewpoint and then make a decision as to what they will do. Hoping that some of that what they anticipate to happen does happen, even new events which reveal new possibilities for better solutions.

The Meshing of A Mess
In the built environment domain and the narrow AEC/OOFM world, we have a seemingly unending set of variables from the domains of finance, physics, economics, spatial aesthetic, material sciences, biology, chemistry and even the human impact to name only a few, to consider. How do these mesh together? How to we find the important points of most impact and positive change? How do we resolve the questions of what values we hold most dear? Where do we find the most value? Even what is expressed as value when the constraints we have held in the past as defining boundaries are being wiped away on a daily basis?

These are the questions as professionals in this business we are called upon to answer. Up to this point I think the indictments against us as being the most inefficient and wasteful are the least of our worries. the damage we have done over the past five decades is largely from our own indecision, infighting and inaction. This has to change soon.

We know we are the largest contributors of waste in our economy and environment. We have demonstrated to be the most resistive to change of any other economic sector. To our credit we have recently begun to awake to these challenges. We don't have 10 or 20 years to solve these difficult issues. We need to be willing to open our eyes to new approaches to problem solving and beg, borrow and steal every possible tool at our disposal and combine those assets into a new solution engine that has not been seen before. I say put aside all our past preconceptions of how or why we did something and start with a clean slate and build a new way of improving our Built Environment. Why? Because we have some of the most difficult and yet impactfull problems to solve. The benefits are enormous while the risks are just as large. Not to act will only continue the same devastating results of the past.

So look beyond your traditional sphere of influence and business. Look to see what others are doing to make themselves more efficient and steal from them. Remake the idea to fit your needs and then do it all over again in ever broadening circles. The power of doubling will take effect and soon the influence of your original action will be the basis of a whole new wave of innovation and change, creating benefit for both the producer and the consumer in ways you never thought or intended.

On to Part 4, the last part for now.


A Sense of Place and Play

A new friend of mine, Pete Bastrom recently posted a discussion in BIM Experts which I'm going to expand upon. It seems to me in the Built Environment we are constantly hoping to make our world a better place to live, at least I trust that is the basis we are all working from. Yet, we still seem to get all tangled up when we develop new spaces, or old spaces and are only thinking of the economic impact of the project we intend to complete. So often we roll out the same sprawling pattern we have found so easy to unroll not thinking of the sense of place we forget. Now I'm not going to wax poetic about the quaint old cities of Europe because they just don't meet the new demands of our lives today. The cost to retrofit them to provide the basics of our lives is extreme for water and power alone, not to mention waste removal and other of life's essentials, both physical and economic.


Machine Metabolism? What is it? Cornell students explain

The Friday Bonus
Earlier this year a group of six Cornell students displayed their most recent work in robotics. They postulated:
Biological organisms can metabolize: break down nutrients into basic building blocks and then use those building blocks to create new things. What if we could reproduce this kind of process in a robotic system?
They hope to show that structures can be erected, maintained and modified, all with little or no human interaction. To be sure this is an early depiction of this idea. But the idea of robots repairing structures without human interaction has only been thought of on space-bound craft in Si-Fi movies and books. Good 'ole R2D2 was designed for this kind of work. Where would Luke Skywalker have been if the trusty R2 hadn't repaired those loose flaps and whatnots trying to come loose while under fire from the evil Empire?

I don't think any steel erectors will be loosing any jobs soon, but it seems possible such robots could be involved in manufacturing environments pretty quickly. Read the full article and let your mind run wild.


Google sells SketchUp to Trimble

Yesterday, 4/26/12 announced the sale of SketchUp to Trimble and Trimble also announced the acquisition. What will this mean to the AEC and others who are avid or even passive user of SketchUp? As usual only time will tell.


Penn State BIM Execution Plan v 2.0 | FM v 1.0 Released

BIM Project Execution Planing Guide - Version 2.0
BIM Planning Guide for Facility OwnersTo add more fuel to the fire, or better, put a blanket on the blaze, PSU has also issued their first version of a BIM guideline for Facility Owners. I'll be looking at that as well. While I'm not an active FM person, I have worked in the sector for a few years and understand what would make a reasonable guideline and structure for a BIM model. I'll get back to you with my first impressions on that new guideline as well. Here's the home page for the Owners and FM guide <click here>
It's good news that PSU has continued to support the profession with these two new documents. Their past work was great, if not heroic, and I expect these new guide documents to be up the same quality as their predecessors.

Readers, I downloaded the Penn State BIM Execution plan v2.0 this afternoon. I've used the previous version, in part several times for planning and organization along with other sources to create customized plans for projects several times. I'll be looking at this new version and give you my thoughts next week. If you haven't already seen the release here's the home page for the new release. <click here>


BIM and XPM: A Made Marriage - Part 3

Part 1 and Part 2 of this series introduced you to a new light-weight management method based on Agile and XPM planning methods. In Parts 1 & 2 I told you I would tell you how we used this theory so in this installment I'll make good on the promise.

We started out trying a piece of web-based tracking software which is open source. We abandoned it for a couple of reasons, the biggest reasons being a serious bug in the software and a lot of terminology specific to software development. As a second attempt we backed off and started over with a stack of 3 x 5 cards to represent the elements of the plan from Releases right through to the Tasks / Tests. Later on the team wanted to use an online solution and we agreed on a simple online forum as a platform. It meant a little more manual work than the previous online software, but we found it worked just as well and was simple to use and it didn't have all that foreign lingo of software development. We were free to make up our own language. I'll also say at this point we also tried spread sheets as an alternate to the web forum, but that was just too unwieldy and didn't have good multiuser support. Spreadsheets really are built for single authors. We did find the spreadsheet was OK as an alternative to the 3x5 cards for planning.

We created several different structures in our forums but the following became our standard of practice.

A list of categories called Active Projects, Completed Projects, General Discussions, and Food for Thought. We used General Discussions for topics that weren't germane to the production of any single job, but something someone wanted to pass along as a supporting thought or reference for the general practice. Food for Thought was used only for discussions that directly related to the management practices and how they might be improved or extended.

Next under each forum category we had the projects themselves. Under these we had children forums for Planned Work, Current Work and Completed Work That looked something like this.

So you can see a very simple mechanism implemented in a simple to use software tool like a forum, gave us the majority of the functionality needed to organize our work. It was easy to move the elements of the discussions as well as the discussions around as their information matured.

It only took us a very short amount of time to teach anyone in the office how to set up and maintain this organization method so we used the junior team members to do this task. That way they got used to the tool and how it was used every day.

The Language of the Forum
Next we had to create a lexicon and grammar to organize the information at each level. We tried a lot of different solutions with varying results. We finally gave each project team some latitude on their choices due to the preferences of team leadership and the complexity of the project. We had a range of organization that had little if any sorting string thought to some that could organize the views by selecting string or substring values along with numbering schemes that produced views with only a very selective result. For instance some teams chose to use a title string that looked like the following organization
[completion] | release | Iteration | story | task | [Responsible] | title and looked like....

[y/n][] Model interior sound partitions

If someone only wanted to see incomplete release 2 tasks they would look for a string like "[n]2.*". Or all the incomplete story 15 tasks with "[n]*15.*" If someone wanted to see all the work they had taken charge of they could look for "*[aa]" if their initials were "aa". So you can see there is a lot of flexibility in an open string and search tool to quickly create searches to display results. Our forum also had a listing view to show all the past activity as new or changed information in the forum, which made it easy to watch the work being completed without having to do a lot of searching.

We also included information in the body of the task / test entry like when it was due as a calendar date [11/15/11] and any reference documents back to the Project Notebook or other web resources before the task description. Work completed was created as a reply to the forum entry and signed / dated along with the hours used to complete the task and test. Both the Task and Test portions had to be completed before the work was marked completed. 

The wiki project notebook
The companion to our forums was a wiki organization which we implemented using Mediawiki. The wiki held both the higher order project information like clients, contacts, project budget and schedule information as well as specific information regarding selections for materials, assemblies and all the other design requirements information. In addition we used template pages that organized much of this higher level information so all a manager or other assigned team member had to do was select one of the template documents, duplicate it in their project and then fill in the blanks as needed. This normalized both the information and the organization pattern for this kind of information and gave each element a url page location which could be used in the forum to point back to when needed. So the wiki became the project notebook and it was uniformly accessible by anyone at anytime from anywhere they could get a web connection.

We also had sections in the wiki to assist project work planning teams to easily create stories, and task collections by creating lists of common stories and tasks / test combinations. They could cut / paste the needed information out to make it easier to create the forum entries. 

So there you have the core of our tracking and documentation methods. Nothing fancy, but it works and it is free. There is enough flexibility in the methods to accommodate a lot of differing need so if you need a simple implementation, pare off what you don't need and use the rest. If you have more people and work to manage, you can step up the organizational framework to meet your needs.

This level of project documentation made it easy to add new members to the team. They only needed to read the information necessary around the work they were assigned to. If they needed some background on how the model was organized the BIM Execution plan gave them that info housed in the wiki and referred to in the tasks / tests they would work on. Instead of having to brief someone for 20 minutes or more, it took about 5 minutes for a new person to join in and get productive, and that was without a senior team member giving them a briefing. Yes this did take some time, but it kept people focused on their work. Work that was needed was completed in timely manner. Work that was not needed yet didn't get worked on. And tracking the completion of work or where there were issues were easily identified and solved quickly by the team or an outside source when needed. After setting the expectations and training this system was very effective in keeping our projects on track and eliminating waste.

I hope this helps you understand how we organized our work. In Part 4 I'll share the measurement indicators we used to track progress. Until then remember "Collaboration is the glue of success."

Now on to Part 4, the last one
This article continues a String of Connections between practice management, BIM and Agile management practices. 


The Future of Architecture: Is there one?

In Architecture Daily a recent article entitled "After the Meltdown: Where does Architecture go from here?" author Vanessa Quirk takes a look at the imbalance of teaching, training and experience in the profession of architecture and the resulting consequences related to the continuing viability of the profession. As a practitioner of over 20 years, I have often wondered how many of my peers survived the practice economically. I chose to leave the profession and use the training in another economic domain and found it prepared me extremely well for just about any endeavor I wanted to turn to.

Now as I look at the landscape of architectural practice I despair and rejoice in the same breath, because the process is so broken. ....


Design Age - Part 2

In Part 1 of this series we identified one of the core issues with design in today's consumer-centric client as one that is complex, if not wicked.(1) Additionally that there is likely a high probability of failure for the first solutions and there is no right or wrong solution, hence there is a high probability of unintended consequences unforeseen by anyone.

In this installment of the series we are going to compare the differences in problem solution outcomes between traditional single mind approach vs. a collaborative mind approach. We begin with the premise that
  • Solutions are found by progressive possible solutions, not simple linear decision-making
 This premise is based on the idea that linear solutions of the traditional Scientific Age are able to handle a limited set of variables where the Design Age uses a parallel solution method of many minds approaching a problem's solution from varied points of view.

Let's look at a graph of the traditional Scientific Age solution method.
From the left to right the colored area under the graph line represents the unknown values. The solution is solved in a linear progressive manner eliminating each unknown with a scientific hypothesis which is tested with a controlled set of data. As more and more information about modality, reaction and effect are discovered a solution is gradually revealed in a stepped form as the graph shows until a final solution is arrived at when all the variables are accounted for.

When we look at the emerging Design Age solution method we see a different kind of graphic representation of the solution.
Here we see a jagged line of resolution which suggests every time a near solution is derived more unknowns are revealed and a new solution is sought. It is a progressive revelation of possibilities until at some point a solution which is 'good enough' is proposed. We may have used a scientific method of testing and proof through data, but not necessarily. In some cases the data may have been approximations or even outright guesses. but in the end some kind of resolution was accepted by the solution team through consensus.

A second premise deals with the time constraints of more complex and wicked problems. time estimates for difficult problems always seem to be difficult for project managers. The time to deliver acceptable solutions always seems to be more than what was anticipated. therefore the second premise is:
  • Time required for more complex problems grows exponentially.
The next graph shows the complexity curve of time required to solve more difficult problems. Notice the curve is not linear but the expression of some coefficient of difficulty that indicates an exponential curve.

This curve is a depiction of  the "no stopping rule" Horst Rittel mentions as part of the definition of a wicked problem. Not recognizing a wicked problem often makes a project manager look bad since for every solution that looks like a resolution, more unknowns become evident and more time is required to find new solutions which account for the newly revealed variables. Stated in other terms an infinity of time is needed to arrive at the complete 'right' solution. It is diabolical and close to insanity to continue to apply Scientific Age solutions to this increasingly difficult problem type. Horst Rittel suggested that for a single, traditional  problem solver insanity must surely be immanent and sure. 

The final premise we will look at in this article states:
  • Resources grow more scarce as complexity and time are increased.
 This time we have two curves. One represents resource availability and the other the time needed to study the problem and arrive at a solution. Notice as we move from left to right the complexity of the problem increases from 'Simple' to 'Wicked'.

The first line representing Resources Availability is reduced from Simple to Wicked for the single reason that knowledgeable and experienced solution providers become more scarce as the complexity of the problem increases.

The second line represents the possible solutions are further constrained due to expansion of facts available for consideration and the lack of time and resources to evaluate an ever-expanding set of available data. Multiple solutions are possible and the lack of consensus between the solution team further constrains the time to an acceptable solution.

At this point if you think all is lost you are close to the mark for the simple reason that most of us are steeped in the belief of the infallible nature of the Scientific Method, yet we see here a case for it's fallibility when facing an unknown set of variables and an ever-increasing set of interrelated complexities. Designers truly have a difficult transition to deal with. We are taught to think in a da vincian method of scientific proof, yet no substantial proof seems to exist as more and more interrelated, previously unaccounted for data appear with each successive solution.

Horst Rittel suggested that a group of interested stakeholders approach the problem knowing that a single fully thought out solution is not probable, rather they were to reach some solution based on a set of documented assumptions and data to arrive at a position of consensus as to what action would be taken. The group was also to be made aware that there would be unintended consequences for their decisions and action taken, but that was part of the price of consensus and a 'best solution' result.

For some, this is a bitter pill of realization to take, but if you look closely and honestly at wicked problems  you find this is their nature and the solutions are of the 'good enough' variety, not perfection tested to the nth degree.

In the next article we will take a further look at the Traditional vs. Emerging problem solving methods. Pitting the singular master solver against the collective mind of collaboration. Until then remember "Collaboration is the glue of success."

Continue to Part 3

(1) "Dilemmas in a General Theory of Planning", Rittel, Policy Sciences, 4:2 (73:June) p. 155.


BIM and XPM: A Made Marriage - Part 2

In Part 1 I introduced the concept of using Agile management techniques in a BIM-centric design / construction practice. After looking at the article I found I made a lot of assumptions and you know what that usually means. I have to apologize for the assumption you would know about Agile, or XPM and how those light-weight management tools would or could work in a design-centric work environment. So to make up for my oversight I thought a quick primer on what the basic parts of an Agile / XPM environment looks like, as we implemented it. One caveat here, if you are familiar with these


"Right" BIM Thinking

Does our thinking need to change in order to do BIM well? How?

What is "right thinking" when it comes to BIM, anyway? How is it different than "right thinking" was 5 or ten years ago? How do you train for it? Can the playing field to accommodate "right BIM thinking" better?

Question by Brian Lighthart in LinkedIn Group BIM Experts

It's Saturday AM and I'm catching up on reading I didn't have time for earlier in the week, so I thought I would pass along this gem I found. I would suggest you read the discussion since, in my humble opinion, this is one of the more insightful questions asked around the general topic of BIM. Those of you who are part of the new rush to use BIM will find this discussion either enlightening or obtuse or even dark. The truth of the matter is Building Information Modeling / Management is a technology still in it's early development. An adolescent at best. All the stakeholders who could benefit haven't weighed in yet. All the potential benefits haven't even been defined, discovered or delivered. And definitely not all the right questions have been asked.

Tablets and other Multimedia Devices - Impact on IT

The Friday Bonus
Gartner Research has posted a new report which deals with the impact of tablets on the enterprise level companies. Due to the increased adoption of multimedia tablet devices like the iPad and Android tablets such as the Samsung Galaxy. It is a rough world out there for IT support groups with an ever-changing set of devices and a new crop of feature sets about every six months. The old 'castle and moat' unified access method is going  by the wayside. A new vision of open and flexible context related access methods are likely the better way to go.

What does this mean for the Built Environment folks. Well the unintended consequences could be rather significant. Cloud access to sensitive information could be one issue. Another is the more open access to project documents, enhancing collaboration and solution development. On the design side, consider the smartConstruction  BIM model that has Qcodes on incoming equipment and inventory that is tied to installation documents embedded in a BIM model. Or delivery instructions to supply house delivery drivers showing the site plan and where they should drop their loads to prevent damage and enhance materials handling on the site. Those are only two ideas, I'm sure there are thousand's more.


BIM and Google Project Glass

A couple of days ago one of the good guys, Carlus Kilgore sent out an update to the Southern Arizona Revit Users Group (SARUG) about a pilot project Google is working on called Augmented Reality. Some of you may have already heard about this and maybe looked at the You Tube Vid Google put up to describe the service. Gizmodo has some more info as well you can check out. So thanks to Carlus for the links and notice


Yeastiziced BIM?

Research scientists in London's Imperial College have discovered proteins that behave like wires to connect DNA in yeast. Now scientists can begin to create new biological circuits which change the behavior of DNA in yeast allowing yeast to be re-engineered to become trackers, tracer items, test monitoring agents and a whole new class of identification and monitoring agents in both inert as well as carbon-based environments.
"Future applications of this work could include tiny yeast-based machines that can be dropped into water supplies to detect contaminants, and yeast that records environmental conditions during the manufacture of biofuels to determine if improvements can be made to the production process."


BIM and XPM: A Made Marriage - Part 1

Since writing this article back in April, It is ranked #2 for the number of all-time hits on this blog. I'd like to encourage you to read all four parts. The hook is I reveal how all this works in the later parts. These lightweight management theories will radically transform your business and professional practice. If you want to see more $$ at the end of the year and create a better working environment, then I strongly advise reading all of the series. aa June '12
BIM and XPM were made for each other. BIM authoring tools of just about all forms are characterized by elements or families which have some kind of data construct attached to the graphic elements. The graphic elements can be driven by parametric data or not. Not surprisingly, the elements are organized in large categories which roughly approximate the organization of the construction material sets needed to erect a building such as foundations, floors, walls, ceilings, furniture, casework, equipment and the like. Views are organized in a way that traditional document sets have been assembled for decades such as plans, elevations, sections and tabular schedules. Since the model is 3d there is also a new view for 3d perspectives, isometrics and other similar views. A very modular and structured way of thinking.

Most importantly from a work management point of view all these elements and views are very atomic and largely independent of each other. They can be created with or without any data or graphic content in them, or at the very least only the barest of information or graphics as place holders waiting for more specific information. The other important


Complex Problems and Light-weight Project Management

I'm currently working on a new project which aims to reexamine one of the key components of our economy and how it might be modified to reduce waste, risk and in the process increase productivity and profit. As you might surmise, it is connected to the built environment.

I was reviewing some thoughts and notes with one of the team members last evening and the topic of  light-weight project management tools came up. If you aren't familiar with the term you probably have heard about Agile and Lean methods. They are the two leading PM methods classified as light-weight methods. Each has their own areas of application, one does not substitute for the other and there are dialects within each of these major classes. On the Agile side are two major dialects called Scrum and eXtreme Project Management (XPM). Scrum being the oldest and eXtreme being younger and having Doug DeCarlo as it's creator and proponent. Scrum came out of a skunkworks kind of environment and is almost totally focused on software development where Mr. DeCarlo's methods are used largely in the software world there is a growing interest and adoption of his simpler more transferable concepts in other domains.


Cost Benefit Analysis and BIM

Cost Benefit Analysis (CBA) is one of those rare and arcane accounting tricks accountants use to help us understand which tire, window, home appliance, or building facade system is most cost effective for the benefits delivered. Pretty rarefied stuff for most of us, but when you stop and think about it CBA is one of those data inputs we need when making good decisions in a collaborative IPD / BIM environment.

One of the great benefits of BIM is the ability to quickly substitute individual component elements for others using global commands. The BIM authoring tools do all the counting for us, we just need to put in the modifying variables like life cycle times, cost per unit measured and a benefit ranking analysis. Some BIM authoring tools allow you to store


Design Age: Six Characteristics of Modern Design

Design Age; Six Characteristics of Modern Design

I've been trying to describe the means and methods of failures in the larger design profession for a few years now. Every time I think I might have some of it defined, I find more to work on and less confident of a succinct set of reasons. The old "the more you know the more you don't know" paradox. If we look at software design is a veritable Eden of failure and and looks like a Gobi desert of success. The expectations of success for software design, delivery and maintenance are so low right now that anything that even looks or smells like it might be a partial success is hailed as a breakthrough. But compare metrics of completed, tested and proven work over time against any other domain and you see how horribly we fail as software designers. But I don't want to waste all my rocks on the lowly IT folks, there's plenty to go around in the physical product design professions as well, and don't forget the built environment folks who haven't had a serious  breakthrough in productivity since the Department of Commerce began tracking such stuff over 45 years ago. By the way software is in the non-farm sector, so that line would be better if it were taken out.

While I'm still looking for more definition around the failure of more and more design projects I have found six characteristics which I and others seem to find present more often than not. If you read my lead-off post about wicked problems I confess some of these characteristics define wicked problems, but more on that later.

Here are the Six.
1. Solutions are needed to further understand the problem.
2. There is no point defined before we begin that says we have solved the problem. Rittel called this the "no stopping rule."
3. Every problem is unique unto itself.
4. Hence, every solution is "one-off" not to be repeated again.
5. Solutions are not right or wrong.
6. There is no commonly understood alternative solution

So, for all you Type A control freaks out there (I'm one as well.) this is not good news. Just when you think you have an answer to a really difficult problem, there is someone out there ready and willing to punch really big, and I mean huge honking holes in your precious solution you've been working on for the past year. So what are the quintessential problem solvers to do? Horst Rittel thought it might be irrational to continue trying to solve problems of the more complex nature by individuals, since the iterative definition of solutions lead to more problems in an ever spiraling circle of failure.

Now there has to be some kind of way out of our dilemma and several folks over the past 25 years have suggested that first we quit trying to solve difficult problems as individuals. Get more people together, get more experience together, and then agree to ground rules that let you work together productively. One of the first, and rather off-putting to our democratic sensibilities, is that majority agreement does not always rule. Rather seek a plurality of consensus not agreement. I know it's a fine line we tread here, but it is a central tenant for making any progress with these difficult problems. Consensus is that dirty little secret lying in the closets of politicians. They rule by cajoling, deal-making and moving power around. That can lead to a form of consensus, but there are positive ways to reach the same thing. I'm not talking about forced compromise, but reaching an agreement to move forward, regardless of prior position or thought.

NOUN: consensus

  1. An opinion or position reached by a group as a whole: "Among political women . . . there is a clear consensus about the problems women candidates have traditionally faced" (Wendy Kaminer). 
  2. General agreement or accord: government by consensus.
You don't see anything about majority of opinion or position, just an agreement to move on. Often a plurality of agreement is as much as we can expect and need from a group of varied stakeholders with a likewise myriad base of experience. And just as important, is consensus can be changed at a later time without serious loss of face or power position, since after all it was just a consent of the group at a point in time, given the information at hand.

But design, isn't that a different thing? Isn't design something that has tangible outcomes and results we can measure success from? Sure it is, but we've been enduring bad design since the dawn of man. It's what trial and error is all about. And this gets back to the first common attribute, "it takes another problem solution to understand the direction toward a possible solution". Now the inferred element is that the earlier effort had some element of failure. Now I'm a proponent of failing fast and often, just to find out what does and does not work. I say better to get it out or the way instead of burying it and having to deal with the failure later, for I've found your sins will surely find you out, eventually. So consensus and being willing to fail are two partners that work well together, if we are all willing to take those mental positions.

Design is becoming more and more complex. Most of you all know that the simpler something looks the more is being done for you and the harder it is to make something that is really difficult look and feel simple. In our world of instant gratification, everyone has the expectation that something will be easy, simple and intuitive. If we can't figure it out without instructions, then it's too hard and we don't want to put in that much effort. We would rather have a tool that is easy to use as long as we can live with the results. Results don't have to be perfect, just acceptable. But on the other hand we really do wish for perfection and would like to have it if we could get it.

Take for instance the clothes washer that is connected to the internet and will call the manufacturer if the spin speed isn't fast enough, or if the fill cycle didn't work just right. Those are two functional elements in the washer that the manufacturer could trigger the washer to run a diagnostic routine to find potential reasons for their existence and potentially have some adjustment in the controls circuits to reestablish the proper set points so the fill cycle works correctly and the spin cycle gets the clothes spun to the correct dryness. If those solutions did not work they could send a warranty repair notice to the local repair company and send you a notice via sms messaging, email or phone call, or all three, that someone was going to come and check out your new washer.

The simple sensors, logic controllers and communication devices are the easy part of this scenario, it's the people part that is difficult, but you can see the problem is far more complex now than even five years ago when we simply bought a washer and used it until it demonstrated some kind of serious problem. We called the repairman on our own. Yet we see the design requirements are far more complex in today's world of possibilities. There is a direct correlation between the greater number of design requirements and the greater possibility of failure, yet we still expect the washer to be simple to operate, convenient to use and efficient in it's consumption of water and energy and the results of consistently clean clothes the results of our efforts.

In the above scenario not only were the mechanical, electrical and industrial designers expected to deliver a great product, but a new element of coordinating a customer service and warranty repair program were also part of the solution. Three very different kinds of organizations, but necessary for the design requirements of this washer. It is a wicked web we weave and one with many sticky points along the way to say the least. Today product manufacturers are expected to deliver not only on the technological side, but the soft side as well. It's not something manufacturers are well known for doing well. But that is the world consumers have been told is possible and that is what they are demanding with their purchasing power and their social media power.

Do pity the poor designer who has to figure out who and how these problems will be solved. Fortunately for some product manufacturers they have awakened to the possibility of an entire continuum of people to solve these problems is much better than a single person or team from a singular viewpoint. More on the other points later...... Continue to part two