Posts Tagged ‘Business Objectives’

One of my recent experiences.


A few days ago, I was at the pharmacy/chemist, my Family Warrant holder for years now.

Stacks of baby-food tins, packs of sanitary napkins and crates of bottled water reduced the customer space to a single file in the small shop. The short guy spotted me patiently waiting behind a lady unhurriedly examining the label on a diet kakra pack. He is one of the guys – there are two or three of them – filling my orders regularly over the last three years. I shouted out my usual order for insulin cartridges and some OTC items. He pulled them out one by one from the fridge, shelves and cabinets and piled them up on the counter, punctuating regularly with a ‘What else, Sir?’

I wasn’t sure if he remembered. Disregarding the awkwardness, I asked him for the Senior Citizen’s discount on the bill. Transaction completed, I stepped out.

Gone for a few minutes on my next errand, I remembered. I returned to the pharmacy, got the attention of the short guy.

‘Hey, you did not give me needles for the insulin pens.’

‘Sir, I asked you ‘What else?’ and you didn’t tell me,’ he looked hurt at my unfair accusation.

He didn’t suspect I would need the needles to get the insulin into my blood.

If this is my pharmacy, it is the same with the appliances store where we’ve bought for last 25 years and all other businesses we transact with. My government does even better – it needs me to have my ration card (used more for identity proof than for buying provisions through government shops at subsidized rates), PAN card for income-tax, Election Card for voting, Know-Your-Customer for some financial transactions and of course, passport for travel, not to mention telephone bills, electricity bills, cooking-gas bills, rent receipts, etc., etc. for identity/residence proof. I’m sure I’ve overlooked a few.

On my part, I’ve been remiss of one thing – on my next visit, I’ll find out the name of the short guy.

While on the subject, there is an interesting post from Bernadette Jiwa’s blog at thestoryoftelling.com that succinctly captures the essence of personalized service – her posts are always short, easy-to-read and jogs one’s mind. Note she is talking about organization consciously basing its entire service model on what it knows about its customer – it’s a lot more than customizing web pages on browsing history or profile data entered/collected or even CRM.


Credits: thestoryoftelling.com and hahastop.com

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?’


‘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.




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.


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.

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

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!


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

Read Full Post »

An earlier post on ‘Enhancing Values’ talked about some simple ways of enhancing the value of custom-made software. This post is also on the question of enhancing the value delivered by a software solution, with a slightly different perspective.

Projects involving development of custom-software are especially great opportunities to deliver significant and special punch for the business; something an off-the-shelf software solution often falls short trying to address the needs of the widest cross-section of customers with the commonest capabilities.

These opportunities are not readily served at the table – they need to be excavated. The efforts get handsomely rewarded when the business gains in real from exercising the punch.

Very recently there is an interesting experience of this kind illustrating the point being made.

The organization is into manufacturing or sourcing basic equipment and executing infrastructure projects using the same. It is rolling out ERP for the whole enterprise. In the pre-sales phase, the marketing function receives the requirements from the customer. It responds with a design that includes the specs of major equipments. When the customer order is received, these go as inputs to the R & D. R & D prepares the engineering drawing using a PLM solution, prepares the BOM and triggers other processes in procurement, manufacturing and contracting functions.

The PLM and the ERP are not tightly integrated. The PLM generates a BOM for a drawing. The Codes for the Items in the BOM would have to be appended manually before the completed BOM could be uploaded into the ERP.

A simple application was needed to close this process gap.

The requirements were outlines as: the BOM would be imported into the application and would be processed for all Items contained in the BOM. For each Item in the BOM, the application would search its database (the Item Master would be periodically downloaded from the ERP; a real-time interface was not envisaged) and would produce a standard Code for the Item by matching the attributes specified for the Item in the BOM against the Item Master. For example, an electric motor may have its type, horse-power, number of poles, etc. specified as attributes. These would be used to obtain a match in the Item Master and retrieve the Code for the standard Item. For sheet-metal Items, the set of attributes was different. Once all Item Codes are appended, the BOM would be exported in a suitable format. This would be uploaded into the ERP by the ERP Support Cell. The process is complete with the filled-up BOM available for all down-stream processes.

Continuing with the requirements: The exception handling was a little more involved – when there was no match and the Item was new. New Item Codes are created in the ERP by a designated member in the ERP Support Cell. He sits a few tables away from the R & D section. How he creates new Item Codes is known to R & D. So the R & D takes it upon itself to design a Code for the new Item using his logic and send it to him as its recommendation along with a duly filled-in indent for creating this new Item in the ERP. In the meanwhile, assuming the new Item Code would be created in the ERP, R & D completed its BOM with standard and recommended new Item Codes and exported the BOM ready for import into the ERP.

Taking the simpler issue first: The last part of the requirements needed to be cleaned up. The process of R & D designing a new Item Code and proactively exporting the BOM with these new Codes plugged in is error-prone and hence cut out. In the revised wrinkle-free process, the R & D merely forwards its indent for a new Item Code to the member in the ERP Support Cell and waits for him to create the new Item and download it for this application. In the second run, the application will find now the Item Code. In this way the logic for creating a new Item Code could change independently without any impact. Of course, now it means that the BOM cannot be completed until the process of creating the Code and downloading the Item Master is completed. Multiple iterations could be avoided if in the first run itself, a consolidated indent for all new Items is generated to be processed by the ERP Support Cell in one shot. In this revised process all Codes are assigned by the application without any manual step.

Now to the nub: The requirements even at this stage miss an important business opportunity – is it not possible to negotiate on the BOM? After all, the BOM made up for over 70% of the total cost. Any savings on the BOM cost would reflect significantly on the last line. For every Item in the BOM, match or no match, there could be opportunities for a) substituting one Item by a cheaper equivalent b) use a similar Item (may not be an exact match) readily available in stock c) use a similar Item (may not be an exact match) from a more reliable supplier etc. etc.

When this important possibility was pointed out, user expressed legitimate fears of abuse of the negotiation capability to cut corners compromising quality for the customer. Negotiation on the BOM need not always mean dilution of specifications or quality. There could be genuine opportunities to affect some savings. The kinds of permissible negotiation and approval levels may be specified to guard against abuses. The second objection was: the equipment specs are laid down and costed by the customer-facing marketing function as part of its solution to meet the customer’s needs and hence are not negotiable. While this may be true, it is quite possible that certain attributes of an Item are non-negotiable while the other attributes are, leading to a few possibilities.

The user is still not very convinced about negotiating the BOM, but has promised to give it a deeper thought. If the user finally finds legitimate room for negotiation, the implication for the application is that it would be required to present a palette of exact (if there is one) and approximate matches when the Item Master is searched using a set of attributes. It could also indicate the impact of making a specific choice from available alternatives. It may also mean that the application may have to be aware of many other things like Work-In-Progress, etc. when it performs the search.

An analyst must tirelessly strive for providing in the software solution aggressive support to business objectives when he is engaged in the process of collecting requirements. A feel for the business domain certainly helps. Anything short is a missed opportunity!

Read Full Post »


In these times, any organization responds by tightening its belt, by putting those new projects on back-burner. In its place, usually a number of quick-yielding initiatives are launched that are limited in scope, focused on results and often cut across functional silos. More often than not, these initiatives go below the IT radar and their roll-out has little IT support. In these times, this is a great opportunity for IT to step forward and support these initiatives effectively.


Let me present one such example of how IT made itself quite useful.


The organization is in the business of executing (fixed priced as well as time-and-material) software projects for its customers by deploying its software professionals on the rolls. It had a top-heavy structure. For making it more even-keeled and to reduce over-all costs of operation, a decision was taken to hire fresh-from-campus trainees (CT) in small numbers, induct them with adequate training and then staff them in projects. Intuitively it made a lot of sense to have some number of fresher recruits; they were skilled in contemporary technologies, they were high-energy’ed and performance driven.


The routiine HR reports did not have much to say especially about these trainees, whether the scheme was working and with what efficacy. Of course, it did show the cost per employee-month dropped somewhat in the monthly payroll. But what about the impact on the business?


For starters, IT decided to separately tag various batches of trainees inducted into the organization so that their performance could be tracked. There were two other models of hiring which were also concurrently in play. Some business-experienced, but not technology-ready professionals were taken in a Hire-Build-Deploy (HBD) model. These guys were sent out for intensive specialized training and brought back into the organization. There were also Lateral Hires (LH) who had some little experience and were a little ahead of the fresh-trainees in the learning curve. These lateral hires, unlike CT and HBD hires, were hired at any time of the year based on needs and not brought in batches; they were also not trained like the CT and HBD batches. These hires were tagged on a yearly bucket (example: 07 LH were guys laterally hired in the year 2007). So there were three different models and several batches of trainees/hires under these models that were uniquely tagged.


Now, IT created a few simple business-relevant views (and values) on these batches:

– How many months of billing each batch generated on an average in the first year and in their   second year in the organization (the tracking was limited to the first two years in the organization)?

How quickly did these hires become billable?

What kind of billing rates these hires realized?

Which Projects absorbed most trainees?…



Though the performance of the hires with regard to billing was not entirely in their own hands, nevertheless some useful pointers were obtained for the business. Expectedly LH did the best in over-all performance, followed by HBD and CT in that order. What was not expected was a detail: a LH candidate with one year total experience did better than an equivalent CT candidate with same one year experience. LH candidate perhaps showed the implicit advantage of the hiring process that, with prior wisdom, successfully matched the candidate’s profile to the demands of an available billing position.


Year-on-Year performance comparison of batches validated: a) the selection process was getting better in specifying and assessing skills and b) various improvements brought about in the induction training was paying off; and, it also pointed to available opportunities for doing even better. Projects that absorbed good amount of these hires presented both an opportunity as well as a risk of diluting quality factors for these customers, if overdone mindlessly. Clearly, the opportunity is for cutting back on the employee costs in the Project for the organization and passing on at least in part the gains to its customer too; and more importantly, how this practice could be replicated in other laggard Projects?    


To cut the long story short, these views were useful to the business to figure out a) if an initiative works for the organization b) which good practices need to be intensified and c) which practices need to be re-examined for better results. The prevailing enterprise applications do not support these over-night initiatives as well as required.


If only IT remains connected with these initiatives undertaken from time-to-time by an organization, there are plenty of opportunities for making a difference to the operations in terms of providing actionable insights and value. Its cross-functional vision enables it to support these initiatives uniquely and quite effectively. Of course, it requires IT to actively scan and sense these possibilities and step forward unbidden to offer active support. The opportunities may not come their way cut and dried and laid out neatly on a plate.


All of these apply even during ‘peace’ times.


This way, IT is in Business, good times or not!

Read Full Post »


Let us go back to the order-entry example and its (single) business objective of reducing the time taken to enter error-free orders. We had developed a partial list of actions for assuring performance with regard to this objective, on two separate threads:

Business Execution thread:

– owner: customer, action: train end-users on orders and their entry.

– owner: customer, action: take up some process reengineering and rationalizing.

– owner: customer, action: make available end-users for training.

– owner: customer, action: adequate bandwidth to be provided to connect up with the back-end order-entry system.

IT Execution thread:

– owner: software service provider, action: train end-users on the new solution.

– owner: software service provide, action: design lightly loaded screens, minimize server visits…

– owner: software service provider, action: make the screens intuitively obvious, minimize clicks for main flow, use technologies like Ajax for rich user interface, generate meaningful error messages, provide useful defaults, drop-down selects, auto-fill, etc. to reduce data entry effort.

– owner: software service provider, action: include in requirements and design the feature to save a partially filled order; also it should be possible for another authorized user to later complete the partially filled order.

The customer’s organization owns the Business Execution thread while the IT Execution thread is driven by the service provider. In this example, there are only two broad organization-level ownerships shown. In general, there could be more specific roles, drawn from the stakeholders and their organizational structures.

Also, the actions read generic in the above. In real, they could get quite context specific in terms of the intents and measures (see examples below).

Some of the actions directly map as activities of a project plan. Example: training end-users on the new solution. And, some could go under SDLC guidelines for the project, gross or fine-grained. Examples: [A design guideline: the landing page should not exceed 60 kb]; [A feature-level coding standard: stored procedures handling multiple on-screen selections should use of table variables for simplicity and speed (this is fine-grained)].

Now, the guidelines strongly emanate from business objectives instead of degenerating into a huge ‘cut and pasted’ linear list. Even if the guidelines are already in place and not generated in this manner, it would still be useful to validate them along these lines to fill the gaps and weed out the unimportant. For instance, it may show that certain business-level failure syndromes may not have sufficient guidelines to protect – a gap to be plugged. It may also be possible to apply a sense of priority to the set of SDLC standards which always threaten to get prolific and often in mutual conflict.

Incidentally, an earlier post ‘Coding Standards – a chimera?’ spoke of the importance of relating the coding standards to architectural attributes and other keys. Here we are enlarging it to relate all SDLC standards as strongly as possible to business objectives which in turn form the basis for the said architectural attributes.

Preemptive planning of this kind significantly enhances assurance of achieving intended business objectives.

In summary, the submission made here is to recognize and plan in a Business Execution thread in mesh with the IT Execution thread which usually is all of a conventional project plan. This stems from conceiving a project to include the main purpose of achieving business objectives instead of limiting it to software deliverables as is the current practice. With it, the clear statement that business objectives have a greater chance of being realized only if both the customer and the service provider plan and work together from day one with an end-to-end vision. On this road, the SDLC standards stand out with definite prioritized purpose.

Extending the scope of a project beyond the limits of software deliverables is an opportunity for the service provider to provide tangible business value, fraught with interesting possibilities for ongoing engagement with the customer. If ERP roll-outs are planned and executed along these lines (not the whole nine yards yet), why not bespoke development?


Read Full Post »


More on the actions that go into Business Execution and IT Execution threads and some new opportunities for service providers:

In a typical ERP roll-out, most actions go into the Business Execution (BE) thread. There would be actions in the IT Execution (ITE) thread to install, configure and customize the solution. But these actions are driven by actions in the BE thread.

Should that not also be the case with non-ERP solution development and roll out? Since the solution is being developed and is not ready off the shelf, that happens to be an intensive set of SDLC actions. Nevertheless the interlock with the BE thread must be maximized so that course corrections if any are applied at the earliest point of time.  Obviously these interlocks must be purposefully arranged for productive use of the customer’s time and not be contrived.


There is this famous curve usually produced often in project kick-off meetings which shows the actions on part of the customer and the developer in a typical SDLC project, without formally identifying the two threads as we have done. The customer involvement peaks initially during requirement gathering phase, drops off during the design and coding phases and again perks up during the acceptance testing phase. This is more the case in waterfall execution and can be adapted suitably for other paradigms of development as well.


The traditional SDLC model does not stretch itself (while ERP roll-outs may) to cover successful roll-outs. This is a crucial activity and the solution developed morphs into shelf-ware if the roll-out is not handled with professional competence and precision.


There is an even more important question of whether the business objectives of the project as originally conceived by its sponsor are achieved thru the usage of this solution. This immediately implies a period of usage on part of the end-users after the roll-out.


The ERP world makes a weak attempt by way of a post-implementation audit service, while the traditional SDLC model completely disassociates with this question. So, between the roll-out and the audit, who is concerned with the progress made? Can it be left to the customer to drive this march without any inputs of professional expertise? What are those sign-posts for success and the failure syndromes? Shouldn’t there be a well-planned and sustained effort during this critical phase? Note this is different from the L1-L2-L3-L4 support of Application Management Services.


The plea made here is: this is a definite opportunity for the service provider to enlarge his bouquet of services and value he delivers to cover these milestones and the customer has some reassurance towards achieving the intended benefits.


Some mature customers even now do plan end-to-end and arrange for themselves assistance of this kind either from the service provider or from some other agency. In any case there seems to be a clear need for formally structuring the actions and defining the services and deliverables associated with the two milestones. And plan them in from the ‘go’. This can also lead to some risk-reward models for the service provider, once these services mature.


(More to follow)

Read Full Post »


A software service provider (applies to internal IT too) usually evaluates his own performance in regard to his customer’s projects on costs, effort and timeline. A project is considered successfully completed if the targets are met on these metrics. While a project may be successfully completed and deployed, it may not still achieve end-to-end business objectives set out initially by the project sponsor in the business case, for various reasons. The one reason is that often the service provider only sees the requirements detailed out to him and not the business objectives themselves. Could the project be planned more holistically if the service provider is exposed to the business objectives as well? Let us see how this could be done.


For example, consider the business objective: the time taken to enter an error-free customer order into the system needs to be reduced (metrics omitted).


For assuring performance in regard to this objective, it is translated into a set of actions necessary on part of the stakeholders.  These actions could be developed using any method. Here, we imagine the contrary, examine reasons and develop preemptive actions.  


Continuing with the above example of order-entry, the business objective of reducing the time taken to enter error-free orders may not successful because of one or more of the following reasons (alongside, a possible preemptive action to protect against this cause of failure is indicated and its ownership):


– The end-users (customer’s order-entry personnel) are not familiar with the business aspects of a customer-order especially about the changes from earlier practices (owner: customer, action: train end-users on orders and their entry).


– The types of customer-orders and their entry are too various and difficult to comprehend (owner: customer. action: take up some process reengineering and rationalizing; however, much of it could lie outside the scope in the current context of developing a software solution for order-entry).    


– The end-users are not trained on effectively using this software (owner: software service provider, action: train end-users on the new solution; owner: customer, action: make available end-users for training).   


– The system is sluggish in its responses when an order is entered (owner: customer, action: provide adequate bandwidth to connect up with the back-end order-entry system; owner: software service provide, action: design lightly loaded screens, minimize server visits…)


– The users have to do more work to get an order entered into the system (owner: software service provider, action: make the screens intuitively obvious, minimize clicks for main flow, use technologies like Ajax for rich user interface, generate meaningful error messages, provide defaults to reduce data entry effort…).


– If the order-entry is interrupted for some reason, user has to start all over again (owner: software service provider, action: include in requirements and design the feature to save a partially filled order; also it should be possible for another authorized user to later complete the partially filled order). 


The above list though not all-inclusive is sufficient for making the point.


Realization of business objectives in a project could be viewed as a combination of ‘Business Execution’ and ‘IT Execution’ threads. Actions such as rationalizing order types and their processing, training the end-users, etc. come under Business Execution thread while actions of SDLC and infrastructure kinds go under IT Execution.


Now the point being made is: a unified project plan must include actions from both the threads for assurance on the achievement of the business objectives, and their synchronization. Even though it is still only an assurance and not a guarantee for results, this holistic approach is likely to yield better end-to-end results. This is in sharp contrast to the current practice wherein the Business Execution thread is at best a diffused set of activities and ownership, and not tightly managed. And the business objectives are not very visible to the service provider.


It is not as if the all actions in Business Execution thread are owned by the customer and similarly all actions in IT Execution thread, by the service provider. Example: owner: customer, action: provide adequate bandwidth to connect up with the back-end order-entry system goes under IT Execution thread as mentioned earlier.


It would be nice if the planning tool allows the threads to be managed individually and collectively in a composite plan with all interdependencies coded.


Who manages the Business Execution thread? A simple straightforward answer is a manager designated by the sponsor in customer organization. Depending on the kind of activities on this thread, other variations are possible. In simple cases, the service provider’s project manager could assume overall responsibility, keeping in mind that the project management competency is what he brings to the table. Even now he manages actions that call for heavy participation of the customer: scope management, change management, risk management, knowledge transfer, testing and approving deliverables. This enhanced responsibility is clearly an opportunity for the customer to derive more value from the service provider and for the service provider to differentiate his services.


Regardless of who manages it, the Business Execution thread is recognized for what it is, planned and meshed with the IT Execution thread.


On the side of the business, it is no longer the traditional role of someone acting merely as the single-point contact for the service provider. It is a more demanding role of one who manages an important thread of actions in the project.


(More to follow)

Read Full Post »