Retaining Customers During Down-turns

  

(Contd.)

  

Waste 2: Over-Engineering

  

In IT services there is a clamor for process models of all kinds. This is understandable because many activities related to software are mental in nature. Unless there is rigor of a model and a method, quality and repeatability are dicey. But one often sees a swing between two extremes: at one end there is an utter disdain for anything remotely resembling a process and at the other end processes of questionable value proliferate to severely impact production efficiencies. And very quickly disillusionment sets in, strongly reacting to the wisdom of processes.

 

As mentioned in other posts, right-sizing the processes with their underlying artifacts is crucial to balance the cost and benefit. A small sample of heavy processes: many simple projects can be tracked using a Excel sheet whereas for some reason, a pert/cpm kind of plan is prepared; an estimation model goes into excruciating level of details; defect classification codes confusingly overlap and run into multitude; activity codes on a timesheet are needlessly granular and overlapping; computing dozens of process metrics, not all of them relevant (see below); applying complex prediction models of questionable validity…

 

For some time, some projects in this organization were scrupulously computing and reporting a commonly-in-use metric of ‘Adherence to Schedule’. A little digging showed the projects were basically streams of defects to be fixed within a few hours to a couple of days at the outer. The status was jointly reviewed by the customer and the software team at the start of the following day and the plan for that day was agreed. If some defect did not get fixed on the previous day for whatever reason, it got done on the next day without generating any heat. The ‘planned completion date’ was being (re)negotiated daily. And a meaningless but feeling-good 100% ‘Adherence to Schedule’ was perpetually reported!

 

Mindless application of process models and heavy processes are more wide-spread in use than as exceptions. Pruning the processes and their artifacts to fit the purpose significantly cuts out waste.

 

To continue on other themes for reducing waste…

Retaining Customers During Down-turns

 

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

 

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

 

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

 

Waste 1: Over-Communication

 

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

To continue on other themes for reducing waste…

 

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

Jest a Minute!

This morning I received this ‘forward’ from my professor! Had to share it with all!

A new vacuum cleaner salesman knocked on the door of the first house on the street. A tall lady opens the door.

Before she could speak, the enthusiastic salesman barged into her living room and opened his big black plastic bag and poured out all the cow droppings onto the carpet.

“Madam, if I can’t clean this up with this new powerful Vacuum cleaner in the next 10 minutes, I will EAT all this dung!” exclaimed the eager salesman.

“Would you like chilly sauce or ketchup with that” asked the lady.

The bewildered salesman asked, “Why, madam??”

“There’s no electricity in the house…” said the lady.

MORAL: Gather all requirements and resources before working on any project and committing to the client…!!!

(With due acknowldgement to the unknown original author, thanks to Prof H B Kekre for the ‘forward’)

On Software Requirements Gathering and Business Objectives

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!

Best Practices of Progress Reporting in Projects

All projects send out status reports or progress reports to various stakeholders at some regular intervals.

This ubiquitous project artifact is often handled in a very routine manner without sufficient realization of what could be possibly achieved with it.

Here are some basic best practices:

1. It is usual to fill it up a progress report with planned activities versus completed (in part or full) in the period of review. In most cases, these activities by themselves may not be meaningful to the stakeholders. The report is much more useful to the stakeholders if milestones are set up that convey to stakeholders in their terms what is achieved at that point and the progress is tracked and reported in terms of these milestones (in addition to or instead of activities).

The milestones are thus meaningful pit-stops for various stakeholders towards achieving their business objectives. Taken together, they show a logical build-up of the project deliverables and progress to the final denouement.

For example, in the WAN project of the last post, a milestone of the kind ‘Training Infrastructure ready for cities A, B and E’ would make more ready sense to the manager of the Implementation Team (see point 8). Instead the progress report talked about the status of the WAN links to cities A, B, C, D…

Practice: Report progress with the help of meaningful milestones.

2. In a project of wider scope, there are several stakeholder classes. The progress report must cater to the interests of all these classes of stakeholders. For instance, in a SAP rollout project, it is easy to miss out the training interests. If milestones are majorly relied upon to communicate the progress, a simple mapping of the milestones to the stakeholders would reveal: a) Are there milestones to cover all classes of stakeholders? b) For a given class of stakeholders, do their milestones build up logically towards the completion?

Though any inadequacy in this regard is pointed out as a deficiency in the progress report, note that this is something to be taken care of in the project plan itself.

Practice: Cover in the progress report interests of all stakeholder classes.

3. Feel free to invent your specific format of the progress report based on the type of project, the concerns of the stakeholders and the stages of execution. One size does not fit all.

For example, consider a project where a development team is loaded with ad-hoc work-packets from a user community. Each work-packet is taken up by a programmer and completed in a few days.

If the traditional progress report format is used for this project, the report would contain perhaps one line per work-packet with its scheduled and actual dates closely matching. This is hardly insightful. In these types of projects, at any point of time, the capacity and utilization of the programming team is of more concern. So the progress report could show for the week the available resource hours and blocked resource hours and a pending queue of the work-packets.

In one such project, the work-packets were streaming in from multiple groups of users whose demands for service were often conflicting. There was no strong governance mechanism in place for arbitration on priorities. In this project, this report was used very effectively to realistically set the users’ expectations by making the backlog quite visible. Many potential conflicts of schedule were preempted much before they came to a boil.

There are times when the format of reporting the progress used in one phase of the project is not suited in another phase of the same project. For instance, when a project nears completion, it switches to the work-packet mode. Here the rush is to get as many items through work-packets covered before the code freeze. At this stage, it does not make sense to talk in terms of scheduled and actual activities.

Practice: Align the progress report closely with the project needs and concerns. It is ok to come up with custom formats and switch from one to another when the perspective changes.

(concluded)

An Experience With A Complex WAN Project

(contd.)

8. About progress report: The weekly progress report assiduously reported the status of progress on each of those 30+ links. On the question of training plans and readiness, the manager of the Implementation Team was asked the progress report did not alert him to the change of dates. His reply was: He glanced at, but not read through the progress report. It gave out too many details. All he was concerned with was ‘When would be the minimum infrastructure required to start the training would be ready?’ That’s a simple question for which he needed a date. And that was not easily read from the progress report!

So we seem to have designed a progress report which was more suited to the management of the project execution and did not make enough sense at least to this end-user. In planning short time-frame projects the tendency is to pack it with all the necessary activities completely overlooking the need to have milestones that are meaningful to end-users. Meaningful milestones are useful in checking if the project is broken down into logically steps and are powerful aids in communicating the progress of the project execution thereafter. There is a lot to be said about effective project progress reporting which will be taken up in a subsequent post.

9. Miscellaneous activities: Often while tracking the core activities of a project, some non-core activities could get relegated to the background. And in course of time these could get critical. For instance, while commissioning the WAN, it also requires some of the current links to be surrendered back to the SP. Though not critical, if this is not done in time, the Org ends up paying charges needlessly for one more quarter.

The project is only a week away from its end. Most links except for a troublesome one where connectivity is being established for the first time, are up and running. The integration of the routers, the firewall and the servers and testing the network are planned for the week ahead. A few changes on the way were taken in the stride: The Org decided, in a simplifying move, to locate all the servers at the SP’s new data center. In some cities, the Org’s offices relocated to new end-point addresses! Some fiber links in the design had to be replaced by RF links and vice versa. For some RF links the masts had to be pushed up to greater heights.

If all ends well as hoped, it is an effort that the Project Office can well recall with pride.

(concluded)

An Experience With A Complex WAN Project

 

This organization (Org) is rolling out SAP to be accessed from 30+ cities. It was already working with a Service Provider (SP) for hosting its enterprise servers and had outsourced its WAN from the same SP. The SAP roll-out meant upgrading the WAN and leasing more space for its SAP servers. At some remote locations, connectivity was being established for the first time by any SP. An additional complexity was introduced by the SP by offering to host the SAP servers in his new data center while the current servers (mail, etc.) were retained in the old locale at least for some time.

 

This was seen as a Project to be completed from start to finish in about 12 weeks including the transition of the enterprise servers to the new data center, under the management of a Project Office. The third parties involved in the Project: the main SP, his subcontractors (visible to a very limited extent), computing and network hardware suppliers and SAP implementation partner. There are some state agencies to deal with figuring as Basic Service Operators. Also some statutory clearances from state bodies have to be obtained for erecting RF masts. The in-house entities involved were the various offices (30+), the SAP implementation team (core group of users in the Org) and importantly the Procurement function for ordering equipment expeditiously. There are business-partners who have to arrange for their connectivity with the SAP servers.

 

This Project brought out in sharp focus a few crucial aspects of Project Management:

 

1. Firstly the Project posed a challenging problem of coordination and communication with multiple vendors on one side to whom the SP had subcontracted the field work of installing WAN infrastructure and the Org’s various remote offices on the other side. The incidents were not uncommon of contractor’s men being refused permission to erect a mast or lay cables by the office, the reason being the intimation had not reached from the Project Office to a specific person in administration function of the office. Or, the contractor’s men were landing at the office on a Sunday when the office was closed. The initial strategy to address this problem was to beat the SP during Project Reviews with the need for closer coordination between his team and his subcontractors. It simply did not work on the ground owing to the multiple levels of subcontracting and at the lowest levels the subcontractor’s men were not capable of resolving problems of communication on the spot. They were easily thwarted. Things improved only when the Project Office handled the problem of coordination and communication with its own offices through a heavy dose of communication about the Project and how vendors would come into office premises for purposes of installing infrastructure and they should be allowed to work without any impediments.

 

2. The importance of communication across silos in the Project Office itself. The Team overseeing the readiness of the data center had accepted a staggered schedule from the SP for augmenting the power supply at the new data center. Another Team was coordinating with the hardware supplier (also the SAP implementation partner) for the installation of SAP servers. At the time of installation, the hardware supplier insisted on switching on all servers at the same time in a cluster thereby demanding full power. This meant a delay of a few days until the power supply was fully augmented to final specified levels. The staggered schedule that appeared to be a smart thing to do to gain time at one time, did not work out eventually. Perhaps this could have been uncovered earlier if the two teams had interacted on the plan that involved building up the power supply in stages. Of course the Team interacting with the hardware supplier missed capturing the fact that all of the power specified would be needed right from the outset. Not to mention an iteration and loss of a few days due to incorrect understanding (On whose part? Not resolved yet!) of the required rack space for the servers.

 

3. The SP himself was probably not used to reviewing detailed plans with his customer in the manner it was done in this case! His plan for laying a fiber in city A was different from that in city B though the activities in both cases were almost identical. The number and description of activities did not appear to be standardized. The Excel based plans did not sequence the activities rigorously either by time or by location. So getting a picture of where the project was during the review, was not easy. These were partially corrected subsequently.

 

The item-wise planning and a weekly time-consuming review had to be accepted by the SP after he badly missed some deadlines owing to some subcontractors’ non-performance. This level of planning details was not insisted upon by the Project Office initially.  

 

4. The SP’s plans showed activities some of which were several weeks long. The SP had to be persuaded to break up the plans with greater granularity consistent with the over-all 12-week time-frame for the Project.

 

5. For risk mitigation, there had to be independent ways of checking on the progress of the Project. Intermediate points in the Project Plan were carefully selected which would allow a physical check by an Org representative on the progress of the Project. Example: receipt of a mast at site, power connection at a remote place, router-to-router check of a segment, etc. This provides reassurance that things are happening on the ground as claimed during the review.   

 

6. The Project reviews takes place with the SP in the Org’s Project Office. The Procurement function joined the reviews with SP to be sensitized about the urgency in procurement of networking equipment and issuance of individual PO’s to the SP under an umbrella PO. This worked quite well as the Procurement function was now for expediting the Project. The intervening Christmas holidays have delayed the order release and execution for the supply of networking equipment.

 

The SAP implementation team however did not participate in the reviews.

 

Similar reviews do not take place with the other third parties involved in the Project.

 

7. Back to communication. The Project Office had originally given a date of 31^st Dec for the entire infrastructure to be ready for use against the final go-live date of 1^st April specified by the SAP Implementation Team. When it was delayed for various reasons to 31^st January (largely due to deadlines missed by the subcontractors of SP), the Project Office was not greatly worried because it was still sufficiently ahead of the go-live date. What was not known to the Project Office was that the Implementation Team had made some revisions to its training plans and now it had scheduled batches of country-wide training from Jan 15^th assuming that the infrastructure would in any case be available from 31^st December. Only a belated meeting between the Project Office and the Implementation Team in mid-December revealed the conflict of time-lines. The training had to be put off to last week of January.

 

This gap in understanding the dates was in spite of the weekly progress report issued to by the Project Office to all stake-holders! This and a few other aspects are the subject matter for the next post.

 

Despite the snafus the Project Office is doing a great job of managing the SP and other parties towards successful completion of the Project.

 

(To be Contd.)

IT Digs In!

 

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!

Developing Applications for Public Service

 

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.

Migration Project Methodology – under the hood

 

(contd.)

 

Let us continue with the remaining steps in putting together the methodology for the core process of migration.

 

6. The Estimation Model is simply derived from the Transformation Model by putting down the time required for carrying out each step in the Transformation Model. Steps of (b) (only those not handled by grep-like utilities) and (c) kind, being manual, would be time consuming. Any inaccuracy in estimation for (a) kind of step will not significantly impact the over-all estimates, being tool-driven. 

 

7. Finally put together the Process Model for the project.  The Process Model is like a kitchen-book recipe for carrying out the migration. It lays down the entire conversion in terms of a sequence of steps cataloged in the Transformation Model to cover all instances of all code-classes in the source context.

 

A sample section of the Process Model for migrating a module ABC shows the following sequence of steps cataloged in the Transformation Model, limited to migrating a set of ASP code-class instances of the module ABC:

 

d.1: Use an identified tool X to convert 10 ASP pages of the module ABC. This is a step of (a) kind.

 

d.2: Use grep on these converted ASP pages to handle instances of change-unit-classes: 1, 3 and 6, a step of (b) kind not handled by the tool X.

 

d.3: Manually scan the converted pages to identify instances of change-unit-classes: 2, 4 and 5, again not handled by tool X or grep-like utilities in steps d.1 and d.2. Note manual scans are not explicitly included in the Transformation and Estimation Models. Also note that sometimes, a grep-like tool may also be used to flag these instances even if the conversion is done manually, thereby averting this manual scan.

 

d.4: Manually convert in all the 10 ASP pages, the flagged instances of change-unit-classes: 2, 4 and 5 as per the transformations cataloged in the Transformation Model.

 

In general, one or more partial or full manual scans of source or target code-class instances must be provided in the Process Model for: a) detecting instances of change-unit-classes that are not handled by the tools or by grep-like utilities b) to cover some special situations c) to look out for new change-unit-classes not listed in the Transformation Model and d) to check the target after conversion. Some over-all scan rates are assumed and factored into effort computation.

 

Note that the efforts required for this piece of migration in the Process Model could be computed, given the Estimation Model, and if the number of instances of those change-unit classes (2, 4 and 5) across the whole set of 10 ASP pages which need to be handled manually in step d.4 are known (not considering d.3 for simplicity). This is the key to estimating efforts in migration projects. In simple terms, find out all instances requiring manual conversions and what is the time taken for converting an instance.  This exercise may also be called as Impact Analysis. At project execution time, Impact Analysis is obviously done exhaustively covering all instances of code-classes to achieve error-less migration.  Whereas at the time of submitting a proposal or initially planning the timeline for the project, Impact Analysis is often done on a representative set of code-class instances and the results are projected across the complete set of code-class instances comprising the source application. Herein lies the serious risk of going wrong with the effort estimates. 

 

There is an important question that we have not addressed yet. Given the source context comprising numerous instances of many code-classes how do we sequence our steps in the Process Model? Note that the other two models, Transformation and Estimation Models, do not address this question.

 

Let us think of the migration project as made of migration units representing chunks of migration which may be progressively carried out and even verified. These chunks could be organized by function. For instance, a set of Oracle Forms in Order Entry or a set of web pages of Product Catalog in an e-commerce site, or they could be by code-class; for instance, all asp pages, all the code in data access layer, etc. It is usually a mix of both approaches. With the former, a migration unit has instances of multiple code-classes to be migrated. For instance, migrating a set of JSP pages would mean migrating the JSP pages themselves, Java beans used by these pages, possibly the CSS, etc.

 

The function-wise approach makes it possible to validate the migration methodology, models and tools early in the project. Once validated, migration could now be undertaken code-class-wise until sufficiency is reached to take up a function-wise migration and switch back and forth. Or, any other mix and sequence of the two approaches. 

 

We have, in the above, successfully laid out the key steps in the migration methodology which is neutral to technologies; and its principles are applicable to a wide range of migration projects: upgrade of infrastructure systems like mail, platform migration of application systems and even ERP version upgrades.

 

This piece focuses only on the core methodology of project execution. It does not cover initial phases like Inventorying, Pilot for validation and estimation or the closing phases like Testing, Data Migration, Cut-over or the pre-project phases of Initial assessment, Preparing the project proposal, etc., all of which are also rigorously methodology-driven.

 

(concluded)