Search My Blog & Website

Monday, December 21, 2009

Learning Centered Education

A learning-centered environment is one that focuses on the needs of the student rather than others involved in the educational process. Student needs range from administrative services, to tutoring and instruction, and include everything in between such as life services.

A learning centered environment ensures that the student is empowered to learn through a balanced power in the classroom, critical thinking, student research and discovery, improved modeling of learning by educators, learning conducive environments, acting on feedback and tight institutional integration with the mission of realizing mastery learning rather than curve grading and ensuring that learning is positioned in a well-applied context to retain and utilize the knowledge learned.

Business Agility: Do You Have Some?

There have been various attempts to define business agility out there. Many are bogus definitions and very incorrect, so I thought I shed some light on the proper meaning of being agile, and what it means to an enterprise. Michael Hugos defines agility to be a product of visibility, motivation and training. I do not fully agree with his point of view, it is too specific and focused on enablers rather than the definition of agility. Agility needs enablers, and these could be some of the required enablers, but not necessarily all, moreover, each environment and enterprise might require different enablers.

According to Webster's College Dictionary, agility is being in a quick and well coordinated state, or nimble, active and lively. So agility is a state when one is able to act quickly and to the extent needed. Over-acting is not agility, its actually exerting more than needed, and under-acting is low performance.

So applying this to an enterprise means that it is able to act quickly and in a lean way. The terms quickly and lean are a little vague, so its not a bad idea to add some context to them.

  • Quick is being able to respond to a stimulus in a time-frame that allows the enterprise to capture an opportunity or mitigate a threat.
  • Lean is being able to respond with only what is needed to accomplish the point above, no more and no less.
An agile enterprise is one that has the capabilities to execute and realize what needs to be accomplished, without overstretching itself or wasting resources.

Some close definitions to mine are Brad Appleton's, which is a little too specific by listing energy and also specifying it along with economy and efficiency; and Wikipedia's definition which ties it specifically to cost. There are many ways to enable agility in your enterprise. Nicholas Evans promotes mobility solutions as one approach. I believe cloud computing will also make possible many enablers for an agile business. An example of how cloud can make telecom providers agile is illustrated in my recent patent.

Agile = Quick + Lean

Some examples of lean enterprises are those that:

  • Can quickly change their website to respond to a trend, or customer need
  • Can easily and without introducing additional cost reposition a product line
  • Can enter a new market area with no additional overhead
  • Can serve new types of customers with no impact on its customer support resources
Developing an agile enterprise is an on-going process, and it pulls from many areas of the enterprise architecture. An agile enterprise has agile business, technology and governance, reflected in its operations, systems, infrastructure and competitive abilities.

Thursday, December 17, 2009

Do Not Undermine Your Most Valuable Asset: The Soft Assets

A couple of decades ago software was provided almost as a possible freebie to encourage buyers to purchase computer hardware. Today both hardware and software are available for free. With services such as Google's App, IBM's Symphony Suite, Sun's Open Office, and others software applications and hardware platforms are available for free. The competitive difference between two organizations is not what assets (capital, resources, technology, etc..) they have but rather how they utilize these assets. In other words their capabilities and in particular their soft capabilities.

Soft capabilities is becoming increasing important. As discussed in a past blog entry soft skills of individuals are things like a person's interpersonal skills and emotional intelligence. The question on the table is what defines an organization's soft assets? We can state that soft assets of your organization include its agility, culture, values, alignment to its mission, sustainability. The reason they are soft is because we usually can not measure them easily. This might change in the future. Today we can measure an organization's performance through monitoring its financial reports and deriving some measures that reflect its level of success in managing its capital and financial resources. However this performance measure is very narrow-sighted, it only addresses one stakeholder of the business, the investor, and does not include all aspects of a business' mission, or maybe none of it at all.

Take for example a company whose mission statement is "preserving and improving human life". To effectively measure the delivery of its mission, measuring return on investment and debt / equity ratios will not provide a true picture. Rather measurements of soft aspects of the business are needed. Examples would be return on educating customers about diseases, adoption of good practices by patients, healing rates, impact of side-effects on the health of patients, economies and other aspects of human life, and the list goes on. Our lack of solid approaches and well-defined techniques makes measuring these performance indicators difficult, and hence we call them soft.

Businesses need to focus on these soft areas, whether they are soft outcomes of the business, soft assets, or soft capabilities; simply because this is where true value lies. True value of a business is its ability to achieve its mission. I consider any business metric that can not be measured in a standardized approach across business borders to be part of the soft side of the business. For example, a business' performance is a soft attribute, simply because true performance is not simply financial return on investment (which has very standard approaches of calculating and measuring), but could include customer satisfaction, and other metrics that most people today do not have standard way of measuring across autonomous domains. The first step of understanding a business's soft-side is to include it as part of the business architecture.

The concept of soft extends beyond businesses and organizations and is also considered at country level, an example is discussed on the Foreign Policy Blog which is seen to be an emerging component in valuation of nations.

In summary, (1) the soft-side is where value is located, and its is usually hidden simply because we do not attempt to measure it, and those who do attempt to measure do not have sound approaches. (2) anything that a business has difficulty in measuring will be defined as soft.

Wednesday, November 18, 2009

Three Fatal Mistakes Leaders Do

Everyone makes mistakes, including leaders. We are all human and its part of how we are. However some mistakes are more fatal than others. These three killers below can diminish a leader's effectiveness.

1. Lack of Consistency
These leaders are not consistent in their performance. They are not involved on a continuous basis and their work habits are sporadic. They also demand more than they give, and are not easily accessible or available, even though they might be working very hard. Their messages are confusing and do not have a clear vision or strategy. Our Creator tells us in the Quran about these types of people in a couple of places,

وَيْلٌ لِّلْمُطَفِّفِينَ (83:1)
WOE UNTO THOSE who give short measure

الَّذِينَ إِذَا اكْتَالُواْ عَلَى النَّاسِ يَسْتَوْفُونَ83:2)
those who, when they are to receive their due from [other] people, demand that it be given in full

وَإِذَا كَالُوهُمْ أَو وَّزَنُوهُمْ يُخْسِرُونَ(83:3
but when they have to measure or weigh whatever they owe to others, give less than what is due!

"These leaders lack loyalty, vision, commitment and respect to their followers and the cause they are leading"

2. Lack of Action
These leaders love to visualize, strategize and come up with ideas, but they never deliver. They miss deadlines, they don't keep up promises, and might even always critique others without providing a solution or alternative. They set standards of behavior or quality and don't abide or ignore them. These types of leaders are also discussed in the Quran,

يَا أَيُّهَا الَّذِينَ آَمَنُوا لِمَ تَقُولُونَ مَا لَا تَفْعَلُونَ (61:2)
O YOU who have attained to faith! Why do you say one thing and do another?

كَبُرَ مَقْتًا عِندَ اللَّهِ أَن تَقُولُوا مَا لَا تَفْعَلُونَ (61:3
Most loathsome is it in the sight of God that you say what you do not do!

إِنَّ اللَّهَ يُحِبُّ الَّذِينَ يُقَاتِلُونَ فِي سَبِيلِهِ صَفًّا كَأَنَّهُم بُنيَانٌ مَّرْصُوصٌ
Verily, God loves those who fight in His cause in [solid] ranks, as though they were a building firm and compact.

"These leaders are usually not team players, are not serious about other team members' opinions, are not responsible, nor reliable, are perceived as not sincere, and provide limited value"

3. Fail to Develop Others
These leaders do not include coaching or mentoring thoughts into their directives. They do not think of providing opportunities for growth and development of their followers. Their main focus is on self-development. Opportunities for learning, development, responsibility and taking initiative are limited in their organizations. Teams are disengaged and clusters of groups exist. Succession planning is not on the radar screen, and sustainability is weak.

Allah (SWT) shares with us many stories of leaders who developed others such as Al-Khider and Musa (PBUH), Mohammad (PBUH) teaching his companions through the revelation from Allah (SWT) in the numerous statements of قُلْ throughout the Quran, Ibrahim and Ismail (PBUH) and many others.

"Leaders who fail to develop others are perceived to lack confidence, vision, loyalty, trust, courage, motivation, teaching and compassion"
Leaders need to constantly revisit where they stand and if they are approaching any of these three killers.

Wednesday, November 11, 2009

Strategy and its Role in Becoming Capable

Strategy is focused on the matching of an enterprise's opportunities and threats (external factors) to the enterprise's capabilities.

In some cases an organization might not have a capability in place that allows it to benefit from an opportunity. In such cases the capability will need to be realized otherwise the opportunity will be missed. The realization of such absent capability is part of the enterprise strategy, and will require enablers from across the enterprise such as technology, locations, roles, processes, intellectual property and more.

Robert Grant, "Contemporary strategy analysis: concepts, techniques, applications", Blackwell Publishing, 2002.

Harvey Thompson, "The Customer-Centered Enterprise: How IBM and Other World-Class Companies Achieve Extraordinary Results", Mc Graw-Hill, 2000.

Tuesday, November 10, 2009

Getting Capable

Institutions vary widely in their capabilities to achieve their mission. You could find two organizations in the exact same line of business, with very similar strategies and business drivers, yet very different results due to the differences in their capabilities. Lets take an example of two airlines. Both airlines share the same mission, transporting humans across the globe safely and in an enjoyable manner. Airline A always takes off on time, lands on time and does not lose luggage. Airline B always takes off late and loses luggage.

Their business requirement is the same, yet their outcomes are very different, which is due to differences in their capabilities.

A capability is a realized requirement, it could also be said that a capability is a business requirement added to some value acquisition process. The value acquisition process should span the entire enterprise to ensure that is picked from all strengths of the enterprise and also did not bring along any unnecessary baggage.

Wednesday, October 28, 2009

Organizational Capabilities in Less than 100 Words

How quick can your organization respond to its constituents needs. How effective can it adapt to changing dynamics in the environment surrounding it? How efficient can it deliver its mission? The answer to these questions depends on what we call organizational capabilities.

Similar to an individual's ability, organizations have abilities to do certain things, these abilities combined with resources, assets, processes and skills form an organizational capability. A few examples of strategic capabilities are (1) The ability to innovate and be creative, (2) the ability to develop and deploy products in a compressed cycle, and (3) the ability to educate and train young people.

Are your capabilities well defined? Do you know how to improve them, and how to measure where these capabilities are enabling your stakeholders to realize the value proposition you are offering?

Monday, October 26, 2009

Know Thy Business Events

A business event is a valuable building block in an enterprise's business architecture. Business events provide insights to triggers and decision points in the business domain. Business events could be classified into three types: External events such as a customer service request, internal events such as closing a project or an employee time sheet submission, and finally temporal events which occur based on the elapse of a given time-frame such as end of month.

There are many important questions to ask oneself about events when building a business architecture or when defining events. Examples are:

1. How are these events identified?
2. Are they unique?
3. Can they be repeatable?
4. How can we structure events in the context of a business architecture?
5. How can events be modular?
6. What processes are related to events?
7. What business capabilities are impacted by events?
8. What impact does the event have on the business services, operations and other areas?
9. Who reacts (which roles) to an event and in what way?
10. How often does an event occur and what is its significance?

Tuesday, September 08, 2009

Step By Step Business Architecture

Developing a business architecture for an enterprise can be a daunting task. However following a systematic approach makes it a bit easier, or at the very least organized.

1. Develop a description of the existing business architecture if it exists. The description should include as much of the AS-IS architecture as needed for the development of the TO-BE architecture.

2. Identify any reference models, tools, patterns and techniques that should be used to develop the TO-BE architecture based on the context, complexity and scope of your business requirements.

3. Select viewpoints of the business architecture to be utilized to illustrate the architecture, according to the business requirements. Common business architecture view points are operational, systems, technology, governance, financial and functional viewpoints.

4. Develop an architecture model for your TO-BE business requirements. Ensure that you perform each of these,
  • Create the model for the specific view point. For example create the activity model for an operational view point of the business architecture. Common models are activity models, use-case models, class models, node connectivity diagrams and information exchange matrices.
  • Verify that all stakeholder requirements and concerns are included.
  • Ensure you have models for business goals and objectives, business functions, business services, business processes, roles, business data,
  • Ensure your architecture has captured the interlocking of organization and functions, and interlocking of processes and systems.
  • For each business function identify when, where, where, how often and by whom will the function be performed. Identify the inputs to the function and the expected outputs.
  • Identify dependencies and assumptions for each business function.
  • Conduct trade-off analysis if any conflict exist among the different views.
  • Validate and verify the developed model against requirements for completeness and scope
5. Select the business architecture building blocks. Reuse blocks as applicable, and develop new ones to add to the BA library.

6. Hold a formal architectural review of the developed model and building blocks with the stakeholders.

7. Review the non-functional requirements and service level agreements. Common non-functional requirements are scalability, performance, availability, costs, reliability and capacity.

8. Complete the documentation for the business architecture by ensuring that you,

  • Have a completed requiements traceability report.
  • Identified requirements that are driving the architecture.
  • Mapped the architecture to reference architectures and models in the organization.
  • Identified new vs. reused building blocks.
  • Documented rationale for architectural decisions.
  • Completed the business architecture report including the business footprint, detailed description of business functions, and their information needs.
  • Outlined the governance footprint as related to the business needs and scope of the TO-BE
  • Included a table of standards, rules, guidelines, assumptions, dependencies, and measures used.

Business and Enterprise Architectures: Differences and Commonalities

Business architecture is a unifying structure that enables the execution of business strategies through initiatives to achieve business results. The business architecture could also be viewed as the relationships and connectivity among the various value streams and the inputs that feed these value steams, the processing centers that enable the value streams and the value realized.

Business architecture is only one component of enterprise architecture. In an enterprise there are business objectives, technology and infrastructure assets, organizational units, security concerns information handling and processing and various other components, each of which can be defined as a separate architecture and part of a defined framework.

The business architecture encompasses the business flows, activity models, use cases, user models, class models, node connectivity diagrams and business information exchange matrices. Business architectures usually reflect a baseline known as the AS-IS architecture and defines a future aspiration known as the TO-BE architecture.

Enterprise architectures explain all aspects of an enterprise; its data, business processes, infrastructure, technology and business

Wednesday, August 12, 2009

Patterns: What Are They? Part 1

Literally patterns are defined as a combination of qualities, items, objects, behaviors, or other which form a consistent or characteristic arrangement. We observe dozens of daily patterns every day. Examples are teen behavior, the movement of the earth around the sun, the blooming of flowers and hundreds more.

"A combination of qualities, items, objects, behaviors, or other which form a consistent or characteristic arrangement"

Patterns are not new to man-kind, the Creator has informed us about patterns in the Quran and other earlier revelations. Recently system developers started to analyze the concept of patterns, pioneered by Christopher Alexander in his book, " A Timeless Way of Building", he defines a pattern as a three-part rule, expressing a relation between a certain context, a problem and a solution.

Patterns are a first step in understanding root causes of the problem within a specific context. It also allows the development of architectural and solution building blocks.

"In systems realization, patterns express a relationship between a problem and its solution within a given context"
For a software designer some pattern examples are: Message Translators, Process Managers, and Proxies to mention a few. A process manager pattern for example will comprise of a sensor to detect an incoming message which initializes the process manager. The process manager in turn executes a set of rules stored in the process manager memory implementing the processing rules, and detects the subsequent steps through a status feedback detector/analyzer.

Considering a different domain, take the example of a group that does youth trips, examples of patterns could be: Headcount Process, Critical Supplies, Meal Managers, Activity Itinerary Manager and many more. An Activity Itinerary Manager pattern will comprise of an input process to capture developmental and coaching themes/needs of the youth trip, a search process to match the theme to a group of activities that meet the objectives of the theme from a repository of activities, the selected lists of activities could then pass by the activity processor which breaks down the activity into steps, each assigned to resources, a lead, a cost structure, risk factor and plan of action. Feedback from the actual deployed activity is then finally fed back into the activity manager for updates to the activity definitions and other relevant areas, within quality expectations.

_____________To Read More _______________

(1) Hohpe and Woolfe, "Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions", Addison Wesley signature Series, 2004.

(2) Haskins and Raveh, "Introduction to Patterns Through Writing Systems Engineering Patterns", 16th Annual International Symposium, 2006.

(3) Gross and Yu, "From Non-Functional Requirements to Design Through Patterns".

Tuesday, August 04, 2009

The Spark ...

Teamwork is touted as the driver behind progress. This is not necessarily true. There is no doubt that teamwork is a fact of life. As humans we have to interact with one another to satisfy our human needs and desires such as socializing, belonging to a group identity, sustaining needs of life among many others.

Effective teams need leaders to align them and give them direction and motivation. The spark that makes groups and societies move is the outcome of individuals. These sparks ignite the team and thrust its members forward, but the team members do not necessarily produce any starting sparks. As Igor Sikorsky once said,

"The work of the individual still remains the spark that moves mankind ahead, even more than teamwork"

If you find yourself on a team, organization or society, with higher levels of motivation, vision and commitment than others, don't despair, that means you are a leader. As a leader you can not work alone, sparks don't develop into fire without a catalyst, and your team is your catalyst. Nurture, coach, and develop the team, and it will be a strong catalyst.

It was once said that a small group are the ones carrying the ambitions of the nation, and a group of those are the ones who sacrifice their time and wealth to accomplish these ambitions, and a group of that smaller group are the ones who sacrifice their lives for the sake of succeeding in the accomplishment of these ambitions. A small group, from a small group, from a small group.

"A small group, from a small group, from a small group"


Picture: Courtesy of NASA: The formation of a star, A molecular cloud is a region containing cool interstellar gas and dust left over from the formation of the galaxy and mostly contains molecular hydrogen. The Spitzer data, in red, green and blue shows the molecular cloud (in the bottom part of the image) plus young stars in and around Cepheus B, and the Chandra data in violet shows the young stars in the field.

Thursday, July 16, 2009

10 Attributes of a Learning Oganization

Communications is a key component of effective leadership. Leaders don't sit in their offices behind their desk, they are out in the field dealing with customers, suppliers, employees and other constituencies of their organization. This interaction between the leader and these other groups and individuals yields tremendous amounts of experience and knowledge. An organization which shares knowledge and learns from its members is a learning organization.

Learning organizations are characterized by the following:

1. Possess solid systems for communications among its members.
2. Knowledge and intellect is respected and appreciated.
3. Team work and collaboration is the norm.
4. Members consult one another on a continuous basis.
5. Members update others on a continuous basis.
6. Teams learn from past experiences, and mistakes are rarely repeated.
7. Information, knowledge storage and retrieval is efficient and effective.
8. Team members are accessible and known for their expertise, contributing to centers of competence.
9. Realizes continuous growth and innovation.
10. Encourages diversity and systems-based thinking.

Is your organization a learning one? How can you assess its learning capabilities?

Tuesday, July 14, 2009

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

Monday, June 22, 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.

Wednesday, June 03, 2009

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.

Monday, June 01, 2009

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.

Sunday, May 31, 2009

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.

Wednesday, May 20, 2009

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.

Monday, May 18, 2009

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

Wednesday, April 29, 2009

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

Monday, April 27, 2009

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.

Saturday, April 18, 2009

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)

Friday, April 17, 2009

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 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.

Thursday, April 16, 2009

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 or from

Wednesday, April 15, 2009

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?

Friday, April 03, 2009

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.

Thursday, April 02, 2009

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.

Tuesday, March 31, 2009

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.

Monday, March 30, 2009

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

Thursday, March 26, 2009

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.

Wednesday, March 25, 2009

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 !!

Wednesday, March 18, 2009

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..)

Thursday, March 05, 2009

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.

Thursday, January 29, 2009

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)

Wednesday, January 21, 2009

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?

Monday, January 19, 2009

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.