Home » SyEN Newsjournal » PPI SyEN 45

PPI SyEN 45

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

WHAT’S INSIDE:

Quotations to Open On

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.

-Nehru

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

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

Introduction

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:

DAY ONE

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

DAY TWO

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:

http://www.virginiadot.org/business/resources/partnerfinalallowres.pdf

Appendices

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

capers.jones3@gmail.com

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.

PPI SyEN 45

Subscribe to PPI SyEN

PPI SyEN 135

PPI SyEN 134

PPI SyEN 133

PPI SyEN 132

FREE Original SE Articles and Industry News?

Subscribe to PPI

MORE About Us