Wednesday, December 05, 2007
Enterprise Architecture and Outsourcing: Ways to Succeed...
Do projects in your enterprise stumble, crumble while IT executives bumble...
Projects usually fail whenever you are required to organize under pressure. Teams are thrown together and then presented with a project without first establishing team mentality or shared skills, knowledge, or vocabulary. Consequently, everyone learns "on the job" by trial and error, often guided by some resident guru whose biases and narrowness of view may prevent the team from examining a number of options, due both to the uneveness of experience and relative political power.
In the world of outsourcing where an onsite US based team has to interact with folks in distant lands such as India, the problem gets even worse where schedules determine everything and you keep stepping in the IT leadership whenever they tell you a phrase like: It's not a perfect world, so make do with what you've got. Compounding this phenomena is the belief that training is expensive and therefore a luxury while thinking it is sufficient enough for everyone to syntactically know english yet not acknowledge the importance of common vocabularies.
My first suggestion is for folks to acknowledge that common practice may be labelled as a best practice but in reality this common practice is a worst practice. How about removing barriers by training the team (both onsite and offshore) as a unit in relevant technologies. Give everyone the same tools and language.
The individual differences among members diminish as learning is shared, particularly when relevant classes are given to the entire team at the same time. Additionally, team members become more familiar with one another's background, education, experience, and problem-solving approaches, as well as personal styles. The team is not using the project as the primary learning experience.
The fact is that whatever training is required will be exacted, whether at the hidden expense of the project, or at the explicit expense of training costs. There is no escaping training of one sort or the other. In any project, without formal training, members tend to try to self-educate, resulting in a lack of common culture or vocabulary. Additionally, with schedule pressures, internal competition, egotism, and fear, members may degenerate into one-upsmanship, hiding information from team members that makes them look especially good to management. Therefore, to give everyone an equal opportunity as well as iron out some of the initial team issues, sending the entire team through formal training sessions relevant to the project can consolidate expenditures and cut risks.
Please note that training isn't the entire answer as one may also need a trial project. Today, our so-called best practices results in practice makes permanent while we should figure out how to practice to make perfect. In the United States military, you don't just read about Tear Gas, but are required during basic training to walk into a gas chamber and breath it. Nothing is more real than reciting general orders while your buddy pukes his guts out. Too many things in today's IT are left academic in feel and theoretical in practice. Software teams should be no different.
| | View blog reactionsProjects usually fail whenever you are required to organize under pressure. Teams are thrown together and then presented with a project without first establishing team mentality or shared skills, knowledge, or vocabulary. Consequently, everyone learns "on the job" by trial and error, often guided by some resident guru whose biases and narrowness of view may prevent the team from examining a number of options, due both to the uneveness of experience and relative political power.
In the world of outsourcing where an onsite US based team has to interact with folks in distant lands such as India, the problem gets even worse where schedules determine everything and you keep stepping in the IT leadership whenever they tell you a phrase like: It's not a perfect world, so make do with what you've got. Compounding this phenomena is the belief that training is expensive and therefore a luxury while thinking it is sufficient enough for everyone to syntactically know english yet not acknowledge the importance of common vocabularies.
My first suggestion is for folks to acknowledge that common practice may be labelled as a best practice but in reality this common practice is a worst practice. How about removing barriers by training the team (both onsite and offshore) as a unit in relevant technologies. Give everyone the same tools and language.
The individual differences among members diminish as learning is shared, particularly when relevant classes are given to the entire team at the same time. Additionally, team members become more familiar with one another's background, education, experience, and problem-solving approaches, as well as personal styles. The team is not using the project as the primary learning experience.
The fact is that whatever training is required will be exacted, whether at the hidden expense of the project, or at the explicit expense of training costs. There is no escaping training of one sort or the other. In any project, without formal training, members tend to try to self-educate, resulting in a lack of common culture or vocabulary. Additionally, with schedule pressures, internal competition, egotism, and fear, members may degenerate into one-upsmanship, hiding information from team members that makes them look especially good to management. Therefore, to give everyone an equal opportunity as well as iron out some of the initial team issues, sending the entire team through formal training sessions relevant to the project can consolidate expenditures and cut risks.
Please note that training isn't the entire answer as one may also need a trial project. Today, our so-called best practices results in practice makes permanent while we should figure out how to practice to make perfect. In the United States military, you don't just read about Tear Gas, but are required during basic training to walk into a gas chamber and breath it. Nothing is more real than reciting general orders while your buddy pukes his guts out. Too many things in today's IT are left academic in feel and theoretical in practice. Software teams should be no different.
