Archives for 2010

Multicultural Training Can Mean the Difference between Outsourcing Success and Failure

In a May 2004 study entitled “Leading Causes of Outsourcing Failures,” the Outsourcing Center^[1] surveyed 305 buyers and providers in North America, Europe, Asia and India to assess their experiences and opinions about outsourcing failures. One-third of respondents were buyers, two-thirds were providers. They concluded that 25% of the reasons for outsourced project failures are due to poor communication (16%) and cultural fit (9%). If you believed 25% of your outsourcing projects would fail because either you or your provider didn’t understand each other, even though you both speak the same language, or innocently offended each other because you didn’t understand each other’s cultural mores, you would do something about it wouldn’t you?

Multicultural or cross-cultural training is a key success factor when considering outsourcing. Gerard (Geert) Hendrik Hofstede is an influential Dutch sociologist whose life’s work includes the study of the interactions between national cultures and organizational cultures. Hofstede defines five dimensions of culture in his study of national work related values which are:

Individualism vs. Collectivism: measure of how greatly members of the culture define themselves apart from their group memberships
Long vs. Short Term Orientation: A society’s “time horizon” or the importance attached to the future vs. the past and present
Masculinity vs. Femininity: the value placed on traditionally male or female values
Small vs. Large Power Distance (PDI Scale): A measure of how widely the less powerful members of society expect and accept that power is distributed unequally
Weak vs. Strong Uncertainty Avoidance: A metric of how extensively members of a society are anxious about the unknown and try to cope with anxiety by minimizing uncertainty

Having an understanding of the Hofstede PDI scale provides insight into one of the foremost causes of cross-cultural communication failures—the difference between high context and low context communication. The low context communicator expects straightforward conversation. If there is a problem, s/he expects a straightforward answer with specifics. In high context countries, subordinates acknowledge the power of others based on their formal hierarchical positions. The subordinates offer their superiors great respect. Out of respect, the high context communicator doesn’t directly inform their superior of project issues due to the concern that the superior may suffer an offense. Neither person is doing anything wrong. They are merely observing the cultural norms of their respective countries.

Effective cross-cultural training solves the issues that resulted in the 2004 survey’s 25% of project failures. Preparing employees to work outside of their native country or to work with offshore outsourcers is extremely important for outsourced project success. Basic multicultural training includes:

Action plan for living abroad
Communication characteristics and role
Doing business in the country
Eating and drinking
Education, studies and professional training
Introduction to culture and history
Laws, norms, taboos and values of the society
Leisure activities and customs
Social contacts, friends and acquaintances
Relations at work and management
Women’s life and role in society

Without understanding these cultural norms, communication breakdowns lead to project failures. One of the greatest mistakes any IT organization can make is to enter into an outsourcing agreement without first subjecting its key players to basic multicultural training. They’ll perform their due diligence in selecting a vendor, but fall short in their due diligence in training their resources.

^[1] The Outsourcing Center is a wholly owned subsidiary of the Everest Partners, L.P.; Two Galleria Tower, 13455 Noel Road, Suite 2100; Dallas, TX 75240; PH: 214-451-3000 FAX: 214-451-3001; http://www.outsourcing-center.com/

The Project Management Method and the SDLC

By Victor M Font Jr 8 Comments

Many people are confused over the difference between a project management method and the System Development Life Cycle. Some believe a project management method is a subset of the SDLC and some believe the inverse, that the SDLC is a subset of a project management method. The truth lies somewhere in between. In terms of importance to a project, the SDLC and a project management method are co-equals which complement each other. Together they harmonize to form a complete methodology for delivering high quality products to our customers that meet or exceed their expectations. Neither can stand on its own to deliver high value to the business. They each have different roles in support of business initiatives. Throughout the life cycle both of these methods work together to achieve business goals, drive the value equation and progress organizational maturity. Though their activities differ greatly, they interrelate and harmonize to produce superior results.

A project management method provides detailed instructions for the discipline of planning, organizing, controlling, reporting and managing project resources to successfully complete project goals and objectives. It includes all of the activities for managing a project. A project is temporal in nature. It has a defined beginning and end. The project management method begins with project inception and closes when its product is delivered. When a project is over, the project manager moves onto something new.

The SDLC provides a framework that describes the activities performed during each phase of a systems development project. The SDLC is about quality, consistency and product delivery. It is about the realization of a product’s requirements. Products are of a more permanent nature than a project because products continue to exist long after the project that delivered it has closed. Therefore, the SDLC’s framework provides guidelines for supporting the product post production. Guidelines include practices for knowledge transfer, training, document turnover, maintenance and on-going support. When a product is to be retired, the project management method takes over to sunset the system. It is a full circle in a system’s life.

Project management is often expressed in terms of the constraints of scope, time and cost. This is also known as the project management triangle. Each side of the triangle represents a constraint. No side can be changed without affecting the others. At one time, “quality” or “performance” was considered a component of scope. The model has since been refined to delineate quality as a fourth constraint.

Time is the period available to complete a project. Cost is the project’s budget. Scope is what must be done to complete the project’s deliverables. The three constraints often compete with each other: scope creep means increased time and higher cost, a tight time frame may mean higher costs and less scope, and a tight budget may mean less time and reduced scope. Quality may be at risk if there are changes to any of the constraints.

To demonstrate the complementary nature of the SDLC to project management, I’ve contrived the SDLC triangle. Earlier I said the SDLC is about quality, consistency and product delivery. Quality, consistency and product delivery are the outputs of a defined, managed, measurable, repeatable and reusable set of processes and practices. The processes and practices form the core framework of the SDLC. Where a project is defined by its constraints, the SDLC is defined by its freedoms and empowerment. The SDLC empowers a project team to choose from among several approved pathways to deliver the highest quality products possible in the shortest amount of time and at the lowest possible cost.

Scope is a constraint that SDLC processes liberate by managing scope creep. Scope creep is a project killer. Let’s be clear, project scope will change during the course of a project. That’s because business priorities are fluid and may drive changes in projects so that evolving current needs are met. It’s how we manage scope that’s important. We’ll never be able to eliminate scope creep, but we can manage it effectively so it doesn’t become the constraint that kills our project. In many ways, managing scope creep begins with the project’s business analyst.

Consistency of process helps keep the cost constraint under control by practicing repeatable, measurable and defined algorithms. Let’s be pragmatic. Whenever we practice something, we get good at it. It doesn’t matter if we’re talking about music and the arts or sports or anything else. The old adage is “Practice makes perfect.” If we do something the same way over and over again, not only will we get good at it; we’ll find ways to improve what we are doing so we can do it faster, better and cheaper.

The schedule constraint is complemented by the SDLC’s timely delivery of a quality product that meets or exceeds customers’ expectations. If we manage scope creep effectively and are consistent in our ability to repeat and improve our processes, not only will we deliver a product on time, there may even be enough wiggle room in the schedule to address lower priority items or deliver the product ahead of the due date.

The complementary relationship between the SDLC and a project management method cannot be denied. They do not compete against each other.

IT Governance and the SDLC – Part 2: Upfront Requirements Elicitation

By Victor M Font Jr Leave a Comment

When discussing investment opportunities at governance meetings, senior managers invariably ask: “How much will the project cost us?” In the early phases of opportunity talks many IT leaders respond with the “SWAG” (Scientific Widely Aimed Guess) based on experiential supposition. Later, after governance approves a deeper investigation into the cost, IT leadership returns to governance with a slightly more predictable estimate known as a ROM or Rough Order of Magnitude, based on nothing more than executive level discussions, the research they’ve done from talking to vendors and presuming what resources will be needed. They don’t even have enough information at this point to distribute a formal Request for Information (RFI). Returning to governance, they supply a statement of work documenting what they believe is required, a Return on Investment (ROI) calculation based on the ROM, resource plan and projected schedule. If all goes well, governance is convinced of the projected derived business value and ROI and approves the project—all based on conjecture.

Nobody up to this point has gathered any of the actual requirements from the business users. The discussions thus far have all been very high level. This is highly ineffective IT Governance in action. You may also say this is IT Governance inaction. Ineffectual governance processes often lead down the path of conducting requirements elicitation and analysis early in the project life cycle but only after the project is approved and funded. This is always a bad decision and one that leads to more problems for IT leadership down the line.

When Business Analysts start the requirements elicitation process after the project approval and kick-off, it doesn’t take too long to discover the original investment estimates were way too low. Now that the true business requirements are known, the project team realizes the scope to deliver the necessary functionality to the business is much broader than they first thought. As the project proceeds several months down the road, IT leadership goes back to governance and asks for more money to complete what they started and explain why the original timeline has to be extended. Governance either reluctantly responds to the increase in funding or trashes the project altogether. Whatever the case, IT leadership loses credibility with senior management.

Do you think this scenario is farfetched? It’s not. I’ve worked in organizations that have followed this exact process and have witnessed it time and time again. Senior leadership’s loss of trust and credibility in the IT organization is always the result. It is a difficult if not nearly impossible obstacle to overcome. Trust and credibility can be regained over time, but it takes a lot more than continuing with the same processes that got you into trouble in the first place. It often requires replacing the senior IT staff and embarking upon a long journey of IT business process transformation.

The truth is that questions surrounding IT investment and prioritization cannot be fully answered until at least one practice area of the SDLC^[1] is executed and at least partially concluded. That area is performing the processes and practices governing requirements elicitation and analysis. This may also be known as a feasibility study. The question that now comes into play is “How deeply must I capture the requirements at this phase?”

The answer is variable depending on the project, but as a general rule of thumb, if we apply the Pareto principle to investment value and requirements, the resulting theorem says, “80% of the business value of an investment comes from 20% of the requirements.” This tells us that we don’t have to capture all of the requirements in the initial pass. We only need to capture the major requirements in a quantity sufficient to extrapolate a fairly accurate resource allocation and cost projection. A common practice is to pad IT project cost estimates with an additional 25% contingency anyway. By executing the requirements elicitation upfront, before project approval, you’ll provide much more accurate cost estimates, lower your contingency padding and reduce the chance of project overruns.

^[1]System Development Life Cycle.

<= IT Governance and the SDLC – Part 1

IT Governance and the SDLC – Part 1

By Victor M Font Jr 2 Comments

What has the SDLC got to do with IT Governance?

It has long been the tradition of board-level executives to defer all key IT decisions to the company’s IT professionals. The truth is that many board-level executives don’t understand IT well enough to manage IT effectively; and IT professionals don’t understand business initiatives well enough to decide how to invest in them. Deferring key decisions to the IT staff often leads to disconnects between the board’s strategic goals and real business initiatives and the investments IT makes. It leads to frustration at all levels.

IT governance is a business-driven function which focuses on the investment and prioritization of IT systems, their performance, risk management and enhancing a company’s competitiveness. It’s about ensuring IT investments harmonize with the enterprise’s strategic priorities. It’s about IT demonstrating to senior leadership they are receiving acceptable value in return for making IT investments.

In June of 2005, I attended a summer session on IT Governance and Leadership at the MIT Sloan School of Management Center for Information Systems Research (CISR) in Cambridge Massachusetts. The course was facilitated by Peter Weill and Jeanne W. Ross. Peter is the director of CISR and Jeanne is a Principal Research Scientist. Together they authored the book IT Governance published in 2000 by Harvard Business School Press. The book is about How Top Performers Manage IT Decision Rights for Superior Results. It is written for “concerned officers of the enterprise (CEO, CFO, COO, and other senior managers) looking for practical guidelines to improve their returns from IT investments.”

According to Weill and Ross:

Top-performing enterprises succeed where others fail by implementing effective IT governance to support their strategies. For example, firms with above-average IT governance following a specific strategy (for example, customer intimacy) had more than 20 percent higher profits than firms with poor governance following the same strategy.

All companies have some sort of IT governance. Effective IT governance includes well defined and documented processes for work uptake, decision making, budgeting and estimating resources, approvals, IT value realization, project reporting and change management. Many IT governance committees are comprised of the senior most leaders from all strategic areas of the business, not just IT leaders. With a finite enterprise budget, there is competition for capital project dollars. There must be a governance process in place to assure that the right projects are getting the right amount of investment at the right time to improve bottom line profitability and shareholder value.

Weill and Ross assert that effective IT governance answers three questions:

What decisions must be made?
Who should make these decisions?
How will we make and monitor these decisions?

To further explain the first question, they say, “Every enterprise must address five interrelated IT decisions: IT principles, IT architecture, IT infrastructure, business application needs, and IT investment and prioritization.”

The SDLC figures prominently in executing the answers to all of the interrelated decisions above with the lone exception of IT principles. IT principles are subordinate to corporate principles established at the enterprise level. They support or enable strategic company business goals, guide the development and implementation of the SDLC and steer the decision making process in the other four areas. We’ll explore the linkage between IT Governance and the SDLC further in my next post.

IT Governance and the SDLC – Part 2: Upfront Requirements Elicitation =>

Taking AIM at Organizational Change Management—Part 2: Cultural Fit

By Victor M Font Jr Leave a Comment

To fully realize a change management strategy, make sure the change fits your culture. You’ll also need detailed reinforcement and communication plans. Cultural fit is as individual as companies themselves. Every organization has its own variety of cultures and sub-cultures. Most businesses establish a target company-wide culture through their mission statement, vision, values and leader behaviors. Senior management demonstrates the cultural norms as they interpret these tenets. How these creeds flow down and become the organization’s cultural norms may differ from group to group within a company just as strategic goals start at the top and evolve to fit each group’s contribution to the overall strategy. There is no one-size fits all approach to cultural fit. There are tactics however that can guide your moves.

First, define the cultural dimensions of each group impacted by your change. For the SDLC, this is your entire IT organization, senior management and your business users and customers. The SDLC represents a broad sweeping change. It is important to first focus on the “low hanging fruit.” Exploit the aspects of the change that produce the highest yield and lowest risk. Take advantage of any opportunity to lead with results rather than rhetoric. Altogether avoid or reduce the initiatives that are more about image and not reality.

Each of your target groups need to have sponsors who are capable of identifying the cultural characteristics that support the change as well as the values, behaviors and “unwritten rules” that resist the change. Positively reinforce and emphasize the behaviors that support the change. Provide high visibility rewards and recognition for attaining the desired state.

Regardless of how effective your positive reinforcement is, you will face cultural resistance. Someone once asked me, “Why is it necessary to have a company-wide SDLC? We all do things now that are effective for us, why change?” This individual was a member of one of the working teams building and vetting the SDLC processes. His question caught me off guard. He didn’t understand the big picture even though he was serving as a change agent and involved with the very construction of the SDLC. As I thought things through, I realized this question is a direct result of my failure to effectively communicate the vision to the change agents.

For each major source of cultural resistance, you need to discover the answers to these three questions:

What are the values, behaviors and “unwritten rules” that are motivating the resistance?
What is it about the culture that reinforces the “unwritten rules?”
What is it about our system that rewards the “bad” behaviors?

Armed with this intelligence, you can then work to define and implement specific changes that reduce or eliminate the cultural dimensions that reinforce change adversity and execute those that reward the new behaviors. Develop a positive reinforcement plan that is stronger than the motivation to keep the status quo. It requires significantly more sponsorship attention, discipline and stamina to inspire a group to move from “discomfort and resistance” to “opportunity and need.” The sponsors must “walk the talk” and visibly display the new behaviors even if they are individually painful.

Consider offering financial rewards as part of your positive reinforcement plan such as a salary increase, bonus, prize or perk for demonstrating the new behaviors. Apply the positive rewards immediately after observing the performance of the new behaviors. Celebrate early successes and wins. Do whatever you can to make it more difficult to continue to operate in the old state.

Build an effective communication plan that explains the objectives and rationale, the time frame and the cost of not changing. Implement the communication plan early and communicate often. Send out frequent progress updates. Focus the organization’s attention forward and generate an excitement about the new changes to the SDLC. Commission surveys or walk around the floor to learn if people understand the message. Are they getting it? Keep your communications credible, comprehensive and clear.

We’ve only touched upon a few aspects of organizational change management. There are a lot of moving parts to any organizational change, but especially so when rolling out a SDLC. An organizational change management strategy is much broader than the few examples I’ve presented here, but for a SDLC implementation, it is absolutely essential.

<= Taking AIM at Organizational Change Management – Part 1

Archives for 2010

Multicultural Training Can Mean the Difference between Outsourcing Success and Failure

The Project Management Method and the SDLC

IT Governance and the SDLC – Part 2: Upfront Requirements Elicitation

IT Governance and the SDLC – Part 1

Taking AIM at Organizational Change Management—Part 2: Cultural Fit

Testimonials

Consulting Services

Copyright Notice

Copyright © 2010–2026 Victor M. Font Jr.

Recent Posts

Recent Comments

Archives for 2010

Testimonials

Consulting Services

Copyright Notice

Copyright © 2010–2026 Victor M. Font Jr.

Recent Posts

Recent Comments

Tags