Feeds:
Posts
Comments

Posts Tagged ‘Productivity’

James Lather in his blog carries this interesting story about an internal memo from Howard Schultz on ‘The Commoditization of the Starbucks Experience’. Though dated, is very much relevant even today. Read on:

From: Howard Schultz
Sent: Wednesday, February 14, 2007 10:39 AM Pacific Standard Time
To: Jim Donald
Cc: Anne Saunders; Dave Pace; Dorothy Kim; Gerry Lopez; Jim Alling; Ken Lombard; Martin Coles; Michael Casey; Michelle Gass; Paula Boggs; Sandra Taylor

Subject: The Commoditization of the Starbucks Experience

As you prepare for the FY 08 strategic planning process, I want to share some of my thoughts with you.

Over the past ten years, in order to achieve the growth, development, and scale necessary to go from less than 1,000 stores to 13,000 stores and beyond, we have had to make a series of decisions that, in retrospect, have lead to the watering down of the Starbucks experience, and, what some might call the commoditization of our brand.

298485028_79fa325d78_z-e1444251366989

Many of these decisions were probably right at the time, and on their own merit would not have created the dilution of the experience; but in this case, the sum is much greater and, unfortunately, much more damaging than the individual pieces. For example, when we went to automatic espresso machines, we solved a major problem in terms of speed of service and efficiency. At the same time, we overlooked the fact that we would remove much of the romance and theatre that was in play with the use of the La Marzocca machines. This specific decision became even more damaging when the height of the machines, which are now in thousands of stores, blocked the visual sight line the customer previously had to watch the drink being made, and for the intimate experience with the barista. This, coupled with the need for fresh roasted coffee in every North America city and every international market, moved us toward the decision and the need for flavor locked packaging. Again, the right decision at the right time, and once again I believe we overlooked the cause and the affect of flavor lock in our stores. We achieved fresh roasted bagged coffee, but at what cost? The loss of aroma — perhaps the most powerful non-verbal signal we had in our stores; the loss of our people scooping fresh coffee from the bins and grinding it fresh in front of the customer, and once again stripping the store of tradition and our heritage? Then we moved to store design. Clearly we have had to streamline store design to gain efficiencies of scale and to make sure we had the ROI on sales to investment ratios that would satisfy the financial side of our business. However, one of the results has been stores that no longer have the soul of the past and reflect a chain of stores vs. the warm feeling of a neighborhood store. Some people even call our stores sterile, cookie cutter, no longer reflecting the passion our partners feel about our coffee. In fact, I am not sure people today even know we are roasting coffee. You certainly can’t get the message from being in our stores. The merchandise, more art than science, is far removed from being the merchant that I believe we can be and certainly at a minimum should support the foundation of our coffee heritage. Some stores don’t have coffee grinders, French presses from Bodum, or even coffee filters.

Now that I have provided you with a list of some of the underlying issues that I believe we need to solve, let me say at the outset that we have all been part of these decisions. I take full responsibility myself, but we desperately need to look into the mirror and realize it’s time to get back to the core and make the changes necessary to evoke the heritage, the tradition, and the passion that we all have for the true Starbucks experience. While the current state of affairs for the most part is self induced, that has lead to competitors of all kinds, small and large coffee companies, fast food operators, and mom and pops, to position themselves in a way that creates awareness, trial and loyalty of people who previously have been Starbucks customers. This must be eradicated.

I have said for 20 years that our success is not an entitlement and now it’s proving to be a reality. Let’s be smarter about how we are spending our time, money and resources. Let’s get back to the core. Push for innovation and do the things necessary to once again differentiate Starbucks from all others. We source and buy the highest quality coffee. We have built the most trusted brand in coffee in the world, and we have an enormous responsibility to both the people who have come before us and the 150,000 partners and their families who are relying on our stewardship.

Finally, I would like to acknowledge all that you do for Starbucks. Without your passion and commitment, we would not be where we are today…

James observes this memo is interesting for two reasons:

1.It shows the problem with ill-conceived process improvement that fixed an internal metric and did not benefit the customer.

2.It is all about management integrity. The CEO is a brave man who, when he sees a mistake, takes full responsibility for it and does a U-turn to solve the problem.

My two cents: A process improvement that fixes an internal metric is not such a sin as made out to be. In fact it is sorely needed with the back-office processes. But when it intersects in any way with user’s experience – the memo provides with many concrete examples in this case – one needs to look at it with much greater care and caution. The points of intersection may not be obvious at the first glance.

End

Source: ft.com/cms/s/0/dc 5099ac-c391-11db-9047-000b5df10621.html#axzz3o8YnDFyr and James Lather’s blog at squawkpoint.com. Image is from flickr.com.

Read Full Post »

Today I can’t imagine myself or any manager getting away with such acts in public. It might even land us in jail under some IPC section.

The year was in late eighty’s.

It was 6-00 in the evening and I took a break and walked around the unit. It was a great sight all around – the papers were strewn on the work-tables and manuals left open on whichever page. All signs of the premises being vacated in a tearing hurry like there was a fire.

So in the following morning, the entire unit had assembled as I launched into another of those raving and ranting session:’ blah blah…Guys, I hate to tell you this – your parents seemed to have given you birth and forgotten all about it and now it for us to teach you basics of hygiene…blah blah…’ Graveyard silence, one or two feet shuffled. No wise-cracks or angry remonstrations. In a little while usual camaraderie returned and all forgotten until the next repeat in a few days and then again…

Fast forward by a few years.

I was in a short-term course at IIM, Ahmedabad. The Professor – unfortunately I’m unable to recall her name – was presenting her analysis of an acute problem the software industry was facing then – attrition of software professionals.

Guys were jumping jobs faster than a frog on hot tin. And the industry did not have a clue on how this could be managed.

And the talk veered around to the (then) youngsters and the esteemed Professor made a few insightful observations:

* The kids all along have been pushed and pushed by the parents to achieve great results in their academics. And when they come into the industry, they are told to slow down: ‘Well, you are too young to become a team-lead,’ ‘You must have at least 5 years of experience in handling…’ etc. etc. They can’t understand this kind of push-back.

* And as a corollary, they’ve missed their childhood fun. When they come into a job, they let their hair down and catch up on the fun they had missed out. The strain of the years of a professional course also tells (Once a kid watched me for a while and asked me how could I possibly enjoy reading a (technical) book at my age). This explains, for instance, why the kid does not report to office on a Monday morning with no prior intimation whatsoever. No point in bursting a few blood-vessels over it.

* Lastly, the only language they understand is one of performance. And use this language to get most out of them. Appealing to ‘feudal’ values like allegiance to the org, values and culture, etc. etc. do not make a significant impression. And this is where most managers fail by merely tasking these kids routinely and unimaginatively without an eye on their performance or drown them in some impersonal high-level metric. This is a subject for a later post.

She did not stop at a passive explanation of the phenomenon. She concluded by saying our leadership style must get appropriately tweaked to pique the interest and performance of these young professionals pouring into the industry year after year. And, of course, save yourself from a stroke or two!

What a colossal waste not doing this! And we bemoan their mediocrity and lack of application. At the risk of displeasing my friends in HR, in most cases I must say they’re entirely innocent of the happenings-on in these quarters. Thankfully for the industry, a small number of youngsters continue to perform very well despite uninspiring and inept leadership.

These observations have not lost their relevance even today as the practices unfortunately have not changed much from what I observe. I suspect the scene may not be very different in other industries.

At least for me, the wisdom had dawned and the rants thereafter dropped off quite significantly – rants of this kind excepted!

Am I tarring them all black? No, not by a long shot. I have known, worked with and gained much from some lucky-to-be-with senior professionals in software and in HR who are an absolute antithesis of what is profiled above. My regret is they are in a minority.

End

Read Full Post »

 

The business tsunami must have already hit the shores of IT service providers by now. In peace times it is always useful to understand how well is our customer doing in his market place, his points of success and vulnerabilities, and add high-impact value to our services. However, in war times such as this, the universal common-sense trend is to fold inwards on costs and productivity. Initiatives to help our customer along this direction would go a long way to forge a stronger relationship. It would not be a smart idea to do nothing maintaining status-quo or get our strategies mixed up.  

 

If we have been servicing our customer for sometime now, it shouldn’t be too difficult for us to see where these opportunities lie. It’s time to make those moves if it is not already too late.

 

Cutting down on waste is an effective strategy to reduce costs and boost efficiency. There is an excellent article by Bill Kastle in iSixSigma magazine (1) on how to cut waste in Financial Services. This post distills some experiences in IT services industry. Here we go:

 

Waste 1: Over-Communication

 

In a production model where the software development involves the long chain of end-users, user-specifier, analyst, designer, coder, tester, user-acceptor, there is communication at every step. A number of system models are in use to support this communication with clarity and efficiency, depending on what is communicated.

 

IT services are often rendered using a model of a mix of onsite and offshore resources.  In some cases, when there are no onsite resources deployed by the offshore service provider, the offshore team directly interacts with the customer’s project manager. In either case, effective communication between the two geography-separated teams is absolutely essential for the success of service delivery and holding regular telecons is a well established practice. A telecon is lot more efficient and time-crunching than exchanging multiple rounds of lengthy emails and much greater clarity is obtained on each other’s views.

 

On the negative, these telecons go on for long hours at inconvenient schedules (due to time differences) for the customer while soaking up a good amount of most productive morning time of the offshore team and is often not sharply focused. Also some more time is consumed in assembling before and returning to desk after the telecon.

 

Assuming there is a diktat that from tomorrow a telecon that lasted for one hour would be limited to 45 minutes by an automatic timer, how would I, as the host initiating the telecom, manage? Some simple steps, really:

 

– I would plan the structure of the telecon by listing the items of priority naming participants and collecting the background material. 

– Communicate the plan and the relevant material to all relevant participants.

– With this prior preparation, tightly orchestrate the call, keeping to the subject on hand and limiting the participation only to those who need to be at each step.

 

If a project of 5 team-members holds 3 hour-long telecons in a week with 3 participants per telecon, a reduction in its duration by 15 minutes yields 1%+ savings of productive hours, not to speak of the customer going to bed 15 minutes earlier and reduced telephone bills!

 

There are times one has to be innovative beyond achieving this basic efficiency in communication. On one occasion, a customer brought up his tale of woe: he had to have these daily telecons with the offshore team that kept him awake late into the nights and sapped his energies. He was building an application, with the help of an offshore team, for managing documents of legal cases and the associated workflow in a law firm. There was an enormous variety in those cases and also in the following workflow. And it took him a lot of time to describe these requirements to the analyst on this side who was trying hard to make sense out of the talk (nevertheless, a vast improvement over the earlier arrangement where he had to make the techies understand him). The customer candidly admitted that he usually missed out a few points in the welter of details discussed, which with great fidelity were missed out as well in the software delivered. And the QA marked them later as defects in the software.

 

Does the above tale of woe point to some ways of reducing the burden of communication and also incidentally reduce defects?

 

Yes, there is at least a couple that could improve matters.

 

Firstly, even in a telecon, clearly a more structured way of articulating the requirements could be deployed. For instance, if screens are used mainly to specify user activities, the requirements may be tightly sequenced as: a) for each field, description (syntax and semantics), default value, display control, filed-level validation b) screen-level (or inter-field) validation and computation and c) for each event (not covered under a) and b) its description, and processing. Templating the requirements thus cuts out free-style (and wasteful) communication and also safe-guards against omissions and lack of clarity very early in the SDLC. This holds regardless of development paradigm: waterfall, agile, etc.

 

This is in a way no different from the traditional method of systematically capturing the user needs in a comprehensive requirements document, instead of catching them on the run as is wont now.

 

As an aside, this is also a potential source for quality problems because the testing team, by not being part of these telecons, is never first-hand aware of the requirements or changes agreed with the customer during these telecons. This disconnect shows up as inadequate coverage in testing or, worse, wrong test cases. A mitigating practice is to at least capture crisply the highlights of the telecom in a follow-up shared communication.

 

Secondly, a familiarity if not knowledge of the application domain significantly helps in reducing the communication burden in regard to understanding requirements. While the luxury of a domain expert may not be available on most occasions, alternatively a short capsule of training program in the problem domain for the analyst greatly facilitates faster comprehension of the requirements. This compromise approach is vastly under-rated or untried. In practice, it has always significantly speeded up capturing of the requirements more completely and clearly.

 

Another aid to easier understanding of requirements: In many projects, short or long, developing a glossary of entities, rules, validation, exceptions, etc. capturing the semantics of the application supported by cross-references is a very useful aid for the same purpose of easy comprehension and also for conserving application knowledge gained over time, obviating the need for verbose documentation. Going beyond the requirements gathering phase, a good glossary is an effective communication tool in all phases of a project. And the nice thing about it is that it could evolve incrementally starting from scratch as more facts are uncovered. This, in practice, has not received the attention it should.  

 

Sometimes the telecon consciously moves away from tasking or problem solving or reviewing mode into a rambling mode merely to establish or strengthen the rapport between the teams on both sides. Or, junior members are called in to watch and learn how to interact with customers. These are planned departures from the course of efficiencies espoused herein.

 

We have looked at only one kind of communication – telecon, and how to bring efficiency and quality therein. The structure of the telecon would depend on its purpose and would evolve over a few sessions. Where the telecon is to explain user requirements, we also saw some approaches to prepare ourselves better in reducing the burden of communication and achieve enhanced quality too. The processes of communication in IT services are pervasive and substantial in a project with enough opportunities to cut out waste at every step and to boost quality.

 

Can we shorten the long service chain of end-users to user-specifier to many in the IT service provider organization and back to user-acceptor? Also can we pare the written-down documentation to a minimum?  These steps should in principle reduce the over-all load of communication. That’s a subject for another day, with implications much beyond communication load.

 

Enriching views and experiences from you, in concurrence or contrary, are most welcome.  

 

To continue on other themes for reducing waste…

 

Ref: (1) http://finance.isixsigma.com/library/content/c040324a.asp

Read Full Post »