I would recommend that all technologists should work in small operations for initial period of their career. The kind of exposure one gets by working in smaller operations has no comparison. I have interacted with developers and systems engineers from very large organizations and with those working for smaller setups and one can easily see the difference. Developers and systems engineers working with smaller organizations have a much broader understanding of their work including the work that goes around them. For example: developers will know how web servers work, how deployments can be done cleanly without any site downtime, how application server clusters work, how to debug and narrow problems to networking issues, how do application frameworks like sturts work internally etc. Similarly systems engineers in smaller setups have a lot of high level understanding of developer frameworks etc.

Engineers working in larger setups sometimes execute in a lot of restrictions. A very process oriented operation with well defined roles for developers, deployers, maintenance teams and IT restricts each of these roles in a tunnel without exposure to complete SDLC. Smaller operations are therefore better for engineers to get a better understanding and broader perspective of the complete software development cycle.

Absolutely. The biggest mistake companies make when offshoring projects is total dependence on the offshore vendor. Trust me I have been that vendor in the past. There are extremely efficient, reliable and skilled vendors out there but managing projects through to success is as much client's responsibility as it is of the vendor. Some of the things we must keep in mind are:

• Never give the project on a turnkey basis, literally. We cannot expect a big project delivered as one chunk on time, conforming to requirements and implementation standards. We need an iterative approach where deliverables start when project is done 20%.
• Business analyst should have a direct line with technical team lead working offshore. Merely giving requirements to a vendor liason is not enough. They tend to get distorted.
• User acceptance testing window should not be built just at the very end of project. Business analysts and perhaps a QA person should evaluate progress with every iteration.
• Must have a small onsite technical implementation team part of project. Budget for these resources when estimating the cost of project. There should be architectural oversight, code contribution and code reviews done by this team. This is extremely important because in house tecnology folks have to support and maintain what is built offshore.

We must leverage the wonderful minds across the globe to get efficiency and cost savings but we can only achieve our goal if we manage right, avoid the hype and appreciate our own role in the process.

Most of the companies that offshore have a specific reason, it is either financial savings or round the clock support or both. We have in fact increased our potential to work from 9 hour day to 24 hour day by going global. Workforce never sleeps is the mantra and that can be achieved along with cost savings by placing teams in different time zones. The challenge is to make this all work seamless and achieve success.

I have been part of various offshore implementations from being an onsite developer to being a manager. In my viewpoint, the key to a successful implementation is involvement of onsite technical folks in an offshore project. Sounds contradictory? well it is not...let me explain. An offshore model where code implementation and even design is done offshore but a strict control over implementation is maintained at client site works like a charm. What is needed is a small team onsite, depending upon the scale of project, that sets architecture guidelines, performs code reviews and evaluates project in iterations while it is being implemented thousands of miles away.

The above is possible with an iterative approach to implementation. High risk iterations should be handled first and shipped to onsite team even before they are ready to be tested. This enables product manager to verify key metrics and technical team can make sure that implemented technology conforms to standards. It is extremely important that onsite developers and configuration engineers understand the nitty gritty of implementation. This is the key to success especially if an offshore vendor is implementing the project. I will share issues specific with offshore vendors in next post, issues that we have to be very careful about while dealing with them.

Most of us have at some stage in our careers worked with companies that do not sell software products as their core business. In spite of software development being just a support sub-system, these companies have huge IT budgets. Generally two types of projects are developed by their IT departments

• Projects that bring direct revenue to company like an eCommerce website for their products. This includes B2B and B2C projects that integrate with legacy backends.
• Projects that help the company function more efficiently by bringing in indirect revenue or by cutting costs.

Business executives of such companies are not very comfortable with the idea of commercializing IT products being created for in-house use because selling IT is not their core business. It is the job of IT executives to help management see reason and value in selling software to other companies in the industry.

The shape and form of product can vary from a full fledged software product with support to just selling the software code on as is basis or just offering technical consulting. Companies like CNN, Washington Post, Morris Digital Media and Gannett have sold IT products in newspaper domain with considerable success. Some of the key advantages that IT executives can highlight to higher management are:

Let us discuss some channels through which non technology companies can sell their IT products without a creating a full scale sales team:

Every business needs to realize the reality of internet, if you are online you are a dot com. Commercializing IT can give an edge to traditional businesses in competing with modern internet companies of today.

Every software development model has some kind of process defined that pretty much decides if that particular development model can be applied for a given project.

• Waterfall model works with a sequential approach wherein one phase follows the other. Requirements are well documented followed by design, implementation, verification and maintenance. In my experience, it is a good candidate for software upgrade/migration kind of projects. Typical examples will be switching technology of an already implemented project from perl to J2EE or upgrading a SAP version.
• The other category of models is the iterative models wherein a product is delivered in iterations with each iteration being a small portion of the final product. Various models like the Rational Unified Process(RUP), Agile and Cleanroom etc fall in this category and propose a variety of iterative methodologies.

All the above processes and methodologies are well defined and widely talked about in software development forums. What is not discussed is the process of interaction between key IT teams that get together to create a product. That process is called communication.

• Business specialists - Business analysts and product managers that define product specifications.
• Software development - Software design and development experts.
• Quality Assurance - Testers responsible for approving that the software conforms to specifications.
• Technology Operations - Systems engineers, database services and deployment engineers
• Project Management - Project managers who set milestones and assess risks

The success of interactions between the above teams determines the success of a project. This is particularly true when success is measured in terms of quality of final product and speed to market. In my view, the managers of the respective teams determine the protocol that will enable them to work more efficiently and deliver quicker projects. Because there is no set pre-defined model to follow, this process is the most challenging to establish.

IT teams at various companies I have worked and consulted for follow communication protocols that are either extremely formal or extremely informal. The driving factor behind what protocol is followed is the nature of business and the past experience of individuals. IT managers who have worked in more conventional businesses are more likely to be extremely formal in their interactions with other teams while managers that are technologists are likely to be on the other extreme.

I will take up a practical example to demonstrate how the two cultures differ:

Problem - Development is behind schedule and so quality assurance is hard pressed for time and project schedule is at risk.

• IT management in company A - Development manager works with QA manager to find a viable solution to meet timeline. The solution can be assigning some extra resources from development to qa for a brief period or to deliver to qa in self sufficient modules that can be tested while others are being developed. The two managers 'accommodate' each other.
• IT management in company B - A meeting of all team managers is called and project management questions delays, creates a risk and status report and/or decides to delay the project. All managers try to save their backs in the big meeting and finger pointing results. These reports are submitted to higher management and situation gets out of control.

A key difference between two approaches is that in an informal environment two managers can find a solution accommodating each other while in a formal environment the same managers are hesitant to think outside the box and take risks.

Project Management has a critical role in determining the culture of any IT department. If project managers let team managers find solutions on their own and are only concerned with results, the environment automatically becomes accommodating. On the other hand if project managers micro manage the project and position themselves such that they become a means of raising grievances and red flags for other managers, red tape sets in and people become mired in processes and projects suffer. Project management should be a facilitator and project driver and not a department with all concerns and no solutions.

Software development lifecycle should follow a well documented model, be it RUP or Waterfall but people are better off leaving a formalized process out of their communication. If having formal communication was good between peers, there would have been communication processes defined and debated in software development forums just like software methodologies.

Being a technologist managing other technologists, I am a big proponent of the informal interactions between various teams responsible for delivery of projects. The goal is to bring results which can be better accomplished if there is trust amongst IT teams and managers stand up for each other which will only happen when interests of managers are aligned with each other and that with interests of the company. "Over process" is an overkill that can severely affect our ability to deliver. Isn't process all about delivering..??

We all have to and more importantly want to face this question at some point in our career. There are two broad schools of thought that answer this question very differently. One thinks that developers should rise up in the management hierarchy and become managers, directors and so on. The other school of thought is that developers should continue as technologists, something they know best. Ultimately it is for developers to decide after weighing options. Developers are typically very skeptical about moving into management as management is new territory for them and they are not very comfortable leaving their comfort zones of implementing projects and dealing with logic to a somewhat illogical world of dealing with people.

I think the first step is to make sure that you are in a position in your career where you have to make a decision. It is better to get to a point where management values you enough to give you the option of being a manager or stay technologist and then decide which way you want to go. Some of the factors developers need to be aware of in their careers:

Once you have the option of moving into management, you can evaluate what works best for you. It is very likely that you choose not to deal with management challanges and are more comfortable with technology implementation. In such a case make sure you should be able to grow as technologist in the company and have a clear career path.

Choosing the right company is the key. You will never face the challenge of being forced into one career track with a company that values its technical people and is invested heavily in technology.