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…

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)