Work Transformation Method Application

As mentioned in a previous post, one of the projects I have completed as part of the MIT SDM program has been to look at the process of diesel engine aftertreatment system calibration.  The project team for this assignment was Genevieve Flanagan (lead), Candice Engler, and I.  Also supporting us was Oliver de Weck and Arun Balasubramaniam.

After-treatment systems are those components on diesel engines that remove particulate matter (soot) and nitrous oxides (NOx) from the exhaust.  Since the introduction of the U.S. Clean Air act, there have been several levels of decreasing particulates and NOx levels mandated; these are sometimes referred to by tiers (Tier I, Tier II, Tier III, Interim Tier IV, Final Tier IV).  Because these are regulatory mandates, a producer of engines must either achieve the mandate or not ship engines.  Producers of engines also do not want to compromise performance of the engines to meet regulatory requirements.  From a project perspective, this is a project that has fixed scope and schedule.

As producers of these cleaner engines have moved up the tiers they have come to rely more and more on software to control the after-treatment systems in order to meet the regulatory requirements.  Part of the process of preparing these engines is to calibrate them and their software in a test environment.  Calibration activities are resource intensive, both in terms of human labor and capital for the test cells.

When talking with the after-treatment team the calibration activity was largely treated as one large task, with lots of iteration within the task.  The variability in the effort and duration for the calibration of each engine configuration was considered unacceptable by stakeholders.  We also learned that the after-treatment team had built a design structure matrix showing the calibration and other dependencies between the components (physical and software) of the after-treatment system.  The DSM was highly coupled, with few small independent components and one large meta-component.

We investigated various mechanism to better plan the calibration activities, including a signal flow graph approach and visibility matrices.  We settled on using a work transformation approach to create the engineering iteration model.  We used the DSM to determine a series of 24 design steps (things that were later labeled "sensor calibration" and "determine soot model", as examples) required for engine calibration.  These calibration steps still happen iteratively (e.g., an activity done during step 2 may require rework in step 1), but now there are identified calibration modes (as opposed to one large task before).  The next step will be to build a probabilistic schedule (most likely using the signal flow graph approach) for the whole calibration activity based on the twenty-four calibration modes.

Another interesting outcome of this project was that a DSM that represented the system architecture of the system was able to be reused, after mathematical transformation, as a project planning tool.  This means that changes to the system architecture can be used to update the project plan with mathematical linkages to the underlying architectural change, including determining project impact of proposed changes.

MIT Systems Design & Management

This year I wrapped up my first of two years in MIT's Systems Design and Management (SDM) program on my way to a masters of science degree.  SDM is a joint degree from MIT's Engineering Systems Division and Sloan School of Management; I describe the program as an engineering management degree.  For me, SDM is a 24 month program.  I have been completing the degree remotely while I retain my full-time employment status.

Normally SDMer's start their program with a boot camp in January.  Because of unusual circumstances, I have my boot camp experience at the beginning of the second year of the program.  For January I will be spending full time on campus completing a few courses and participating in various design challenges, professional development sessions, and cohort building exercises.  The required courses include a review of statistics and probability and a course on the human side of technology; if I can fit it in I plan to take another course on technical writing.

The last year of the program has been a very positive experience, even with the required juggling of work, family, and school.  The classes have been everything one would expect from MIT.  So far my courses have included product design & development, real-options in engineering systems, systems engineering, systems architecture, concepts of supply chains, systems project management, and engineering analysis and design.  The projects completed during the classes have been challenging and (I think) beneficial to a better understanding of various systems.  I'll plan to write a few follow-up blog posts on the projects:

• Use of Real-Options to Value Vehicle Telemetry Designs
• Multi-attribute Utility Applied to Integration of Bio-alcohols into Existing Distribution Infrastructure
• Use of Design Structure Matrix and Work Transformation to Plan Diesel After-Treatment Calibration Projects

If any is more interesting to you, just post a comment and I'll plan to comment on it sooner rather than latter.

Over the next year I have many more Sloan (aka management) courses to complete, a few ESD courses, and a thesis to write (of which I am still trying to settle on a topic).  I'll work to keep everyone updated as the next weeks and months unfold.

Cheers, Hank

Lean and Agile Software Architecture - How Much Up Front Architecture?

I was recently asked by a colleague a question about how much 'upfront architecture' should be done if the systems development project is going to use and Agile approach. My response is below...hopefully it helps others when they struggle with answering this question.

I would say it depends (big surprise) on several factors – A lot of this comes from Lean thinking, not Agile.

In Lean Architecture (Coplien & Bjornvig) the authors say Lean is typified by a Plan-Do-Act cycle, whereas Agile is typified by a Do-Inspect-Adapt cycle. In other words, Lean = Think then Act, Agile = Act then Think. Both have their place, so knowing when and how much to do of each is important.

Here are some factors that might drive one to more thinking before acting or acting then thinking:

• Does spending time up front thinking offset by an increase in ‘fraction correct and complete’ of work (i.e., decrease rework) enough to justify the time thinking. This could be quantified with modeling, but we would need historical information in order to calibrate the model.
• How well can you predict the future? Forecasts are wrong, forecasts further into the future are more wrong. If the future is highly variable, it might lead to less up front planning and more adapting. As long as this adapting (rework!) is planned into the project schedule/budget.
• How important is it to get it right up front? In space satellites you only really test the satellite completely when you launch it, so you better get it right the first time. In pure software-as-a-service system you can write a few hours or days of code, push it into production, if it’s wrong you can rollback and try it again. I’m guessing our projects are at neither extreme.
• Projects at scale require intentional architecture; laying runway for features. A big piece of intentional architecture is defining the interface requirements. (It’s also part of requirements management). Maybe one can be lean by defining the interfaces using self documenting code (javadoc style) with stubs and example clients (so that the clients become part of the documentation, and give one a feel for the elegance or lack thereof of the API). Projects success is highly correlated with the quality and completeness of the interface requirements (including API and human-computer interface) agreed up front.
• A study of several systems projects said 5-15% of the total project budget should be spend in CD (concept design phase) and PD (preliminary design phase) to bring about the most successful outcome to the project. This 5-15% cost expenditure, depending on the project, may be up to ½ of the project schedule. (INCOSE Handbook of Systems Engineering).

This probably doesn’t answer the question, but maybe it gives some guidelines that will help you decide which way to go.