it is how we do it

it is how we do it

it is how we do it

it is how we do itit is how we do it

it is how we do itit is how we do it

it is how we do itit is how we do it

it is how we do it

it is how we do it

it is how we do itit is how we do it

it is how we do it

Agile methods use iterations, or short, time-boxed development cycles. During an iteration, developers work on the highest priority features. They plan to complete whatever they committed to by the end of the iteration.

Due to the unpredictability of software development, you can be sure that sometimes the team will have too much to do (and less frequently, not enough to do) if they are estimating honestly.

When there is too much to do, the best option is to cut scope, since changing the iteration date undermines the primary advantage of time-boxed iterations – quick technical and business feedback.

There are three ways I know of to cut scope, each of which have different tradeoffs. Here’s a rundown:

Simplify Over-engineered Designs.
On any software project, there are many technical decisions that can complicate the implementation of a feature. Sometimes these are unavoidable, such as the need to preserve legacy behavior, or support multiple variations. More often, though, a team will decide to use an approach that makes good technical sense, but adds on a good deal more complexity.

Make sure that you are doing the simplest thing that meets the requirements for today’s functionality, testability, and ease of maintenance. Planning too far ahead for the future can hamstring a development effort, and force project delays.
For example, many teams get caught up in “architecture”, which often means building complex application frameworks and middleware, some of which may never be used. This is especially dangerous early on in a project, when details are still fuzzy. Over-building of infrastructure is often a sign that the development team doesn’t have enough details about what features to implement, and their priority.

Simplify Features.
Sometimes the communication between business users and developers can be challenging, even with an ideal on-site customer (as proposed by XP). Many times, a specific feature request can be solved by alternative means that still addresses the business problem. This is a great way to reduce scope while still addressing critical business needs.

So if Joe Customer asks for a automatic notification whenever any order is placed in the system, maybe he actually would be fine with a daily or hourly email with an order summary report. The latter might be a matter of minutes to implement with a simple database report, while the former might mean intrusive, risky changes to the order processing logic in the system.
Cut Low Priority Features.
As a last resort, you may need to eliminate the lowest priority features to make a deadline. This is why Agile methods stress that business priorities should be clearly understood before each iteration. If you run out of time working on something technically difficult, but relatively unimportant, it’s hard to explain why the ten simple, higher priority features won’t make the release.
Communicate with your customer about the proposed cuts as soon as possible to allow them to re-negotiate priority if necessary. You build trust and confidence by involving the stakeholders in tough decisions while there’s still time to react.

The top 10 risks of offshore outsourcing are as follows.

1. Cost-Reduction Expectations
The biggest risk with offshore outsourcing has nothing to do with outsourcing – it involves the expectations the internal organization has about how much the savings from offshore will be. Unfortunately, many executives assume that labor arbitrage will yield savings comparable to person-to-person comparison (e.g., a full-time equivalent in India will cost 40% less) without regard for the hidden costs and differences in operating models. In reality, most IT organizations save 15%-25% during the first year; by the third year, cost savings often reach 35%-40% as companies “go up the learning curve” for offshore outsourcing and modify operations to align to an offshore model.

2. Data Security/Protection
IT organizations evaluating any kind of outsourcing question whether vendors have sufficiently robust security practices and if vendors can meet the security requirements they have internally. While most IT organizations find offshore vendor security practices impressive (often exceeding internal practices), the risk of security breaks or intellectual property protection is inherently raised when working in international business. Privacy concerns must be completely addressed. Although these issues rarely pose major impediments to outsourcing, the requirements must be documented and the methods and integration with vendors defined.

3. Process Discipline (CMM)
The Capability Maturity Model (CMM) becomes an important measure of a company’s readiness to adopt an offshore model. Offshore vendors require a standardized and repeatable model, which is why CMM Level 5 is a common characteristic. META Group observes that approximately 70% of IT organizations are at CMM Level 1 – creating a gap that is compensated for by additional vendor resources on-site (see Figure 1). Companies lacking internal process model maturity will undermine potential cost savings.

4. Loss of Business Knowledge
Most IT organizations have business knowledge that resides within the developers of applications. In some cases, this expertise may be a proprietary or competitive advantage. Companies must carefully assess business knowledge and determine if moving it either outside the company or to an offshore location will compromise company practices.

5. Vendor Failure to Deliver
A common oversight for IT organizations is a contingency plan – what happens if the vendor, all best intentions and contracts aside, simply fails to deliver. Although such failures are exceptions, they do occur, even with the superb quality methodologies of offshore vendors. When considering outsourcing, IT organizations should assess the implications of vendor failure (i.e., does failure have significant business performance implications?). High risk or exposure might deter the organization from outsourcing, it might shift the outsourcing strategy (e.g., from a single vendor to multiple vendors), or it might drive the company toward outsourcing (if the vendor has specific skills to reduce risks). The results of risk analysis vary between companies; it is the process of risk analysis that is paramount.

6. Scope Creep
There is no such thing as a fixed-price contract. All outsourcing contracts contain baselines and assumptions. If the actual work varies from estimates, the client will pay the difference. This simple fact has become a major obstacle for IT organizations that are surprised that the price was not “fixed” or that the vendor expects to be paid for incremental scope changes. Most projects change by 10%-15% during the development cycle.

7. Government Oversight/Regulation
Utilities, financial services institutions, and healthcare organizations, among others, face various degrees of government oversight. These IT organizations must ensure that the offshore vendor is sensitive to industry-specific requirements and the vendor’s ability to: 1) comply with government regulations; and 2) provide sufficient “transparency” showing that it does comply and is thus accountable during audits. The issue of transparency is becoming more significant as requirements such as the USA PATRIOT Act and the Sarbanes-Oxley Act place greater burdens of accountability on all American corporations.

8. Culture
A representative example: although English is one official language in India, pronunciation and accents can vary tremendously. Many vendors put call center employees through accent training. In addition, cultural differences include religions, modes of dress, social activities, and even the way a question is answered. Most leading vendors have cultural education programs, but executives should not assume that cultural alignment will be insignificant or trivial.

9. Turnover of Key Personnel
Rapid growth among outsourcing vendors has created a dynamic labor market, especially in Bangalore, India. Key personnel are usually in demand for new, high-profile projects, or even at risk of being recruited by other offshore vendors. While offshore vendors will often quote overall turnover statistics that appear relatively low, the more important statistic to manage is the turnover of key personnel on an account. Common turnover levels are in the 15%-20% range, and creating contractual terms around those levels is a reasonable request. Indeed, META Group has seen recent contracts that place a “liability” on the vendor for any personnel that must be replaced. The impact of high turnover has an indirect cost on the IT organization, which must increase time spend on knowledge transfer and training new individuals.

10. Knowledge Transfer
The time and effort to transfer knowledge to the vendor is a cost rarely accounted for by IT organizations. Indeed, we observe that most IT organizations experience a 20% decline in productivity during the first year of an agreement, largely due to time spent transferring both technical and business knowledge to the vendor. Many offshore vendors are deploying video conferencing (avoiding travel) and classroom settings (creating one-to-many transfer) to improve the efficacy of knowledge transfer. In addition, employee turnover often places a burden on the IT organization to provide additional information for new team members.

Business Impact: Offshore outsourcing can reduce IT expenditures by 15%-25% within the first year. Longer term, process improvements often make great impacts on both cost savings and the quality of IT services delivered.