Feeds:
Posts
Comments

Posts Tagged ‘IS’

Project-Management premium.wpmudev.org

There was a news item recently in the press about Tata Consultancy Organization (TCS) planning to lay off 30,000 professionals accompanied by words on the ‘big corporate for-profit exploiter’ from some of those impacted or to-be guys for the human element in the story. The guys, it seems, are largely managers with 8 to 10 plus years of experience.

The company has denied it saying the annual weeding out exercise would be only to the extent of 2% to 3% of total strength as it has done in preceding years.

Let us assume for a moment the company is true to its word and there are no compelling reasons of business downturn warranting a bigger-than-usual axing.

While the development is certainly unfortunate especially for the affected, it is hardly surprising. And I’m sure it is neither sudden.

Why does this happen?

When it comes to weeding out, the organization looks at the value an employee brings to the operations in a series of assessments. This is even more significant at senior levels as these guys are pricier and hence most vulnerable.

The avenues available to a senior (a project lead or a manager) to enhance his contribution are essentially in two directions: a) He contributes to the project he is managing/involved or b) He contributes to some corporate objectives not linked to his project. In many organizations seniors are mandated to wear both the hats to get more out of their strengths and maturity.

As far as direct contribution to the project goes, opportunities are many:

1. Of direct and high impact for the organization of curse is to mine the project/account to increase the billing incrementally/strategically. Or, to wow the customer on scope,cost, time, performance or quality parameters of the project.

There are a number of other ways to step up the value (not in any order):

2. Reduce income leakage by handling the lost hours.

3. Increase productivity by using tools, cutting waste, streamlining processes, etc.

4. Flatten the cost pyramid by substituting more junior resources in place of seniors

5. Get the customer to sponsor an incentive plan and other recognition schemes for the team. While the costs incurred in these schemes are low the returns are manifold.

6. Develop it as a reference account/project by putting together, solution stories, application/technical notes, and other marketing/sales assets.

7. Get the customer to agree to site visits by prospects.

8. Get the customer to speak in the organization’s promotional events.

9. Generate newer views of the project by formulating imaginatively metrics to address his pain areas. For example, mapping the change-requests to physical pieces of code would be useful in pointing out which modules are hit by poor articulation of requirements, lack of coding skills or sheer business volatility.

10. Reduce the hassles of dealing with the team in some perceptible manner. For example, cut back on the communication load.

11. Alter some service parameter to customer’s advantage like coverage/turnaround times.

12. Engage the customer to gain a business perspective and his plans, to support mining efforts.

13. Harvest reusable/training assets.

14. Validate and refine quality assurance/productivity/staffing/estimation/methodology models/norms.

15. Groom junior resources in technical and soft skills. In one project, juniors took turns to be present when the lead reviews with the customer to improve their reviewing, communicating and objection handling skills.

16. Stand by him by going beyond the letter during his crisis time.

I’m sure you have a few other ideas too. The opportunities are many limited only by imagination.

So what is holding you back, friend?

If the project is a dead-end kind offering no scope for any initiative at all over an extended period of time, it’s time to move on to another project or even organization.

End

Read Full Post »

Nudging e-Shop Customers to Buy

 A recent article in NYT “Nudged to the Produce Aisle by a Look in the Mirror” talks about interesting experiments carried out by researchers to increase the purchase of produce by the American shoppers firstly for an altruistic motive of reducing the consumption of unhealthy processed food without hitting on their head and in turn save indirectly tax-payer’s money on health-care. Preaching about diabetes or slapping taxes on junk food have not yielded expected results. And of course the business motive of higher profit margins the produce fetch for the stores.

The corollary question is: could these experiments be applied to generate in an online e-shop just the right amount of pressure to nudge the shopper towards the desired behavior?

Let us look at a few possible candidate experiments/findings:

 Produce 800px-Fredmeyer_edit_1

 “In one early test at a store in Virginia, grocery carts carried a strip of yellow duct tape that divided the baskets neatly in half; a flier instructed shoppers to put their fruits and vegetables in the front half of the cart. Average produce sales per customer jumped to $8.85 from $3.99

A shopper filling his basket with unhealthy processed food would be unable to ignore seeing a near-empty produce-side of his basket.

Likewise in a e-shop, we could total up and present how much of produce has the shopper bought till now as he fills up the shopping-cart? We could also present the RDA value of items selected.

 Produce EmpressWalkLoblaws

 “With those same guinea-pig customers, the scientists tinkered again with the cart, creating a glossy placard that hung inside the basketsIn English and Spanish, the signs told shoppers how much produce the average customer was buyingand which fruits and vegetables were the biggest sellers (bananas, limes and avocados)By the second week, produce sales had jumped 10 percent

This is about conformance to social ‘norm’.

Bruce Temkin in his article lucidly sums it up as:

“Why it works: Unlike the previous two examples, this tactic makes no effort to engage reason, rather it harnesses one of our intuitive biases—conformity bias. Our brains like shortcuts, and in order to skip unnecessarily lengthy rational calculations, our minds tend to assume that if other people do something we should do it too.”

In fact this easy flowing default disposition of the shopper is used to advantage in a variety of ways in designing the layout of the mall and its stacks.  

In a e-shop this simply amounts to presenting prevailing context sensitive social ‘norms’ without appearing too obvious.

A flavor of this is already a common practice in many other market segments: “Those who bought this have also bought…”

 OLYMPUS DIGITAL CAMERA

 “Scientists are beginning to study ways to get shoppers to buy more produce, but grocers and their suppliers have already spent years perfecting strategies to sell processed foods. Here’s a sampling of tactics:

THE SWEETEST ITEMS are sold at eye level, midway along aisles, where shoppers’ attention lingers longest.

THE ENDS OF AISLES are huge revenue generators, especially for soda, which makes 45 percent of its sales through racks there, according to the Coca-Cola Retailing Research Council.

IMPULSE PURCHASES (60 percent of purchases are unplanned) can be encouraged by placing items next to checkouts…”

There a number of these findings all about placement of the items to advantage on the shelves in the mall.

Similarly generic research findings for on-line shopping and site-specific and shopper-specific analytics could aid in tweaking placements, search results ordering, etc.

For e-shop designers, it would certainly be profitable to look at what works for the physical shops.

End

                                                          .

                                                                                                     .

Credits: nytimes.com/2013/08/28/dining/wooing-us-down-the-produce-aisle.html, Bruce Temkin in experiencematters.wordpress.com/2013/09/05/design-experiences-to-nudge-consumers/ and Wiki

Read Full Post »

Scene II:

Anon Presentation

The main accomplishment in Scene I was to wean the End User (EU) away from ‘reports and formats’ and get him to talk about the performance defining parameters and have the application compute them for him.

So when they assembled again a few days later, the Business Analyst (BA) and the End User (EU) had a ‘cheshire’ grin.

The report designed this time had all the right columns and filters for selection. Additionally Fuel Efficiency was computed and reported at the bottom.

The Consultant (C) checked if they agreed on how Fuel Efficiency was computed. While the definition was simple – the ratio of kilometers run upon fuel consumed –in reality the method for computing it was a little tricky and at best approximate. It was important to ensure this was understood clearly and unambiguously. The kilometers run had to be marked from one tank-fill to another and the efficiency computed over so many tank-fills. The period of computation was not delimited by a day or a week or any other time period. Over many tank-fills, the computation would have made little difference if it was delimited by tank-fills or by time-period, but not when the tank-fills were only a few in a week.  Also it was not always a full tank-fill. Sometimes they went in for a fill on sighting a filling station though the tank was not empty yet. This meant the amount of fuel filled had to be additionally captured and it could not be assumed always to be the capacity of the tank.

To their credit, this was clearly set out by the EU and well understood by the BA. No issues there.

‘Now, what do you do with this magic number on Fuel Efficiency?’ C asked the EU.

‘Well, I now I know if I have a problem or not.’

‘know’ was the proverbial red-rag to the C.

‘How do you know? Let me put it differently – how do you defend this number to your boss?’

‘I look at this number and look at the type of roads covered.And I know if it’s right or not.’

‘How does it work?’

‘It all depends – if the kilometers were run on highways, I expect a higher efficiency than if it were within a city. Similarly, if the vehicle is on a productive run, it is usually at a lower speed and hence at lower efficiency than in transit.’

‘So you look at the number and look at the composition of the run kilometers and take a call?’

‘Yes, that’s right.’

‘Everybody – your boss and the supervisors in the field – they buy your call?’

‘Well…’

‘How about getting the system to apply the ‘judgment’ you presently make?’

‘If it can be done…’

‘All you need to do is to capture the daily break-up of kilometers run under those four heads: Intracity (Production and Transit) and Intercity (Production and Transit).’

‘That’s possible, though it may not be accurate. We can get the vehicle crew to log the daily kilometers in that manner. That’s not too much additional effort for them.’

‘Now, let us get the break-up in and compute the Fuel Efficiency for each of those four categories separately. You’ll then see clearly the performance and the problem if there’s one.’

End of Scene II

Clearly this was more helpful in getting nearer to the problem area. The trick was to ask the question ‘What would you do with the output?’ repeatedly and get as close as possible to the real performance or the problem. And not stop half-way and get the EU to cover the rest in his head.

In many instances the EU is shortchanged in a manner he is not even aware of.  He is required to further process the data given to him. Essentially the output is not directly usable.

It would be interesting to do this simple check on any system – how many of the outputs are directly usable, immediately supporting decisions made? It may reveal pockets of IT inefficiencies, besides throwing up redundancies and inconsistencies in the output.

For reasons of clarity a minor detail was missed out in the above scene: the EU pointed out while a break-up of daily kilometers run is a simple matter, the fuel consumption in the day could not be broken up under those heads. And, hence, Fuel Efficiency could not be computed under the different categories.  For a moment C’s efforts to push for greater proximity to the performance appeared stymied. He suggested: start with reasonable targets for Fuel Efficiency for each of the four heads. For the actual kilometers run over several tank-fills, compute the weighted Fuel Efficiency, applying the targets to these kilometers. Now the weighted target Fuel Efficiency is available for comparison to the actual Fuel Efficiency realized.

End

.

.

Credit: openclipart.com (Anonymous)

Read Full Post »

Scene I:

Anon Reunion

The Consultant (C) was charged with the job of providing an extra level of oversight to the projects under execution. He had called a meeting of the End User (EU) and the Techie doubling up as a Business Analyst (BA) to inquire about the status of the project.

The company operated a fleet of vehicles that traversed the length and breadth of the country. The project was to develop a software application: ‘Daily Fleet Movement (DFM)’. This was conceived as the first of the several modules they needed to operate and manage the fleet.

The BA reported on the status: The EU and he had agreed on a set of reports – the primary output of the system (screen based or in print) to be generated on the vehicle and the driver with facilities for filtering on dates, towns, etc. He further stressed, in C’s presence, on the finality of the report content and formats arrived at after lengthy iterations. This, he believed, was necessary especially in view of an earlier experience where the project dragged on inordinately with changes to the output coming from the EU right up to the final stages of the project. The solemnity that BA was imposing on the occasion made the EU nervous about what he was signing off. So he had questions and concerns on what he would get to see from the application and if the same debilitating ‘holes’ and the painful iterations of the earlier experience would recur this time too.

While this discussion on the formats and the flexibility in retrieval was talked about, C jumped in with a question for the EU:

‘Well, you certainly need these reports and you’ll get them.  But I’ve a concern.’

Both EU and BA stopped in their tracks and looked at C.

‘I’m sure you’re tracking and managing the operations on the basis of a few parameters?’

‘Most certainly so, how else would one go about?’ The EU didn’t say it, his body spoke.

‘How come these don’t get mentioned in your discussion?’

‘Not right. You heard us talk about the ‘Vehicle Usage Report’, the ‘Fuel Efficiency Report’

‘Do you realize you’re asking for Vehicle Usage Report and our friend here is giving you a big daily log of which vehicle plied where? Exactly what you’re asking for. While the name of the report is comforting, what would you do with it?’

‘What’s wrong with it? I’ve always got one compiled. I can find out, for instance, how many kilometers did a vehicle cover in a day.’

‘So you’ll find out, I’m suresomehow from this log. Though I don’t know how. Now don’t you want the software to compute and report the same for your ready use instead of you ‘finding out’?’

C turned to the BA: ‘Just as I suspected. More often than not, the output generated by an application stops short of what a EU must have. And the EU fills up the gap by some means, sometimes even erroneously, watering down the benefits of automation. He doesn’t know to ask. If that’s not short-changing the EU…’

And to the EU: ‘The few parameters that you need for tracking and managing the operations are called Key Performance Indicators (KPI’s)’

Again the look of ‘What’s wrong with him?’

‘My submission is: You tell the BA you need these KPI’s to be computed and reported. Let him start from there and figure out how they’re computed and how could they be presented for effective communication. You don’t tell him: ‘These are the reports I need, here are the formats, now can you get on with it? And you don’t ‘find out’

The BA and the EU agreed to take up one KPI – Fuel Efficiency – and adopt this approach to design the report afresh from first principles.

End of Scene I

Not to be laughed off. Many sessions of requirements gathering proceed along the above lines, especially in smaller and not-so-IT-savvy shops. Two common reasons: a) The EU is very assertive and/or b) The BA lacks the necessary skills to set the right start for the discussion and take it to conclusion. It is a misconception that a techie or a UX designer with his wireframes is adequate to tease out the business requirements.

So what we have nett nett is the patient telling the doctor: ‘I know what ails me, Doc, give me these pills.’

The Scene II gets even more interesting when they meet again to apprise C on the output they had designed to report on Fuel Efficiency. Once the approach was clear, now arriving at a design was a pretty straight forward exercise.  Right?

Please wait for Scene ii to appear where C continues his review of the design presented to him, making a point or two of far-reaching impact.

End

Read Full Post »

Greg Satell in an article in Digitaltonto talks about the challenges faced by the Millennials in US. That is the post–Generation X, born between 1977-1998.

“However, this new generation has a problem. They are coming of age at a time in history when great technological forces are converging to democratize the use of complex and powerful machines, which is giving a false sense of validation to their youthful exuberance and making it easy for them to ignore hard truths. Here are some of them, unvarnished.”

One of the hard truths in his list is skills.

“I think every generation has its challenges. The problem with this one is that they are so misunderstood. Everybody seems to think that they are too techie and should get more “real” when in fact they aren’t nearly technological enough.”

I can see many of you are already on your feet even if you’re not the target of Greg’s truths. But wait for a moment, let Greg explain what he means by the above rather summary indictment.

“…Truth #2: Your Skills Are Substandard

You are, it must be said, not alone. The United States comprises but a small fraction of the world’s population and most of your youthful compatriots live outside of it. I’ve spent most of my adult life overseas and have had the opportunity to know many of them well.

In Ukraine, I developed a training program that ushered over two hundred young people into professional life and I interviewed each one personally. The typical candidate was about 20 years old, spoke five languages and could do econometric modeling. The starting salary was $200/month and we never lacked applicants…”

Ah, that’s what comes out of Ukraine. I’ve heard similar stories in the past from Lithuania and Latvia too.

How does our crop of young IT professional fare in comparison?

Our IT services organizations are not complaining – they seem to be getting exactly what they need. The info-age workers are happy with the cash and the bash and so are the factories churning them out by the clock.

A cozy party…Please Do Not Disturb.

End

.
Source: digitaltonto.com; openclipart.com and wackywits.com

Read Full Post »

One of the biggest challenges in building software and systems and least appreciated is about drawing the line on what features are in and what are not. Whenever you catch the smell of feature creep, call for this modern parable. Or even better, in the project kickoff held right at the outset when expectations, success factors and scope are discussed, it may be a good idea to take your audience to this story during coffee-break:


Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. “What do you think this is?”

One advisor, an engineer, answered first. “It is a toaster,” he said.

The king asked, “How would you design an embedded computer for it?”

The engineer replied, “Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I’ll show you a working prototype.”

The second advisor, an IT Analyst, immediately recognized the danger of such short-sighted thinking. He said, “Toasters don’t just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don’t look to the future, we will have to completely redesign the toaster in just a few years.”

“With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard- boiled eggs, poached eggs, fried eggs, and various omelet classes.”

“The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, ‘Cook yourself.’ The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs.”

“Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don’t want the eggs to get cold while the bacon is frying, so concurrent processing is required, too.”

“We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won’t buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message ‘Booting UNIX v.8.3’ appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook.”

“Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8 MB of memory, a 30 MB hard disk, and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!).”

The king wisely had the IT Analyst beheaded, and they all lived happily ever after.

End
.
Credit: Unknown Usenet source (edited), wackywits.com, openclipart.com (seanujones) and public-domain-photos.com.

Read Full Post »

I’ve heard rumors like this emnating from the corridors of government offices. This is a new one for me reported from an IT company – good for some chuckles:


.
Five cannibals get appointed as programmers in an IT company.

During the welcoming ceremony the boss says:

“You’re all part of our team now.

You can earn good money here, and you can go to the company canteen for something to eat. So don’t trouble the other employees”.

The cannibals promise not to trouble the other employees.

Four weeks later the boss says:

“You’re all working very hard, and I’m very satisfied with all of you. However one of our female developers has disappeared. Do any of you know what happened to her?”

The cannibals disown all knowledge of the missing developer.

After the boss has left, the leader of the cannibals says to the others:

“Which of you idiots ate the developer?”

One of the cannibals raises his hand hesitantly, to which the leader of the cannibals says: “You FOOL!

For four weeks we’ve been eating team leaders, managers, and project managers and no-one has noticed anything, and now YOU ate one developer and it got noticed.

So from now on please keep away from any of those guys.”

End

.
Source: EnjoyTheMasti and amazing-animations.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 »

Coming back after a long hiatus.

Many products and services are not bought by customers for they think ‘it’ won’t happen to them. This is the ‘Invulnerable Customer’ syndrome. This is not something new in the market segments of Insurance, Healthcare, Vehicle and Home Safety. It is in this context, the following interesting story comes from Roger Dooley writing at: http//www.neurosciencemarketing.com/blog/ articles/invulnerable-consumers.htm

“…The prescription for this marketing dilemma was found in a hospital, of all places. Can you imagine a group likely to be more careful about hand-washing than healthcare professionals in hospitals? Not only are they well educated about hand hygiene practices and the reasons for them, but they actually see patients who suffer from the same kinds of infections that can be transmitted when hands aren’t washed properly. Surprisingly, according to Penn psychologist Adam Grant, even among health care professionals hand-washing practices leave a lot to be desired.

Grant attributes this behavior to a feeling of invulnerability on the part of the healthcare pros. This feeling is amplified by the fact that they are exposed to germs often in the course of their work but rarely become ill. So, Grant conducted an experiment by placing a sign next to a hand hygiene area. One version of the sign read, “Hand hygiene prevents you from catching diseases,” while another version said “Hand hygiene prevents patients from catching diseases.”

Bearing out the invulnerability theory, the sign that pointed out the threat to the healthcare professionals didn’t change their behavior at all. In contrast, the sign that changed just one word but pointed out the danger to patients (a group seen as vulnerable to disease) increased the use of soap and sanitizing gel by 33% and boosted the probability that the healthcare pros would wash their hands by 10%. (See Science Daily and the original paper. HT to Wray Herbert.)

Many products are sold on the basis of self-concern, and rightly so. But, if that’s not working with some customers, alter the message to reflect the risk to others!…”

Well, Insurance companies are already on this track talking about protecting near and dear ones.

How about relooking at civic-minded injunctions that presently score nil impact and may even be distracting like:

‘Do not litter here.’
‘Keep Your City Clean.’
‘Do Not Cut Lanes.’ …

And, throw in visuals too for drama and numbers for emphasis. Well, at places, statistics on road accidents or the run-away population count do appear.

There are numerous other scenarios, I’m sure, where this principle could be tried out. For instance, should we apply to pithy time-worn injunctions in ethics?

While the above expresses it as a sales/marketing problem and a possible solution, let me point out a interesting manifestation of this principle of concern for others in an entirely different area: Information Systems!

I recall how we designed an application for an insurance company. Our UI design experts claimed their design had taken care of many things: colors, images, etc. Shorn of these frills, the main business was done on a screen displaying a form to be filled in by the customer. And on this screen, the usual UI gimmicks meant very little as it was a plain and simple form-filling exercise. How can the user-experience be improved at all in this all-too-common context of form filling? I wasn’t happy with what we came up with though I could not put my finger on how it could be done better to push our experts.

That’s when I got onto the net and zeroed on software solutions providers in the same space. And I found my answers with one vendor! He had used two devices that vastly improved the interaction, I thought:

a) He called the column that we had titled as ‘Persons to be covered’ as ‘Beneficiaries’. A small thing, you would say. But the word ‘Beneficiaries’ is much more positive encouraging the user in what he is doing for his near and dear.

b) More importantly there was a small pie-chart that showed what is the coverage he is buying presently and what he has left out, prompting him to think about including more. The dreary form-filling chore now has a little more punch of value to the user as well as the service provider!

While these may not be the ultimate in what could be done, it certainly gives you a flavor of what could magic could be wrought by an imaginatively designed IS application. A small sliver of what is meant by IT as a business-enabler.

Let us not settle for less with our designers!

End

More interesting stuff at http//www.neurosciencemarketing.com.

Read Full Post »

 

(contd.)

 

Before we get to the core, I must mention about an interesting solution that kind of addresses concerns voiced about mixing up business logic in Processing Reports. Recently I came across a case study where a MNC had the usual problem of reporting from a variety of dispersed and disparate sources such as Excel sheets, legacy ERP systems, etc. The reports were quite complex. And, there was no single container to host all the processing logic. The Organization deployed an ETL software that fitted the bill and loaded the data into a Reporting Database! This SQL database was used purely for reporting purposes only. On this database, they also built their business logic as a uniform interface and pulled out their reports. This architecture certainly fixed the problem of scattered business logic. The data is still transactional and the database was not a data-warehouse kind.

 

Even when there is a container application like an ERP instance to host the business logic and the reports, this solution may become an alternative meriting serious consideration when the reports are quite complex. The downsides to this approach are: a) introduction of an intermediate step and possible time delays b) the output business logic is still separated from transaction related business logic c) views may be generated from the ERP instance or from the Reporting Database – the challenge of making them look alike and d) the reports have to be coded explicitly instead of using the ERP-native report-generator. And, all the associated maintenance issues.

 

How would I, as an IT professional (not as a management consultant), go about if I need to rationalize the output system of reports (and views) for maximum business impact? An exercise that may be applied to a system of reports that exists already or to reports that are being planned for a new application. While some steps are obvious, some are not. The obvious steps (especially in a IT-mature organization) are included here for completeness:

 

         Compile a list of reports that need to be subjected to this exercise of rationalization.

 

         Develop the business purpose of each report. Weed out duplicate ways of stating the same purpose. Qualifiers are useful in generating variants of a business purpose: Shows payment-pending invoices by Region, Shows payment-pending invoices by Office, Shows payment-pending invoices by Customer, Shows payment-pending invoices by Product-line, and Shows payment-pending invoices by Period, etc. 

 

         One may or may not have the option of meaningfully (re)naming the reports pointing to their purpose.  

 

         Do a preliminary check if the information content of the report supports the business purpose. The depth of this check depends on IT professional’s knowledge of the business and best practices in the domain. 

 

         Generate a reference matrix showing reports and their users. These users are grouped under their functional silos: Finance/Accounts-Receivables, HR/Payroll, etc.

 

         Classify the users for each report: He may be a ‘direct’ or ‘responsible’ user using the report for managing his operations; Or a ‘supervisory’ or ‘accountable’ user using the report to review the operations with his team. An ‘informational’ user is merely informed by the report. This simple classification is adequate for most purposes.

 

         Revisit each report with its direct and the supervisory users. Validate the business purpose, the information content and the format – the format aspect of a report, though quite important, is not pursued further in this blog. There are some interesting and powerful opportunities at this step to restore true value: a) Check if the report is directly used by the user as such or if he does further processing to make it usable for its intended purpose. Very often, it is found, user makes some additional massaging to the numbers in the report: a missing summary or computing a ratio or a KPI, a comparison with a past period, etc. A significant efficiency contribution would to be to cut out this massaging b) More complex massaging is usually carried out in Excel. Can this be done away with or at least seamlessly integrated? c) This is an opportunity to ‘hard’ reconcile the supervisory perspective of a business aspect with the direct operational perspective. A no-brainer simplification is to ensure the Transaction Report goes to operating personnel and the related Summary Report goes to supervisory personnel and d) Review the list of ‘informational’ users of this report and reasons for their inclusion or exclusion. Mark candidates for inclusion/exclusion.

 

         These done, take the discussion to the broad plane of user’s responsibilities how the reports support those responsibilities. This would reveal those ‘missing’ views and reports – potential for creating value. It is not unusual to find system outputs not covering the entire breadth of user’s responsibilities or his KPI’s.

 

         Review with each informational user, the list of reports he receives and his thoughts on inclusions and exclusions. Go back to the direct and supervisory users of the reports to finalize the ‘informational’ inclusions and exclusions. At this point, the report may even undergo some changes to suit the needs of the informational users or some missing reports may again be uncovered.

 

         Note that a report with multiple ‘responsible’ users especially from different functional silos strongly indicates multiple business purposes stated or omitted.  And a report with multiple purposes is a strong candidate for splitting.

 

         Multiple reports for same or related purposes are good candidates for merging. When the business purpose is quite specific (not generic like ‘highlights cost-overruns’) their distribution lists could still be different if they present different perspectives. Do they?   

 

         Develop an exhaustive list of abnormal events that could occur in each functional silo and across silos. Relate each event to the Exception Report that shows it up. This may reveal events with potentially serious consequences being passed through. It is also important to check a) if these events are pointed to at the earliest possible instant after their occurrence b) the reporting intensity is commensurate with the degree of abnormality and c) recipients of the reports include all users concerned with the origin of the events and the organization’s consequent responses. Without sufficient care here, process breaks could severely impair the organization’s ability to respond.

 

         A report-type view of the system of reports also throws up useful but gross pointers to some imbalances. Absence of Log Reports may readily indicate holes in statutory compliance or weaknesses in security audit procedures and in some cases even recovery capabilities. Few Exception Reports may point to, as we have already seen, a failure to flag down significant abnormal events in the operations and the ability to quickly respond. Are the operating and supervisory personnel adequately (not overly) serviced, covering their major responsibilities and accountabilities with Transaction, Processing and Summary Reports? Similarly, are business purposes adequately and powerfully supported? Are functional silos bridged optimally?

 

It would be interesting to see if some principles of project portfolio management could be carried into this exercise of rationalizing system outputs. 

 

Like we have rigor in design of database (ERD, normalization…), this appears to be a ripe candidate for proposing a formal model and practice both for design and importantly for ongoing review.  

 

In summary, rationalizing the system outputs has ready pay-back in terms of managerial effectiveness by: a) re-engineering the outputs for maximum out business impact and operational efficiency b) weeding out redundancies in outputs as well as their distribution c) discovering opportunities for filling gaps and creating value for the business and d) making up for debilitating process breaks.

 

Importantly, note that IT application boundaries, their technology platforms or deployment architecture do not pose any problems in carrying out this exercise. Since change is constant with businesses, this cathartic effort is not likely to be single-shot.  

 

A potential service offering of real value from CIO’s stable? It has a quick turn-around and for most part may not need face-to-face or travel.

 

(concluded)

 

Read Full Post »

Older Posts »