If the aim of western-style capitalism is to ensure that an ever greater proportion of the wealth of nations is controlled by an ever smaller clique of individuals, then it is clearly 'successful'.
However, I for one would question how sustainable such a system can be?
It seems to me that the operation of the economy has become extreme and aberrant since c.1970 (maybe since 1950) with the rise of 'professional managers' and the abrogation of power, by government, to speculators and lobbyists.
What do you think? Here Are The Four Charts That Explain What The Protesters Are Angry About... |
Earlier this week, we published a chart-essay that illustrates the extreme inequality that has developed in the US economy over the past 30 years.
The charts explain what the Wall Street protesters are angry about. They also explain why the protesters' message is resonating with the country at large.
Here are the four key points:
1. Unemployment is at the highest level since the Great Depression (with the exception of a brief blip in the early 1980s).
2. At the same time, corporate profits are at an all-time high, both in absolute dollars and as a share of the economy.
3. Wages as a percent of the economy are at an all-time low. In other words, corporate profits are at an all-time high, in part, because corporations are paying less of their revenue to employees than they ever have. There are lots of reasons for this, many of which are not the fault of the corporations. (It's a global economy now, and 2-3 billion new low-cost employees in China, India, et al, have recently entered the global workforce. This is putting pressure on wages the world over.)
4. Income and wealth inequality in the US economy is near an all-time high: The owners of the country's assets (capital) are winning, everyone else (labor) is losing.
Three charts illustrate this:
The top earners are capturing a higher share of the national income than they have anytime since the 1920s:
CEO pay and corporate profits have skyrocketed in the past 20 years, "production worker" pay has risen 4%.
After adjusting for inflation, average earnings haven't increased in 50 years.
It's worth noting that the US has been in a similar situation before: At the end of the "Roaring '20s," just before the start of the Great Depression. (See some of the charts above).
It took the country 15-20 years to pull out of that slump and fix the imbalances. But by the mid-1950s, employment, corporate profits, wages, and inequality had all returned to more normal levels. And the country enjoyed a couple of decades of relatively well-balanced prosperity. But now, everything's out of whack again.
Importantly, the inequality that has developed in the economy over the past couple of decades is not just a moral issue. It's a practical one. It is, as sociologists might say, "de-stabilizing." It leads directly to the sort of social unrest that we're seeing right now. |
Hmm. This sounds to me like a variant of the Kanban approach to software development. Nowadays there are quite a lot of organisations applying the principles of lean thinking. There are even some who have started to recognise how those principles apply to Lean Product and Process Development (ref: Prof. Allen C Ward, Michael Kennedy and Don Reinertsen).
I guess the 'lean mainstream' (that's a term I thought I would never have occasion to use) are just becoming aware of the rapid progress that has been made in applying lean principles to the development of software-intensive systems since c.2003.
It would be really interesting to get some real quantitative data regarding the effectiveness of 'the factory' implemented by Menlo Innovations. A software company takes a page from Toyota's playbook |
Using a combination of Toyota-inspired lean manufacturing principles and an open office atmosphere, Menlo Innovations' work environment is attracting attention. |
By Katherine Reynolds Lewis, contributor
 Menlo Innovations in Ann Arbor, Mich. FORTUNE – At most white-collar job offices around the country, workers scurry from cubicle to cubicle, speaking in hushed tones. Take a step into software firm Menlo Innovation's offices in Ann Arbor, Mich., and it's clear that this firm is more cotton mill factory floor than monastery.
Instead of rows of cubicles, visitors enter an open space that calls to mind an artist's loft or an industrial warehouse that is filled with the sound of a dozen overlapping conversations.
"A lot of people don't believe software development can be done in anything but library quiet," says CEO Rich Sheridan, during a tour of his company's space. "I have 12 years of experience that says differently."
Sheridan and his co-founders built Menlo's work culture with a great deal of intention, and with the modest aim "to end human suffering in the world as it relates to technology." The free-form floor plan was inspired by Thomas Edison's Menlo Park, N.J., laboratory, which had an open and collaborative workspace that in turn drew inspiration from the machine shops of the day.
"There are no rules around here about how the space is formed," Sheridan says. Network and electrical cables are pulled down from the ceiling, rather than from a wall or pillar, so lightweight tables can be pushed together in the center of the room, or moved around as needed. The staff put the CEO's desk wherever in the room is convenient -- rather than in a glass-walled corner office.
But arguably the most novel element at Menlo is one that put southern Michigan's auto industry on the map decades ago. Just as Kichiro Toyoda standardized the manufacturing and quality control processes for car production, Menlo has created its own standardized process for making software. Thousands of companies have attempted to duplicate Toyota Motor Corp.'s (TM) success when it comes to quality and culture, but Menlo is one of the few that captures the core principles, says Jeffrey Liker, an engineering professor at the University of Michigan and author of The Toyota Way.
"The concept of lean production was introduced in the 1980s and that was considered as big a revolution as moving from craft production to mass production," says Liker, who has studied Menlo's operations. "Any piece you see in Menlo you'll see somewhere else. What you won't find [elsewhere] is all the pieces working together…."
Menlo's approach seems to be paying off. The software company has been on the growth path ever since it was founded in 2001 and has regularly made Inc. magazine's list of fastest-growing private companies.
So what exactly makes Menlo such a well-oiled machine? Here are a few things that certainly help:
Assigning bite-sized pieces of work
As Menlo programmers map out their work on a project with customers, they estimate how many hours each step will take and write it on a card. They then assign the cards to a given day of the week, ensuring that the eight hours of each workday are filled -- but not exceeded. "They know what's expected of them," Sheridan says. "They don't have to go around asking, 'Boss what do I have to do next?'"
Keeping projects in plain sight
Just as Toyota believes you must see the problem to solve it, Menlo tacks these task cards onto their office walls. Each project has its own code name and the project boards are broken down by day, with a piece of yarn across the current day and a yellow sticky dot indicating the current card. When the programming team believes a card is finished, they replace the yellow with an orange one.
If Menlo's quality assurance specialist agrees that the given task on these cards has been completed, she will place a green dot on top of yellow; if not, a red dot sends the task back to the developers. "When the string moves down on the next day, you would expect to see green dots above the string but none below. That tells us we're exactly where we expected," Sheridan explains.
Menlo takes a page from the doctrine of agile programming -- which itself stems in part from Toyota's production system -- by focusing on continuous improvement and feedback. "A lot of people labor away for months or years and are never sure, [asking themselves] 'does anyone care what I'm doing?'" Sheridan says.
Observing the customer in action
Menlo has a "high-tech anthropologist" (a term the company coined and trademarked) on staff who visits customer's offices and observes the people who will be using the software and how they actually work, using that information in the software design process -- rather than just working from the abstract descriptions of customer requirements. "They don't want to develop software that implements bad processes," Liker says.
Similarly, Toyota requires all engineers to spend three months in a dealership selling cars to better understand their customers' experience. The chief engineer for each car model is expected to be the voice of the customer. For instance, the chief engineer for Toyota's Sienna minivan drove through every state in the country as well as Canada and Mexico, taking detailed notes, to understand what drivers experience in different climates and road conditions.
Training workers to stay flexible
Everyone at Menlo works in pairs. Two programmers share a single computer and mouse. So not only do you have two pairs of brains working on one problem, you avoid what Sheridan calls "towers of knowledge," a scenario in which only one person in the company knows what stage a project is at, or what's needed next. "Those towers become prisons eventually for people who are inside of them, because they can't go on vacation, they can't do anything new," Sheridan says.
The worker pairs switch every week, so people are constantly learning new things and working with different coworkers.
In a nod to its lean manufacturing inspiration, Menlo's office is called "the factory floor" and the woman who assigns worker pairs each week holds the title of "factory floor manager."
Start of a revolution?
Menlo's setup is starting to attract attention. Sheridan conducted 100 tours of the company last year, and expects to match that number this year. There's bound to be some misunderstanding, Liker says, as when U.S. auto executives toured Toyota in the 1980s and came back to paint their floors the same color and recreate the same spotless, organized factories they saw in Japan.
"What they were missing was the culture and the development of people," he says. "People are starting to understand the real essence, which is not just-in-time inventory, but having people communicate with each other, working in teams and solving problems together.... People are not going to stretch themselves unless they feel respected and part of the team." |
Not a bad analogy to grab people's attention and get them thinking about the contribution they make… or fail to make. The pig-chicken comparison certainly illustrates a good point about commitment and the need to limit work-in-progress.
My concern is that this 'view from the pig-sty' is too developer-centric.
To extend the analogy, the walls of the sty prevent the pigs from seeing far beyond the boundary walls (and pig-sty walls are usually very substantial, to stop the pigs from breaking out). Which makes it difficult for the pigs to see the project to which they are so dedicated in the context of the end-to-end value stream. That is, the overall health and wealth of the farm. Remember that most pigs are kept as weaners or growers, and are eventually destined for the slaughter house.
This limited horizon is, of course, a feature of all projects and one reason why I suggest that the project concept should be considered harmful. A continuous process that flows value in 'single-pieces' from concept-to-consumption is more effective and more efficient.
But given that many organisations are likely to be constrained to organise work into projects for some time to come, lets consider some roles other than that of developer. To what animal character, for instance, would you assign the role of the Product Owner (aka the 'entrepreneurial system designer')?
What about the end-users (and consumers for that matter) with whom developers ought to collaborate in order to understand their particular stakeholder needs and values? What about the other stakeholders and their needs? What animal characters are they? Discuss.
The creative power of lean-agile development is the ability to create new knowledge fast. It does this through experimentation and set-based engineering. In the process, evidence regarding the viability of many ideas is collected, and many (most?) ideas are thrown away (or put aside for later). The new know-how can be captured as knowledge patterns and trade-off curves that can be incorporated into the design & development process to guide future iterations.
But developers need to take care not to become over-committed to specific concepts. Most ideas, by definition, wont contribute to, and cannot be incorporated into, the desired outcome. Over-commitment is an attribute of the 'serial fix-on-fail' approach that characterises what I call the 'agile random walk'. That just wastes time, effort, money, goodwill, and credibility.
So, upon consideration, the chicken (or more specifically, the hen) is the best animal role model for the lean-agile developer.
The hen contributes value that is really appreciated by the end consumer, and keeps to a regular delivery cycle. Proper treatment and attention to the hen's 'process' can greatly influence productivity and velocity, delivering more (eggs) for less (food), faster (laying rate). The hen is not afraid to fly up onto the walls of the pig-sty, to take a look around, to see the surrounding landscape. The entire flock progresses by moving from one fertile area to another, creating value as they go, instead of persisting to root around in a sty where the mud (and s**t) forms an ever-deeper quagmire.
If the flock is free-range and fertile, its activities will be coordinated by a cockerel (perhaps I'm pushing the analogy a bit too far now?), who musters the hens, finds where the most enticing food is to be found, and protects the flock from interference and danger from outside. Perhaps the cock should be the totem animal of the Scrum Master?
To my mind, that means the best analogy for the Product Owner is the Farmer. Agile Animal Farm - Pigs, Chickens, and more
|
Once upon a time there was a chicken and pig walking down the country road. The chicken turns to the pig and says, “I have a great idea! Let’s start a breakfast restaurant called Ham-n-Eggs”. The pig thinks for a moment, and then says, “No thank you. You would just contribute (your eggs) and could leave when you wanted to, while my bacon would be on the line”.
This humorous yet telling analogy from the Agile world helps us distinguish those that are just involved from those that are truly committed on an Agile team. However, in the real world, pigs do have to work with chickens and even other animals around the farm. Let’s take a look at each animal more closely. I have seen or heard about the Pig, Chicken, Fox, and Seagull before and I will also introduce a few more new animals (e.g., Rat, Cat, and Bull) to this interesting analogy. How many of these have you seen in your Agile workplace? |
Pig - They are fully dedicated to the project and the Agile team. They are committed to the work. They work in a pig-pen with other pigs who love their work and environment and love to pitch-in. If Agile is being implemented correctly, they are more than willing to put their bacon-on-the-line every day because they feel ownership of the work. They are assertive and accountable for the success of the project and have a majority (if not all) of their performance goals linked directly to the success of the project and their specific Agile team. Chickens – They come and go on the project. While chickens are mostly helpful, because they are contributing their eggs, they don’t always understand the full context because they are not a dedicated team member. So occasionally they may accidently contribute a rotten egg. They are not accountable for the success of the project, although they may have a small portion of their performance goals linked to the success of the project. Fox – They like to stealthily move into and through the team seeing who has certain skills and ideas. Then they like to steal not only resources (Agile team members) for their own teams, but they also steal ideas. They are not necessarily negative, because they are often so quiet in their manipulative work. They are dedicated to their own success. Seagulls - They like to fly around the project and not really contribute in any manner. They enjoy “talking” (mostly hearing themselves speak) and pretend they are adding value, but they are only annoying the pigs (Agile team members). Often, they like to swoop in so it can look like they are involved (and they’ll tell others this). They are often quite negative, squawk a lot in a “know it all” manner, and often poop on people and their ideas. Rat –They are deceiver types who will use the trust of the team to gain insight into topics so they can then “rat” on what is going on to others. Often on Agile teams, they are really deceivers because they are really anti-Agile or just plain negative people. They often know the decisions that are made based on certain contexts that the team is in, but will twist the truth in order to bring the project down. It is important to identify these deceivers as quickly as possible and get them off the team.
Cat – They are a lazy type on an Agile team that really do not pitch in but instead like to sleep instead. They are almost purposefully not assertive, have been used to just “getting by” on projects for years, and are not really interested in feeling ownership of the work. They typically neither positive nor negative and simply like to be left alone. The other team members will begin to notice this behavior and realize they are not really interested in becoming part of the team. Bull – They are command-and-control types (often management) who think they can continue to tell their functional reports what to do even though they are dedicated to their Agile teams. They charge right into the team and attempt to direct them to their own work and often deviate the team from building product functionality. Typically, they are not interested in the Agile mindset because they see it as a challenge to their authority or don’t really understand or care about the business benefits of Agile, but instead want to maintain their own status.
I hope you enjoyed these animal analogies. Did you recognize any of them? What Agile animals are on your Agile farm?
Here are few more links to other Agile animal references: Enjoy! Read more at cmforagile.blogspot.com |
Here is some very interesting research that considers how people respond to change and what motivates them.
It has a profound significance for anyone that wishes to develop leadership skills. Although a job is often regarded as a purely economic transaction, in which people exchange their labor for financial compensation, the brain experiences the workplace first and foremost as a social system. |
people who feel betrayed or unrecognized at work — for example, when they are reprimanded, given an assignment that seems unworthy, or told to take a pay cut — experience it as a neural impulse, as powerful and painful as a blow to the head. Most people who work in companies learn to rationalize or temper their reactions; |
they also limit their commitment and engagement. They become purely transactional employees, reluctant to give more of themselves to the company, because the social context stands in their way. |
Leaders who understand this dynamic can more effectively engage their employees’ best talents, support collaborative teams, and create an environment that fosters productive change. Indeed, the ability to intentionally address the social brain in the service of optimal performance will be a distinguishing leadership capability in the years ahead.
|
Thanks to @FlowchainSensei for distributing a link to the CareersInTheory blog post below.
A very interesting update of Maslow's Hierarchy of Needs. Seems more confirmatory than not, in the essential matters. What are the fundamental human needs?
What things, if we get them, will make us happy human beings?
Are there such things as universal human needs, that everyone in every society would identify with, or does it depend on your personality and cultural background?
In an earlier post on Maslow’s classic hierarchy of needs, I mentioned that it had been criticised (Hofstede, 1984) for being based on Western sensibilities. In defence of his criticism Hofstede cited a research study by Haire et al. (1966) in which managers from 14 different countries were asked to rate the importance of various needs (security, social, esteem, autonomy, self-actualisation) as well as indicating their level of satisfaction and fulfilment of those needs.
In this study, only the managers from the US ranked the needs in the order proposed by Maslow.
So does that mean that Maslow’s needs are not universal?
A more recent study by Tay & Diener (2011) was based on data gathered by the Gallup World Poll, conducted across 123 countries between 2005 and 2010, which asked questions about:
- Subjective well-being (SWB). This included three measures – life evaluation (rating your life on a scale of ‘worst possible’ to ‘best possible’), positive and negative feelings (measured by asking whether people had experienced a lot of laughing, enjoyment, worry, sadness, anger, etc., in the previous day).
- Needs similar to Maslow’s were assessed by asking what they had experienced in the last 12 months
- Basic – had they had enough money for shelter or had they gone hungry
- Safety – did they feel safe walking alone or had they been robbed
- Social – had they experienced love or do they have people who will help them
- Respect – had they been treated with respect or had felt proud of something
- Mastery – experience of learning or using a favoured skill at work
- Autonomy – could they choose how they spent their time or did they experience freedom
Tay & Diener analysed the various responses to these questions and identified various relationships.
They found that not having these needs met consistently led to a low life evaluation. However, having all the needs met did not guarantee that you would evaluate your life highly.
They found that the fulfilment of each need had a reasonably independent effect on well-being. This means, for example, that the impact of Social needs was not dependent on whether more Basic needs had been completely fulfilled. This somewhat contradicts one of the assumptions of Maslow’s hierarchy, that more basic needs must be fulfilled before higher needs have relevance.
However, Tay & Diener conducted another analysis to try and identify the order in which needs emerged by looking at which need shows up as important after basic needs are fulfilled. Although the results were not conclusive, there was some evidence that the needs emerged in a similar (but not identical) order to that proposed by Maslow.
Another thing they found was that different needs were linked to different types of well-being.
- Basic needs fulfilment was linked to increased life evaluations and to a reduction in negative feelings.
- Social and respect needs fulfilment were linked to increased positive feelings.
- Respect and autonomy needs fulfilment were linked to a reduction in negative feelings.
Yet another thing was that, when needs fulfilment was taken into account, income didn’t significantly contribute to increased well-being.
Finally, all of the relationships they found were reasonably consistent across different countries.
So, maybe different cultures have become more similar between 1966 and 2005, or perhaps it’s just managers who differ in different cultures.
Further reading
- Haire, M., Ghiselli, E.E. & Porter, L.W. (1966) Managerial Thinking: An International Study. New York: Wiley.
- Hofstede, G. (1984) The cultural relativity of the quality of life concept. Academy of Management Review 9(3), 389-398. DOI: 10.5465/AMR.1984.4279653
- Maslow, A. (1943). A theory of human motivation. Psychological Review, 50(4), 370–396.
- Maslow, A. (1970). Motivation and Personality (2nd ed.). New York: Harper & Row.
- Maslow, A. (1971). The Farther Reaches of Human Nature. New York: McGraw-Hill.
- Tay, L. & Diener, E. (2011). Needs and subjective well-being around the world. Journal of Personality and Social Psychology, 101(2), 354-365. DOI: 10.1037/a0023779
|
The 'five questions' outlined by Mats Lederhausen (below) seem remarkably similar to Sir John Whitmore's GROW model for mentoring. That is:
– Goals - What is your desired outcome & how will you quantify its characteristics?
– Reality - Where you are now, what's the gap to where you want to be, and what is possible?
– Options/Obstacles - What actions will serve to close the gaps? What are the barriers and how can they be overcome?
– Will/Way Forward: What actions will you take today, tomorrow, next week to progress?
You can use this yourself, of course (self-mentoring)… but it always seems to work better when these questions are asked by a coach or mentor.
Although derived in the context of sports coaching, the GROW model (and most such models) necessarily are a form of the Shewart/Deming Plan-Do-Check/Study-Act (PDCA) cycle.
In the context of ICT and business, I prefer Prof. Alan C. Ward's version, the LAMDA Loop, which is particularly tuned to product design & development involving teams of contributors, each with specialist skills.
For the PLAN & DO steps of the PDCA Cycle, go once around the LAMDA Loop, as follows:
LOOK - at the current state, the desired outcome(s) and the gaps, honestly.
ASK/Analyse - why does the current state pertain? What are the root conditions and causes?
MODEL - the set of solution options, only rejecting those which the evidence indicates are not viable.
DISCUSS/Decide - engage all contributors to determine what set of solution options you will collectively progress… which set of options are 'pulled' by the desired outcome? Decide upon an Action Plan.
ACT - to implement the Action Plan and collect feedback on the results.
Then cycle around the LAMDA Loop once more to complete the CHECK & ACT steps of the PDCA cycle.
And then continue to use the LAMDA Loop for each successively more fine grained solution to your problem, or on successive iterations of the product.
Let me know how well you find this works for you. Tweet me at @pg_rule Five Questions Every Mentor Must Ask |
One of my partners, Mats Lederhausen, recently shared with me a mentorship framework, first inspired by wellness guru, Deepak Chopra, that he's evolved and used over the years. The framework is an amazingly simple-yet-powerful set of five critical questions. |
These five questions, when asked in the order presented, form an effective diagnostic tool that can provide better guidance to mentees, employees, or generally anyone with whom you are playing the role of a counselor. Additionally, they can serve as a self-diagnosis of one's own capabilities and opportunities. |
Here are the questions:
1. What is it that you really want to be and do?
2. What are you doing really well that is helping you get there?
3. What are you not doing well that is preventing you from getting there?
4. What will you do differently tomorrow to meet those challenges?
5. How can I help / where do you need the most help? |
Here is a link to a stream of eight videos of Jeff Sutherland & Ken Schwaber explaining the origins and purpose of Scrum at the ESE Conference in Zurich in April 2011.
http://youtu.be/2r1GYC04VHI
This is part of the history of software engineering of which all IT professionals should be aware. It just goes to show that little in this world is really new.
It also points out the challenge and need for a real cultural change, not just by those involved in the so-called 'software industry' ... more Here is a link to a stream of eight videos of Jeff Sutherland & Ken Schwaber explaining the origins and purpose of Scrum at the ESE Conference in Zurich in April 2011.
http://youtu.be/2r1GYC04VHI
This is part of the history of software engineering of which all IT professionals should be aware. It just goes to show that little in this world is really new.
It also points out the challenge and need for a real cultural change, not just by those involved in the so-called 'software industry' (the term is itself indicative of the challenge) but also throughout organisations that call upon the efforts of software professionals. Actually, a change of mindset in how organisations, in both the public and private sectors, are led and managed. The problems are people-oriented, not technical.
But you knew that, didn't you? URL: www.youtube.com
From the title, it seems that the Select Committee does not intend to pull any punches. And nor should it! MPs to publish report on Govt IT rip-offs – “time for a new approach” |
On Thursday the Public Administration Select Committee will publish “Government and IT— a recipe for rip-offs: time for a new approach”.
The report is the culmination of months of investigation by the Committee and its advisers into the way government buys and uses IT.
The Committee’s witnesses included representatives of SMEs who suggested that government IT is dominated by a few large suppliers that charge too much and suppress innovation.
One of the SME representatives, Martin Rice, said the IT industry should apologise. He told the Committee: “I think the IT industry should publicly apologise to the citizen for the rip-offs of the last 10 or 20 years.”
He added:
“We are reinventing the wheel and it should not be allowed. As a taxpayer, I am very angry about this … A lot of these problems have been solved; they are not being brought to the Government because of the oligarchy. It is not in a profitable interest to bring you these paradigms. That is why I feel the oligarchy has to stop…” |
Further conversation on the pros and cons of outsourcing ICT. Jim Smith •
Grant,
"Let the buyer beware" may have come into use based not how smart the seller was, but on how dumb the buyer was.
I still maintain that a company who cannot manage their internal use of IT is not likely to prudently manage an outsourcing company. In the US, big companies go with big outsourcing companies who are much better at monetizing the deal than the client is at negotiating a winning deal for themselves.
Here's a simple model I use to get CEO's to look at outsourcing differently; These numbers are a bit out of date, but accurate to make the point.
Let's say that a decent programmer cost a company $80,000 and another $20,000 in overhead. That's $50/HR. Now that you've outsourced, that same body is going to cost you $150/HR, that's $300,000 a year for a developer. Do you think that might be why so many companies hire in house developers even after they have outsourced?
I once killed a outsourcing proposal by pointing this out to the CEO. The HR person refused to pay the operations manager more than $100,000K. I pointed out that the the outsourcing proposal on the table would be paying the OPS mgr. $300,000. They went with hiring a real CIO (the HR person still wanted to go cheap) and never outsourced.
The suppliers you mentioned should seize on this concept and sell their differences. Having said that, you cannot underestimate the tremendous security CEO's perceive in going with the "safe" selection. I'm not certain which international bank is in sourcing after a relationship with IBM, what does that tell you?
No matter what a company has to pay to hire a CEO level CIO, that's a better choice than abdication through outsourcing.
|
I'm completely with you @Jim. I hadn't meant my post to seem to contradict anything you'd said.
It seems to me that much outsourcing has been promoted by organisations in desperation at the lack of stakeholder value delivered by the in-house IT group. That is, as an attempt to 'outsource a problem'. That never works (as your post indicates).
It only ever makes sense to outsource services once the organisation has control and understanding of its process performance. And then it makes sense to outsource only non-core competencies (if you outsource core competencies, you are giving away the business. Ask Boeing about that!).
Even then, one should consider the rationale for outsourcing… that an external supplier that specialises in the required service will be able to deliver the necessary value more effectively than can be achieved in-house. Sufficiently more effectively to at least maintain the service quality (i.e. within budget, on-time, working straight from the box, innovating to keep pace with the competition, etc) *and* make a profit. So the customer needs to ask themselves whether they believe the supplier can do that, and continue to do it. Without unethical exploitation of staff, despoilation of the environment, damage to social capital, etc. It would be no bad thing to ask the supplier how they intend to achieve that.
Other people have observed the ubiquity of software-intensive systems. So for many organisations, there is no business without software. And hence competency throughout the software lifecycle, from 'concept to cash to retirement, *is* a core competency for many organisations. In which group I would include: banks, insurance companies, retail, logistics, energy supply, manufacture of many kinds, most consumer service, public admin, etc.
As you say, it seems far better for an organisation to develop their own in-house capability, aligned with the strategic goals and business needs of the 'leading coalition' of C-level executives, than to put the future of their organisation into the hands of someone with an agenda entirely their own.
–––––
Just to add some further figures to the ones you posted. My company regularly acts as an independent, objective 'Quantity Surveyor of IT' for clients who have outsourced application development & enhancement, and/or support & maintenance. It is not unusual to find organisations paying their suppliers from 3x to 7x the 'going market rate' for pretty ordinary software systems. Especially in the context of multi-year outsourcing contracts.
Much evidence shows that the *median* effort expended to develop (from 'requirements ready' to 'done') one unit of functionality (as perceived by the end-user) is between 7.69 – 9.47 hours of productive work (workhours). Yet some contracts include rates equivalent to c. 18 – 36 workhours per unit of functionality (i.e. per function point). On top of the costs of that, one must add the suppliers efforts spent on programme & account management effort, eliciting the requirements, deployment and integration, etc, plus the customer organisations costs incurred throughout.
Is it any surprise that some customers are choosing to insource?
Read more at www.linkedin.com |
Here is the original posting on LinkedIn, followed by the response I posted to it.
The world is changing. The practices of both large enterprise software vendors and suppliers of outsourced services have to change. Their role is to understand stakeholders and what they value, and then to deliver it. Indeed, the best service providers have a deep understanding of what their client's customers value, and they work to assist their clients to create customer delight.
Exploitative attitudes and behaviours will be found out for what they are. Web 2.0 services now provide budget holders with many choices, so they don't have to feel they are hostage to the whim of their suppliers. How difficult is it for you to fire your existing IT Outsourcing firm?
|
Are you unhappy with the level of service provided by your chosen IT Outsourcing firm? Have you considered switching to another provider but are having challenges in escaping existing agreements? |
Believe me, it's very difficult! The vendors make certain that the hurdle for reversing the arrangement is very high.
It's difficult for companies to negotiate clear and concise exit agreements with these large firms. First of all, the vendors get to amortize the refinement of their contracts over years and many client experiences. The client on the other hand has very little experience negotiating outsourcing deals. |
Companies considering outsourcing should research other companies who have in-sourced after a failed outsourcing experience, then they would be better prepared to negotiate a successful contract
|
when the business gets involved in an outsourced deal, they have to pay for every single hour of support. So, if a company outsources because it cannot manage IT when it's owned, who do you suppose it going to win in an outsourced environment. In fact, I could never be convinced that the vendor doesn't recognize the weak management situations and capitalize on that by low bidding the initial deal, knowing that they'll make it up on all the client requested changes and additions.
|
A former executive at one of the largest outsource providers told me that at the moment the contract was signed, the team was required to meet with finance and discuss how best to "monetize" the deal, even before execution begins.
|
Jim Smith
CEO, Enterprise Management Group |
@Jim describes the common, but very disappointing experience that many organisations get from their outsourcing vendors. But it really doesn't have to be like this.
I do know a number of suppliers of outsourced services that retain the focus on delivering value to the customer and who consider themselves to be 'stewards' of the customer's intellectual property. The concept of stewardship includes: recognition that the customer's systems & IPR remains the customers; that the supplier is a service provider; that the 'supplier as steward' has a professional duty to put the customer's interests before their own.
So it is essential that the customer organisation takes pains, before letting a contract, to understand whether the supplier will be predatory, or service-oriented.
Characteristics one should look for include:
– The supplier insists on a period during which all available knowledge of the customers systems are captured, documented, and made available to both the customer and suppliers staff, preferably in an on-line knowledge-base.
– The supplier commits to keeping the knowledge-base up-to-date as a key tool for improving the effectiveness of the support & maintenance service.
– The supplier is prepared to hand back the customer's systems whenever the customer so chooses (not just at pre-set contractual milestones), and builds-in arrangements for an orderly hand-off.
– The supplier is prepared to guarantee a year-on-year reduction in support & maintenance costs (corrected for inflation & foreign exchange rates, of course).
– The supplier can provide quantitative evidence where they've acted as stewards for other customers, showing systematic improvement in the total costs of the service provided.
The perennial adage 'caveat emptor' continues to apply. But I suggest that using the old argument that 'no one ever got fired for buying from XXX' is an abrogation of the responsibility to conduct due diligence and to build relationships that benefit your organisation in the long term.
Read more at www.linkedin.com |
|
