Feeds:
Posts
Comments

Posts Tagged ‘Vendor’

Every interaction with a customer including complaints is an opportunity to build or strengthen our bridges with our customers.  Very often we find our customer-facing staff blowing away this opportunity that lands on our lap for free. To better understand this gift recall what we go through when we go out to engage a customer unsolicited.  

And how do we blow it away? Usually by keeping our interaction down to a crisp and a minimal response demanded by the context.  Technically flawless, business-wise not so wise.  Of course at the other extreme, we might have a loquacious rep overdoing it pushing the customer to annoyance.

What then do we do with this opportunity? Well, there are several avenues to be explored: we could gain useful insights into his decision making process (why or how did he settle on our product?), his experience with competitors, his post-purchase impressions, what else would he like to see as features, does he see enough of our brand publicity… If it is a complaint, information about events leading to the failure could be collected.  Did he have other issues/signals before the failure occurred?  Does he have thoughts on how this failure could have been possibly averted? Of course what would work depends on the temperature of the call.

All of these cannot happen without orienting our customer-facing staff adequately, constructing different possible scenarios and outlining avenues for enriching the interaction.  

Note outsourced call-centers are optimized to enhance calls handled in a day rather than quality engagement with the caller, at once totally eliminating this opportunity.

Incidentally all of the above apply to our interactions with prospects too.

Here’s a short well-written piece from Art Petty on this same theme exhorting us to have transformational interaction instead of transactional. A personal experience included. So why settle for less when its potential benefits could be dramatic?

End

Read Full Post »

you getting monkeys is not just with hires. Goes for vendors, contractors, third parties…

This is for the managers and executives priding on their ability to squeeze every freebie, concession and discount out of their beleaguered vendors.

Here we go:

The  headman from the painting cum landscaping company  was speaking with the hard-driving customer about the job awarded to them.

Laying-Turf  jokesoftheday.net

In the first room, she said she would like a pale blue. The contractor wrote this down and went to the window, opened it, and yelled out “GREEN SIDE UP!”

In the second room, she told the painter she would like it painted in a soft yellow. He wrote this on his pad, walked to the window, opened it, and yelled “GREEN SIDE UP!”

The lady was somewhat curious but she said nothing. In the third room, she said she would like it painted a warm rose color. The painter wrote this down, walked to the window, opened it and yelled “GREEN SIDE UP!”

The perplexed lady then asked him, “Here I’m telling you what to do and you keep yelling ‘green side up’?”

“I’m sorry,” came the reply. “them…are laying sod in the front and around.”

End

 

 

Source: Adapted from jokesoftheday.net

 

Read Full Post »

Hiring a

That was frivolous – but not what follows:

An interesting article on the subject of managing the talent available to the organization appeared recently in Forbes that presents perspectives known and new of great significance to both employers as well as employees of now and future.

Here are some excerpts (in quotes) with minimal paraphrasing (in italics) and there is some re-sequencing and emphasis (underlined), entirely mine, to improve the flow and readability, I thought:

The challenge: “Ask anybody who manages a business and they will tell you how important it is to hire the right people. Top companies recruit at the most selective schools, offer excellent pay packages, generous benefits and a comfortable work environment… Unfortunately, it seems that even the best firms are facing a widening skills gap and it will only get worse… Clearly, if businesses are to remain competitive, they need talented people…with the right skills…all the time. Talent, therefore, has become as central as marketing or finance to corporate strategy.

The volatility of technologies… is rendering old skills useless. So even if your workforce is highly qualified by today’s standards, they might not be tomorrow.

Yes, that soon. While the threat of technology obsolescence is not new, the immediacy of it happening is scary, forcing a rethink on how we manage talent.

Writing on the wall for the employees: “It used to be that you would choose a career, join a company and work there for your entire career. Clearly, that time has passed. As business models rise and fall, firms need to adapt and acquire new skills in order to stay competitive.

Hiring

Skills in demand: “In past generations, prosperity was primarily an issue of high-skill versus low skill jobs and a poorly educated, low-skill workforce could be upgraded through training and education…things aren’t so clear-cut anymore because the types of skills needed in the new economy have changed…Going forward, it seems that there are two broad areas that will continue to be in demand: people skills and design skills…So, not surprisingly, most good jobs are design related (broadly defined to include, engineering, software, marketing, etc.).

By ‘design’ it seems to imply platform independent design skills for it adds in the same breath design skills like Flash development suffer from the same danger of rapid obsolescence.

Training: This is not entirely a surprise.

Top firms have long understood the need to invest training and some, like McDonald’s and General Electric, have gone to great lengths to develop extensive corporate training programs. More recently, executive education programs at universities have also begun to play an important role in developing new skills. However, training of lower level employees is often neglected, but shouldn’t be. One study comparing Costco and Sam’s Club found that by investing more in front line personnel, Costco was able to increase revenues while actually lowering costs.

Compensation: “MIT’s Zeynep Ton, author of ‘The Good Jobs Strategy’, has found in her research that well-trained well-paid employees are not a cost driver, but a sales driver. A higher paid workforce results in less turnover and better customer service. Even in retail, companies that invest in people outperform.

A model useful in the job market: “Elance (www.elance.com) has come up with a new model for talent to fill the gap. On the surface, it’s just another freelance service, acting as a go-between for companies that need short-term help with projects and people looking for work. But take a closer look and it becomes clear that the company is far more ambitious than that. It tracks employments trends so freelancers can see where demand for skills is increasing and where it is declining. The firm also offers more than 20,000 training courses so that people can build new skills to meet demand. Then, as freelancers perform jobs and gain expertise, they build up their profiles and increase their earning power.

Contract Workers, an engagement model useful to the employers: “Increasingly, work is project based. A company might need to develop a new website or have marketing materials prepared or build a new feature for an existing platform. This creates short-term demand for non-core skills that may not make sense to retain full time. Elance has come up with an interesting solution it calls talent clouds. Rather than keeping talent on staff, employers can build their own network of freelancers, track their performance on projects and keep up with their progress learning new skills. So if they liked working with a Flash developer last year, they can see if he’s now certified in HTML5.”

Near-exclusive employment: While on the subject of contract workers, I bring up a related model, not part of the original article, that opens up interesting possibilities.

I would extend the problem and solution offered by contract employment to cover SME’s (Subject Matter Experts) too where the problems are more severe. An IT services organization lands customers from a variety of industry segments. For instance in one project we needed someone to tell us about production of photographic films and in another we wanted insights on simulation of chemical reactions. A long felt need is for a clearing-house for domain experts in various fields of specialization whose expertise could be used on a part-time basis. The one reason it has not taken off yet, I guess, is these experts are employed somewhere and their terms of employment forbids them to take up external assignments even if the experiences promise to enrich the experts’ skills eventually benefitting their employers. I’m for organizations to allow this kind of engagement as long as there is no conflict of interest. The engagement model could vary from an individual rendering services as a project consultant or it could even be packaged formally as the organization’s services. See the Xerox example cited elsewhere. Clandestine and unethical practices if any would then be replaced by formal engagements.

The current model of exclusive full employment is inefficient and wastes talent, a scarce commodity in societies. Time has come to try out near-full employment. This could be a more light-weight and cheaper alternative to conventionally engaging a consulting house. Before you rubbish the idea think of this: this is already in practice in the academic world.

Academic Partnerships: “Another strategy that some firms are adopting is partnering with universities to ensure that students are graduating with the skills they need. IBM, for example, has built an open source curriculum and works with over 1000 universities.

Well, this is quite successfully practiced for years now by IT organizations in India at least. They are known to work with professional training institutes, often designing custom curriculum. Working with universities had posed a problem. I recall years ago when the teaching community was in a fix – teaching Windows in the course on Operating Systems was considered improper since it meant ‘promotion of a commercially proprietary platform’. May be they have resolved those issues now.

Strategic Partnerships: “As complicated as the world has become, the truth is that no company can build all the skills it needs, but many are learning to fill the gap with partnerships. For example, Xerox’s legendary PARC Labs now undertakes projects for a variety of companies… Yet, to be effective, these relationships have to be cultivated, monitored and deepened. Partnerships can no longer be treated as mere supply relationships, but extensions of the talent ecosystem.

A vendor is also an important resource to reduce the high cost in-house structure. Where as it is not uncommon to look at our vendor with suspicion, as a necessary evil and even as a threat. We hold up his bills and even poach on his critical resources while he looks on helplessly. Hopefully good sense will prevail in course of time. It requires quite a change in thinking to assume greater responsibility for a vendor’s survival and success.

Open Platforms: “Another way that firms are tapping into talent is through open technology. Rather than building products as closed platforms, they are providing resources, such as SDK’s and API’s, so that outside developers can enhance and expand the capabilities that were designed in-house. After all, the value of an iPhone depends not just on the hardware and the operating system, but on the hundreds of thousands of apps that others have built for it. In a similar vein, IBM recently opened up its Watson platform to outside developers to help reap the benefits of external talent.

This movement has taken firm roots and is irreversible.

The New War For Talent: “In 1997, McKinsey declared a ‘War for Talent’ and advised their clients to focus on recruiting and retaining the “best and the brightest.” They suggested that firms should create a compelling “employee value propositions,” invest in A players, develop B players and move quickly to get rid of C players.

However, those types of distinctions have become anachronisms. Today, you need not only a strong value proposition for employees, but for everybody in your talent ecosystem. Further, an “A player” with yesterday’s skills isn’t going to do you much good…

Most of all, in today’s semantic economy, it’s not the resources you own that are important, but what resources you can access and that’s especially true of talent.

What to speak of ‘everybody in the talent ecosystem’? Do you honestly think we make a real good value proposition to the employees and the prospective hires in the first place? The hires-facing personnel hardly exude the excitement.

Finally: Horse-whipping the recruitment function in an organization is not the whole solution to ensure right talent is available at all times. It requires a more holistic and multi-pronged approach including inducting newer models of engagement. Who would bell this cat? HR?

End .
.
Source: http://www.forbes.com/, Images from the Net.

Read Full Post »

In my treasure hunt for stories on customer service/experience, I reached out to who else than Rajanga Sivakumar, a revered Guru on Hewlett-Packard’s vast range of testing and measuring instruments/solutions, and now practicing as a Business Excellence Advisor.

In this guest post he pulls this story out of his jumbo bag of anecdotes – my first success in getting him to tip over his bag 

[This is a real incident, the names of players, organizations, car models etc. not specified]

This was year 1998. Prem was delighted when the company informed he had become eligible for a pricier company transport. He could now get for himself the car he fancied – the newly introduced model Z of a well known international manufacturer (Brand A), to be made locally in India. In the pre-liberalization times, cars were available from the three local manufactures, their models at least a decade old. Even better the company was allocating Prem from the first lot of model Z assembled from imported kits (SKD) with no locally sourced parts. Model Z living up to its reputation, Prem and his family were happy with their choice. .

The car came with a prized accessory for Prem and his family – an audio tape player. Though disc players were also available then, the family preferred the audio tape player to avail of the large collection of audio tapes of Carnatic music they had assiduously accumulated over years. They loved to hear the music especially when travelling long distance.

After functioning quite well in the first six months, the audio tape player began acting up. In the space of about year and half it had to be repaired over five times at the retail service centre of the well known auto agency from where the car was bought.

Help_Desk gsagri04

Prem was very much irked with the frequent failures of the device and the inordinately long times taken to set it right. Now he asked the agency to replace the under-warranty unit for its erratic performance. And he wanted it done in time for his upcoming travel.

After many rounds of discussions and referring the matter to the principal’s (Brand A) HQ in Delhi – Prem himself participated in the talks with the principal – the agency came up with a solution: they would replace it with a new unit with the customer bearing 50% of its price. This was not acceptable to Prem and the matter ended there.

Argument

In about 3 months Prem retired from his current employment and joined a newly formed software company as a consultant. His new employer offered him the facility of a new car. He promptly replaced his model Z with model U of Brand B.

Also, Prem was consulted by the company on the different brands and models available for many of the executives joining then. Needless to add he struck Brand A off the list, the latter immediately losing out on sale of two large and two small cars conservatively estimated to be about a whopping Rs 19 lacs+.. And of course, it didn’t end there.

Against this loss what did the agency and its principal save to their (dis)credit? Rs 4,250 they had asked their customer to fork out.

A clear case of an easy opportunity squandered away, to forge loyalty in a favorably disposed customer at so little cost, through inept handling that was neither prompt nor gracious. Altogether a forgettable experience he did not forget.

And more importantly not seeing a customer as more than a customer. Someone out there had not been astute enough to assess the potential of Prem – for future purchases for himself and more significantly as an influencer in his circles.

While on the subject, I recall:

“Diamonds are forever
They are all I need to please me
They can stimulate and tease me
They won’t leave in the night, I’ve no fear that they might desert me…”

That was Shirley Bassey in the eponymous James Bond’s movie of 1971.

Well, customers too could be forever – if their experiences are right+ and sustained.

Thanks, Rajanga for the elucidating story.

End .
.
PS: Rajanga may be contacted at: rajangasivakumar@gmail.com. The image is from openclipart (gsagri04).

Read Full Post »

I am on a constant prowl to collect stories on what companies do to enhance their customer’s experiences employing a variety of different strategies.

While on this subject, not entirely unrelated, I’m reminded of the question of ‘Employee Satisfaction’ in a software services company I was associated with. The attrition of professionals in the company was higher than the industry average. As customary the managers including the HR confidently diagnosed the problem as one of substantial wage disparity – salaries outside were easily 30% or more than what the company was paying. Unfortunately this coincided with downward business cycle leaving not much room for any significant revision. 

While the issue of compensation cannot be easily brushed aside with the younger lot in software industry, I’m dismayed to find it occupying all of the center-stage to the entire exclusion of what other things could be done for the employees.  Mumbai as a city and software services as a job leave very little time for anything else. A good number of professionals spend 2 to 3 hours daily just commuting to and fro in crowded trains/buses.  Many of them hail from other cities living in spacious accommodation before moving to closet-sized apartments in Mumbai. Given this background, reducing the hassle of living in Mumbai is a strategy worthy of serious consideration. But that doesn’t happen. A few token steps are kicked off without a cohesive strategy on this theme, more as an apology – such as providing assistance in paying utility bills, credit card bills, etc.

‘Managers’ don’t much buy into all those industry reports that cite a number of factors up there besides doling out hefty increases in compensation for employee retention/satisfaction. 

 Coming back to customer experiences, here is a simple story on the same theme of making life a wee bit easier.

This is from ‘Through the Eyes of the Customer.’  James Watson makes the point in his post so well I did not try paraphrasing it.  

“…

I love it when someone makes my life easy.

CVS Pharmacy did that this morning.  

I’ve been taking an daily allergy prescription for the past three years.  Once a year, my doctor has to re-approve the prescription so  that CVS can refill it.  And that once-a-year event happened to coincide with this month’s refill.

 Pharmacy

So, I expected that  I’d have to call my doctor, and request to have  the prescription renewed.  Or worse, schedule an appointment to get into my car, drive to the office, and endure a check-up. Either way, I’d be forced to break out of my normal routine of simply picking up the prescription at the CVS Drive-Thru and do some extra work…. 

… so I thought….on

But when I dialed the local CVS pharmacy, and punched the Prescription number into the keypad on my phone, that friendly recorded voice told me that my auto-refill had ended, and that my physician must approve the refill.  

“Damn,” I thought… Here goes”….

But the next automated message made my day:

“Press “1′ if you would like CVS to contact your physician on your behalf.”

Yes!!!  One less thing for me to do, because CVS would do it for me; they’ve designed their customer-facing process in a way to reduce work for the customer; they’ve made my life easier!!! I was delighted.

Now, it might only take me five minutes to call to my doctor’s office and make the arrangements myself.  And a five-minute task done once a year may not seem like much of a hassle. Over the course of that year, it’s really not – except when it is.  Like this morning.

The point is not the CVS saved me five minutes; the point is that CVS eliminated a Task from my To-Do-List.

Most people don’t keep track of time as clearly as they keep track of tasks that need to be completed.  Saving a customer “a few minutes” may not be clearly visible to that person, but if you save the customer from having to perform a task, they’ll notice it every time, and they’ll precieve it as a BIG convenience.  And it’s the customer’s perception that drives their behavior and loyalty.

…”

I recall a similar experience I had with a mobile service provider a couple of years ago. I went in to purchase a replacement SIM for my cell-phone. When I took the form with me duly filled in, at the store they pointed out I had overlooked pasting a mug-shot on the form. It meant going back home to fetch a photo. While I was ‘Oh sh##t’ing, they made me stand against a wall, got a camera out and took a shot right there in the store!   

Whether the business is of providing services or supplying products there are opportunities galore to mitigate the hassle factor for the customer in his interaction, surely  a worthwhile goal for businesses to go after.   

End

                              .

                                   .

Credits:  jlwatsonconsulting.typepad.com/my-blog/

Read Full Post »

“…

Mint

Of all the things that waiters/waitresses (henceforth just referred to as “waiters”) could do to increase tips, how important would you place “giving mints” at the end of a meal in terms of effectiveness?

It turns out, you and I probably greatly underestimated the psychological process behind mint-giving.

In a study published in the Journal of Applied Social Psychology, researchers tested the effects that mints had against a control group (where no mints were given) in order to measure their effectiveness in increasing tips.

The results were surprising to say the least.

  • The first group studied had waiters giving mints along with the check, making no mention of the mints themselves. This increased tips by around 3% against the control group.
  • The second group had waiters bring out two mints by hand (separate from the check), and they mentioned them to the table (ie, “Would anyone like some mints before they leave?”). This saw tips increase by about 14% against the control group.
  • The last group had waiters bring out the check first along with a few mints. A short time afterward, the waiter came back with another set of mints, and let customers know that they had brought out more mints, in case they wanted another.

This last test was where waiters saw a 21% increase in tips versus the control group.

At first glance, the last two groups seem very similar: two mints (per-person) were brought out, and the waiter mentioned them.

So, what was different?

In the last test, the only difference was that the waiter brought out the second set of mints after some time had passed, and mentioned that they had done so in case the table would like some more.

Researchers concluded that this seeming genuine concern for the customer (“I thought you might like more mints…”) and the spontaneity of the gesture connected with customers much more than the additional pieces of chocolate mints would imply, even if the waiter did this for every customer.

This is good to know, because it means that it’s applicable to businesses outside of restaurants.

So, how can a business utilize this knowledge?

…”

(Source: See Credits below)

There’s more to this story than the positively-reinforcing gratuity for the waiter.

Waiter

If we closely look at this scenario, there are 3 essential elements to it:

* Buyer buys a product and/or a service.

* the product or the service is delivered (the waiter could be doing intermediate deliveries too).

* At the end-point of the delivery, the delivery agent is empowered to give away from a range of freebies.

Selecting a freebie appropriate for the occasion and giving it away with finesse and solicitousness are both a matter of training and the employee’s imagination.

It’s easy to see paying attention to this end-of-service experience is a low-hanging fruit in its impact on the overall service experience.

Most self-employed appliance-repair technicians do it in some ways. But mostly overlooked in the organized sector of the industry.

An example from the organized sector:

Class-room training courses usually include hands-on exercises. These are usually very focused and easy enough to be completed within the limited time-slots allotted in the tight course format. A more ambitious course may allow in its format for elaborate projects/case-studies demanding in-depth application of the skills or concepts learned.

Now we get to the ‘mint’.

At the end of the course, the instructor could point out how the projects and their challenge could be further enhanced by interested participants working on their own time outside of the course. And if someone chooses to do so, the instructor could make a time-bound offer of a certain number of free telephonic support calls to help him complete his extended project.

Only imagination limits what could be wrought by the ‘mints’ at the end-point of a delivery.

End

                                                                     .

                                                                              .

Credits: The slightly edited extract included in the post is taken from an interesting blog post at https://www.helpscout.net/blog/the-psychology-of-personalization-how-waiters-increased-tips-by-23-percent-without-changing-service/ . Image is from openclipart (waiter shokunin).

Read Full Post »

The Road to Failed Endeavors is paved all the way with Execution Screw-up’s.

Here’s someone from the most unlikely quarters that got it right.

This is a 120+ years-old 5000+ strong organization, serving 200,000 customers dispersed over a sprawling metro.

Well, what is special about them?

– For starters, six-sigma like performance with 400,000+ transactions in a day, almost on time, every time. These are end-user transactions and do not include internal en-route transhipment transactions normally prone to errors. Contrast it with the hi-tech baggage handling by the airlines industry.

– No disruptions in a city where every political party routinely organizes strikes for whatever reason.

– Education of the employees: Barely literate, some up to 8th Grade in school.

– Technology: bicycles and wooden-crates. No documentation at all. Recently introduced are booking through SMS and a web-site to inform and collect feedback.

The wonder organization is the Dabbawalas of Mumbai – a subject of study by many management schools.

A dabbawala literally meaning (“box person”), is a person in India, most commonly found in the city of Mumbai, who is employed in a unique service industry whose primary business is collecting freshly cooked food in lunch boxes from the residences of the office workers (mostly in the suburbs), delivering it to their respective workplaces and returning the empty boxes back to the customer’s residence by using various modes of transport.

So honest and reliable that customers are known to send home their pay-packet through the dabbas.

What works for them?

‘Their efficiency is not entirely a management marvel; it is rooted in their cultural values,’ says Ramesh Kamble, a professor of sociology at Mumbai University. The 5,000 dabbawalas come from a particular community of Maharashtrians, hailing from 30+ villages around Pune, deeply influenced by the Bhakti [devotion] movement. Denying exclusivity in hiring, Pawan Agarwal, a senior officer of the organization says:’The only recruitment criterion is a ‘guarantee’ – essentially, a verbal assurance of the candidate’s character – by an existing member. Most people tend to refer their friends or family members who belong to the same community…Our values, inclinations and psychology are similar. So there is better understanding and teamwork.’

Bino Paul GD, an associate professor at the TISS School of Management and Labor Studies observes: Their tremendous sense of social coherence with the city – they live with their families, eat home-cooked meals and lead respectable lives – further contributes to the culture and the cohesiveness of the dabbawalas.

There are other management gurus who think it is not as simple as that. How could it be so? They see a whole range of management, organization and process related factors contributing to the impeccable performance. They have not yet discarded the phenomenon as unscalable and freakish.

Whatever, an organization that works unerringly amidst the prevailing chaos. Could it be emulated elsewhere? The Wharton study tries to explain why this story is not easy to practise with the taxi drivers, for example, of Mumbai city. Reasons cited are hard and long duty hours, unrewarding business, the fuedal culture and a life of deprivation for the migrants from the north who constitute a large part of the population, etc.

Interestingly, it also means the stellar performance is now institutionalized outlasting several different leadership periods. In fact leadership is not mentioned anywhere in various write-up’s on this success story. Are there more examples of such kind?

End

Sources: Grateful thanks to knowledge.wharton.upenn.edu and Wiki.

Read Full Post »

Milestones are important in any paradigm of project management regardless of what tools are used to assist in project management. Carefully planned milestones go a long way towards success of a project and satisfaction of its stakeholders.

While a project may be reviewed in great detail by looking at the level of tasks, it is the milestones and their dates that aggregate the impact for easy comprehension of the bigger picture.

Now, is there a basis for setting up these milestones in a project?

While it is not exactly a science, some useful guidelines can certainly be framed to help in defining the milestones. A word of caution, of course, is in specific situation, these guidelines may be required to be adapted to fit the occasion.

Here we go:

Every important event in the life of a project is enshrined as a milestone. Usually these events mark the completion of a phase of the SDLC cycle for a module or piece of the system under development.

Associated with a milestone is a deliverable (code, document, bug-list…) of value to the stakeholders.

It is often overlooked the acceptance of the deliverable by the customer is also a milestone. It implies the deliverable is adequately tested by the vendor before delivery and is also sufficiently tested by the customer for its acceptance. The principle applies to all committments required from the various stakeholders for the successful execution of the project. And these milestones represent the committment of their owners (stakeholders) to the project. This must be impressed up on all at the very outset. It is not a solo show by the vendor driving all the milestones.

As far as possible, a milestone has a single stakeholder responsible for the deliverable. For instance, QC testing is normally done by an independent Quality group and hence gives rise to a separate milestone to mark that activity.

Obviously the definition of the milestones and their sequencing are settled jointly by the stakeholders, usually guided by the customer’s priorities and any inherent dependencies and risks.

Often a simple step is missed out of making sure all stakeholders are in the know and in agreement with the schedule of milestones. It has the potential for causing serious consequences. How often do we find the customer has planned his vaccation when the deliverable is required to be tested by him for acceptance!

A corollary of associating a deliverable with a milestone is to also link a quantum of payment by the customer to the vendor commensurate with the efforts towards the milestone.

The milestone’s deliverable must be ‘executable’ (verifiable), must represent a significant addition to the functionality delivered in the earlier milestones. And, even usable especially in the later stages of the project.

For this reason, it is a good practice to ensure the deliverable of the current milestone is completely integrated with the earlier deliverables.

In all but the simpler projects, at any instant of time, activities may be current on more than one milestone.

A key question still remains is: How many milestones should be defined in a project?

More milestones a project has, it is less risky for the customer. He has greater visibility into the project and sees it being ‘conquered by divide and rule.’ It is also less risky for the vendor as any lack of alignment of the deliverable with the customer’s needs is detected at the earliest point of time for correction. The down-side of having too many milestones is the overhead associated with readying the deliverable by the vendor and its testing by the customer for each of those milestones.

Obviously, it is the other side of the coin if there are too few milestones in the project. Besides, the vendor also gets paid later in the day for his efforts.

What is the golden mean?

Of course it depends on the size of the project. Well, a thumb-rule could be a vendor’s milestone for every 15% of the project efforts completed or for every 3 to 4 weeks of elapsed time whichever is earlier.

It is also not unusual to define a hierarchy of milestones in larger projects.

It is a normal practice to estimate and track other performance parameters besides the timeline for each milestone individually.

Hence, a high-level milestone or a set of milestones at lower level may be planned so as to include the all the phases of the SDLC cycle as completely as possible. Only then many performance parameters are meaningful. For instance Defects Density is meaningful for a milestone only if all the development efforts are included in that milestone.

And, finally, it is possible for the vendor to set up internal milestones not visible to the customer as part of the strategy to split it up into manageable pieces.

End

Do share your experiences in this regard.

Source: Image form Wiki

Read Full Post »

 

Recently I learnt about an alarming situation regarding a system rolled out in a utility service for rendering emergency help to public users. It is quite imaginable that similar conditions may be prevailing in number of other towns in various utility operations.

 

It appears that these systems are not developed centrally under controlled processes as one would have thought, but more as local initiatives. And these are developed with the help of freelancers or part-time professionals and not with employees on rolls. This is understandable for reasons of skills shortage and also costs involved. And dealing with an individual developer is a lot easier than dealing with a service provider company especially for carrying out changes. In this mode of development, the changes, more often than not, are occasioned by requirements originally missed out due to lax ways of specifying rather than requirements evolving over usage. So it is not unusual to see a spate of changes lined up soon after the roll-out.

 

The code rolled out in the production server does not match with the code on the development server. Perhaps some code pieces are lying somewhere on the development server not easily traceable, or they are lost, or some changes were made directly on the production server. The seriousness of the situation has not sunk in yet. The ability to maintain and enhance the software is seriously compromised. For those of us who have been in this business long enough, this is not unusual. But what is scary is these are public-facing applications rolled out in the field, whose malfunction could cause personal injury or, worse, loss of life.

 

Further, there is no concept of version control or a sand-box for thorough testing before roll-out. It is not known if the system is piloted first before the full roll-out to iron out wrinkles.

 

As if this is not enough, I understood the freelancer has gone away for reasons not known. May be it was a cost cutting measure or the freelancer hiked his fees or he had to put distance between himself and the mess that was created (may not be entirely his doing). Needless to say there has been no formal hand-over process. When even the live-code inventory is incomplete, code or system documentation is too much to ask.

 

Into this scenario, the freelancer’s replacement walks in. Can you imagine his/her plight? And, there is a pile of pending enhancement requests waiting for him/her to take up right away. What it takes to maintain software is not always appreciated. What is at stake is not the individual’s performance, but safety of public users for whom the system is in operation.

 

Since public safety is involved, it is important that some minimal norms are enforced for developing and subsequently maintaining these systems and, the compliance to these norms are audited from time to time. May be these norms and audits are already an established practice in some  geographies.

 

This is not a call against freelancers who deliver great value, flexibility and responsiveness (and skills too) required by users whose requirement for software development is light and sporadic. It is a call for controlled processes for developing software especially for moderate-to-high impact applications.

 

Processes must be recognized as a mandatory piece of any scenario wherein software is developed or used for a serious application. The processes are not meant only for the developers; importantly, they also discipline the users (not the end-using public) who commission the developers and whose laxity is also often the root cause of the ensuing mess. It follows that both the developers and the users must be educated on the processes to be followed.

 

Of course, the processes must be right-sized to suit the customer and the application. Else, they could enormously slow down the software development efforts. Admittedly, right-sizing processes may not be a trivial exercise. Further, it is not required to induct a full set of processes which could be quite intimidating for a light-load user. It is sufficient to implement some key processes at a level of simplicity that serves the purpose. 

 

This could be done with some minimal professional help. May be there are sources from which it is possible to buy right-sized processes; and, get the freelancers to follow them.

 

On part of the software service providers, there is money on the table for those who come up with innovative models to develop and service systems for these light-load customers at affordable TCO without compromising on the norms. 

 

Of course, an off-the-shelf package solution significantly mitigates the risks and must be strongly considered as a solution over custom development.

Read Full Post »

 

A question I pop up often at software professionals is how do you evaluate a OO design. We assume presently functional completeness of the design is not in question.   The responses are interesting and various. They usually circle around: How well encapsulation, polymorphisms…are implemented in the design. How well reusability is used…. And some get into OO metrics.

 

I rarely get countered that the question is a wide open one; there are several aspects (some 20 plus non-functional attributes) to a design and which one do I have in mind for evaluating a design. After all design is a model for realizing both functional and non-functional user requirements.

 

If I were asked to be more specific on what is my chief concern in regard to design, I would then say it is the basic ability of the software to take in changes to its functionality over time. Changes to the functionality implemented in software are inevitable owing to the way an organization responds to internal and environmental shifts. With some software, these changes are easier to make and in some, it is gut-wrenching.   And, today, a good part of any IT (non-Capex) budget is spent on getting its software to change in step with the business needs.

 

So the concern over the software design being able to take changes in its stride is legitimate and important enough to say: the design that permits changes to be made more readily with less effort is a better design. Is this all about the usual non-functional attribute of ‘maintainability’? May be, in parts. I would like to think about it more as a legitimate evolution of the software while ‘maintenance’ connotes status quo. And today, the pace of this evolution has quickened even in ‘stable’ businesses.

 

Now let us proceed to figure out what possibly could be the criterion for evaluating the design from this perspective. This could also be turned on its head to ask how does one design that readily accommodates changes.

 

OO is already touted as a paradigm which is well suited to handle changes. Why? Because of its concepts such as encapsulation, inheritance, interface mechanism (?), etc. are suited to cope up with changes. Obviously, whichever design uses these features heavily, as shown by appropriate metrics or otherwise, is the way to go? 

 

This misses a crucial point. The initial functional requirements demand a set of abstractions. The design is best done by recognizing these abstractions and aligning its abstractions with the same. This is the true purport of all those OO guides that tell us how to identify candidate classes by listing out nouns from the problem description… If this is done as it should be, the initial alignment is ensured. This still does not guarantee the design as capable of coping up with changes to come.

 

The same principle applies to changes. Changes also demand a set of abstractions in the areas of change if they need to be handled later with minimal effort. A design that also aligns its abstractions with those in the areas of change is the one that truly delivers the promise of OO paradigm.

 

So the key to good design seem to lie outside of design phase! It is in the phase of assessing requirements; and, importantly, how these requirements would change in the foreseeable future. While we do a good job of the former, the latter has no place in our practice as yet! Not aware if formal methodologies for gathering and modeling requirements call for attention to this aspect. Is there a section distinctly devoted in the requirements document to foreseeable evolutionary changes? Not in 9+ cases out of 10. Not a wonder our systems are not well equipped to adapt to flow of time?

 

The software development community could come up with: “How can we foresee changes to come? If we could, we would provide for it from go.” This is strictly not true in all cases. It is not too difficult to figure out with the users which parts of the business processes are apt to change, if only we bring our questions to the user’s table specially targeting the future. Some are obvious in the trade and these are well taken care of even now.

 

Examples:

 

Tax laws: These could change from time to time.

 

Sales-person’s incentives or commission: The scheme for incentivising sales-persons changes from time to time even mid-year depending on the business objectives. In a healthy quarter, getting new clients may be important and in a sluggish quarter, mining current accounts may be the priority. Clearly the scheme needs to be abstracted.  

 

However, plans to open a new office, to start a new distribution channel, to introduce new pricing policy or new service offerings, to acquire a company…may not be uncovered in a routine study of requirements, the focus being on the present. Only a targeted probing with users may bring out these and other possible change triggers.  A word of caution is: the average user we engage with may not be wise to some of these plans!

 

In summary, a formal and focused business volatility analysis could be carried out with users at different levels of the organizational hierarchy so that the abstractions required by the business now and in future (to the foreseeable extent) are identified and the design abstractions are appropriately set up. The design abstractions could range form simple parameterization to more refined OO and variability techniques. The mode of deploying the changes also influences the choice of design technique.  

 

In fact it is a good idea to include a discussion on how the design would be impacted by anticipated and unanticipated changes in the user requirements: would the design abstractions take them in their stride elegantly or would it cause major upheavals. One recalls how in Operations Research, the algorithms provide for sensitivity analysis to figure out the impact on the computed solution if certain conditions were to change. Incidentally an earlier ‘Change Management’ post talks about the sensitivity of effort estimates to changes in user requirements.  

 

Is this a non-issue with packaged solutions like ERP? No, it is still an issue, perhaps to a lesser degree. Configuring a ERP solution for the current business practice is not a trivial effort. And when there are changes to current practice, reflecting these changes could turn out to be a minor or a significant effort depending on the degrees of freedom in the initial lay-out. For instance, consider organizations that frequently reorganize their operations – divisions and departments merge and split, get centralized and decentralized…The ERP could be elegantly re-configured for all these changes or it could be a snake’s pit depending on how it was set up initially.     

 

As an aside, abstractions in the requirements gathering phase may also be necessitated for an entirely different reason – the involved users may not be clear or articulate about their needs at that point of time or the scenario is in some kind of flux. These may get fleshed out later. Design abstractions must be able to cope up with these too. 

 

All along the software architects and the designers were required to think of abstractions. Now are we wanting our Business Analysts also to get into the groove? Yes, that’s the drift. 

 

How do we build systems for businesses which are intrinsically very volatile? Will look at it in a post to follow.

Read Full Post »

Older Posts »