Technical / Scientific Reviews Leadership

We had a guest speaker come in from Johns Hopkins APL to our leadership class at UMBC last night. He shared with us his career experiences and some tips.

One thought I got from his visit was the importance of teaching technical/scientific review meetings leadership. I did a search on the Internet quickly to see what is out there, but there is very little literature in how to successfully run and conduct a technical review.

I am not talking from a process perspective, like what the process for an SRR should be. These processes are well known and understood. But rather I am talking from the leadership perspective. Areas like

1. Tools
- What are the best tools to use during the review, slideware, spreadsheets, technical documents, etc..
- Can reviews be conducted remotely over collaboration S/W like NetMeeting, Notes
- What is more effective in-person or remote meetings? I did both each has it pros and cons

2. Negotiation schemes
- So the client PM takes over the meeting, how do you as the lead SE on the contractor side react?
- Just got into a project yesterday, you need to do a walk-thru tomorrow, who are players? how to run the review smoothly?

3. Time control
- Mr. chatter loves to chat, and whiner complains about each requirement, and repeater has to make sure we all memorize his statements before we leave, how to filter and weed out the garbage talk and retain the technical meat you are looking for?
- One big 8 hr meeting with 1 hr lunch and 2 15-min breaks, or 4 2-hr meetings over 4 days?

4. Scope control
- Ok, we are doing a use case review, but lets quickly go over the architecture, 60/40 opposition, what do you do?

I attended a workshop by Edward Tufte, the professor at Yale last Spring, he discussed some very interesting thoughts about how some organizations fail to conduct reviews simply because they use poor tools. He gave the example of NASA and the shuttle explosion. In his opinion as well as the many experts who evaluated the crash, the failure in the shuttle started not at launch, but rather way back in the technical review process. NASA was too heavily dependent on power point fluff. It was very easy to lose focus of the strategic technical issues and questions during the reviews.

This all needs more research...

Have You Looked at the 2 F Words? Five Factors !

Developing a new product in no easy job. The uncertainity that looms around you seems endless. This uncertainity can be broken down into 5 areas as explained by Michael Porter, in his book "Competitive Advantage: Creating and Sustaining Superior Performance".

1. Potential entrants

2. Supplier Power

3. Buyer Power

4. Substitutes

5. Industry competitors

New Product Requirements

There are various sources for requirements gathering for a product or service. Obviously the most important source is the customer who will be using the product or service.

Another valuable source is the environment in which the product and customer will both be surrounded by. A list of the most relevant environments that a product manager or systems engineer should take a look at are:

1. Technological Environment
Presence of new inventions, innovation, methods, processes, materials to achieve new tasks or perform older one better, etc...

2. Economic Environment
The cyclical changes in local and global economies, inflation (prices rising/lower purchase power), recession (trade down/employment down), unemployment, depression (panic), recovery, prosperity (employment up/trade up), off-shoring, debt/savings levels, income distribution

3. Competitive Environment
The landscape of competing (monopoly, perfect, oligopoly, monopolistic), competitors status, etc...

4. Sociological Environment
Cultures, changes in industries, religion, subcultures (teens, seniors), crime rates, etc...

5. Political-Legal Environment
Legislation, regulations, PACs, wars, etc...

6. Demographic Environment
Age, gender, customs, location of residence, etc...

7. Natural Environment
Natural resources, raw materials, pollution, etc...

Astute system engineers should research all these environments. The level of research might differ from on environment area to another depending on the product/service being developed. In some cases other environments might be considered and some of those listed above ignored.

Needs - Wants - Demands

Just like a smart marketer, an astute systems engineer knows the difference between the three:

Needs - are basic requirements, like eating and going to the bathroom

Wants - are needs that become requirements for fulfilling basic needs, for example people want education to find a job, to make money to buy food to meet the basic need. Wants are shaped by the environment the client is in.

Demands are wants for specific products coupled with an ability to pay.

Marketers do not create needs. Needs already exist. People need to eat, move, dress and learn. Marketers only promote the idea that a burger, car, Jeans and private school will satisfy the client's needs, by highlighting the benefits the client will achieve using the product.

Is that What Your Client Really Needs?

Customers need a lot of things, in most cases they do not realize what they need. However we can usually group a customer's need into these 5 areas:

1. A stated need - I need a box of cereal
2. Real need - I need something healthy to eat quickly in the morning
3. Unstated need - I expect to find the cereal box easily and quickly
4. Delight need - If the cereal will allow me to add fresh raisens and banannas all the better
5. Secret need - Got to show off infront of my wife and tell her I got it on sale 3 for price of 1

An experienced system engineer can sense and identify the needs 2 - 5, and bring them out to the client for verification -- this is where value is added.

The 4 Ps of Marketing and 13 Aspects of a Good Requirement

Just as marketing has 4 Ps: Product, Promotion, Place and Price

Requirements have 13 attributes:
1. Describe what and not how
2. Atomic
3. Unique
4. Documented
5. Identifies owner
6. Traceable
7. Necessary
8. Complete
9. Unambiguous
10. Identifies applicable states
11. Testable and quantitative
12. Not a constraint
13. Not a goal

Rule of thumb: A requirement should be satisfied by only 1 design component, it not feasible then it should be broken down further.

Systems Engineers Don't Only Engineer Technology Systems

That is true... Almost all industries and discplines need system engineers, simply due to the fact that everyone needs something.

Traditionally we are used to seeing systems engineers working in the defense sector to define requirements for the next state-of-the-art missle, or at a high-tech firm developing and trackign requirements for the seemless e-commerce application.

Masjids, churches and synagouges need system engineers to articulate the needs of their congregations, define priorities and ensure that requirements add value. Schools need to develop effiecient operational systems, retail stores need to streamline their sales, and the list goes on...

Just like the following list of items could be marketed.. they could also be system engineered...

Goods - Technology products, consumer products, commercial products, etc...

Services - B2B, B2C, C2C (yeah myspace, blogs, etc..), C2B (resume websites, etc..), professional, educational, security, etc... the list services never ends

Events - Yes events which are complex could require the art of engineering

Experiences - Ever heard of Opera Aida..

Persons - We can market persons, can we system engineer a person.. sure we can define requirements for that person to reach certain goals.. we call that also coaching, mentoring, training, and many other things ...

Places - Engineer a downtown...

Properties - Engineer the Pyramids

Organizations - Build a non-profit systematically.. yes that also is systems engineering

Information - Indeed.. that is what we call IT system engineers...

Ideas - System engineers make not only great inventors because of their holistic views and ability to identify gaps, but also.. great value initiators .. very similiar to marketing slogans..

"Everyone can benefit from a little System Engineering"
Ayman Nassar

Ways for Satisfying Needs and Wants

One of my teachers, Prof. Pitta, of University of Baltimore once mentioned There are 4 main ways people can achieve their needs, let take a look as well as at their (Acquirer / Releaser) score.

Coercion:
When someone takes something like force. Like someone breaking into your car to steal your GPS. In this case, that someone achieve a small gain, he probably sells that $600 GPS for $50 or for a couple of sniffs of white powder. The victim, you, loses, the cost of repairing the car glass, replacing the GPS and the sense of security. Score: (+ / ----)


Origination:
When one goes out to acquire a product or service through exerting effort, using natural and free resources. This is like going fishing, spending a whole day under the sizzling sun, and getting a catch of a dozen trouts. You win, no one loses (at least directly). Score (++ / neutral)

Transfer:
When someone receives a product or service as a gift. In this case no productivity is performed and hence not mutual exchange of value. Such is the case with giving a begger change. The begger gains a limited value, but the donor doesn't gain, besides the fact of maybe feeling good about helping someone in need, nor does the society. Please do not confuse begging with charity. Charity is used for productivity and development. Score (+ / +).

Exchange:
This is where value lies. Exchange is when you go a get a car in

exchange of 20 g rand, or an iPod for $200, or a voice recorder for $2 5. In these cases, you will use the car to go to work (get income, take kids to school, etc..) so you develop value out of the car, or use the iPod to listen to Quran to be a good person (gaining value for yourself long term as well as short term and society), and recor d lectures or interviews on your voice recorder. In all these c ases you gained value from the products you acquired, the seller gained value by receiving cash and making profit on his/her sale and invested the extra towards further production and development. True value occurs in exchanges. Score ( +++++ / +++++)

Marketing and Systems Engineering

Of course there is a great deal of relationship between Marketing and Systems Engineering. After all their main focus is creating and delivering value to cusotmers. The American Marketing Assocation (AMA) defines marketing as "An organizational function and set of processes for creating, communicating and delivering value to customers and for managing customer relationships in ways that benefit the organization and its stake holders.

Marketing is about exchanging products and services to satisfy needs and wants. These needs and wants represent value to those taking part in the exchange process.

Systems engineering is about articulating these needs and wants, representing them clearly and making sure processes exist to deliver these needs and wants "requirements" to the client with low risk.

Everyone is marketing something, whether it is oneself at a job interview, a product they develop, a school they send their children to, a doctor they visit, or a place they travel to enjoy. Sharing the experience of all these types of activities is one way of communicating their value, i.e. marketing ...