Instilling Change: A Key Component of Leadership

Leading change is by no means a trivial job. Only the experienced leaders with astute vision can lead their teams to change. The Prophet Mohammad (peace be upon him) is a role model for not only change, but transformation.

Our Creator informs us that no group of people will change unless they take initiative to embrace change themselves. Indeed the only things that is constant is change itself, or as Muslims know it as the sunnah of Allah (ways of Allah).

Scholars of management [1] define a few steps which are key for successfully leading change. I summarize these points [2] and provide references from the Quran and teachings of the Prophet (PBUH).

1. Intention:
Quran: Indeed Allah does not change the condition of a group unless they change themselves.
Hadith: Indeed deeds are based on their intentions

2. Urgency:
Quran: So flee to Allah quickly indeed I am to you from him a clear warning
Quran: And hasten to a forgiveness from your Lord and a paradise the width of the skies and earth

3. Clear Vision:
Quran: And Indeed Allah is my Lord and your Lord, so worship him, this is the straight path (Mary 36)

4. Stick to a Good Team:
Quran: And seek patience in your soul with the ones who remember their Lord in the early morning, and the evening late at night, seeking his pleasure and acceptance (Cave 28)
Quran: Wow to me, I wish I have not taken him/her a close companion (friend) (Al-Furqan 28)

5. Self Critique Self:
Quran: Oh you who believe fear Allah, and shall a soul see what it has prepared for its tomorrow (hereafter), and fear Allah, indeed Allah is with what you have performed all knowing
Hadith: Seek forgiveness, for indeed I seek forgiveness 70 times in a day

6. Take Action and Perfect it:
Hadith: Indeed Allah loves if one of you do an action, that you perfect it

7. Be Consistent:
Hadith: The best of deeds are the continuous, even if they are little

8. Take Small Steps:
Hadith: This way of life (Islam) is deep so get in it slowly and gently

9. Don't Give Up:
Quran: Tell my servants who have transgressed upon themselves to not despair from the mercy of Allah, indeed Allah forgives all the sins.

10. Offer Value and Increase Benefit:
Good deeds wipe out bad deeds

11. Ensure You are Working on a Sound Foundation:
Fix your beliefs and values
Quran: And Satin said when the matter was over (life on earth, and the day of judgment), indeed Allah promised you the promise of truth, and I promised you and broke my promise, and I had no power over you, except that I invited you and you accepted, so do not blame me, and blam yourselves. (Ibrahim 22)

12. Set and Realize Realistic Goals
Quran: Indeed Allah does not burden a soul with more than what it can handle

13. Stay Away from Distractions
Quran: Do not even come near fornication
Quran: So flee to Allah

14. Remember Your Mission in Life:
Quran: I have only created jinn and mankind to worship me
Quran: Is it not that with the rememberance of Allah that hearts have tranquility and content

15. Remember Life-cycles End:
Hadith: Remember the destroyer of all pleasures (death)

16. Never Execute Trivial Work:
Hadith: A human's accountability on the day of judgement will not be over until he is asked about four things, from among them is his time and how he utilized it

17. Forecast Risks:
Quran: Indeed the plotting of Satin is weak
Be vigilant and forecast problems and risks




[1] Dan Cohen and John Kotter, "The Heart of Change Field Guide", Harvard Business Press, 2005.
[2] Ayman Nassar, "Implementing Change", Friday Khutbah, Hanover, PA, July 10th, 2009

The Demise of Quality - My Wife's Friend, British Airways and Air France

I was vacuuming the living room last evening, when my wife told me that her friend arrived safely in Egypt after a long flight from Washington with a connection in London. She then added that her 10 year old son is walking around in his swimsuit at home and her friend is wearing some old maternity clothes she had from a decade ago. I asked my wife "Did they lost their luggage?", she replied that no a single bag of the eight pieces her friend and her three kids had arrived.

It has been two days since my wife's friend family had arrived on board British Airways with no luggage. I mentioned to my wife that her friend should request a compensation of some sort, may $100 per passenger, so they can use this modest pocket money to go buy some clothes until their bags appear. My wife's response was "we are thankful that they arrived safely". Well, yes of course compared to Air France's latest flight that plunged in the Atlantic, the losses and inconvenience is minimal, and one should always be thankful, regardless of what one goes through". The point however is that the passenger's (customer) expectation is be transported safely along with his luggage from point A to point B. If customer's start changing their expectations, quality will automatically by definition change.

An attorney would seize the opportunity and ask the passenger to file a suit against the airline asking for some ridiculous amount of money as a compensation for damages. Maybe $1 million dollars per lost bag, or the highest that the court will allow. We have various mindsets of customers when it comes to settling disputes with a service provider. At one extreme a client will say no problem, just get me my bags if you can, when you can. On another extreme another customer will say meet me at court, and then there are infinite of perspectives in between.

What would you do? What would a good system's engineer do? Share your thoughts in the comments below.

Probability Distributions for Business Events - Binomial

System engineers and technical managers need to make decisions based on the probability of certain events occurring. For example during a risk assessment practice, the systems engineering might be calculating the risk value of an event, and based on the value of the risk level the organization will take certain steps to respond to the risk.

To accurately calculate the risk value which is calculated as the (impact level * probability of occurrence), the probability distribution selected needs to be accurate.

In some events outcomes could be binary, for example: good or bad, correct or incorrect, successful or failed, conforming or non-conforming. A suitable probability distribution would be a binomial probability distribution, using a binomial calculator the system engineer can calculate the probability of occurrence of one of the two possible events knowing the sample size (n), the rate of good versus bad, or correct versus incorrect (p) and the number of items (x) fitting a particular outcome. For example if we select a sample of six items from a batch which has a defect rate of 3%, we can find the probability that the sample has one defective item using the binomial formula

P(x) = [n! / x! (n-x)! ] p^x (1-p)^(n-x)

In the above example, n=6, p=0.03, x=1

Using the formula above or the binomial calculator available at Texas A&M, we get that P(1) = 0.1546

Stay tuned for other probability distributions that are also common in business environments.

Two Approaches to Use Statistics on Your Project

Most people don't like statistics, and most decision-makers make wild guesses when they need to take a decision. Statistics might not be the most straight-forward science during the college years, but it has tremendous value in providing insights and guidance for making rational decisions.

Using statistics one can show various properties of a set of data such as the mean, mode, median, dispersion and distribution. These parameters can be represented graphically using histograms, charts and other visual illustrations.

Another approach using statistics is to develop inferences, test hypothesis and develop forecasts through the use of sample data from a bigger population. Relationships between variables can be developed and illustrated using a scatter diagram or a regression equation.

Six Sigma's DMAIC vs. Design for Six Sigma's IDOV / DMADV

Six sigma's success is mainly contributed to its DMAIC model. The DMAIC model focuses on defining an issue with an existing process or product, measuring the deviation from the expected behavior, analyzing the data for insights to root causes, improve the current process or product through minimization of deviations or improvements and finally controlling the system to sustain the gains achieved.

IDOV and DMADV which are two design-based models slightly differ from DMAIC as follows.

Objective and Approach: DMAIC views the current process or product as correct and economical, but needs to minimize some gap leading to inefficiencies. IDOV / DMADV view the current process or product as in need of redesign or design change to achieve customer satisfaction.

Process Capability: DMAIC views current process as capable of satisfying customer needs, whereas IDOV / DMADV views current processes as a candidate for improved yield regardless of volume and complexity.

Design: DMAIC views the current design as satisfactory for the client's needs, whereas IDOV / DMADV views the need to consider various drivers for design, such as cost, manufacturing, producibility, maintainability, robustness, usability, efficiency, security, agility, compliance and testability.

Flexibility: DMAIC assumes that the current design and processes are flexible to meet customer demands and needs, whereas IDOV / DMADV highly considers potential customer demands and forecasts newly developed needs

Validation: IDOV and DMADV both consider validation and verification of the outcomes of a design or process in meeting objectives.

To read more:
[1] Chrisitian Madu, "The House of Quality in a Minute", Chi Publishers, 2006.
[2] Rod Munro, "The Certified Six Sigma Green Belt Handbook", Quality Press, 2008.

3 Practices to Becoming an Agile and Lean Enterprise

About a month ago I was approached by a client asking to give advice regarding some organizational changes and major layoffs they were embarking upon. The client sent me an email with about six or seven different options to pursue to cut on their operating expenses.

I noticed that all the options were focused on eliminating employees. My question to myself, if eliminating employees seems the favorable and only approach that comes to mind, why were these employees present in the first place? There must have been a need for them in the organization, otherwise why were they hired in the first place? What operations will suffer when these folks are let go?

Many businesses fail to realize that a lot could be done way in advance to avoid shedding off employees. Letting go of your most valuable resources, your staff, should be the last thing to do, before closing shop. I list ten actions that can be done months before the crunch becomes severe to be forced to shut down.

1. Reduce non-valuable activities, a.k.a trivial work.
Non-valuable activities are those which your customers are not willing to pay for, they do not change the form or function of the product or service they are interested in. An example is rework, due to defects in a process used to produce the end product or service. Other examples are wait-time during the process. For example if you order a book online, you are willing to pay for the book to be shipped from the publisher to your location, you are interested in how much time it takes the book to wait at each regional hub for its next pickup. If there is a cost to the shipper to pay for the time spent at each shipping hub it will increase the cost of your book shipment and will not provide you any value. The only value you realize is the book being shipped to you as fast as possible. Instead of focusing on accelerating valuable processes, one should first eliminate non-valuable processes, as the effort of work will probably be less and the outcomes more effective.

Muslims also know non-valuable activities as "Lagow", an Arabic term mentioned in the Quran in several places, as deeds that have no benefit, or are a mere waste of time. These are deeds that keeps one's focus away from his purpose in life, which is the success in the hereafter.

Before improving valuable processes, it is important to get rid of as many non-valuable processes as possible. In the case of my client, they were focussing on products that yielded low profit margins, were difficult to market, promote and sell, and required large staffing and overhead.

2. Reduce waste
Waste is all around us in our activities. It is imperative that before we develop new processes to improve deficiencies we actually reduce waste as much as possible. Waste could be due to over production, excessive steps due to complexities of processes, queuing and idle time, defect correction and rework, poor organizational and planning processes, lack of controls and creativity stagnation.

Through some auditing and analysis it was found that my client had opportunities to reduce expenses of photocopying, utilities, rent and other non-valuable activities prior to let go of employees who were driving valuable activities for the end user.

3. Use facilitation to reduce cycle time and enhance efficiencies
A facilitator who is neutral to the different entities in your enterprise, and who has no authority or decision-making control, can bring tremendous value to your organization. The facilitator can apply collaboration concepts, systemic approaches and architectural thinking to decompose problems, address impacts in all areas of interest, and ensure a collaborative environment exists where the various team members can share ideas, brainstorm and foster creativity.

Controling Many Small Changes: Taming the Culprit for Most Accidents or Failures

As changes creep upon our processes, methods and systems; we accumulate little bits of inefficiencies which eventually become large and cripple the system.

Six Sigma helps ensure continuous improvement, through the use of data collection to analyze and understand how a process works or changes. The focus in this case is to reduce variations to processes or design ultimately leading to less defects. Common approaches to identify these variations or deltas is through the voice of the customer (VOC), quality function deployment (QFD), failure mode effect analysis (FMEA) among many others.

Lean improvement approaches can also help address change creep consequences. The focus in this case is more on waste minimization and elimination. Common approaches are value stream analysis, the five S, Kaizen events, just in time, work standardization and error proofing.

__________________________

Picture: The Nile Delta in Northern Egypt. Image depicts delta erosion.

Feedback: A Core Component of a Successful Process

Processes comprise of a functions which operate on inputs to produce outputs. Data associated with the inputs and outputs can be used to further enhance the process quality. The data related to the process outputs could include important elements that when fed back to the input within a solid analytical framework could offer valuable insights and impacts on the process improvement.

Several key steps in designing the appropriate data collection, analysis and feedback system are summarized below:

1. Decide where to collect the data
Data can be collected at the input, various processing points, decision-points, at the output or any combination of all of these locations.

2. Decide what measurement systems to use
Various techniques exist to collect and measure data. Decisions need to be made on best statistical approaches, summarization techniques, collection methods and the levels of accuracy and precision needed.

3. Decide how to analyze the data
Approaches of data analysis need to be determined. It is important to determine cause and effects, root causes, correlation, regression dependencies and other relationships among the various variables and factors.

4. Decide on how to use the information resulting from the data analysis
Decisions related to the application of the information learned is important. For example will information be applied in real-time, or after process reengineering is brainstormed.

The Cruiseterminal - The World's Floating Dock

Even by Dubai's standards the Cruiseterminal is an extravagant project. Rigged to a foundation in the Persian Gulf it can host three of the largest cruise ships. Its an integrated system comprising of its own photovoltaic electricity generation subsystem, an entertainment and retail subsystem, a 180 room lodging subsystem, docks for tens of smaller boats.

A system such as the cruiseterminal brings new challenges not only to system design and development, but also system operations, support and maintainability.

To check pictures of the Dubai floating Cruiseterminal among other structures, check De51gn at http://de51gn.com/design/the-floating-world-of-koen-olthuis/

Using the Theory of Constraints & Six Sigma to Fix Critical Components of the Economy

Constraints are all around us. The theory of constraints is a lean problem-solving concept based on a simple concept, that a process can not move faster than the slowest part of the process.

Our economy as a complex enclosed system has constraints and it will respond to stimulus as quick as the slowest link in the economy. The chart on the left illustrates some major components of the economy. They all need to be improved for the stimulus to realize benefits, otherwise it will be a temporary patch.


The root of the problem lies in three areas:

1. The concept of printing money and the process followed to release cash into the market. The Federal Reserve Bank - which is not a government entity - is provided the authority to distribute the nation's currency and supervise banks which are members in the system. When the US releases currency into the market it requests the Federal Reserve Bank to print dollar bills in return for an interest payment on the amount. No real assets are provided as collateral to backup the value of the printed currency. The value of the currency is only backed up by the reputation and promise of the US government to accept the currency as a form of payment. As users of the currency lose faith in the governments ability to keep the promise the value can drop significantly. One reason for the poor confidence in the currency, is the automatic depreciation of the currency the day it was printed. For every US dollar printed a small percentage is due to the Federal Reserve Bank as interest on that printed dollar, in a sense every dollar released into the market is really worth 0.98 of a dollar, if we assume an interest rate of 2%. Add onto this, the fact that the US government is running into a non-stop deficit in social security, and other areas leading to increase in bond issuing to countries such as China and India, further diminishing the value of the US currency.

2. Interest rate or usury is another problem in the overall system. The fact that currency value depreciates today based on some future value determined by an interest rate automatically leads to inflation, and future depreciation of natural resources. Charging interest is like pumping steroids into a body builder, eventually at some point the body will collapse.

3. Selling what we don't own. The idea that goods and services can be sold without actually owning them creates a virtual commodity system, not backed up by real commodities or assets.

Unless these areas are fixed no stimulus package can work on the long term. Some simple steps to address this issue are:

a. Identify the constraints of the financial and monetary systems
b. Exploit the constraint or re-engineer
c. Subordinate other steps in the overall process to the improved constraint
d. Revise the constraint if it has not been eliminated by steps b and c
e. Repeat the steps above for other constraints

Applying this into practice can be as follows:

a. Identify the constraints of the financial and monetary systems
- Currency not backed by a true tangible asset (some natural resource like gold or silver)
- Currency being depreciated the day it is printed, solely due to interest
- Distribution and sale of products that do not exist (example lending money to a business when the bank does not have the exact cash reserved, selling a commodity that one does not own and has not yet paid for)
- Using interest rates to discount projects, assets and commodities to a future value, leading to valueless future assets, commodities, natural resources

b. Exploit the constraint or re-engineer
- Re-engineer the monetary system that issues a currency based on a true asset and not just a promise
- Re-engineer the concept of future valuation
- Re-engineer the concept of wealth circulation

c. Subordinate other steps in the overall process to the improved constraint
- Use a sustainable natural resource to backup the value of an issued currency
- Use joint partnerships, gifting (0% loans) and entrepreneurship, moving away from interest bearing loans of money that is not owned by lenders.
- Base future valuation on true-value (value proposition) provided to global society rather than a discounted interest rate.

d. Revise the constraint if it has not been eliminated by steps b and c
e. Repeat the steps above for other constraints

One Way to Ruin a Great Product Idea - When Design and Implementation Miss

A friend of mine sent me some interesting pictures for projects that might have seemed successful on paper, when in implementation they failed. This is where a systems engineer comes in handy, in cases like these.

A Financing System for Prosperity, Growth and Social Justice

My dear friend Mohamed El Habashy sent me a link to an interview that he was part of on PBS. He was one of several experts interviewed on hot topic of Islamic financing. It seems that the World suddenly woke up to realize that a system that was revealed to mankind some 1430 years ago is now all the sudden a good choice.

The Islamic financing system is based on one of three main models:

- Mosharaka (joint ownership through stocks, capital partnerships)
- Qard Hasan (good lending, a loan with no interest (0%) regardless of amount and maturity date)
- Mudaraba (entrepreneurship or partnership with effort and experience)

Several key concepts in Islamic financing are

1. Joint sharing in risk and reward (property/asset price increase and decrease) - is part of the definition of ownership in Islam, and it provides responsibility and fairness to all parties.

2. The concept of selling money (lending with interest) is prohibited. In Islam lending money as a form of investment is prohibited and not in compliance with the Islamic Shariyah.

3. Sales are only acceptable on items owned. This means someone can not sell an item (product, service, shares, commodity, etc..) unless he has paid for it in full and has full control on it. In Islam a person selling stocks that he never paid for is prohibited and not in compliance with the Shariyah.

As of today there are no 100% Islamic compliant financing vehicles in the US, the efforts mentioned above in the PBS article are good and trying to strive to get close to the fair and just Islamic financing. However due to regulations and other factors there are some gaps, such as the joint risk sharing in a partnership model. Islamic financing has been around for 1430 years from the days of Prophet Mohamed and it is implemented in many parts of the World (UK Links: 1, 2, 3, 4, 5) we in the US are just behind. There is a US institution that has started offering some Islamic vehicles.

There is no question that Islamic financing is fair, just and solid, providing fair social rewards to all parties involved, unlike other means of financing. Islamic financing can be used by non-Muslims as well whether they decide to fund or use the system.

Usury/interest was prohibited not only in the Quran, but Jesus and Moses were ordered to tell the people to not engage in usury. (proverbs 28:8, Ezekiel 18:8, Exodus 22:25)

Finally America Might See a High Speed Rail System, or Might It Not

It's not about time that America gets a high speed rail. It is way past due. Japan had one for decades, and Europe has been there, did that ages ago.

These days there are discussions about two impressive high rail initiatives worth mentioning. In the West Obama is pushing for $13 billion ($30 billion total cost) high speed rail system (links 1) in California and the heart of America's Mid-West, Chicago, my favorite city. In the East King Abdullah is launching a high speed rail route between Makkah and Madinah.

Wikipedia has compiled a list of high speed rail projects across the globe. The Saudi project is impressive as it has the least cost / mile worldwide. The American is impressive because it is the first in the Western Hemisphere and second fastest worldwide reaching a little over 150 miles / hr.

Now here is the big project. China's high speed rail, the longest worldwide reaching over 800 miles and exceeding the American train speed. A really neat chart showing the world's top high speed projects can be found at infrastructurist.com by Yonah Freemark.

So the questions that pop up are: Why did it take America too long to initiate such a project? Will it be a success or another Acela (links 1, 2) Successful system development is contingent on many factors some of the critical ones are policies, supporting infrastructure, overall cost, stakeholder value proposition.

So why do I consider Acela a failure (1) Well, for one it was a very expensive system, secondly, it did not take away much volume from other modes of transportation. If it takes me an hr to drive from my home to get to an Acela station in Washington DC so that I can get to New York City in a couple of hrs, I might be better off driving up to New York in 2.5 hrs and pay less in gas and have the convienence of my own transportation in all the other pockets of cities and suburbs that lack public transportation. Just one of many aspects of the overall system that needs to be considered.

The boundary of a high speed rail system does NOT stop at the tracks, it goes beyond the tracks and stations to the supporting infrastructure that will allow people to get to the high speed stations, use the facilities and services within the service levels and value proposition a stakeholder will expect.

New PMP Practice Book Released Today

I just received a proof copy of my new PMP practice book today. The book is a great tool for those who prefer the self-study route. It comprises of 15 chapters covering the concepts of project management, a project's life cycle phases, process groups and project domain areas (scope, schedule, cost, risk, communications, risk, procurement, quality, human resources and integration). It also includes a chapter on professional responsibility, and a chapter with extra 130+ questions. The whole book offers over 420 practice questions very similar to the exam. The book is not a study guide (it does not have content to study, just problems to practice), it does have a chapter on how to prepare for the exam and various tips ranging from "how to get to the test center" to "how to respond to questions"

It can be purchased online from https://www.createspace.com/3380201 or from Amazon.com

Tools Alone Produce Fools

Managing a project or defining a complex system requires the knowledge and skills of appropriate methodologies and processes to realize the objectives. An individual who only knows how to use a project management tool (see selected list of tools in the sidebar), but lacks the understanding of the iterative and progressive nature of projects and how to manage the different processes within each phase will not be able to lead a successful project.

There is a big difference between developing a schedule that works and a schedule that looks good in a tool. Expert project managers need nothing more than a pencil and sheet of paper to lead a project. Tools help automate calculations and enable updates and corrections easily, allow tracking of changes and ensure a controlled environment that is agile and flexible. Tools do not defie methodologies, approaches, strategies, or plans. Tools do not execute, monitor or control and tools do not communicate, coach, inspire, motivate and collaborate. Only project managers do.

Are your pencils sharpened?

High Availability Systems Failure

Does your business require availability capabilities? In today's complex business landscape and the demand for high accountability and transparency, high availability becomes a basic requirement in operations, information access and decision-making.

Interestingly most high availability environments that fail are unable to deliver the expected results no because of technology immaturity, but mostly due to poor management and oversight. A publicly known example is the State of Texas data loss as a result of invalid checks and balances and inappropriate technical management. In this particular case according to the article in the Dallas Morning News IBM has been fined $5.4 million. Of that, $2.7 million was for failing to resolve problems quickly and $1.2 million was for server outages. Data backup breaches, missed mail deadlines and taking more than 15 minutes to respond to serious incidents accounted for the rest, according to department records released this week.

Next time you implement a high availability solution, do not get fooled by the latest server technology, data backup system or disaster recovery tools. A high availability technology with a staff member who can not use it makes it useless.

Maryland is First in the Nation to Reach Recovery and Reinvestment Act Milestone

States are required to meet certain federal guidelines and requirements to be eligible to use recovery funds allocated to the State. On March 23rd, Maryland reached this milestone. According to the State of Maryland Governor's website, "Phase I of Maryland’s ARRA funded highway projects totals more than $224 million and has the potential to support up to 10,000 jobs".

On the top of President Obama's priorities are business integrity and fiscal responsibility. Vice President Biden has been assigned this responsibility. This will drive the need for certified project managers and professionals by contractors to ensure best compliance possible with sound business practices and accountability standards.

This is a great time to get PMP certified for professionals interested in pursuing recovery act projects. I am offering several workshops soon.

Risk Management Through Coaching

To manage risks on a project we tend to follow various processes such as planning for risk management, conducting qualitative and quantitative analysis, and responding to risk. These processes include specific details such as the definition of a risk, risk triggers and thresholds, steps the team will take to identify risks, the classification and groups of risks, risk prioritization and many other little details. These processes work very well - when implemented correctly of course - and are successful in avoiding the negative consequences of a potential risk should it occur.

Besides these well known and understood project management, agility or systems engineering processes, coaching and mentoring is another powerful tool for risk management. Having another project manager as your coach allows you to get a fresh insight on project health and can hold you accountable in an informal manner to project goals and aspirations. Your coach acts as a friendly auditor and makes collaboration even fun.

Next time you manage a project don't forget to have a coach or buddy, whom you trust. You will not only gain some insights on your progress, but you will also be motivated to raise the bar.

External Project Risks More Important than Ever

As the economy becomes more challenging and the impact of globalization increases project risks become more in number and impact. Moreover external risks are closer than before. Examples of external project risks that have become much more visible during the downturn and that project managers should start accounting for if they haven't already are:

- Fluctuating currency exchange rates
- Labor issues (strikes, layoffs)
- Regulation changes
- Customer investment and purchasing changes
- Contract breaches
- Financing and investment opportunities

3 Ways To Guarantee a Failed Product

I was at the county jail a few weeks ago coaching a group of young men on strategies to transition back into society. I asked them two questions, the first list 3 goals you would like to accomplish during your lifetime, things you will be proud of in the hereafter. They jotted down some goals on 4*6 cards. The second question was list 3 things that if you do, you are 100% sure that there is no way you can achieve these goals, it will be impossible to achieve them. I gave them a few minutes and they all had a few points to share.

One example of a goal that was shared was to get back to education and enroll in college, get a degree and be a productive member of the society. The young man noted involvement with illegal substance to be a factor not allowing him to realize this goal.

Developing successful systems follow the same pattern. We need to understand user requirements, the utility of the system, why is the system needed, what value is the system offering, the gap it is filling. Once that goal is clear and understood, we need to make sure we protect these requirements from "outside noise", what is also known as scope creep. Scope creep is for sure a main reason why projects fail, it is when we add requirements, remove requirements, or just change requirements in an uncontrolled fashion, without going back to understanding the rationale and true value for doing so and relating it to the project's objective, cost and schedule.

Reason 1: Low Quality Requirements and Scope Creep - Uncontrolled Changes

A second young man in the group shared his goal was to be a successful businessman offering valuable services to the society. He noted down that unethical dealings would be a reason to ensure he never accomplishes his dream. I advised him that to overcome this hurdle he needs to continuously gauge his relationship with his Lord and measure his values and ethics. If he notices that his relationship is getting weaker, he needs to take corrective actions.

In the domain of systems development we call that validation and verification. Is the project still valid? i.e. is it still delivering what it was originally intended to deliver. And is the work correct? Can we verify that the work is what was expected earlier at the beginning of the project, through testing, and if it is not correct, can we take corrective actions to resolve defects. This validation and verification needs to be conducted throughout the whole life cycle of the product, and not just near the time we turn it over to the client, otherwise the deviations from the expected results could be huge, leading to costly modifications, schedule slippage and possibly a failed product.

Reason 2: Not Considering Validation and Verification Early in the life cycle of the product - Developing the wrong product, or developing the right product incorrectly

A third person shared that his goal was to be a teacher, nurturing young minds not only with knowledge but the application of the knowledge and its purpose. I reminded him to share with his future students trace back the purpose of the knowledge they learn from him, to the purpose for which we were created. Everything we do needs to serve the purpose for which our Lord created us.

Similarly, in the domain of product development, we can that requirements traceability. How do the original requirements defined by the client relate to design work, development work, testing and final product features. It is important that throughout the life cycle of a product we maintain a clear trace of how the work we are currently involved in relates back to what the customer needs.

Reason 3: Poor Requirements Traceability - Missing some Requirements in Implementation, adding Features not Needed, or both


Make sure if your customer asks for a mule, you deliver a mule as expected, and not a cow. Although a cow has plenty of benefits and utility, it might not serve the need satisfied by a mule.

7 Tips for Engineering Students

I often get questions or concerns from engineering students about studying and being able to pull through college to reach their goals of becoming engineers. I have to admit going through engineering school is no light challenge, but at the same time it is an enjoyable experience.

Common comments are concerns of not being able to understand the questions in an exam, or not able to go through the needed steps, or just finding subject matter too complicated.

Here is my advice for of these folks and other future engineers.

1. Understand that engineering is all about problem solving for the betterment of humanity, through the use of scientific facts. This means that a good engineer must,

• understand what the problem is (how it happens, why it happens, when it happens, where it happens)
  
• analyze the problem - visualize it (use a pencil and paper to sketch, engineers are born to sketch)
  
• determine its scope - (how big is the problem, who does it affect, under which conditions)
  
• determine what information is given to us (data, assumptions, facts)
• learn the sciences (calculus, physics, chemistry, etc..) to use in problem solving
• apply these sciences to the appropriate solutions for the relevant problems

2. Never memorize, engineers are thinkers. Anything you learn must make sense to you. You must understand why a theorem or rule is the way it is, how it came to be so, this will help with critical thinking, and will enhance information retention.

3. Do not depend on calculators too much, understand how calculations occur, understand how the value for the various engineering functions are calculated, the meaning behind a differential, or integral, etc.. Then use the calculator to just speed up calculations - remember a fool with a tool is still a fool.

4. Develop mini-processes for yourself of things to do when you analyze engineering problems, make these processes adaptive to suit your thinking styles, analytical abilities and memory capabilities.

5. Practice makes perfect. Just like spending ours in the gym pumping those muscles up, or on the court perfecting those slam dunks. Engineers need to practice solving various types of problems (easy one, long, ones, short ones, complex ones, complicated ones, straight-forward ones, etc...).

6. Be organized - learn how to manage real-estate space on your paper. Organize data, analysis, scratch notes, results, conclusion in clear separate sections of your sheet. Be a good communicator, improve your writing and verbal skills, to allow you to effectively communicate your solutions to others.

7. Love the subject matter. You can never solve a problem, you don't care about. A good engineer can never design a bridge if he cares more or less of the importance of crossing the river. Love it, adore it, live it, immerse in it... be the engineer !!

Iterative and Incremental - We Have Something to Show

On projects which follow a waterfall methodology and run into project delays, usually there is nothing to demonstrate to the client. This is a little different with iterative and incremental methodologies. Iterative meaning we repeat the life cycle processes over and over, with an incremental addition in each run. With iterative and incremental development a delayed project can demonstrate an artifact to the client. It might not be everything the client wished for, but it is there.

Iterative and incremental methodologies provide higher levels of confidence to project sponsors, who would be more willing to extend investment in a troubled project than a project with no output at all.

Agile methodologies embed iterative and incremental approaches. Examples are Rational Unified Process (RUP), SCRUM, XP and others.

Great leaders know how to scope these increments and how often should they come out. For example lets consider a generic problem well know to everyone, the current economy down fall. This problem does not have a one shot solution. A $700 billion stimulus plan will not solve it for once and for all. It is just an iteration that will yield some results in 18-24 months, to keep things afloat. Most probably another iteration will be needed to sustain some of the new initiatives started in increment 1, and so on.

We apply iteration and increment processes in our daily lives as well. When we go to the grocery store to purchase soup, we don't purchase 100 cans of soup for the full year, even if we could successfully store them and pay for them. We purchase maybe 5 or 10 cans for a week or two, we then repeat the grocery purchasing process in one or two weeks.

Reasons for iteration are many,
(a) gain confidence in an experience to decide whether to repeat it or sustain it or not
(b) streamline cash flow
(c) simplicity
(d) effective time utilization
(e) limitation in resources
(f) shorter demand cycles (time to market, constituent demand, etc..)

Effective Project Management in a Snipit

What are projects all about? A project is about delivering capabilities on time and within budget. So you are hired as a project manager at company ABC to ensure that their new product can be developed within the next six months and within budget as defined by the product team.

To ensure the delivery you need to accomplish a few basic items. Most people don't even do this bare minimal checklist below.. and guess what they wonder why their projects are among the 60%+ statistics of failed projects.

a) Understand the problem/gap the product is offering to solve (ie understand the value of the end product)
b) Define the project scope (schedule, cost, capabilities, stakeholders, assumptions, dependencies and risks)
c) Put together a good team that compliments each others skills, abilities and knowledge.
d) Define all work items that are needed to make the capabilities (product) delivered, in a hierarchical format (aka work breakdown structure - WBS), detailed to a level that can allow weekly reporting on the status of work completed
e) Define activities and their duration and resources needed to accomplish the work defined in the WBS, and come up with a schedule and cost budget.
f) Track the work completed relative to the cost and time spent to date and as planned. Are your cost and schedule variances healthy?
g) Know and track your risks throughout the project and mitigate as your move forward.
h) Ensure changes are controlled and tracked along with risks, issues, cost and schedule health.

You can be comfortable that you have a good chance of delivering your end product. Of course there are other details, but for the most part this is the backbone, if its solid, your project should be able to make it to the finish line.

Volunteer Team Members on Your Project?

Have you ever run a project that is solely or mostly running on a project team of volunteers? I was presenting to a group of program directors in the research field. Their dilemma is that they manage projects which have team members fully run by volunteer researchers from other organizations.

After comforting them that they are not the only people in the world that run projects fully dependent on volunteers, but rather they are part of the millions of teachers, religious groups, social service groups, civil rights, good citizens, and dozens of professionals who donate their time and expertise for the good cause of the World .. they became more relaxed.

So back to their challenge... How to get a volunteer - someone who is not paid, not officially or legally bound, not under your authority or control - to do their part on the project as a team member?

Answer is simple: Motivate and ensure the value they are interested in by doing this good will is present and did not disappear.

I have managed and coordinated tons of projects such as the one we are talking about. I also participated in tons where I was a team member. Bottom line --- as long as there is volunteer value. They will not only stick around, but will produce exceptional value... let it evaporate and before you know, they are all gone.

Example: Project X: Goal is to initiate, launch, implement and supervise a series of monthly community dinner at a Muslim community. Volunteers who are interested in being part of this project will most probably join for one or more of the following reasons,

a) they like food, food events, cooking, or have some passion to food
b) they like social gathering and chatting with others, like to be part of a group, or big family
c) they respect organization and like to see these events well organized and a god experience for every one
d) they just want to help out a community they belong to and enjoy being part of

So as a project manager, you know that all these volunteers are not getting paid, have very limited time, might live far away, but are interested in helping out, because they told you. As long as those 4 items above are maintained, they will keep coming. Now when something happens and for example these volunteers are no longer allowed to cook and bring in their own meals to share with others... they will not come because point a) is not longer available. Or if they feel that participants dont get along together and some tensions arise then they will stop again because point b) is no longer available... and so on.. you get the point.

So in a nutshell project manager need to have strong emotional intelligence skills and keep their eyes and ears open to what the volunteer team members are interested in and how much of it is on their projects.

Back to the volunteer researchers from all across the country that are on Bob's project (not real name). As long as the researcher's can add their work to their tenure requirements, paper portfolio, get academic recognition, be known as a participant, be respected for their knowledge and ideas, be able to have open communications with other scientists..... they should stick around.

Successful teams develop because they strive for the carrot, regardless what form the carrot takes.

Enterprise Architect vs. Service Architect

If you open any book on SOA you find it defined as an architecture which offers a framework for improved business - technology alignment. In [1] SOA is defined as "a framework for integrating business processes and supporting IT infrastructure as secure, standardized components - services - that can be resused and combined to address changing business priorities". The IBM SOA Foundation [2] defines SOA as "the practice of deriving an information system design from a business design".

I find both definitions to be confusing and incomplete. The first definition is basically an enterprise architecture (EA) framework, right? The definition that it is a framework means that it defines governance, perspectives (views) and/or some methodology. Similar to TOGAF, or Zachman (does not have a methodology) or other well known architectural frameworks. TOGAF which is a framework for enabling the design, evaluation and build of the right architecture for an organization [3] offers an enterprise macro level architectural definition. TOGAF defines four main domains - business, data, application and technology. Well, the answer is not quite right. SOA is not EA, SOA is applicable at a level lower than the enterprise, it is focused on the service level, wherever it might be. In some cases services could be enterprise-wide and high level, but most of the time it is local.

Lets think of SOA as the "service instantiated" architecture for an enterprise architecture. To make it easier to understand lets take the example of a small non-profit community center. An enterprise architecture for this community center is the evaluation, definition, design and build of an integrated structure unifying the community center to allow it to achieve its mission. For example an enterprise staff appraisal system as part of that architecture. On the other hand SOA will define how the various services related to a staff performance system can be designed in IT resources and aligned to the business goals. Services could be "Staff Feedback Solicitation", "Performance Appraisal Metrics Definition", "Performance Appraisal Metrics Assessment", and several more. So in a sense SOA is addressing the question of "now we have an enterprise wide structure and method to appraise staff performance, how can we actually turn it on, and customize it for different departments, with optimum reusability of approaches and resources.

Other definitions of SOA is that is it is "a methodology and approach that can be utilized to deliver or to support an enterprise architecture initiative" [4].

______________________________________________________________
[1] Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones and Rawn Shah, " Service-Oriented Architecture (SOA) Compass: Business Value, Planning and Enterprise Roadmap, IBM Press, 2006.

[2] Rob High, Stephen Kinder and Steve Graham, "IBM's SOA Foundation: An Architectural Introduction and Overview", IBM Business Consulting Services, Version 1.0, Nov 2005.

[3] The Open Group, "The Open Group Architectural Framework (TOGAF)", Version 8.1.1, Enterprise Edition, 2007.

[4] Niel Maehiter, Quote in an Article titled, "What's the difference between SOA and enterprise architect?" by Joe McKendrick, June 11th, 2007. (link)

Metrics for Defining the Complexity Level

I was sitting in a meeting when a whole bunch of folks started sharing ideas on how to assess the level of risk associated with a project or system under development (SUD). Some thoughts were to consider the number of requirements, others the number of change requests needed, and some suggested the level of engineering support needed for a requirement to be realized, for example does the requirement call for an architectural change, design change, development change, or just test or only support during testing.

I agree with the last proposal, analyzing the scope of changes is a good way of defining the complexity and hence the risk of the project, then we can create metrics that reflect these different levels of engineering support. Merely looking a total number of requirement, change requests or development teams involved might not provide the most accurate assessment. Instead, the system architecture needs to analyze and study the requirements impact and assess design complications, development challenges, testing validity and deployment issues. This integrated view can provide a more objective feel for the level of complexity involved in the SUD. A system might have only two system level requirements that drive the whole architecture change and hence brings in large design, development, testing, deployment and support efforts, compared to another system which has 2 dozen requirements which marginally impact development and will hence have a much lower effort in other areas and less overall complexity and risk.

I came across some interesting articles and papers on this topic.

A Complexity Assessment Methodology for Programmable Electronic Mining Systems
Software Complexity Measurement
Design Complexity Measurement and Testing
A Function Point Method for Software Complexity Measurement

How do you assess the complexity of a project in your environment?

A System for Complex Event Management

It is expected that about 2 million individuals will visit Washington DC on Jan 20th. This will not be the largest event that draws pedestrian traffic. Each year Saudi Arabia hosts over 3 million pilgrims in Makkah and its surrounding areas for the Hajj worship activities. The Saudi's can attest that is is by no means an easy job, to keep the crowds safe, moving and able to do what needs to be done with ease.

The inauguration is a little different and less complex that Hajj in a sense that the largest part of the event is confined to the Mall and mostly static - i.e. folks are sitting or standing to witness the President as he gives his speech. Whereas, the Hajj is a more dynamic experience. Pilgrims move back and forth between Makkah, and the nearby mountain of Arafat and the valley of Mina on the outskirts of Makkah, 8 km away. Among the pilgrims are also celebrities such as Presidents and leaders of Muslim countries, businessmen, athletes, scholars and other well-known public Muslim figures who have intended to perform their pilgrimage. So the complexities of the inauguration might be much simpler than that of Haj, yet the organizers and teams overlooking its management have put a great deal of effort in organizing it that is worth discussion.

I share a few images - courtesy of the Washington Post - of how the event is organized illustrating security checkpoints, seating areas, entrances, exits, rest areas, vending, etc.. You can call these mission diagrams or context diagrams, at the end of the day the represent the high level architectural overview, which is worth appreciating as it reflects the amount of effort out into managing an event effectively.

The Saudi Government as well has recently taken extra ordinary measures to control the Hajj traffic and ensure safe experiences for the pilgrims. What is interesting is that the Hajj planning never required the closure of any streets in Makkah near or around the Holy Kaaba, unlike the inauguration plan, nor has it required security checkpoints such as those in the inauguration, other than guards at the entrance of the Grand Sacred Mosque for visual inspection.

This is a very interesting domain that is worth research, and I am sure there is a lot to learn from both the Saudi and American experiences.

Update: 3/22/09 - There is a discussion on linkedin related to major event management, you can follow it here, if you are member of "Project Manager Link" group.

Is there a difference between a SOA repository and a SOA registry?

Generally speaking a registry is a location that stores information about registered entities. A few of examples of registries could be a town's birth registry which records all births in the town, a College class registration office, and an annual article index of a publication which lists all articles that appeared in the publication during a particular year.

Registry is defined in the Webster's College Dictionary as the "place where a register is kept", and the dictionary defines register as "a book in which records of events, names, etc., are kept".

In the examples provided above we see that the birth registry will contain a list of all names of people who were born in the town, their dates of birth and maybe some other information like the address at the time of birth, ages of parents, names of parents, etc. We do not expect to see the actual people in the registry ! The people will be in their offices, homes or wherever else.

Similarly, in the case of the annual article index, which is another form of registry we expect to see the titles and dates of publication of articles that appeared in the publication during that year. We do not expect to find the articles themselves in the index of articles.

A repository on the other hand is a location where actual artifacts are stored. We can guess that for the example of the birth registry, the actual repository would be hospitals, delivery clinics and places where people give birth. This is where we can actually find the babies.

Similarly in the case of the article index, the actual articles would be find in the various issues of the publication throughout the year, and would be stored in a library.

Repository is defined in the Webster's College Dictionary as " a place where things are deposited, stored or offered".

So now in the context of SOA, we can define the Service Registry and Service Repository as follows.

Service Registry
A comprehensive list of all SOA services available to an enterprise to achieve a business objective. The list would include the service identification information, location of the service, service classification (purpose), and information about how to interact with the service.

Service Repository
A storage location that houses the SOA service and its components, is involved in controlling access to the service and the presentation of the service to its users

If we ponder for a moment we notice that some key areas of a SOA service are neither part of a service registry or service repository - at least by defintion. For example a service's history, statistics about the the service, performance reports, etc.. by definition are not part of the repository. Some SOA implementations or frameworks might decide to store such service management reports and information in the repository, others might wish to develop a SOA Service Management Repository which will house that kind of informaton.

Systemic Reflections from the Obama - McCain Race

There is no doubt that Obama not only won the elections, but also smashed his opposition. Looking at the Electoral votes we see a torrent gap 349/163 and a popular vote of 53%/46%... what a surprise... totally unpredictable... I personally thought he might win 51%/49% and maybe an electoral vote ratio of 1.1/1... not 2.14/1..

So this tells us that human systems are totally unpredictable.. engineering a system with a human as part of it might be suicidal in some cases. So lets take the example of engineering a commercial aircraft, is the pilot part of the system or not? Most system engineers will say.. not really ... the system is the plane (structure, mechanical, electrical, etc..) we can model those, but we can't model the pilot, what if the pilot is too slow to land, or fell asleep during take off.. so many soft factors to model, so lets take the pilot out of the picture.. and then we test (verify) out plane with an average pilot... that is a pilot who did not have a bad day, did not lose a loved one the week before, is not tired, has no spousal problems, etc.. So the test passes, aircraft declared ready for production, sold and used for years, without a hitch...

We recall the Egypt Air flight than mysteriously dropped out of the Eastern US skies on Halloween night 1999, until our date we have theories and thoughts of why the sky bus blew up and perished in the air... some say the pilots walked out of the cabin to stretch, when the senior pilot walked in and committed suicide, other theories are cracks in the wing, a third fuel leakage, and a fourth contribute the root cause to a strike 10 yrs ago when that batch of 747s where in Seattle on the assembly line, and that because they were not in a good mood the quality of manufacturing standards was below nominal.. who knows.. it could be all the above, or none of the above.. bottom line is that many of these root causes include a human factor.. totally unpredictable .. just like the American voters.. the time has come to include soft factors into engineering problems -- Point 1... we can't ignore soft factors

Now, wasn't it the McCain campaign that distributed those millions of DVDs in swing states to tell them about how radical Islam is? Covering up truth, and smearing others does not work anymore... the people are more educated nowadays than the 80s, 70s, and 60s.. thanks to the so called Internet, and its myriad of facebook, you tube, google and countless other applications.. --- Point 2... Fooling customers never works, eventually they will know that you are marketing a 747 and selling a prop.

Finally, end users buy and use what they want, not what you tell them they need... Americans don't want their daughters and sons in Iraq, Americans don't want their 401Ks wiped out, they don't want to lose their jobs, telling them that pulling out of Iraq is not only stupid, but irrelevant.. regardless whether it is a good idea or not, its not what they want to hear. End users want to hear solutions to their problems, they don't want solutions to other problems, and they are not smart enough to know where root causes come from, you where there when the plane crashed.. then you must be involved. --- Point 3... It doesn't matter how brilliant or great your idea is, if it does not solve my problem, its worthless in my perspective [1], also I don't care why the system crashed, the point is that you did not do a good job designing it. Don't blame the storm, blame the plane [2]

We can wish as much as we want, model as much as we want, take the means, but at the end whatever Allah ordains will happen...

Now whether Obama will deliver on his promises is a completely different story, history will let us know.

SOA Programming Allows Independence

The SOA programming model is to embrace underlying programming languages that are already deployed in the enterprise. It does not mater whether applications are .NET, CICS, Java, SAP based, or based on any other technology, these technologies are all transparent to SOA.

SOA allows the architect to hide any variations or differences between languages and programs to maximize reuse. Additionally we can drill down into unique aspects of a specific language or program only when needed, without exposing the details.

One of the major benefits of this programming model followed by SOA is to program and develop business and service design rather than a technology. For example the programming focus would be on a student grade verification process, rather than a .NET session.

Any experiences to share?

XML's role to SOA

SOA leverages the standard XML data representation to reduce underlying complexity of application environments. Some are examples are;

- Passing XML documents and schemas between applications allows for the standardization of data format and type, which this improves predictability and performance.

- XML documents are easily understood by different stakeholders such as architects, analysts, developers and users, leading to enhanced data maintenance, traceability and clarity.

- XML allows the support of standardized vocabularies across the enterprise, hence reducing mis-interpretation of corporate data and data models.

- XML allows a SOA based system to realize a foundation data representation and data management layer.

For SOA to leverage the benefits of XML, a solid XML architecture should be developed and implemented. Such architecture should include architectural components for data transport, structure, validation, verification and modeling. Accommodations for RPC-style messaging needs to also be considered if an environment does not support document-style messaging (SOAP). In such cases we need to ensure no conflicts exist between usage of RPC-style SOAP messages (from shaping XML documents around a parameter data exchange model).

A Slotting System for Misery, Poverty and Crime

It was a bit of a shock to see that Marylanders favored bringing slot machines to Charm City, and its suburbs. It is no more than a call to bring crime, prostituition, and long term economic failure. This is not just my opinion as a Muslim Systems Engineer, but that of any person who has some basic knowledge of economics and social reform will have the same opinion.

What comes easy goes easy. Slots brings a system of vapor to Maryland. No true productivity, no true growth and no true value proposition, other than greed to the operators.

We should not be surprised to see more bankruptcies, shattered households, and chaos similar to the global financial crash pretty soon in the Free State.

Should Systems Engineers Study Psychology?

Given the fact that systems engineers deal with systems, and most systems comprise of a human element in it, it seems to make sens that systems engineers need to know a little about how people act.

Humans are very complex system components, they can be viewed as a system in themselves (human system), or even a system of systems (SoS) (digestive, neural, circulatory, psychological, muscular, etc..)

So maybe after all those biology classes we used to study in middle school do have some benefit to enterprise architecture. I guess systems engineers who are involved in soft system should study not only psychology, but maybe also other human systems of interest to the largest SoS.


I came across an interesting article at http://www.techjournalsouth.com/news/article.html?item_id=6299 which discusses cognitive systems engineering, which is defined as, "A combination of psychology, anthropology, computer science, design and systems engineering, the field of cognitive systems engineering is the understanding and designing of systems that require human intellectual work".

Got to go dig those science books..

So What are the Services in SOA?

Service-oriented architecture has gained heavy adoption over the past few years. The next several postings will provide a high level SOA introduction. I am hoping the posting could serve as a basic primer for systems and project professionals working on a SOA project.

What is service-oriented architecture?
An architecture that allows the alignment of business processes and objectives to Information Systems in a flexible and adaptive manner, through the defintion of services.

What are these services?
Services are modular and repeatable business processes. A service could be defined at different levels of the organization. for example, a "customer update" could be a service that allows a customer to update their profile. On another level, a subscriber authentication process - to allow customer to gain access to her profile to update it - could be a service.

What are the main characteristics of a SOA service?
Services are also loosely coupled, maintaining a relationship that minimizes dependencies and only requires the awareness of connected services. Services are stateless and minimize information related to a specific activity.

So some examples of simple services in a sales department of a business could be; "collect customer information", "collect product /service information", collect payment terms". Each of these services could be broken down further as needed

Good Engineers are Managers and Leaders

Many schools of thought separate between leadership and management. While I agree they are different they are intertwined constructs. Read more here.

Lets take a simple example, one of that of a sales manager. Most people will agree that a sales manager is primarily a management role. However in the case of a small travel agency serving the air travel needs of its clients, the sales manager on a daily basis finds herself performing tasks such as establishing new relationship with potential suppliers (leadership), negotiating contracts and deals (leadership), motivating her sales staff (leadership), developing sales target plans (management), performing forecasts (leadership), reviewing sales reports (management), training employees (management(, coaching high school interns (leadership), addressing customer complaints (management) and calculating sales team commission (management). This is another example of how a sales manager role in a small business deploys leadership skills to remain highly competitive and ensure superior client value.

How much of your time as a systems engineer do you spend managing, leading and engineering?

Perfection Never Ends... KISS brings us closer

Last night I was chatting with a friend of mine who is working on the launch of a new project. I asked, "How far are you from launching?" His unexpected reply was "We will miss this year's launch and do it next year, I want to make sure everything is complete and people get to say wow"

The question we need to consider "Is it better to launch today when there is need, but have a modest service offering?, or to spend another year perfecting the service offering and miss the boat on this year's demand?"

KISS (Keep it Simple & Short) brings us closer to deployment and reality.. apply agility... get something working out the door, serve the need, use the opportunity to make further improvements in later releases... perfection never ends.

The Assertive Systems Engineer

So you are on a project to help the team develop a successful system. You notice things that don't make sense, or are not they way they should be. You raise your concern, "Hey, team we need a process to automate testing". Everyone looks at you as if you are some wacko, and then moves on with their business. Two weeks later and after 4 more team meetings you raise the concern again, and again. Finally one team member says "We always did testing this way, and we don't have the money or time to develop the automation, so don't keep repeating this".

What do you do? Shut up? Go with the flow? or be stubborn, resist to work in a chaotic environment? Actually the reaction should be neither. Smart systems engineers need to be adaptive, flexible and understanding of the business constraints and technical limitations. They also need to be assertive and counselors of best practices and approaches.

Document your technical opinion, the problem as you see it, the proposed solution, the rationale for the solution and consequences of not addressing the problem. Be assertive about your technical opinion, and also flexible to adjust the solution as needed to meet the laws of physics and constraints the team must abide with.

Remember systems engineering is all about engineering a system with the most optimum means, in accordance to sound decisions and rationale

ISO IEC 15288 / INCOSE SEBoK v3.0 Life Cycle Stages

Life-cycle definition is an important aspect of any system. By defining a life-cycle we can establish a framework for meeting stakeholder needs in an orderly fashion.

This order comes from the presence of stages in the life-cycle, and decision-making at the end of each stage to determine the readiness to move on. Stakeholders are concerned with the business case, funding and capability of a system at each stage.

INCOSE SEBoK ver 3.0 defines seven life-cycle phases. Each of these phases are listed below. Phases 2 - 7 are the same as the six phases defined in ISO 15288.

Pre-concept Phase:
Inputs: New ideas
Process: Creative systems engineering and requirements definition
Outputs: Identified enabling technologies

Concept Phase:
Inputs: Studies, experiments, models
Process: Requirements identification (if not done in pre-concept), indepth feasibility studies, prototypes, risk evaluation, early validation
Outputs: System requirements, feasible design solution

Development Phase:
Input: System requirements
Process: Development, integration, verification and validation
Outputs: Developed, verified and validated system

Production Phase:
Input: Tested system
Process: Modifications, re-verification, cost reduction
Output: Manufactured product

Utilization Stage:
Input: Performance reports, change requests, operational work orders
Process: Operations, change management
Output: Operational product, upgrades

Support Stage:
Inputs: Modifications, change requests
Process: Change control, maintenance, cost reduction, support
Output: Sustainable service and supported mission

Retirement Stage:
Inputs: change requests, competing systems
Process: System migration, removal, disposal
Output: Disposed system

System Sustainability: No Longer an Option

System developers rarely analyze or even worry about the long term sustainability of a system. The main focus is usually on today's and the near future's needs. The client says "I need to consolidate these two billing systems by next January".

Everyone on the projects starts to focus on this requirement. It becomes an architectural driving requirement, functions and operations of the new system will be based on this requirement and dependencies will start appearing, which if traced will be found to have largely come from that main requirement - consolidate by January.

No one gives thoughts to what happens after January. How and what will the new consolidated system look like and need to do to remain sustainable and not turn obsolete in a year or two and require another consolidation project with something else at the time.

Last year I was fortunate to do some research work under the supervision of Dr. Peter Sandborn of the University of Maryland. We looked into this topic - how to create sustainable software - and have come up with a model that might help extend the life-cycle of software systems.

With news that countries like Oman will run out of oil in 40 years popping up, sustainability in all aspects is no longer an option, but a requirement.

Agile In a Nutshell

Agile development is all about short iterations. Using what is known as a scrum process requirements are iterated and turned into use cases which are tested and so on.

The goal in agile is to test early, to identify early defects; and use continuous stakeholder feedback to deliver high-quality consumable code through use cases, and a series of short time-boxed iterations.

A New Buzzword in Town - Cloud Computing

So first it was Application Service Providers (ASPs) then Utility Computing and now comes Cloud Computing... It seems that every couple of years the industry needs a new set of buzzwords to keep the PR machine running.

Well there might be some slight differences between utility and cloud computing, but I would not really identify them as differences, I would just note them as the same with a slightly different scope. Instead of renting computing resources - utility computing - cloud computing rents applications and IT services.

So what is this cloud computing after all? Reading through various articles it seems to be nothing more than an application service provider hosting enterprise IT services for its clients. Its just technology improved from what was available in the mid-nineties, and vendor are looking for a way to get over the unsuccessful connotation of ASPs by relabeling the concept into cloud computing.

Some links on the topic from various trade rags for those interested:

http://gigaom.com/2008/02/28/how-cloud-utility-computing-are-different/
http://www.businessweek.com/magazine/content/07_52/b4064048925836.htm
http://www.gartner.com/it/products/research/cloud_computing/cloud_computing.jsp
http://www.technologyreview.com/Infotech/19397/?a=f
http://www.businessweek.com/technology/content/nov2007/tc20071116_379585.htm

What is RUP?

RUP short for Rational Unified Process is a process for software engineering. Originally develped by Rational Software, Inc. - now acquired by IBM.

RUP focuses on the following best practices:

1. Four major phases in a software development cycle (inception, elaboration, construction and transition)

2. Within each phase RUP allows for iteration and incremental development. this supports refined requirements, risk reduction and results oriented management.

3. Disciplines which group activities by nature. There are nine disciplines defined (business modeling, requirements, analysis and design, implementation, test, deployment, configuration management, project management and environment). These disciplines spread across the four phases of a software project.

4. Manage requirements using tools that support traceability, prioritization, validation and quality management.

5. Develop component-based architectures, where components are primary concepts for design. They are self-contained modules with clear interfaces that can provide a well-defined function.

6. Visually model software using languages such as UML, or SysML. Numerous tools on the market support these languages such as IBM's Rational Suite, IBM's Telelogic DOORS, iRise, Visual Use Case, Visual Paradigm and many others.

7. Verify software quality, especially in the areas of functional, performance and reliability compliance.

8. Control changes to software through a traceable and end-to-end approach.