Read monthly Project Performance International's Systems Engineering Newsjournal, named "PPI SyEN". PPI SyEN presents for the engineering professional 30-60 pages of valuable technical articles on topical subjects, shorter technical pieces, in-depth coverage of the month's news in systems engineering and directly related fields, pointers to useful resources and relevant industry events, plus limited information on PPI's activities.

Welcome to PPI SyEN 45


Quotations to Open On

Read More… (link/anchor to Quote)

Feature Articles

Partnering in Systems Engineering, by Charles D. Markert

Building a Virtual Software Engineering University (Channel 18), by Capers Jones

Read More… (Link/anchor to article)

Systems Engineering News

PMI, INCOSE, and Lean Advancement Initiative (LAI) at MIT Partner to Find Best Practices for Delivering Successful Programs

Applied Systems Thinking & Engineering in Healthcare

Business Leaders Need Systemic Thinking for Sustainability

It’s Time to Rethink Our Approach to Safety Engineering

Tom Gilb Awarded Honorary Fellow at the British Computer Society

Read More… (Link/anchor to News)

Featured Societies – The Council of Engineering Systems Universities (CESUN)

Read More…(link/anchor to Societies section)

Systems Engineering Tools News

SysML Design Quality Metrics Supported by SDMetrics V2.3

Read More… (Link/anchor to SE Tools section)

Systems Engineering Books, Reports, Articles, and Papers

The Complete Project Manager: Integrating People, Organizational, and Technical Skills

The Complete Project Manager’s Toolkit Use SyEN Body Bullets

Design Structure Matrix Methods and Applications

Flexibility in Engineering Design

Technology, Globalization, and Sustainable Development: Transforming the Industrial State

Object-Process Methodology: A Holistic Systems Paradigm

Systems — A New Interdisciplinary Open Access Journal for Systems Science and Engineering

More-Mud​dling-Thro​ugh-Engine​erring (TBP)

Does model-based engineering make sense?

Read More… (Link/anchor to SE Books, Articles…)

Conferences and Meetings

Read More… (Link/anchor to Conferences section)

Education and Academia

Colorado State University Adds Online M.S. and Ph.D. to Systems Engineering Offerings

Postdoc Position on Coverage Analysis of Concurrent Specification, Languages, Inria/LIG, France

UW–Madison launches online Sustainable Systems Engineering Graduate Program

Institute for Systems Research, University of Maryland

Read More… (Link/anchor to Edu/Academia section)

Some Systems Engineering-Relevant Websites

Read More… (Link/anchor to Websites)

Standards and Guides

SySML 1.3 Released

Read More… (Link to Standards & Guides section)

Some Definitions to Close on

Failure Modes and Effects Analysis (FMEA)

Failure Modes, Effects and Criticality Analysis (FMECA)

Fault Tree Analysis (FTA)

Event Tree Analysis (ETA)

Read More… (Link/anchor to Definition)

PPI News

Read More… (Link/anchor to PPI News)

PPI Events

Read More… (Link/anchor to PPI Events)

Quotations to Open On

Time is not measured by the passing of the years, but by what one does, what one feels, and what one achieves.


Behold, I will do a new thing; now it shall spring forth…

-Isaiah 43: 19 KJV

Feature Article

Partnering in Systems Engineering

Charles D. Markert

charles.markert (at) gmail.com

Copyright All rights reserved.

Table of Contents

Introduction 1

Genesis 1

Why do this? 2

What is it? 2

The Process 3

Agenda for Typical Partnering Workshop 3

How Partnering is conducted. 4

Observations 6

Conclusions 7

Resources: 7

Seven Principles of Partnering 8

About the Author 9


Like Systems Engineering, Partnering comprises a deliberate, well defined process to be used to achieve a desired outcome in a complex and unpredictable environment. The intriguing thing about partnering is that it comes close to being a systems engineering approach to human behavior on a project.

Let’s face it. We are usually engineers who think in logical, fact based reality. When things go wrong, we believe there must be some hidden reality we can uncover and design some countermeasures to make it work. This is also true of less predictable and less visible human interactions. Both of these realities introduce risk into the project and need to be mitigated.

As complex as inanimate mechanical, electronic and chemical systems can be, the human interactions can be equally difficult to predict, control, and mitigate unintended consequences. Systems Engineering swims in the pool of variables such as: unforeseen conditions; oversights; interrupted schedules; erroneous requirements, changed circumstances; conflicting functionality; etc., etc. One of the biggest variables in systems engineering as well as any multi-faceted endeavor is the human element.

Carbon Units (aka people) are the most ignored components of success even though there are many solutions. Most solutions depend entirely upon that elusive thing called “leadership that inspires teamwork”. Some have it, most do not. Partnering is a process driven manifestation of leadership, collaboration, and cooperation. Those of us trying to ‘herd cats’ (lead a team) can appreciate such a process that has been proven to work through thousands of applications. We appreciate leadership that works especially when we are participants in and subject to others leading the team.

1 Genesis

Partnering is an overlay on a project. It is a supplement to project management. It is an often neglected need for which the price we pay can be very high. The brain power can exist on the systems engineering team and yet go unused or at least sub-optimized.

Partnering was originally designed for parties to a contract to develop an agreement on how to behave toward one another. The contract spells out the terms and conditions, the material, size, shape, color, location, fit, function, reporting, timing, cost, and quality of the deliverables but it does not spell out how the individuals involved should cooperate, collaborate or communicate with each other. See Figure 1.

Neither Systems Engineering nor traditional Project Management addresses this as a part of normal business. It is crucial to point out that Partnering does not usurp either set of methods. I come from the world of facility design & construction and discovered what the US Army Corps of Engineers (USACE) did to start partnering. My previous organization, the Naval Facilities Engineering Command (NAVFAC), adopted the process and had equally good success. After my career with NAVFAC I became a group process facilitator and developed Partnering as my specialty. In doing so, I adapted partnering to large IT contracts. It does not matter what the product is of the endeavor. It can be a construction project, an information technology work order, or a service agreement. The common denominator is that a cross-organization team is involved.

2 Why do this?

The benefits are huge. Partnering collectively saved USACE & NAVFAC upwards of a billion dollars in litigation. It is truly amazing what can be done by building a functioning, high performing team in a technical environment. In the private sector, since litigation is not as prevalent as in the public sector, (as far as I can tell) the benefit takes on a slightly different emphasis. However there is universal emphasis to complete a project within budget, on-time, and smoothly because this means more business in the future. The bottom line benefits all concerned.

Now for the puzzling part. Partnering is still not taught as part of Project Management nor is it in the Systems Engineering Curricula. I have been privy to some of the reasons why this is so. Personal and professional egos have a large part in the ignoring of this excellent tool/process. “This is just common sense and is built into good Project Management.” I beg to differ. Firstly, there is nothing common about common sense. Secondly, if it happens on a project it is because of the tenacity of some high ranking individual who insisted on it. Otherwise it suffers from the almighty and ever present “assumption”.

I witnessed the demise of the quality movement at the hands of leaders who said ‘this has become ingrained in our way of doing business, so we need not refer to TQM (or CQI, etc.) nor do we need Process Improvement Teams (PITs) or Quality Management Boards (QMBs).’ When these died out and the vocabulary of Quality Improvement was dropped, the system reverted to its prior equilibrium where excellence occurred less frequently and only at the hands of the few who “got it”.

Figure 1

When the leader at the top insisted on Partnering, it worked. There are many federal agencies and state highway departments using this concept on their construction projects today. There are but a handful of technology corporations using it. It does not matter whether the project deliverable consists of bricks or bytes. This process works on any type of project where there is cooperation and collaboration needed for a multi-disciplined and/or a multi-organizational team.

Partnering is as much about your success as it is about the other party’s success. Once you both figure out what the other party wants, getting there is often the easy part. Headaches go away, pains in the neck disappear, posterior discomfort is eased, less Maalox is consumed and you become better looking. What’s not to like?

Partnering, when done properly causes people in the participating organizations to look out for the other organizations’ best interest and are happy to do it. They work together, happily creating better solutions to the inevitable problems. Management’s best practices actually work when they are launched in a culture where communications flow easily. Partnering is the tool, technique, process, and philosophy, which enables this to occur.

3 What is it?

The components of Partnering are not new. Partnering in the construction industry has been widely adopted for federal and state construction projects and has begun to be accepted in the information technology industry and a few other industries. The business sector claims to be practicing partnering. What they call partnering is usually a simple partnership or joint venture.

Partnering as defined by Construction Industry Institute’s report, ‘In Search of Partnering Excellence’, 1991, is as follows: “Partnering is a long term commitment between two or more organizations for the purpose of achieving specific business objectives by maximizing the effectiveness of each participant’s resources.”

It is important to define partnering because most of the time, when partnering is said to be used, it merely means people are simply working together or it means it is a legal partnership. Partnering for the client is simply the confluence of the formal partnering approach with the actual conduct of business. It is either between internal divisions or branches or their contractor at various levels. It enables improved productivity.

It is fundamentally the alignment of purpose, team behavior, and a focus on problem solution and prevention. The structure of the approach opens doors and promotes cooperation that might have only occurred through individual initiative in spite of the organization, not because of it.

The vast untapped discretionary energy and potential of those who do the work can be unleashed only by providing the opportunity for their internal self-motivation. The old adage that motivation is an inside job is true. All employees have the choice of doing just enough to get by or doing more than ever expected. Partnering unlocks this potential because there is something in it for everyone.

Partnering relies on the participation of all authority levels of a project organization. An initial planning session of a few hours with the leadership team, including the Champions, is required to set the stage and get the leadership on the same page. See Figure 2. It is important to get all expectation built around one definition of partnering.

Figure 2

This is preliminary to the Initial Partnering Workshop also known as the Charter Workshop. This is typically a 1 to 3 day offsite session with the key players from all levels of the chain-of-command for all participating organizations. The Partnering team builds an agreement called a Partnering Charter that they sign and commit to for the life of the project. As the project progresses, occasional Regular Partnering Workshops are held as agreed upon during the Charter development. These meetings are for the entire team and are typically monthly or quarterly for 2 to 6 hours in which the use of partnering is assessed, discussed, and adjusted if necessary. The meeting also includes Issue identification and actual team-based problem solving.

4 The Process

The process is as follows. First, decide you want to embark on this journey, and then find an expert concerning the partnering process. These are usually Partnering Facilitators and they should be independent from the project. Be aware that anyone can claim to be a partnering facilitator so it is up to you to be sure they are properly “vetted”. They can be contracted from an outside organization or they can be from some other part of your organization. The issue here is one of trust. An independent third party will be viewed to be less biased than an employee of one of the parties to the project. Without a facilitator your meetings will likely be business as usual. That is, they will be a BOPSAT (bunch of people sitting around talking) and little is accomplished except for a few of the most vocal.

One of the most neglected aspects of partnering is celebration of progress. We all know that behaviours that receive praise and recognition get repeated and multiplied. Likewise that which is criticized gets avoided. Some of us are real good at criticizing. So much so that the focus of such criticism begins to exercise strategic withdrawal to avoid pain. Let’s just consider the positive side of the equation for now because the prevailing attitude is “why praise, it is part of his/her job and he/she knows it.” That attitude results in so much missed productivity it is not funny.

Some celebrations are no more than a public pat on the back; other teams may have a BBQ on company time at major milestones. Your imagination can produce a plethora of ways to encourage high levels of performance and positive behavior. It is also stealth teambuilding. Frequency of celebrations and regular follow-on partnering workshops can vary depending on how well partnering is being sustained and how much emphasis is needed.

The Initial Partnering Workshop contains a large amount of work to be done as shown in the figure below. This is one reason why a professional facilitator, or an internal consultant trained as a professional facilitator, is needed.

5 Agenda for Typical Partnering Workshop

A typical agenda for a two day Partnering Workshop is shown in Figure 3 and listed as follows:


1. Introductions

2. Personal Expectations & Concerns

3. Present Project Description

4. Present Organization Charts

5. Partnering Described

6. Characteristics of Worst & Best Projects

7. Rocks In The Road (Real & Potential Problems)

8. Teambuilding Exercise

9. Personal Style Discussion

11. Paradigm Video or AGC Video

12. Goals Desired by each Organization

13. Discovering Potential Common Goals

14. Vision Discussion (Identify Elements)

15. Identify and Rank Values to be Practiced in the Workplace

16. Entire Group Develop Draft Vision Statement


1. Breakout Session to do Problem-Solving for Highest Priority Problems

2. Report-Outs

3. Breakout Session (Writing Vision, Goals, Guiding Principles)

4. Report by Subgroup

5. Feedback to Subgroups

6. Breakout Session to Refine Goals, Vision, Guiding Principles

7. Report Back by Subgroup for Consensus

8. Identify Gets and Gives for Each Organization

9. Develop Issue Resolution Process

10. Create Partnering Evaluation Process

11. Create Implementation Strategy

12. Ratify/Sign The Charter / Group Photo

Figure 3

All participants have a tendency to jump right into the specifics of the project that need attention. While the initial Workshop is not designed for this, we include a little issue identification and problem solving to help assuage this urge somewhat as we develop the team’s problem solving skills. It sets a standard for a problem-solving process.

Real or potential issues can then be identified using surveys, brain-storming, and the ‘gets and gives’ tool. Teams are launched to deal with selected real or potential problems. A peer ladder is developed to resolve issues. A feedback/assessment process is designed. The implementation plan is developed to include monthly or quarterly facilitated follow-up sessions. These sessions address both the progress on issues, problems, and goals as well as an assessment of how well the Partnering Charter is being followed.

Figure 4 depicts how the agenda items contribute to the creation of the various work products that are the ‘fingerprints’ of partnering.

The process is complemented by whatever additional tools the facilitator can provide. A secret to success in any team endeavor is being able to draw out the best from everybody. We have all been on a team at one time or another that performed amazingly well and everyone had an enjoyable time on that project. Problems were raised and solved quickly, the right people were available when needed, and things went smoothly. This approach helps that happen more often.

It is entirely appropriate to combine facilitation methods, tools and techniques used in other disciplines to identify requirements, resolve issues, and generally further the progress. The “Gets and Gives’ Matrix is one such tool. Many facilitation tools commonly used in requirements gathering, strategic planning, Business Process Re-engineering (BPR) and creative problem-solving can be used with excellent effectiveness.

Figure 4. Work Product flow

The best approach, and most attractive to managers, is for an organization to get its internal act together first with a few sessions and then to venture outward to conduct Partnering sessions with their primary stakeholders or contractors. As an example, the ship operations department may do Partnering with the finance and acquisition departments, all of whom can, and do, benefit from improved communications and better working relationships. It may also be wise to conduct partnering sessions between headquarters and regions.

6 How Partnering is Conducted

The following is a description of the initial Partnering Workshop in which the Charter, Escalation Ladder, Problem Solving approach and Evaluation Process are created by the team. Major elements of the process, based on the typical agenda, are discussed below.

Team Building:

A basic aim of this endeavour is to build a high performing team of people doing everything possible to make the project successful while avoiding conflict. Teambuilding should not be just a bunch of “touchy-feely” exercises for the sake of teambuilding. My approach is to minimize the number of exercises and then be sure to explain the learning point afterward. Stealth teambuilding is preferred. Also, the simple act of getting to know the other team members is helpful. Understanding the fact that people have different styles of leadership, followership, and communication is helpful with individual relationships

Same Page Discussion:

There are many meanings for the word partnering and this can cause confusion and erroneous assumptions. A short briefing using the dreaded PowerPoint gets everyone to understand what Partnering is and why the leadership has chosen to do partnering on this project. This is also an opportunity for those members who have experienced partnering in the past to share their experience and observations.

Charter includes Vision, Mutual Goals and Guiding Principles and is signed by all participants:

The concept of the Charter is to memorialize the agreements reached in this Initial Partnering Session. It makes public the promises made by the team members to each other and to the project.

The project Vision Statement is created much like a Vision Statement is done in a Strategic Plan for an organization. The entire team brainstorms suggestions, then a small break-out group uses them while crafting a proposed statement for the entire team to consider, modify and ultimately adopt.

Mutual Goals are created based on the ideas brainstormed and discussed regarding the ideal project, lessons learned from previous projects, specific organizational interests, and participant expectations. These are selected based on their commonality across organizations. This is to ensure that the emphasis and effort benefit all parties and not just one special interest.

Guiding Principles adopted by the team are generated for the values that they want put into practice in the workplace. The top few (5 to 7) are assigned to breakout groups to write an operational statement for each value that describes behaviours that embodying that value.

These comprise the Charter which is adorned with the organization logo, printed out, and signed by everybody at the end of the workshop. A team photo is taken at this point.

Evaluation Process:

The evaluation form includes the goals and guiding principles as well as general questions about how well partnering is being used during the project. Each item is scored on a scale of 1 to 5 by each team member. This is done on a regular basis, compiled anonymously, and shared at each follow-on partnering workshop. It is not an exercise in laying the blame; but is focused on determining what must be done to improve the low scores by the next evaluation and on celebrating the improved scores.

Action Plan with Next Steps:

Near the end of the workshop the team addresses actions that need to be taken, by whom, and by when. These include communicating the substance of partnering to all who were not present, arranging future meetings, and taking actions uncovered in problem-solving – each person develops a personal “Path Forward”.

Issue Resolution/Escalation Ladder:

The Issue Resolution/Escalation Ladder, Figure 5, is a unique, structured approach to problem-solving that facilitates quick resolution of issues. The chain of decision-makers for each organization is aligned into a ladder format so it is crystal clear who the counterparts are across organizations.

Figure 5 Issue Resolution and Escalation Ladder

The team recognizes the likelihood that problems will occur. They adopt a process of identifying and resolving these issues at the lowest level possible in the shortest amount of time. This process is called the Issue Resolution Ladder and it is for the entire team to use.

The ladder was developed by the US Army Corps of Engineers (USACE), Mobile District, in the late 1980s as part of their new Partnering Process. USACE did this as part of a highly successful effort to reduce or eliminate litigation.

Rules for Escalation: The process of elevating an issue from a lower level progressively through to a higher level for resolution is called Escalation. Below are several general guidelines most often used for rules:

1. Resolve Problems at the Lowest Level

Once an issue is identified, at whatever level it appears, you and your counterparts at that level have a responsibility to resolve the problem within a specific period of time before escalating it to the next level. Obviously, this is most effective when more authority is delegated to the lowest reasonable level.

2. If Necessary, Elevate Problems Quickly and Simultaneously

When it becomes apparent that the issue cannot be resolved at that level, it is mutually agreed to elevate it to the next level of authority quickly and simultaneously. The period between escalations increases as the level increases. If the issue is not resolved within that period, together, they must quickly escalate it to the next level.

3. No Jumping Levels of Authority

Once it is determined that escalation is necessary, it is moved up one level on the ladder where it must be attempted to be resolved. Skipping a level usurps the process and erodes communication and threatens to delay decision-making.

4. Do Not Ignore the Problem

Inaction is unacceptable. The problem will likely not go away. In fact it will surely take longer, grow bigger, and cost more to resolve later.

5. Make Only Decisions with Which You Are Comfortable, Elevate the Rest

If the needed expertise and delegated level of authority are at that level, then by all means make the decision and move on. If you do not possess either the expertise or authority, then escalate it simultaneously so there are no surprises at the next level. Invite all parties to participate at each step of the ladder, as appropriate, when solving the problem.

Identify the people: The ladder is designed to identify specific individuals on each level of the ladder. It is tailored to the structure of the team. Include everyone’s contact information on the formal Ladder documentation.

7. Observations

Partnering is a process. It requires time, commitment and follow-up from a team of people who are regularly involved. Sometimes, a project manager may call a “partnering meeting” for problem solving on the job. Partnering promises the benefit of the most efficient form of conflict prevention. It also builds positive working relationships, and establishes the climate for creativity and innovation which is so important over the full term of the project.

Partnering does NOT modify the contract documents or existing “chain-of-command. The new working relationship which is created by Partnering does not amount to a modification of the basic contract documents. Partnering creates a climate of cooperation and collaboration aimed at achieving jointly defined goals which are fully consistent with the agreed upon project.

The Partnering Charter is a voluntary promise. The Charter does not establish enforceable rights or duties. When parties agree to conduct their working relationship in a new way through principles written in a Partnering Charter, they do not create a contract. Their purpose is aspirational and inspirational, rather than legal; they aspire to achieve jointly defined goals for success and they voluntarily commit themselves to work together in productive ways.

The Partnering relationship is attractive to participants because it promises cooperation rather than confrontation in the workplace, and it also offers the possibility of significant improvements in quality and profitability. Partnering is voluntary.

Partnering is two way. Partnering is just what the name implies, a joint effort toward common goals. In terms of collaboration and problem solving, it is a two-way street. When used in its most productive way, Partnering can be more than an agreement to give-and-take. Collaborative problem solving is the only way to reach the elusive ‘win-win’ solution to a conflict. At the Partnering workshop, team members experience the value of working together as they discuss common goals, write the Partnering Charter, and prepare action plans. In the melting pot of ideas, the experience and expertise of the whole team is combined synergistically to create outcomes that go beyond compromise to find solutions that address the interests of all. Such a two-way exchange of ideas occurs when people communicate candidly and openly.

Partnering is sharing the credit, not affixing the blame. It is important for the team to remember the Partnering axiom “Fix the problem, not the blame!” When finding someone to blame for a problem is the first concern, problem solving takes a back seat. Partnering requires that the parties take a new attitude toward the risks of the project.

Partnering is NOT “Document to CYA.” A key principle of Partnering is efficiency in communication and problem solving. Partnering emphasizes personal communication: “Talk, then write.” There should be a climate of trust that neither side will try to gain an advantage from candid and frank communications. When team members communicate directly and to the point, they are more likely to avoid misunderstanding, clarify and refine issues, and engage in meaningful discussions. They should be able to find the best solution for the good of the project and team members. Their decisions can then be memorialized with appropriate documentation.

Partnering is NOT adversarial. Partnering proposes a better way of resolving project issues. Instead of hiding information, it is shared and discussed in the team context. Instead of combat, there is productive competition of ideas and views, held in the context of positive working relations based on trust and candour. When team members are enabled by Partnering, they can be “hard” in tackling a problem, while being ‘easy’ on their colleagues who may have differing views. With the explicit goals found in the Partnering Charter, team members can engage in principled collaboration to find the best course for the good of the project and the team members.

Partnering is NOT easy. It is a big mistake to believe that Partnering can be created in a few hours at a workshop and will then automatically yield benefits to a project. The workshop is only the beginning in building productive relationships and processes. It takes constant attention and effort by each individual to promote Partnering attitudes in word and deed. The team must also commit to take the time to check-in on the health of the Partnering relationship and the progress toward the mutual goals found in the Charter. When surveys, report cards, or other feedback processes indicate areas for improvement, the team must choose and apply appropriate corrective action. The team must be prepared to commit resources – people, time, and money – to these efforts. The lesson learned: Partnering works only when people “walk the talk” by fulfilling the Partnering commitments every day.

8 Conclusions

Partnering offers a team the ability to take control of their situation. Participants in Partnering have a chance to eliminate the barriers of miscommunication, blame-laying, and discord. They are given the chance, if they will take it, to pull together toward common goals rather than competing for short term “wins” at the expense of the other participants.

Partnering is not a panacea but it has proven to produce better results, more good will, and fewer frustrations than happen when it is not used. The organization could be performing as well as all the management books say they could. Those books generally do not provide specific tools to use. You cannot build your home without the proper tools.

When the team truly embraces Partnering, the core values of Partnering will be found in the workplace: there will be visible organizational support, personal trust, candid problem solving communication, shared responsibility and opportunity, and concentrated striving toward common goals. When these core values continue to characterize a working relationship, an efficient and effective team can reach for the greatest possible success for all.

The bottom line for systems engineering practitioners is that partnering applies to this profession as much as it does to any other team based endeavour.

9 Resources:

“Partnering in Construction: A Practical Guide to Project Success” by Carr, Markert, et al. published by the American Bar Association in 1999.

Naval Facilities Engineering Command Construction Partnering Handbook: https://portal.navfac.navy.mil/pls/ptl/docs/PAGE/NAVFAC/NAVFAC_WW_PP/NAVFAC_NAVFACLANT_PP/LANT_BL/LANT_CI/LANT_CI5/NAVFAC+PARTNERING+POLICY.PDF

AASHTO Partnering Handbook 2005: http://quality.transportation.org/sites/quality/docs/AASHTO_Partnering_Handbook.pdf

CalTrans Partnering Field Guide http://www.dot.ca.gov/hq/construc/Partnering_Fieldguide.pdf

State of Arizona DOT: Issue Resolution Ladder Report Form: http://www.dot.state.az.us/Highways/ConstGrp/const_manual/Forms/Chapt_1/ResolutionLadder.pdf

Virginia’s Field Guide for Partnering for VDOT Projects November 2005:



Seven Principles of Partnering

1. Align Everyone: The alignment of everyone on the team, and supporting organizations, is crucial to a true results-oriented team effort. When we know where we are going and where we’ve been, we have a better chance to achieve our aim. Mutual agreement on the endeavour’s vision, and goals and guiding principles is paramount to successful Partnering. Mutual and clear expectations are the fuel of accomplishment. Expectations of teamwork behaviours and project outcomes need to be clearly stated and frequently revisited.

2. Selflessly Contribute: A person’s ego can help or hinder the efforts of the team. The ego that drives one to contribute whatever it takes to ensure the endeavour succeeds, is useful and to be encouraged. However, the ego that requires credit for everything one does prevents team building. That ego that engenders the feeling that “I am better than you and you had better listen to me and do it my way” is nothing short of destructive.

3. Be Trustworthy: Playing nice together engenders trust, sharing and a greater sense of belonging to the endeavour. Trust is earned, not demanded. Being trustworthy is the prerequisite to earning trust. Sharing of ideas that can solve problems, save money and/or improve the outcome can help trust to be earned yet most often occurs only after trust is established.

Our basic human response is to seek pleasure and avoid pain. People would rather enjoy than dread an experience. People want to do well and have accomplishments of which they can be proud. We will do great things, given the opportunity.

It is better to prevent a dispute than be forced into an actual dispute. This obvious common sense philosophy is not so common after all. There are many hidden agendas that prevent prevention and destroy trust. It is essential to become aware of these hidden motives and deal with them.

4. Communicate Every Which Way And Often: Communication is necessary and helpful to the team and imperative to the production of quality results. The meagre attempts organizations make to communicate are but lip service compared to the communication that occurs in a successfully partnered endeavour. Unless and until abundant communications is integrated into the business process, it will not be adequate. Regular feedback and resulting action regarding project and Partnering performance is necessary to ‘keep Partnering alive’.

5. Empower People: People empowered to do the job will get more done than those who are not. Those who are micromanaged and given little control over their world of work will have checked their brains at the door of the workplace and delight in watching the organization make stupid decisions. Those who are empowered will help the organization make better decisions. Human nature rules.

6. Synergize To Maximize Brainpower And Energy: The synergy available from a teamwork culture can be awesome. Those who are encouraged to consult with other team members will make better decisions. Problems solved and issues resolved in team meetings will be adopted faster and last longer than those made by individuals in the vacuum of individual perceptions and personal paradigms.

Opportunity either happens by serendipity or you can make it happen. Partnering ‘legalizes’ the proactive approach by encouraging continual issue identification and problem solving by everyone. Having open and honest discussions aids in the search, discovery and prevention of potential problems and the resolution of actual problems.

7. Celebrate Often And Well: Recognition and reward is essential to personal motivation. Recognition for what was accomplished often needs to be nothing more than a ‘thank you’ in private and/or public. Tangible rewards, where possible, are fine when properly shared. Rewarding the team as a whole is much better than only rewarding the team member who worked as an individual.

About the Author

Charles D. Markert, BSCE, MSOE, MPA, CPF

Mr. Markert is an engineer, manager, facilitator, inventor, writer, and consultant. Mr. Markert was a key co-author of the book, “Partnering in Construction: A Practical Guide to Project Success” by Carr, Markert, et al. published by the American Bar Association in 1999. He has been facilitating business process workshops since the early 1990s. He has facilitated partnering, strategic planning, process improvement, team-building and problem-solving workshops since 1996 when he retired from the Naval Facilities engineering Command (NAVFAC). He is a certified professional facilitator (CPF) through the international Association of Facilitators. He also teaches facilitation concepts and practices to group process facilitators. He is currently the CTO and Chief Engineer for CavitroniX Corporation.

He currently resides in Purcellville, Virginia and can be reached as follows:

Voice 540-338-1255, Cell 202-498-2308

Email charles.markert (at) gmail.com

Building a Virtual Software Engineering University (Channel 18)

Capers Jones

June 2012


Copyright All rights reserved.

As of 2012 the technologies exist to create a virtual-reality software university that would resemble a real university, only with more sophisticated access to learning materials. The essential idea is to use concepts from virtual reality sites such as Second Life but apply them to practical software education topics.

In order to do this the process would start with licensing a virtual reality rendering engine from one of the sophisticated computer game companies. But instead of using the engine to create virtual battlefields or forests, the engine would create what appears to be a university campus complete with buildings and students. To be convincing a virtual campus would probably need to be aesthetically pleasing and feature landscaping as well as campus buildings.

Potential students would be able to move their avatars through the campus and enter the buildings. For example there would be buildings labelled “ Project Planning and Estimating Department,” Project Governance Department,” Project Requirements Department,” “Cyber Security Department,” “Risk Analysis Department,” and so forth.

Upon entering one of these virtual buildings there would be a series of virtual class rooms and virtual offices for the instructors and professors. This model assumes that live experts will be participate in the virtual university so the offices would have the names of actual experts such as Dr. Barry Boehm, Dr. Victor Basili, Capers Jones, and others who entered into agreements to offer courses through the Virtual Software University.

Of course the instructional staff would not be present at all times, so office hours would be posted on the virtual offices. In addition students would be able to leave messages and requests for the various professors and instructors.

The class rooms would appear to be actual class rooms similar to those at MIT, Harvard, Princeton, and other major universities. Several kinds of courses would be offered. One form of course would be presented in real time by the avatars of live instructors. (It is assumed that the Avatars for the Virtual Software University would be images of the actual instructors.) These live courses would be announced and could be scheduled. Some of these would be free but others might be fee-based.

There would also be recorded course materials that students could download and use at home or at their convenience.

The virtual class rooms would be more sophisticated than most real class rooms, in that all of them would be able to have multiple screens, feature animation and dynamic materials, and possibly even use 3-D instructional materials.

Interaction between virtual students and virtual professors would be similar to real life, in that questions could be asked and answered. Some of the interactions might be even more sophisticated than normal human interaction, since the Virtual Software University envisions working tools for topics such as planning, estimating, requirements, design, and of course working compliers and interpreters for teaching various programming languages.

A very powerful capability of the Virtual Software University would be a sophisticated curriculum planning engine. Potential students would identify their career choices or preferred occupations, and an intelligent curriculum engine would generate a full list of all courses needed to support their choice.

Not only would courses be identified, but also the current books and journals, professional associations, forms of certification and licensing that might be needed, and many other attributes for major occupations such as software engineering, project management, software quality assurance, data base analyst, and perhaps 150 more knowledge-based occupation groups.

Of course every university needs a good library, and the library for the Virtual Software University would be world-class. It would have features not offered in normal libraries. For example suppose a student is interested in the topic of “software testing.” Not only would the library have abstracts of every published book and article on testing, but it would constantly be refreshed by means of intelligent agents that would scan the web for new materials.

Of course for many topics the number of books and reference items might be in the millions, so the library would also include tools for narrowing searches and for assigning relevance scores.

Since the Virtual Software University might be accessed by students from several hundred countries, there would also be real-time translation services between all major natural languages. Thus courses might be simultaneously available in English, Russian, French, Italian, German, Portuguese, Arabic, Spanish, Japanese, and essentially every human language.

Ideally the translation services would encompass both text materials and perhaps even spoken discussions among students and faculty. A sophisticated university such as the Virtual Software University would no doubt license language translation tools plus perhaps voice to text tools such as Dragon or one of the others.

It is obvious that the virtual software university would want to offer world-class facilities for those who might have physical limits. For example to aid the deaf and hard of hearing all spoken material would be simultaneously translated into printed text. All video and instructional films would automatically include close captions or subtitles. This technology is available in 2012. It would also be possible to offer simultaneous translation of spoken courses into sign language. However translation of printed materials into sign language may not be fully available circa 2012.

For the blind all printed materials would be translated into speech. This technology also exists in 2012. It might even be possible to support simultaneous translation into Braille, although that is perhaps outside the state of the art as of 2012.

For those in wheel chairs who prefer that their avatars also have wheel chairs, the classrooms and buildings of the virtual software university would all be accessible to wheel chairs, and also clearly identified verbally for the blind.

The Virtual Software University would include other kinds of assistive methods for a variety of physical handicaps.

As with real universities, students would be able to interact with one another and would also be able to participate in special interest groups or Wiki sites on topics such as static analysis, inspections, requirements engineering, and dozens of others.

Because quantitative information is sadly lacking in real universities, the Virtual Software University would have licenses from all major benchmark groups and would have working versions of a variety of planning and estimating tools, test tools, and many others.

Unlike real universities the Virtual Software University campus would be operational 24 hours a day 365 days per year. Of course live instructors would take normal holidays and vacations, but the library and the recorded course materials would always be available.

Assuming global students and global faculty, it makes good sense for the Virtual Software University to operate around the clock. After all it is always daylight somewhere. Indeed with a global faculty as well as a global student body, the Virtual Software University would be a true 24-hour per day operation.

Because topics of interest change fairly often, the Virtual Software University would include a “Student Center” where students from many countries and many fields could interact with one another in order to exchange information and find out what techniques are being used successfully and which ones are difficult to master.

As with real universities there would be many special interest groups or people who are all interested in the same topics. One service that the Virtual Software University could provide would be access to local and national information from many countries such as the U.S., China, Brazil, Japan, India, and many others. For example each country might have its own bulletin board that could be used to announce courses and webinars that are located in the various cities of the home countries of the students.

Another service that the Virtual Software University might provide is a daily summary of webinars on selected topics such as testing, requirements engineering, and new tools and methods. Currently there are so many webinars offered that it is not easy even to keep track of them.

In the student center there would be a virtual bulletin board. Here vendors of tools or services might place ads, and students with interests in special topics might start looking for “birds of a feather” groups.

The Software Virtual University might also use LinkedIn, Plaxo, Facebook, or another network service to send messages to students with special interests or with common interests who might want to communicate with each other.

Since students would not be on campus more than perhaps an hour or two per day, the Virtual Software University would also include links to various e-book sources such as Amazon, Barnes and Noble, Google, etc. Indeed course curricula and selected texts would be capable of being downloaded and ordered as e-book packages for various courses such as testing, estimating, project management, and the like.

The fundamental idea for the Virtual Software University is to consolidate the huge but unorganized collections of knowledge about software topics into discrete learning packages that are aimed at specific and important topics such as quality control, estimating, planning, status reports, and dozens of others.

Two other aspects of the Virtual Software University would be different from regular campuses. First, each of the major professional associations such as the American Society of Quality (ASQ), the International Function Point Users Group (IFPUG), the International Software Standards Group (ISBSG, the Project Management Institute (PMI), or the Software Engineering Institute (SEI) could have their own virtual buildings and offer both training and membership services.

The same concept would be available for major corporations such as IBM, Google, and Microsoft. They could design and commission corporate buildings on the virtual campus where training in their products could take place. In fact some of the funding for the Virtual Software University would no doubt be the fees paid by corporations for these structures and for participation in the Virtual Software University. Smaller corporations such as ComputerAid Inc. and SmartBear might also want to have a presence on campus.

Another unique aspect of the Virtual Software University would be links to major conferences such as the Japanese Symposium on Software Testing (JaSST) or the IBM Innovate Conferences. The Virtual Software University would have several large conference halls where those who could not attend actual events in person would be able to participate in the major sessions and tutorials. Attendance policies for these virtual conferences would be set by the conference committees, and would probably offer reductions on the fees for attending in person.

The Virtual Software University might also offer occasional guest speakers who are famous in the software world: Bill Gates of Microsoft, Sergey Brin of Google, Mark Zukerberg of Facebook, and Larry Ellison or Oracle are examples. These software luminaries sometimes do speeches at real universities and conferences. But due to logistical limits, seldom can address audiences of more than perhaps 5,000 people. With the Virtual Software University, the same speakers might easily gather virtual audiences of 100,000 or even more.

The early versions of the Virtual Software University would probably offer short courses or webinars that lasted only an hour or less. However it is technically possible to envision the Virtual Software University linking to real universities and offering standard curricula in virtual environments.

If the idea catches on then eventually real universities such as Harvard and MIT, the University of Florida, or the University of Nalanda in India might participate and offer virtual courses either on their home campuses or through the facilities of the Virtual Software University.

At some point the facilities of the Virtual Software University would be sufficient to administer examinations and offer professional certification in topics such as requirements engineering, function point analysis, testing, project managements, and perhaps dozens of other technical disciplines where certification is available.

It is not impossible for the Virtual Software University to eventually award actual degrees up to the PhD level. However that could only occur if the curricula and faculty were accredited. Actual degrees from the Virtual Software University might not be feasible until 2035 or thereabouts due to the novelty of the concepts and the logistics of accreditation. The initial versions of the Virtual Software University would be aimed at professional training rather than undergraduate or academic training.

Security would have to be included as part of the design of the university virtual campus. This is to keep hackers and viruses from damaging the course materials or disrupting the sessions by means of denial of service attacks. There is always a need for cyber security to discourage hacking, phishing, identity theft, and other endemic problems of the computer era.

Although it may be 10 years or more before this kind of Virtual Software University occurs, it is interesting that the essential technologies to build the Virtual Software University all exist in 2012.

Not only do the technologies exist in 2012 but the costs for constructing a virtual campus would probably be only in the range of $150,000 which is much less expensive than building real class rooms. Assuming that companies such as IBM, Microsoft, and Google who already have course materials and instructors wanted to do this, a Virtual Software University could probably be up and running within 90 days of starting out.

It is not impossible that the Virtual Software University could do for education what Face Book and Twitter have done for social networks; i.e. make learning so easy and enjoyable that attendance would reach into the millions.

Because of the lack of expenses for physical buildings and infrastructure the Virtual Software University would be much less expensive to operate than a real physical university. The main cost drivers would be instructional compensation, licenses for software, and network access fees.

A live one-day seminar that costs $895 per student might be profitable for $200 per student if offered through the Virtual Software University. Student loads would be much higher in the Virtual Software University than in normal live instruction.

For live professional training the class sizes range from 10 to perhaps 50 attendees. For virtual training via webinars and other on-line methods class sizes range from about 200 up to more than 1,500. Thus lower costs per student are offset by higher student numbers.

Needless to say the concepts of the Virtual Software University could also be used for other forms of education such as medicine and law. (For medicine it is obvious that real physicians would be needed for surgery and conditions involving examination of actual patients.)

It is even possible to apply the same ideas to primary and secondary education. Even in 2012 it would be much cheaper to build a virtual school for the deaf than it is to build such schools in real life.

For primary and secondary education there are already rather sophisticated e-learning tools on the market such as IStation, Mindplay, Adobe, Riverdeep, Follett, and others that use a variety of dynamic and animated approaches to help hold the attention of students while imparting information. The same ideas can be applied to many other learning situations. There are also e-learning tools for faculty such as those by Virtual Education Software (VESi) which is congruent with the themes of this report.

Currently it costs between about $75,000 and $100,000 per student per year to operate schools for the deaf and blind. If the virtual learning tools and methods discussed here were applied to teaching the deaf and blind, the annual costs would probably be in the range of $3,000 to $10,000 per student per year.

The concepts of virtual training are not as attractive for primary schools as they are for schools dealing with older students because parents depend upon real schools to take care of children during the work day.

But for secondary education and higher education virtual training is much less expensive. There are no physical infrastructure costs. Licensing software is much cheaper than building physical class rooms which need heat, cooling, and maintenance. The ratios of students to teachers in a virtual classroom can easily grow to 35 or more. The cost savings potentials are significant.

It is possible to envision hybrid schools for the deaf and blind where virtual training would augment live instruction, and students would spend part of the time with live instructors and regular classrooms.

The main barrier to applying the concepts from the Virtual Software University to training the deaf and blind would probably be opposition from various educational unions, and resistance from state assemblies and school boards.

A web search on “average college tuition” found a CNN Money analysis dated October 26, 2011. This study showed that annual tuition costs for state and community colleges and universities was about $8,244 per year. Living expenses were about $13,203 per year, with total costs of $21,447 per year. Private university tuition averaged $28,500 per year with the living costs of $13,724 per year for a total annual cost of $42,224 per year.

Assuming that the concepts of the Virtual Software University were applied to normal undergraduate college education, the probable annual tuitions might be only about $1,500 per year. There would be no physical infrastructure costs at all combined with a much greater ratio of students to faculty than with real universities. Living expenses may or may not be lower with virtual training.

However the real value of virtual training would only be partly based on cost reductions. It is theoretically possible, and this needs research to prove, that the educational effectiveness of virtual education would equal and perhaps exceed that of normal class-room education.

For example immersive training is easily accomplished by virtual methods, but expensive using live instruction. Sophisticated learning tools featuring animation and dynamic simulations are easy to accomplish with virtual methods, but seldom even attempted with live instruction. Continuing to study on weekends and during spare time is easy with virtual methods, but very difficult with live instruction.

The bottom line is that technologies exist in 2012 to make significant technical advances in professional education. Some of the same technologies might be usefully applied to special education needs such as teaching the blind and deaf. Eventually these technologies could extend to many forms of education covering many professions.

Systems Engineering News

PMI, INCOSE and Lean Advancement Initiative (LAI) at MIT Partner to Find Best Practices for Delivering Successful Programs

Wasting time and financial resources are often dismissed as the cost of doing business when it comes to engineering programs. To help organizations overcome these challenges, reduce risk, and improve ROI, the Project Management Institute (PMI) and the International Council on Systems Engineering (INCOSE) – which first announced their partnership in September 2011 – teamed with researchers and industry members from the Lean Advancement Initiative (LAI) at the Massachusetts Institute of Technology (MIT) to develop The Guide to Lean Enablers for Managing Engineering Programs. The guide is an in-depth study that identifies 300 lean enablers, or best practices, that effective teams and organizations can implement to reduce waste and increase project and program success. Access the full report on Dspace (at) MIT or view the catalog record with citable URI.

More information

Applied Systems Thinking & Engineering in Healthcare

The United States Health Reform (Affordable Care Act) presents health care providers and payers with the goals that should be achieved in the reform health care environment and the rationale for those goals. Developing strategies to implement the act’s policies by any health care organization must take into account the underlying theories of the act:

* Managed change through payment design and funds flow

* Market place competition

To execute strategy, effective internal organizational management is a must and can be facilitated through a strong alignment between mission and operating factors. The mission must relate to the organization’s markets. Markets are best addressed through a local perspective where the ACA goals can be applied within a specific community or culture. The systems approach brings as many participants in the system to define their mutual success as it relates to reform.

More Information

Business Leaders Need Systemic Thinking for Sustainability

To resolve today’s challenges, our leaders must overcome the erroneous perspectives that created the predicament. At the most fundamental level, this requires moving from a “linear” way of thinking – where we focus on quickly fixing the most visibly broken parts of what isn’t working – to a “systems” perspective that brings thought and behavior into line with the natural laws of sustainability. Despite years of talk about systemic thinking, few companies or governments actually practice it. This is due, in part, to the lack of a simple framework to guide the implementation of a systems perspective.

More information

It’s Time to Rethink Our Approach to Safety Engineering

Hierarchical decomposition of systems into relatively independent, functional modules and components; making the individual components and functional modules as reliable as possible; having well defined processes for the assembly and operation of the systems; extensive simulation of the behavior of the components, modules and overall system; and continuous quality measurements and improvements approach to quality and safety works well for systems that are relatively static and deterministic, that is, whose future behavior can be generally calculated because the system will produce the same outputs from a given set of inputs. However, such an approach breaks down for complex systems composed of many different kinds of components, intricate organizations and highly different structures, all highly interconnected and interacting with each other. Such systems exhibit dynamic, unpredictable behaviors as a result of the interactions of their various components.

Most complex, software-intensive systems fall under this category. For the last few decades we have been using software-based digital systems in the design of complex machines, including airplanes and cars. More recently increasingly sophisticated smart systems are being used in industry after industry, including energy management, transportation and urban planning.

How can we best manage the risks involved in the design and operation of such complex, software intensive, socio-technical systems? How do we deal with a system that is working as designed but whose unintended consequences we do not like? How can we make these systems as safe as possible?

The best work I have seen on the subject is by Nancy Leveson, professor of aeronautics and astronautics and engineering systems at MIT. Professor Leveson is a leader in the field of safety engineering in highly complex systems. Earlier this year she published her new book–Engineering a Safer World: Systems Thinking Applied to Safety, which can be downloaded here.

More Information

Tom Gilb awarded Honorary Fellow at the British Computer Society

Software and systems engineering legend Tom Gilb has been awarded Honorary Fellow by the British Computer Society. A photograph of Bob Harvey, current President of BCS, congratulating Tom on the Hon. FBCS award, while past President Jim Norton looks on, is here {link to http://www.gilb.com/blogpost139}.

Tom is the author of nine books, and hundreds of papers on these and related subjects. Tom has guest lectured at universities over UK, Europe, China, India, USA, Korea – and has been a keynote speaker at dozens of technical conferences internationally.

Featured Society

The Council of Engineering Systems Universities (CESUN)

The Council of Engineering Systems Universities (CESUN) was established in 2004 by universities offering educational and research programs in engineering systems. CESUN membership includes more than 50 universities in North America, Europe, Asia, and Australia. The Council provides a mechanism for the member universities to work together developing engineering systems as a new field of study. An overall objective of the Council is to broaden engineering education and practice.

The primary activities of CESUN are to:

Discuss critical issues affecting the development of engineering systems

Undertake joint projects of mutual interest

Share educational material

Provide a clearing house to match PhD students with faculty opportunities

Organize meetings, symposia and conferences

Work with related professional societies and professional journals.

Engineering systems is said to be a new interdisciplinary field of study involving technology, management and the social sciences. It encompasses activities in the following areas:

System Engineering

Technology and Policy

Engineering Management, Innovation, Entrepreneurship

System and Decision Analysis, Operations Research

Manufacturing, Product Development, Industrial Engineering.

CESUN is governed by an Executive Committee, whose membership is currently:

-William Crossley, Professor, School of Aeronautics and Astronautics, Purdue University (USA)

-Olivier de Weck, Associate Professor of Aeronautics and Astronautics and Engineering Systems; Associate Director, Engineering Systems Division, Massachusetts Institute of Technology (USA)

-Larry Head, Associate Professor and Department Head, Systems and Industrial Engineering, University of Arizona (USA)

-Daniel Roos, Japan Steel Professor of Engineering Systems and Civil and Environmental Engineering, Massachusetts Institute of Technology (USA)

-William Rouse, Executive Director, Tennenbaum Institute, H. Milton and Carolyn J. Stewart Professor of Industrial and Systems Engineering, Georgia Institute of Technology – Chair (USA)

-Deborah Thurston, Director, Decision Systems Laboratory, Department of Industrial and Enterprise System Engineering, University of Illinois (USA)

-Theo Toonen, Dean, Faculty Technology, Policy, Management and Professor in Institutional Governance and Public Administration, Delft University of Technology (the Netherlands).

The CESUN website provides listings for available faculty positions in the field of engineering systems (including systems engineering).

More information

Systems Engineering Tools News

SysML Design Quality Metrics Supported by SDMetrics V2.3

SDMetrics V2.3 adds support for analyzing UML models that are extended by UML profiles. A prominent example of a UML profile is the Systems Modeling Language (SysML). SysML adds common concepts from model-based systems engineering (MBSE) to UML. SDMetrics users can define custom design metrics and rules to take these extensions into account. Systems engineers need model-based metrics to manage large-scale projects. SysML metrics are an important input to design and development effort estimation, and monitoring of design and development progress. SysML design rules assess the completeness, correctness, and consistency of SysML models.

More information

Systems Engineering Books, Reports, Articles and Papers

The Complete Project Manager

Integrating People, Organizational, and Technical Skills

Randall Englund and Alfonso Bucero

Published by: Management Concepts

ISBN: 978-1-56726-359-6

Publication Date: 2012

Binding(s): Softcover

Abstract: The Complete Project Manager: Integrating People, Organizational, and Technical Skills is the practical guide that addresses the soft project management skills that are so essential to successful project, program, and portfolio management. Through a storytelling approach, the authors explain the necessary skills and how to use them to create an environment that supports project success. They demonstrate both the why and the how of creatively applying soft project management skills in the areas of leadership, conflict resolution, negotiations, change management, and more. The Complete Project Manager integrates theory and application, humor and passion, and concepts and examples drawn from the authors’ experiences as well as from contributors who share their stories. The concepts are easy to understand, universal, powerful, and readily applicable. There is no complicated model to understand before practicing what you learn…or wish you had learned when starting your career. Achieve greater results through changed thinking in a way that is simple and immediately actionable! This guide has an accompanying workbook, The Complete Project Manager s Toolkit, sold separately.

More Information

The Complete Project Manager’s Toolkit

Randall Englund and Alfonso Bucero

Publisher: Management Concepts Press

From Amazon.com:

This companion to The Complete Project Manager provides the tools you need to integrate key people, organizational, and technical skills. The core book establishes that success in any environment depends largely upon completing successful projects; this book gives you the means and methods to meet that goal. The hands-on, action-oriented tools in this book will help you develop a complete set of skills—the right set for you to excel in today’s competitive environment.

The Complete Project Manager’s Toolkit will enable you to implement the easy-to-understand, universal, powerful, and immediately applicable concepts presented in The Complete Project Manager. You may already be aware of what you need to do; this book supplies the how through:




Examples of real people applying the concepts.

Use these tested methods to overcome environmental, personal, social, organizational, and business barriers to successful project management!

More information

Design Structure Matrix Methods and Applications

Steven D. Eppinger and Tyson R. Browning

Publisher and Date of Publication: MIT Press – June 2012

MIT Press description:

Design structure matrix (DSM) is a straightforward and flexible modeling technique that can be used for designing, developing, and managing complex systems. DSM offers network modeling tools that represent the elements of a system and their interactions, thereby highlighting the system’s architecture (or designed structure). This book addresses the four primary types of DSM models, offering tools for representing product architectures, organization architectures, process architectures, and multi-domain architectures (which combine different types of DSM models to represent multiple domains simultaneously). Each chapter provides many real-world examples of applications of the DSM types, representing a wide range of industries (including automotive, aerospace, electronics, building, and pharmaceutical), countries (among them Australia, Germany, Japan, Turkey, and the United States), and problems addressed (modularity, outsourcing, system integration, knowledge management, and others).

Flexibility in Engineering Design

Richard de Neufville and Stefan Scholtes

Publisher and Date: MIT Press – September 2011

MIT Press description:

Project teams can improve results by recognizing that the future is inevitably uncertain and that by creating flexible designs they can adapt to eventualities. This approach enables them to take advantage of new opportunities and avoid harmful losses. Designers of complex, long-lasting projects—such as communication networks, power plants, or hospitals—must learn to abandon fixed specifications and narrow forecasts. They need to avoid the “flaw of averages,” the conceptual pitfall that traps so many designs in underperformance. Failure to allow for changing circumstances risks leaving significant value untapped. This book is a guide for creating and implementing value-enhancing flexibility in design. It will be an essential resource for all participants in the development and operation of technological systems: designers, managers, financial analysts, investors, regulators, and academics. The book provides a high-level overview of why flexibility in design is needed to deliver significantly increased value. It describes in detail methods to identify, select, and implement useful flexibility. The book is unique in that it explicitly recognizes that future outcomes are uncertain. It thus presents forecasting, analysis, and evaluation tools especially suited to this reality. Appendixes provide expanded explanations of concepts and analytic tools.Technology, Globalization, and Sustainable Development: Transforming the Industrial State

Nicholas A. Ashford and Ralph P. Hall

Publisher and Date: Yale University Press – October 2011

Excerpt from publisher’s description:

In this book Nicholas A. Ashford and Ralph P. Hall offer a unified, transdisciplinary approach for achieving sustainable development in industrialized nations. They present an insightful analysis of the ways in which industrial states are currently unsustainable and how economic and social welfare are related to the environment, to public health and safety, and to earning capacity and meaningful and rewarding employment. The authors argue for the design of multipurpose solutions to the sustainability challenge that integrate economics, employment, technology, environment, industrial development, national and international law, trade, finance, and public and worker health and safety. This book is essential reading for anyone with a policy or scholarly interest in sustainable development and the critical roles of the economy, employment, and the environment.

Object-Process Methodology: A Holistic Systems Paradigm

Dov Dori

Publisher and Date: Springer – August 2002

Springer description:

Object-Process Methodology (OPM) is a comprehensive novel approach to systems engineering. Integrating function, structure and behavior in a single, unifying model, OPM significantly extends the system modeling capabilities of current object-oriented methods. Founded on a precise generic ontology and combining graphics with natural language, OPM is applicable to virtually any domain of business, engineering and science. Relieved from technical issues, system architects can use OPM to engage in the creative design of complex systems.

The book presents the theory and practice of OPM with examples from various industry segments and engineering disciplines, as well as daily life.

Systems — A New Interdisciplinary Open Access Journal for Systems Science and Engineering

Systems (ISSN 2079-8954) is an international scientific open access journal on systems engineering and systems management, published by MDPI online quarterly. The first issue will be released in 2012. Editor-in-Chief of Systems is Thomas Huynh, Graduate School of Engineering and Applied Sciences, Naval Postgraduate School, Monterey, CA 93955, USA, email: thuynh (at) nps.edu.

Huynh says:

“An interdisciplinary field of science, systems science studies complex systems in nature, society, and science. It crosses the boundaries of fields like, for example, complex systems, cybernetics, dynamical systems theory, systems theory, control theory, social systems theory, systems biology, systems ecology, systems psychology, chaos theory. This journal encourages submission of papers capturing research in these fields.

Systems engineering is a multidisciplinary field of engineering used in complex projects to produce trustworthy systems while satisfying schedule and budgetary constraints. The application of systems engineering reaches beyond engineering of physical systems and into engineering of socio-technical systems, which have both social and technical subsystems, such as financial systems, health care systems, energy systems, and organizational systems. This journal will be open to all who share this vision of broad applications of systems engineering. We encourage submission of papers that are theoretically sound and practically useful and advance extension or applications of non-systems engineering fields to systems engineering fields and vice versa.

This journal promotes interdisciplinary marriage of various fields studying the general properties of systems and interdisciplinary studies that integrate knowledge and theoretical frameworks of various fields such as biology, mathematics, medicine, computer science, and statistical mechanics, to name a few. Aspiring to provide a venue that supports a constructive exchange of ideas across different fields, this journal is designed to appeal to a diverse audience of research scientists in academia and industry as well as practitioners and developers in all areas related to systems—systems engineers, engineers from all traditional disciplines, systems theorists, scientists, social scientists, mathematicians, economists, biologists, etc.

The Editors and Editorial Board will maintain the highest standards of peer review. Accepted articles will be immediately published online. An important aspect of Systems is that we aim to achieve a short review cycle. We will also publish research results in as much detail as is necessary. We welcome your proposals for special issues of the journal on selected topics of interest and suggestions for appropriate guest editors. We welcome your feedback, suggestions, or ideas on how to make this journal a success.

I look forward to making Systems a leading venue for publication in systems science, systems engineering, and interdisciplinary system-related fields, distributed under the terms and conditions of the Creative Commons Attribution license.”

More information

Does model-based engineering make sense?

This article at Machine-Design.com provides an interesting mechanical engineering slant on model-based engineering.

“The concept of “model-based engineering” (MBE) has generated a lot of buzz lately and perhaps rightly so. As you probably know, this approach tackles product development using a kind of digital “master model” (not necessarily CAD) from which all downstream activities can be derived to build the product. The approach replaces ambiguous documents and can eliminate the need for physical prototypes before a particular design has been chosen. Engineers can simulate and iterate as much as necessary to refine the model while meeting requirements and adhering to design constraints …”

Read more

Conferences and Meetings

iFM2012 ABZ 2012 – Abstract State Machines

June 18 – 22, 2012, CNR Research Area of Pisa, Italy

More information

12th International School on Formal Methods for the Design of Computer, Communication and Software Systems: Model-Driven Engineering (SFM-12:MDE)

June 18 – 23, 2012, Bertinoro Italy

More Information

NDIA Systems Engineering Division 2-Day Seminar

June 21 – 22, 2012, Arlington, VA

More information

GfSE User Forum: MBSE in practice – challenges

June 22, 2012, Hamburg, Germany

More information

International Conference on Business Process Modeling, Development, and Support (BPMDS 2012), the 13th edition of the BPMDS series, held in Conjunction with Conference on Advanced Information Systems Engineering (CAiSE’12)

June 25 – 26 2012, Gdansk, Poland

More information

3rd IEEE Track on Collaborative Modeling and Simulation (COMETS 2012)

June 25 – 27, 2012, Toulouse, France

More information

EuroSPI 2012 Conference/19th EuroSPI Conference – European Systems and Software Process Improvement and Innovation

June 25 – 27, 2012, Vienna University of Technology, Austria

More information

PETRI NETS 2012 – 33rd International Conference on the Application and Theory of Petri Nets and Concurrency

June 25 – 29, 2012, Hamburg, Germany

More information

12th International Conference on Application of Concurrency to System Design (ACSD 2012)

June 27 – 29, 2012, Hamburg, Germany

More Information

Eighth European Conference on Modeling Foundations and Applications (ECMFA)

July 2 – 3, 2012, Technical University of Denmark (DTU), Kongens Lyngby, Denmark

More information

8th European Conference on Modelling Foundations and Applications

July 2 – 5, 2012, Technical University of Denmark, Denmark

More information

The World Congress on Engineering 2012

July 4 – 6, 2012, London, United Kingdom

More information

INCOSE International Symposium (IS) 2012

July 9 – 12, 2012, Rome, Italy

IS2012 Call for Papers: Deadline for draft papers, and proposals for panels and tutorials for IS2012 is November 8th, 2011.

More information

Interdisciplinary Network for Group Research (INGRoup) – Seventh Annual Conference

July 12 – 14, 2012, Chicago, IL, USA

More information

10th ACM/IEEE Conference on Formal Methods and Models for Co-Design


July 16 – 17, 2012, Arlington, VA, USA

More information: http://www.cpe.vt.edu/reg/acmieee/index.html

IEEE SOSE 2012 7th International Conference on System of Systems Engineering

July 16 – 19, 2012, Genoa, Italy

More information

International Conference of the System Dynamics Society, 2012

July 22 – 26, 2012, St. Gallen, Switzerland

More Information

4th Improving Systems & Software Engineering Conference (ISSEC) 2012

August 15 – 16, 2012, Melbourne, Australia

More information

KSE 2012

August 17 – 19, 2012, Danang, Vietnam

More information

19th World Congress of the International Federation of Automatic Control (IFAC 2014)

August 24 – 29, 2014, Cape Town, South Africa

More information

EmpiRE 2012 : Workshop on Empirical Requirements Engineering

August 25, 2012, Chicago, USA

More information

Workshop on Model-Driven Engineering for Networked Ambient System (MDE4NAS)

August 27 – 29, 2012, Niagara Falls, Canada

More information

9th INCOSE SA Conference – The Jewel in the Crown

August 29 – 27, 2012, Pretoria, South Africa

More information

18th International Symposium on Formal Methods

August 27 – 31, 2012, CNAM, Paris, France

More information

Sixth IEEE International Conference on Self-Adaptive and Self-Organizing Systems (SASO 2012)

September 10 – 14, 2012, Lyon, France

More information

International Workshop on Enterprise Integration, Interoperability and Networking (EI2N’2012)

September 12 – 13, 2012, Rome, Italy

More information

10th International Conference on Formal Modeling and Analysis of Timed Systems (FORMATS 2012)

September 18 – 20, 2012, London, United Kingdom

More information

12th International Workshop on Automated Verification of Critical Systems (AVoCS 2012)

September 18 – 20, 2012, Otto-Friedrich University in Bamberg, Germany

More information

Risk Engineering Society Conference (RISK 2012)

September 20 – 22, 2012, Sydney, Australia

More information

RePa 2012 : Second International Workshop on Requirements Patterns

September 24, 2012, Chicago, USA

More information

20th International Requirements Engineering Conference (RE 2012)

September 24 – 28, 2012, Chicago, Illinois, USA

More information


September 25 – 28, 2012, Magdeburg, Germany

More information

2nd Requirements Symposium

September 27, 2012, Berlin

MODELS 2012, ACM/IEEE 15th International Conference on Model-Driven Engineering Language & Systems – Call for Papers – Deadline 19 March 2012

September 30 – October 5, 2012 – Innsbruck, Austria

More Information

6th INCOSE Annual Great Lakes Regional Conference 2012

October 12 – 13, 2012, Schaumburg, Illinois, U.S.A

More information

World Engineering Education Forum (WEEF12)

October 15 – 18, 2012, Buenos Aires, Argentina

More information

19th Working Conference on Reverse Engineering

October 15 – 18, 2012, Kingston, Ontario, Canada

More information

Human Factors and Ergonomics Society HFES 2012 Annual Meeting

October 22 – 26, 2012, Boston, MA, USA

More information


October 23 – 25, 2012, Paris, France

More information

The World Congress on Engineering and Computer Science 2012

October 24 – 26, 2012, San Francisco, USA

Building Business Capabilities (BBC) 2012

October 28 – November 2, 2012, Fort Lauderdale, FL, USA

More information

12th Annual CMMI Technology Conference and User Group

November 5 – 8, 2012, Denver, USA

More information

INCOSE UK Annual Systems Engineering Conference 2012

November 7 – 8, 2012, London, UK

More information

Systems Engineering Day 2012 (TdSE 2012)

November 7 – 9, 2012, Paderborn, Heinz Nixdorf Museums Forum, Germany.

More information

14th International Conference on Formal Engineering Methods (ICFEM 2012)

November 12 – 16, 2012, Kyoto Research Park, Kyoto, Japan

More information

3rd International Conference on Complex Systems Design & Management (CSD&M 2012)

December 12 – 14, 2012, Cité Internationale Universitaire, Paris (France)

More information

INCOSE International Workshop IW2013

January 26 – 29, 2013, Jacksonville, Florida USA

More information

International Symposium on Engineering Secure Software and Systems (ESSoS)

February 27 – March 3, 2013, Paris, France

More information

SysCon 2013

April 15 – 18, 2013, Orlando, FL, USA

More information

SETE 2013

April 29 – May 1, 2013, Canberra, ACT, Australia

12th International Symposium of the Analytic Hierarchy Process/Analytic Network Process (ISAHP 2013)

June 23 – 26, 2013, Kuala Lumpur, Malaysia

More information


September 9 – 11, 2013, Keio University in Japan

More information

9th European Systems Engineering Conference (EuSEc 2014) – INCOSE EMEA 2014 Sector Conference

October 2014, Cape Town, South Africa

Education and Academia

Colorado State University Adds Online M.S. and Ph.D. to Systems Engineering Offerings

In response to industry demand, Colorado State University, U.S.A., has added and an online Systems Engineering Master of Science and Ph.D. in addition to its popular Master of Engineering. As some of the only online graduate degrees in this field, these programs have been shaped by input from industry and government leaders, preparing students to meet industry demands with immediately applicable knowledge. These degrees cover critical topics such as risk analysis, project management, support systems, and engineering processes.

More Information

Postdoc Position on Coverage Analysis of Concurrent Specification, Languages, Inria/LIG, France

Inria/LIG, Grenoble, France has available a postdoc 16 month fixed-term contract position on coverage analysis of concurrent specification languages.

CONVECS is a research team of Inria and LIG. Its areas of expertise lie on formal verification techniques and tools for asynchronous concurrent systems. CONVECS is involved in several research directions: providing formal specification languages for describing concurrent systems; enhancing temporal logics and verification tools; fighting state explosion; designing generic components for verification, test, and performance evaluation; and demonstrating the applicability of its methods and tools on real-life applications with academic and industrial partnership. In particular, the members of CONVECS have been developing the CADP verification toolbox for about 20 years. CADP is dedicated to the design, analysis, and verification of asynchronous systems consisting of concurrent processes interacting via message passing.

This post-doctoral fellowship will be part of the « OpenCloudware » project funded by the FSN (Fonds national pour la Société Numérique). The project is led by France Telecom / Orange Labs (Meylan, France) and involves 18 partners (including Bull, Ow2, Thalès, Inria, among others). OpenCloudware aims at providing an open software platform enabling the development, deployment, and administration of cloud applications. The coverage analysis approach proposed in this project will be used for designing and verifying self-management protocols in cloud computing developed in the context of OpenCloudware.

Requests for more information and all questions concerning this post-doctoral fellowship should be addressed to: Gwen Salaün, e-mail: Gwen.Salaun (at) inria.fr. Applications received after July 15, 2012 may not be considered.

UW–Madison launches online Sustainable Systems Engineering Graduate Program

The University of Wisconsin-Madison, USA, has introduced a new online Master of Engineering in Sustainable Systems Engineering (SSE) program, which will begin January 2013, with applications being accepted through to October 15, 2012. SSE is designed to prepare mid-career engineers with knowledge in sustainable engineering practices to be leaders in managing systems that impact the quality of water, land, air, energy, economics, and society. In addition, SSE focuses on the technical aspects of three specializations-energy production and distribution, facilities and built environment, and public infrastructure.

More Information

Institute for Systems Research, University of Maryland

Institute for Systems Research, University of Maryland (ISR) is home to cross disciplinary research and education programs in systems engineering and sciences, and is committed to developing basic solution methodologies and tools for systems problems in a variety of application domains.

The Institute for Systems Research is a permanent, interdisciplinary research unit within the A. James Clark School of Engineering at the University of Maryland. Since its beginnings as one of the USA’s National Science Foundation’s original Engineering Research Centers 1985, ISR has been at the international forefront of interdisciplinary research and education in the system sciences and systems engineering. ISR attained permanent institute status at the university in 1992 and graduated from the NSF program in 1996.

ISR is home to about 100 faculty and other researchers from 14 departments and four colleges across the University of Maryland.

ISR’s basic research has resulted in many new algorithms and sophisticated models for decision making and control (the sense-decide-actuate lifecycle), communications, and computing needed to model and design engineering systems that are highly automated, autonomous and distributed. New approaches to the planning and multi-objective optimization-based design of engineering systems also have been developed.

Because large-scale science requires systems engineering and, conversely, systems engineering and implementation of modern real-world systems doesn’t occur without good systems science, ISR develops both basic solution methodologies and tools for systems problems in a variety of different areas. Its advances in the system sciences have been driven by a wide range of complex applications, which have changed over time. ISR’s current main research areas are:

Communication systems and networks

Control systems and methodologies

Neuroscience and biology-based technology

Micro and nano devices and systems


Design, operations and supply chain management

Systems engineering methodologies

Computing, speech, artificial intelligence, data mining.

ISR research expenditures totalled US$17.5 million in 2011.

More information

Some Systems Engineering-Relevant Websites


This webpage contains some intriguing definitions of systems engineering terms, contrasted in pairs. That is not to recommend some of these definitions!


This is the website of MFPT, a non-profit professional society with a 40-year legacy of promoting failure prevention technology. An interdisciplinary technical organization, MFPT is strongly oriented towards the practical application of health management across every engineering sphere. The MFPT community includes professional scientists, engineers, failure analysts, maintenance specialists and others who represent a wide variety of disciplines from government agencies, universities, research institutes and industry.


This webpage contains some interesting commentary on SysML 1.3.


Functional Architectures enable re-use of concepts across multiple generations of technology. The FAS method shows how to create Functional Architectures in SysML.

The FAS method is the name of a method for the use-case-driven creation of a functional architecture for systems, first published by Jesko G. Lamm and Tim Weilkiens – at the TdSE conference in Munich, Germany, in November 2010. The conference paper is the definition and foundation of the FAS method. Since then it has attracted attention. In November 2011 Lamm and Weilkiens presented at the TdSE conference in Hamburg, Germany, Artisan Studio tool support for the FAS method together with Andreas Korff from Atego. In December 2011 they chartered the FAS working group of the GfSE (German chapter of INCOSE) with the aim of further improving the method and providing tool support for major SysML modeling tools. In January 2012 the working group published an open source plugin for the FAS method for the modeling tool MagicDraw, and in April 2012 an open source plugin for the modeling tool Enterprise Architect, extending the coverage of supported tools.

Current research activities for the FAS method cover aspects like variant modeling, layer architectures, and N^2 matrices.


This site of Ian Alexander contains a list of requirements-related software tools – free, shareware, free trial & commercial, with considerable overview and evaluation comment. The tools list is not as extensive as PPI’s, but contains much more information about each tool.


Ana Gallego and Ignacio González Alonso have uploaded to an open source server the first SysML diagrams using a hybrid method to perform a Model Driven Scientific Method. They feel it could benefit any PhD student or any scientist interested in designing new complex experiments in a multidisciplinary team. Or any other one that will have a complex set up being an individual researcher. Both will benefit from having a VISUAL design of the experiment, and that’s why they are proposing this approach to science and would like to encourage its use.

The diagrams describe an experiment performed without SysML (about a contribution to a conference already published) and the DoE (Design of Experiment) for the same experiment but using SysML to architect the components and define the processes.

They are downloadable as a Topcased exported project: https://www.assembla.com/code/model-driven-science/subversion/nodes/t

Or if you don’t have Topcased or you don’t know how to use it, you can access directly the diagram images captures at:


Any comments, suggestions, or issues are welcome. The model is released as open source, so use it, reuse it or modify it for your own purposes, citing the authors and linking to the original source (in other words recognizing the work done).


This webpage contains a few useful downloadable requirements management resources.


This is the website of Tom and Kai Gilb. The site contains leading ideas on project management, stakeholder values, quantification, agile, quality, requirements, evo, quality control, and systems engineering. Generously, there are some hundreds of downloads of files containing valuable information authored by Tom Gilb, Kai Thomas Gilb and other authors.

Standards and Guides

SySML 1.3 Released

The OMG has published SysML version 1.3. The specification document is available on the OMG website. A version with change bars can be downloaded to see the differences to the previous version.

Typically the dot versions of SysML contain only minor changes. However, SysML 1.3 comes with many changes in the area of ports. The basic concept is still the same as for SysML 1.2. There are “normal” ports to provide and request features and there are flow ports to specify the flow of things inside and outside of a block. New is the implementation of the above concept, and the concepts of proxy and nested ports.


More information

A Definition to Close on

Some Definitions to Close On: FMEA, FMECA, FTA, ETA

Failure Modes and Effects Analysis (FMEA):

Failure modes and effects analysis (FMEA) is a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service. Failures are prioritized according to how serious their consequences are, how frequently they occur and how easily they can be detected. The purpose of the FMEA is to take actions to eliminate or reduce failures, starting with the highest-priority ones.

“Failure modes” means the ways, or modes, in which something might fail. Failures are any errors or defects, especially ones that affect the customer, and can be potential or actual.

“Effects analysis” refers to studying the consequences of those failures.

Failure modes and effects analysis also documents current knowledge and actions about the risks of failures, for use in continuous improvement. FMEA is used during design to prevent failures. Later, it is used for control, before and during ongoing operation of the process. Ideally, FMEA begins during the earliest conceptual stages of design and continues throughout the life of the product or service.

Source: American Society for Quality

Failure Modes, Effects and Criticality Analysis (FMECA):

See Failure Modes and Effects Analysis (FMEA). Source: American Society for Quality

Fault Tree Analysis (FTA):

Fault tree analysis (FTA) is a top down, deductive failure analysis in which an undesired state of a system (system failure condition) is analyzed using Boolean logic to combine a series of lower-level events. These fault conditions are classified by the severity of their effects. The most severe conditions require the most extensive fault tree analysis. This analysis method is mainly used in the field of safety engineering and reliability engineering to determine the probability of a safety accident or a particular system level (functional) failure.

Source: http://en.wikipedia.org/wiki/Fault_tree_analysis

Event Tree Analysis (ETA):

An event tree is a graphical representation of the logic model that identifies and quantifies the possible outcomes following an initiating event. Event tree analysis provides an inductive approach to reliability assessment as the tree is constructed using forward logic. Fault trees use a deductive approach as they are constructed by defining top events and then use backward logic to define causes. Event tree analysis and fault tree analysis are, however, closely linked. Fault trees are often used to quantify system events that are part of event tree sequences. The logical processes employed to evaluate event tree sequences and quantify the consequences are the same as those used in fault tree analyses.

Source: http://www.eventtreeanalysis.com/

PPI News (see www.ppi-int.com)

PPI at IS2012 – Rome

Content: Use SyEN Body Text for news information

PPI Events (see www.ppi-int.com)

Systems Engineering Public 5-Day Courses

Upcoming Locations Include:

Amsterdam, The Netherlands

Adelaide, Australia

Brisbane, Australia

Rio de Janeiro, Brazil

Munich, Germany

Requirements Analysis and Specification Writing Public Courses

Upcoming Locations Include:

Melbourne, Australia

Stellenbosch, South Africa

Las Vegas, USA

Amsterdam, The Netherlands

Software Engineering Public 5-Day Courses

Upcoming Locations Include:

Sydney, Australia

Pretoria, South Africa

Amsterdam, The Netherlands

OCD/CONOPS Public Courses

Upcoming Locations Include:

Brasilia, Brazil

Pretoria, South Africa

Las Vegas, USA

Cognitive Systems Engineering Courses

Upcoming Locations Include:

Adelaide, Australia

Las Vegas, USA

CSEP Preparation Course (Presented by PPI subsidiary Certification Training International)

Upcoming Locations Include:

Las Vegas, USA

Austin, USA

Munich, Germany

PPI Upcoming Participation in Professional Conferences

PPI will be participating in the following upcoming events. We look forward to chatting with you there.

ICOMS Asset Management Conference | Participating | Hobart, Australia (4 – 8 June 2012)

INCOSE IS 2012 | 
Exhibiting | Rome, Italy (9 – 12 July, 2012)

Land Warfare Conference 2012 | 
Exhibiting | Melbourne, Australia (22 – 26 October, 2012)

Kind regards from the SyEN team:

Robert Halligan, Managing Editor, email: rhalligan@ppi-int.com

Ralph Young, Editor, email: ryoung@ppi-int.com

Stephanie Halligan, Production, email: shalligan@ppi-int.com

Project Performance International

2 Parkgate Drive, Ringwood, Vic 3134 Australia

Tel: +61 3 9876 7345

Fax: +61 3 9876 2664

Tel Brasil: +55 11 3230 8256

Tel UK: +44 20 3286 1995

Tel USA: +1 888 772 5174

Web: www.ppi-int.com

Email: contact@ppi-int.com

Copyright 2012 Project Performance (Australia) Pty Ltd, trading as Project Performance International

Tell us what you think of SyEN: email to contact@ppi-int.com

If you do not wish to receive a copy monthly of SyEN in future, please reply to this e-mail with “Remove” in the subject line. All removals are acknowledged; you may wish to contact PPI if acknowledgement is not received within 7 days.

Scroll to Top