In our first semester we learned about issue trees in MP and event trees in DDA and how they help break-down problem statements into solvable nuggets. In addition to these trees, here are three more analytical frameworks to breakdown problems:
Means-ends networks: The initial problem statement is broken down by identifying all the obstacles that hinder reaching the goal. Then develop an action to get past this obstacle and in turn identify new obstacles that would thwart this plan. When all of these levels’ impediments are addressed, the overall problem statement should be solved.1
Objective hierarchy: Another hierarchical structure where a broad objective is developed out of the problem statement at the highest level. This objective is broken down into narrower objectives. As the objectives get narrower they take the form of actions, therefore they are called ‘means objectives’.2
Consequence tables: This structure is useful in comparing multiple options. List the multiple alternatives on one axis of the table and attributes to compare on the other axis. Give each alternative a rating for each attribute (the rating being relative to that of the other alternatives). Color coding the ratings based on different thresholds visually helps in comparing the alternatives.3
Looking back at our past two MP project I feel as though a means-end network would have been very beneficial (in addition to the issue trees we developed). There were several obstacles in both the Carlos Museum and Delta projects that needed to be sorted out and solved at a basic level.
Although the MP projects we were given the previous two semesters were real issues, one aspect that was limited (due to the sheer number of students) was a constant engagement between us and the firm we were trying to help, to narrow the scope. Boiling down to the scope was part of the MP learning process, however Detlof von Winterfeld and Barbara Fasolo point out in “Structuring Decision Problems: A Case Studying and Reflections for Practitioners” how much of an iterative process structuring a problem and decision analysis can be. Shown below is the decision analysis ‘snake diagram’ that clearly shows the back and forth that is necessary, especially in the early stages of a project, between the decision board (decision makers) and the decision team (decision analysts – those that are responsible for formulating a solution). After being given the scope of the problem, the decision team has the decision board sign off on their understanding of the problem prior to moving on. This gives the decision analysts an opportunity to refine the scope of the project with the assistance of the decision makers.
Brainstorming is also included in the way of developing alternatives and assessing them. Not surprisingly the Plan for Action and Implementation only take up a third of this process with most of the foundation work being done prior, as was suggested in MP.
Figure 1. Spetzler Snake Diagram for Decision Analysis. von Winterfeldt, Detlof and Fasolo, Barbara, “Structuring Decision Problems: A Case Studying and Reflections for Practitioners” (2009). Published Articles & Papers. Paper 30.
At work I am often tasked with ensuring that younger engineers are billable on my projects. I find this task much more difficult than the project itself, probably because of my ineffectiveness at delegation. Carl Selinger, in The Art of Delegating, discusses 4 ways engineers can be better delegators:
“Clearly describe what needs to be done and by when”: Here Mr. Selinger discusses creating the proper framework to allow the delegate to be successful and communicating this framework to them. I have experienced where a misinterpretation by the person helping me results in them progressing down the wrong path. However, it is also important to not construct a framework that is too restrictive as it limits the delegate’s creativity. Mr. Selinger’s next point also speaks to this.
“Accept that the work will not be done exactly as you would have done it”: Provide the delegate with some freedom in making decisions – this may result in them making mistakes, but in my experience the feedback they receive from those mistakes is their best learning tool.
“Keep track of delegated work”: It is up to the delegator to keep track of all delegated work. I think it’s important to let the delegate concentrate on the details of tasks they have been assigned and leave the tracking of their progress to me.
“Give constructive feedback and criticism”: As I mention above, the feedback engineers receive on their work is the best way to learn. Mr. Selinger calls for “good, substantive points”. I think all feedback should first discuss the project at hand and also include a more generalized version so that the younger engineer can apply it to future tasks.
