Data migration Strategy (Contd.)

Continuing from the earlier post on Data Migration, here is the concluding piece on various Data Migration Strategies (by Soumendra Mohanty inDM Review Special Report, May 2004):

In Part 1, we discussed what could be the phases in a typical data migration project. The same questions will keep on coming back to the project managers again and again-

1. How am I going to determine the performance criteria?
2. What are the risks and how am I going to manage those?
3. Do I have a failure mode effect analysis document which captures the failure modes and does a cause and effect analysis?

There are many other questions that arise. Let us look at the different strategies and checkpoints which are an integral part of a data migration project.

While implementing data migration architecture, the data migration team has to take a number of considerations. Following are a few of such considerations:

• Data volume analysis
• Source system and target system processing power
• Complexity of data mapping rules and business rules

Point-to-Point Data Migration Architecture

If during transformation, several records are normalized into separate database records that will result in a significant increase in the overall data volume, extract data from the source system(s) as is and move it to a staging area in the target system, then apply cleansing and transformations locally.

Highlights:

• Reduced network round trip
• Local transformations means the actual data migration process is over, data has actually reached the targeted server.
• Leverage processing power of target server

Hub-Spoke Data Migration Architecture

Figure 2 shows partitioning source data and preconverting the historic data in the source environment and supports any number of source and target systems (spokes) while managing the overall ETL processes through a hub.

Highlights:

• Can accommodate any number of sources and/or targets
• Data rules are kept at a separate layer
• Load balanced on target server

1. Making Sense of Data Migration

The biggest challenge with a data migration project is: Making the target system understand what the source system is telling it.

Here are a few key practices and issues with data migration projects.

Comprehensive Mapping. Every data field that is going to be migrated from the source system to the target system must be defined and examined to ensure compliance with field lengths, data types, domain values permitted, system rules, integrity checks and any other possible issues.

A detailed data map is critical to understanding where information is going as well as whether there are any known or avoidable obstacles in the way of successfully arriving there.

A good data map will detail an in-depth cross-referencing of all mutual fields across the source system and the target system. Ideally it should include:

• Names of applicable to and from fields
• Lengths and data types of these fields
• Any logic involved in mapping such as string truncations or validations against any business rules

Extract Validation. Data in source system is known to contain problems or can be unknowingly incorrect due to many possible factors including human keying-in errors and/or a lack of checks and accountability particularly in less sophisticated systems. Any validation rules that can be utilized to locate and fix these problems should be performed on the first-pass data extract extending the process to multiple iterations if required.

It is common that some errors will not surface until others have been identified and fixed. Whereas the source system may ignore the discrepancies with, for example, items like same persons billing address recorded different in different files or database tables, the target system, potentially having better business rules, may opt for a Type I or Type II slowly changing dimension implementation for the same address change. Data validation and clean up is an essential and key component of a good migration plan.

Quality Transformation. Data extracted from the source system needs to be transformed or translated into a format that the target system can import and understand. This transformation will not only the defined data mappings, but will also execute any underlying business logic functions that may be essential to populating more complex data structures.

Fortunately, these stages can be efficiently performed by technically advanced ETL tools such as Informatica, Ab Initio, DataStage, etc.

So far we have discussed the technical aspect of data migration. However, as with many IT projects, the what, where and when is just as important as the how. When dealing with the management aspect of a data migration project, following issues should be considered.

2. Phased or Big Bang Approach?

When choosing to migrate data from one system to another, does it make sense to try to accomplish this all at once or move data over through a controlled phase of multiple releases?

Naturally there will be pros and cons to both options, considering which approach will best fit your organization needs to be evaluated on a variety of factors.

Some examples of these factors can be as straightforward as how much data there is to migrate or as seemingly abstract as the amount of training effort it will take to make a "big bang" worthwhile to your organization in terms of the ROI.

3. Stakeholder Expectation

How long will the migration take place? How many internal resources must the client IS team commit to the migration and for what period of time? What is the impact on the other business-critical processes? What is the cost?

The answers to these questions should all be addressed before a single object is extracted or a single transformation is designed. A data migration project cannot succeed if it is poorly scoped therefore project schedules, estimated level of effort, costs and resource requirements should be all provided and adhered to.

4. Rollback

When importing data into a target system, what happens if the data migration fails? Are we prepared to either utilize existing transaction rollback functionality or do we have capacity to design and build our own if none exists? How do we manage the client expectation in such cases? Do we have a mitigation plan in place? Have we discussed these with the client IS team and business users?

Answers to these questions gives us an additional layer of security and contributes a lot in terms of executing the project in time, within the budget as well as managing customer expectation all along.

5. Scalability

Naturally, when one starts to talk about data migrations with information owing back and forth, and how this will improve business, the issue of scalability is bound to surface.

As a manager, just as you should ensure that you have the infrastructure in place to support foreseeable growth, you should also ensure that your data migration can be leveraged for this growth as well.

6. Replication

The issue being: what happens in case of disaster or irrecoverable system failure? Commonly this issue will rear its head during a data migration project - typically born from the pressure placed on the manager to get a migration right so that 100 percent production is never at a stake.

Migrating data to a backup system at the same time as a new target system should be seriously considered to add one more layer of security and ensure that the disaster recovery plan is in place.

Data migration is an important aspect of most software development efforts yet that importance is often overlooked or inadvisably minimized. It is the rare software development effort indeed where the eventual measure of success is not in some way dependent upon the accurate migration of data. The reason for this is quite simple - opting for a new system is a business decision having its own priority. However, migrating historical data to make the new system work may not be a top priority factor, rather making the new system work and sustain the business critical processes are the top most factors.

The success of the data migration project lies in a seamless data movement and always remains on the shadow of implementing the new system.

Following are few common risks that will summarize the data migration project discussion we had so far.

Failure to treat data migration as a project unto itself. Data migration is complex undertaking that should not be regarded as merely a peripheral effort to the main development project. The data migration effort should be treated as a complete sub-project with a defined process, a thoughtfully derived time and cost estimate, and a series of phases that can be tracked or managed.

Underestimating the time and cost of data migration. It is important to perform a reasonably diligent survey of source systems in order to determine the quality of those source system's documentation and source data. If the source system does not have up-to-date data documentation in the form of data model and data dictionary, the task of determining the structure and data types of the desired source data and it's mapping to the target data will be increased in time and cost. If the source system has less stringent data quality requirements than the target system or if the data quality of the source system has been allowed to lapse over time, the actual act of performing the migration will take longer time due to the need to perform post-migration data clean up.

Lack of end-state data quality. If the migration effort does not formally specify the level of end-state data quality and the set of quality control tests that will be used to verify that data quality, the target domain may wind up with poor data quality. This will negatively impact the perceived outcome of the development effort.

Failure to support the organizational support. When the complexity and importance of data migration is not adequately appreciated it may be difficult to gain organizational support for that data migration, especially in terms of funding and resources. It may be even more difficult to garner a positive level support in separate organizations that have primary responsibility for the source data. This can happen when the organization supporting the source data feels threatened by the new system or it can happen simply because the migration effort is not a top priority for that organization.

Lack of appreciation for the complexities of data mapping. The central effort of data migration is understanding the source data and developing the mapping that allows the data in the source domain to be accurately transformed and moved to the target domain. There are many factors affecting mapping that can be ignored:

• Ensuring that the semantics sense of a given attribute is correctly mapped: the same datum may carry a different name in the source domain than in the target domain; the source domain and the target domain may carry the same name for what is conceptually a different datum.
• Understanding that the number of entities and their respective relationships may be vastly different between the source domain and the target domain.
• Strategies and extensions may have to be developed to handle certain intractable mappings if they are discovered. An attribute may exit in the source domain that does not exist in the target domain and vice versa.

These issues and subsequent impacts may manifest themselves in both quantitative and qualitative ways:

In quantitative sense this can result in:

• Costs associated with error detection
• Costs associated with error rework
• Costs associated with error prevention
• Time delays in operations
• Costs associated with delays in processing

In a qualitative sense this can result in:

• Difficult and/or erroneous decisions
• Organization wide data inconsistency
• Low acceptance level by users of the new system

The most important factors in mitigating the risks of data migration are to treat the data migration as a project and to use a sound methodical process having the following KPIs:

Data Profiling - Gain a complete understanding of the content, structure, quality, and integrity of the data of the source system.

Data Mapping - Develop an accurate set of data mapping specifications from the source system to the target system.

Migration Approach and Architectural Considerations - Whether point-to-point migration or hub-and-spoke migration, this needs to be evaluated and carefully articulated.

Development - Selecting an ETL tool to automate the migration process and make it more scalable should be a high-priority item.

Quality Assurance - Conduct mock migrations, pilot migrations before the final migration run; this will ensure that the migration process is robust and trusted.

Data Migration Strategy

Here is a good reference on understanding Data Migration Issues, Approach and Strategy by Soumendra Mohanty, published by DM Review Special Report:

PART 1

Business focus and strategies driving business change over a span of time. Inevitably the core business processes captured in numerous information systems applications get retired and replaced with newer, more functional systems.

Since such driving forces are inevitable, what does the business do with the existing data? Existing data should not be scrapped or forgotten, because this data was used for several years to define the very existence of the same business. Instead the information must be massaged and tailored for the new system, thereby safeguarding the history and linking with the new or enhanced system.

However, the massaging and tailoring of this massive amount of data and propagating it to the new system is not so straightforward. Rather, it leads to the whole new world of data migration.

Let us look at a few real-life scenarios to understand the complexity and enormity of challenges in data migration:

• Database schemas are going to be different, business entities change to portray different functional meaning, and format and usage of data captured in a new system can be totally different.
• Data field lengths might change and pose severe data integrity issues.
• Other trouble points:
  What is the size of the historical data?
  How many source systems are involved?
  How much processing power is available in the existing system?
  Is any of the system's CPU and memory expandable?
  Are there any production applications that may conflict with the migration?
  What is the available network throughput?
  What is the network bandwidth utilization? - Peak hours/off-peak hours

Fortunately enough, through the use of best practices, technology-driven focus and domain experience, the task of data migration does not have to be such a challenging issue. The process of migrating data can be broken down into a series of well-defined atomic level tasks, control metrics and procedures that reduce both cost and time to completion.

1. Data Migration Approach

There are a number of considerations and well-defined phases to execute a data migration project.

Phase 1 - Data Migration Planning. Develop migration strategy and approach, define scope, schedule, resource plan, technical requirements and detailed execution plan.

Phase 2 - Analysis and Design. Develop migration routines, validate business requirements for historical data, data analysis (profiler), mappings, referential integrity and certification scripts.

Phase 3 - Mock Migration. Conduct dress rehearsals for each planned release. Mock migrations may be partial or complete end-to-end cycles to verify migration procedures and benchmark the cycle times for each migration task.

Phase 4 - Pilot Migration. Complete end-to-end migration in the pilot environment. Coordinate with business users in doing data validation, verify and evaluate the control mechanism and metrics.

Phase 5 - Live Migration. Execute full-scale migration into production environment.

Phase 6 - Post-Migration Activities

Typical deliverables for the defined phases include:

• Data Migration Approach and Road Map
• Data Source Documents
• Infrastructure Planning and Metrics
• Technical Design Documents
• Failure Routines
• FMEA Document - Failure Mode Execution and Analysis
• Migration Status - Dashboards
• Data Migration Metrics and Control Charts

Diagnostics on the current environment on the following parameters also should be gathered:

• How much data will be moving from point to point (server to server)?
• How much processing power is available at each point covering both peak and off-peak hours?
• What is the estimation of the amount of transformation and cleansing needed?
• What are the data profiling and data validation rules/phases applicable to the data?

2. Data Migration Phases

A data migration project also has defined phases.

Figure 1 depicts the six phases of a data migration project. The phases may happen concurrently or in an iterative fashion. Entry and exit criteria should be defined for each phase and milestones should be set to trigger auditing, reviews as well as stakeholder expectation and communication processes.

3. Phase 1 - Data Assessment

Key Activities

• Identify data sources
• Run system extracts and queries
• Conduct user interviews and awareness programs on data migration process
• Review migration scope and validation strategy
• Create work plan and milestone dates

Key Participating Groups

• Data migration leads
• Business users
• Program sponsors

Deliverables/Outputs

• Migration scope document
• Migration validation strategy document
• Work plan with milestone dates

4. Phase 2 - Data Cleansing

Key Activities

• Identify data cleansing needs and expectations
• Create data prep worksheets
• Clean up source data in current system
• Format unstructured data in other systems
• Run extracts and queries to determine data quality
• Create metrics to capture data volume, peak hours and off-peak hours

Key Participating Groups

• Data migration team
• Client IS team

Deliverables/Outputs

• Modified source data that increases the success of automated data conversion
• Control metrics and dashboards

5. Phase 3 - Test Extract and Load

Key Activities

• Create/verify data element mappings
• Run data extracts from current system(s)
• Create tables, scripts, jobs to automate the extraction
• Address additional data clean-up issues
• Execute application specific customizations
• Run mock migrations
• Load extracts into the new system using ETL tools or SQL loader with bulk loading functions
• Conduct internal data validation checks including business rules and referential integrity checks
• Report exceptions to client team
• Perform data validation

Key Participating Groups

• Data migration team
• Client IS team
• DBA team

Deliverables/Outputs

• Extracts from source system
• Data migration modules, jobs, scripts
• Application loaded with converted data
• Exceptions, alerts and error handling control points

6. Phase 4 - Final Extract and Load

Key Activities

• Run final extracts from the current system(s)
• Execute specific customizations on target database
• Execute application specific customizations
• Run pilot migrations
• Load extracts into the new system using ETL tools or SQL loader with bulk loading functions
• Conduct internal data validation checks including business rules and referential integrity checks
• Report exceptions to client team
• Perform data validation

Key Participating Groups

• Data migration team
• Client IS team
• DBA team

Deliverables/Outputs

• Extracts from source system
• Data migration modules, jobs, scripts
• Application loaded with converted data
• Exceptions, alerts and error handling control points

7. Phase 5 - Migration Validation

Key Activities

• Prepare migration validation reports and data movement metrics
• Review migration validation reports and metrics
• Record count verifications on the new system
• Reconcile or resolve any exceptions or unexpected variations
• Sign off on migration validation

Key Participating Groups

• Data migration team
• Client IS team
• Business users

Deliverables/Outputs

• Signed-off migration validation document

8. Phase 6 - Post Migration Activities

Key Activities

• Complete data migration reports and cross-reference files/manuals
• Data sanity reports
• Target system usage reports
• Infrastructure capacity report and dashboards
• Sign off on data migration project

Key Participating Groups

• Data migration team
• Client IS team
• Business users
• Business sponsor

Deliverables/Outputs

• Exception reports, cross-reference files/manuals
• Infrastructure dashboards
• Signed-off data migration project closure document

Part 2 will focus on data migration strategies (and is being published as a separate entry).

Defragging the Team - A good Analogy!

[Source: Article in Gantthead by Ian Whittingham, PMP ]

If nothing else, it makes me feel vaguely virtuous, in the way that having my blood pressure taken or cholesterol checked does. No matter, I always have to click around the Programs menu to find it, hidden away in the Accessories folder under System Tools, sandwiched between Disk Cleanup and Files and Settings Transfer Wizard. But when I click Analyze, I realize I have not been as diligently attentive to the needs of my laptop as I should have been.

A braided ribbon diagnostic displays the state of my C drive: wide expanses of white space delimited by irregularly spaced red threads, interspersed with blue lines of varying thickness. Just as in nature, file management appears to abhor a vacuum. A pop-up window chides me: “You should defragment this volume.”

What the diagnostic graphically depicts is the extent to which the files on my PC have become fragmented across my C drive. But if I switch to the peripheral memory store that occupies my E drive, the analysis is much more reassuring: large blocks of blue predominate the ribbon display. This depicts the ideal state of contiguity in which all files should reside. The bluer, the better.

The variations in these color-banded patterns--red for fragmented files, blue for contiguous files, green for unmovable files and white for free space--are generated by algorithmic behavior designed to overcome the limitations imposed on the storage of information by both the physical properties of my laptop’s storage media and the algorithms that write files to the drive. Ideally, to optimize read/writes and utilize efficiently the media’s storage capacity, files must be moved around with the aim of allocating them contiguously in the memory store, so that any available free space is maximized.

However, the continuous process of adding new, amending existing and deleting unwanted files creates churn within the memory store. As churn impedes contiguous file allocation, file extents are created to workaround the distribution of the free space available. But as more files are added, amended or deleted, more extents are created, causing more fragmentation across the volume and a consequent degradation in performance. All of this occurs in the background, unnoticed by me; which makes defragging my disk drive a necessary and periodic chore.

And so I click Defragment and wait for the ribbon display to imperceptibly re-arrange itself, bit by bit, as files are compacted and relocated. But as the diagnostic ticks closer to 100 percent complete, watching the restoration of my disk drive’s integrity I am suddenly struck by the recognition of a best practice that might equally apply to a project team as to my PC: the periodic defragging of the project team.

Project teams are just as susceptible to performance degradation, caused by churn, as the storage media on my laptop is. But what are the symptoms of churn in a project team? And how might they be remediated so that team performance is restored?

A defining characteristic of highly performant project teams is integrity. In project teams, integrity is most commonly manifest in how the team accomplishes its work. Integrity derives from the ability of each team member to operate in a coordinated and proactive manner such that the effectiveness of individual actions is reciprocated and compounded by those of other team members. Thus, the project tasks that each member performs are integral to the overall performance of the team.

There are many ways to achieve team integrity, but the most obvious root to this is through effective role definition. Each team member must have a clearly defined and acknowledged role within the team, with minimum overlap with other team roles (except where required in the case of back-up, or to maximize resource allocation to a critical path activity or function). However, this involves much more than just compiling a RACI (Responsible, Accountable, Consultative, and Informational) matrix of team member roles, and then posting it to the project website. The key here is acknowledged role.

Unless the responsibilities and accountabilities of an individual team member are explicitly acknowledged by the other team members, boundaries and ownership can rapidly become blurred or porous. If project tasks are being left unresolved and unclaimed, or if multiple team members are working on the same task in apparently disjointed or uncoordinated ways, these may be incipient symptoms of churn.

In highly matrixed organizations, contention for team resources by competing projects may also be contributory to churn. If team members are dividing their time (and attention) among multiple project threads, there can be loss of focus on meeting project objectives. As pressure increases to meet deadlines and work packages or tasks are completed in isolation without regard to integration with other project tasks, further dislocation can occur. This coping behavior is similar to the file extent workaround: tasks are allocated to the time available without regard to quality or scope of work. Thus, tasks become fragmented from their objectives. On software development projects, for example, code builds created in such environments often exhibit a higher rate of bug fixes and post-release patches.

By their intrinsic nature, distributed teams are more susceptible to fragmentation than co-located teams. While large scale meetings might appear to be an effective forum for project leaders to set direction and communicate status, it may not be true for each project team member. For example, conducting a project meeting via telecom with 20 participants across four times zones for 75 minutes each week does not necessarily create a strong sense of team cohesion, nor is it an effective use of each participant’s time. Consider that such a meeting will consume 25 man hours per week of time (almost two man months per year) and will tie up 190 point-to-point communication channels among the participants.

Just as partitioning the volume on a disk drive can reduce the number of read/writes and reduce churn, you can apply a similar principle to team member interactions such that only the specific needs of the project that are relevant to a team member’s domain expertise or functional role are engaged. But to achieve this, a trade-off has to be made in the amount of facilitation effort required of the project manager. The communication needs of each team member--as it affects the performance of their project contribution--must be well understood and acted upon by the project manager to be effective.

As in the process of disk defragmentation, the project manager also needs to create contiguity within the project team. Viewed simplistically, contiguity can be taken to mean nothing more than project team member co-location. And certainly agile project teams fit this analogy very well, especially in the results they achieve. However, contiguity can also mean much more than just physical continuity and interaction. Contiguity should be a source of team cohesion and integrity.

One way in which it can be achieved in distributed and virtual teams is by continually relating the functional responsibilities and tasks of team members to the achievement of business objectives. When teams lose sight of the objectives they also lose the point of the tasks they are executing. And although this may not always ameliorate the effects of churn, it is one way in which project managers can help their teams to defrag themselves and restore team performance.

Building Trust and Agile Practices

[Source: InfoQ]

During Agile 2008, Dr. Linda Rising held a presentation centered on experiments conducted many years ago, presenting how deep, powerfully affecting, and difficult to avoid are human “prejudices” and “stereotypes” as seen from the perspective of psychology and cognitive science. In the second half of the session, she explained how it is possible to minimize and overcome the impact of prejudice. This article is a summary of that presentation.

The following experiment was mentioned throughout the session, an experiment conducted in 1954 and known as the Robbers Cave Experiment:

Two groups of 12-year-old boys were taken to a Boy Scouts camp, but neither group knew of the other’s existence and believed that their group was the only group in the camp. (Of course, they traveled to the camp by different buses.) During the first week, the two groups carried out their activities separately. They swam in the lake, built hide-outs, and pitched tents. The accompanying adults (who were actually the researchers conducting the experiment) ensured that there was no contact between the two groups. The members of each group bonded as a team.

After one week, the two groups became aware of each other’s presence (as contrived by the adults). At this point, despite their not actually seeing each other, the two groups began distinguishing between “us” and “them” and saying “they (the other group) intruded on our territory”. The researchers were surprised by the extremes in boys’ reactions: how quickly the members of each group had bonded initially with each other and how quickly both groups had seen the other as “the enemy.”

The two groups were then brought together. In a plan set-up by the “adults”, the two groups participated in competitive games such as baseball and tug-of-war, and the total scores for various games were recorded for each group, with the adults acting as judges. The group that won with the highest total score for the day was awarded prizes. When that happened, the losing group burned the flag of the winning group and raided their camp; the two groups were on the verge of declaring all-out war on each other.

Dr. Rising broke off her story about the experiment here and turned to the topic of people’s prejudices. Humans are born with an instinctive ability to instantly determine whether what is in front of them is safe or dangerous, edible or inedible, enemy or friend. Since this ability is instinctive, it is an ability that humans acquired through competition for survival and the process of evolution. For humans in primitive times, slowness in distinguishing whether the person in front of them is a member of their own tribe or a member of an enemy tribe was a life-or-death issue. However, because of this instinctive ability, humans also came to categorize other humans — in other words, stereotyping them — the moment they laid eyes on them.

People categorize other people: enemy or friend; family or stranger; insider or outsider. This decision is made in an extremely short period of time, and categorizing then leads to stereotyping and simplification, with people making presumptions about others based on first appearances. Prejudice has two characteristics:
• Everyone has prejudices
• Nobody realizes that they are prejudiced

In other words, everybody mistakenly believes that they are not prejudiced. Consequently, while people believe themselves to be making rational decisions, they in fact constantly justify their behavior and that of their friends, family, and colleagues, and constantly presume the actions of strangers and outsiders to be “bad.”

Stereotypes simplify the way people view others. Despite the rich and complex individuality inherent in each person, people label others focusing on general outward appearance and ignoring details and difficult-to-observe features. Dr. Rising gave this example during her explanation:

“People who are married tend to use presumptive expressions when talking about their spouses, don’t they? They ‘never’ tidy up the kitchen, or they’re ‘always’ complaining. This is another kind of labeling due to prejudices.”

Moreover, when supervisors and managers evaluate the abilities of the staff working under them, the same prejudices and stereotyping occurs. In many cases, a supervisor “determines” the ability of a worker in about three weeks, labeling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice.

Not only this, prejudices can also cause people to lose the capacity to demonstrate their own abilities. Here Dr. Rising introduced another experiment. In general, females are believed to be less proficient in mathematics than males (in the case of the United States). In this experiment, the subjects were given a mathematics test. If no mention of gender was made before the test was administered, there was no difference in the results between males and females. However, if comments were made about the relationship between mathematical ability and gender before the test was administered, the females scored lower than the males. Furthermore, the same results were obtained by simply having a column on the test paper for subjects to fill in their gender, without any comments about gender being made. This is an example of consciousness of their own gender activating prejudices and inhibiting a person’s natural abilities.

Prejudices and stereotyping are rooted in human instincts, and so influence everyone. However, these can also be obstacles when many people are attempting to work together to complete a complex job or reach a common objective, missing chances for people to display their individual abilities, inviting mistakes, and in some cases even lowering the capabilities of the people who have prejudices. How is it possible to escape from these prejudices and/or lessen their impact?

Continuing the story of the first experiment, Dr. Rising said:
The researchers tried to stop the conflict between the two groups, but simply making the two groups carry out activities together produced no noticeable results. The researchers then staged an “incident” in which the camp’s water supply was cut off and all the boys had to check the water pipe (more than 1 km long) to see where it was blocked. When the blockage was found and removed, the members of both groups joined together in celebrating. By involving all the boys in the resolution of an “incident” that affected the entire camp, the conflict between the two groups evaporated.

Humans can cooperate. Given a common objective, they can work together to tackle the task at hand. In a study using monkeys, the experiment was set up so that two monkeys obtained food by cooperating with each other. Initially both of the monkeys obtained food, but the experiment was changed so that only one monkey obtained food even when the two monkeys cooperated. However, even when one of them realized that it would not receive any food, it cooperated with the other, and the monkey who received the food shared it with the other monkey.

Humans can cooperate. Dr. Rising says that this human ability is also instinctive. In order to cooperate, there is no need for the two parties to like each other. All that is necessary is that one party acknowledges the efforts of the other, and the other party recognizes the efforts of the first. A relationship of mutual respect for the ability and contribution of the other party is born from that. People feel happy to be respected and trusted; such instincts are inherent to human nature.

Taking advantage of these natural human instincts, Dr. Rising points out that Agile practices are outstanding from the standpoint of enabling people to display their abilities, especially the fact that face-to-face communication promotes cooperation…

Dr. Rising’s presentation at Agile 2008 discussed how tied up in prejudices humans are, how the capacity of teams is diminished by stereotyping, and how Agile teams overcome these negative impacts. In the opinion of the author, such knowledge cuts through the workings of the human spirit and brain and seems somehow excitingly close to the human limit.

Why Companies seek new ERP Software?

SYSPRO, has announced the results of a survey covering the enterprise applications investment strategies and

adoption trends of 250 mid-market manufacturing and distribution companies.

IDC, a leading provider of global IT research and advice, conducted the survey during the first quarter of 2008. 

The survey found firm evidence of growing dissatisfaction with currently installed enterprise resource planning (ERP)

solutions, which respondents say are lacking the business process  requirements and cost controls needed in today's

economic environment. Nearly a quarter of those surveyed said their dissatisfaction with their current solution capabilities

had moved from 17% dissatisfied to 25% dissatisfied, between the fourth quarter of 2007 and the first quarter of 2008.

When asked to describe their current business culture as it applies to technology buying behavior, most (38%) of these

mid-market respondents described their culture as "pragmatic, yet visionary." This was in contrast to cultures

that were more aggressive or more conservative in their buying behavior.

The following reasons companies gave for seeking new ERP software are ranked according to the percentage of companies citing them:

Ø       Process improvement (26%)

Ø       Cost reduction (17%)

Ø       Lean manufacturing functionality (12%)

Ø       Better inventory control (10%)

Ø       Enhanced distribution functionality (9%)

Ø       Additional financial functionality (7%)

Ø       System scalability (6%)

Ø       Compliance/regulatory requirements (6%)

Ø       Interoperability with disparate systems (3%)

Ø       Additional analytics/reporting functionality (3%)

Survey results also indicate that 70% of the respondents are demanding

configurations that meet their industry specific requirements.

Research findings on Reasons for Success in Project Execution...