When an important member of a project team is moved out to help with another project for meeting a tough schedule, it leads to an antipattern called the 'Domino Effect', writes Dr R Srinivasan

In the last article, we had discussed a few antipatterns under process management, in software development. As suggested by Osterweil in his paper, Software processes are software too, it should be borne in mind that the process is a very important umbrella activity in order to achieve a product with excellent performance meeting the specified function. Unfortunately, many-a-times people are not conversant with how to implement the right type of process as part of the development cycle and hence have to face unexpected pitfalls.

On the other hand it may also happen that an organisation, which is not well-versed in processes, may tend to adapt a monolithic process for all possible projects, whether they are big or small or of different complexities. Such a situation may also be felt necessary to reduce the time to market the products in the competitive world. The antipattern observed under this situation is called "One size fits all".

It has been pointed out by software experts like Moynihan, McCormick, Brown, and others, that in such an organisation the problems may be faced both before the decision of resorting to a monolithic process and after it has been dictated, to be adopted by all the projects in their pipeline. In the former case it will lead to schedule overrun as well as cost overrun. In the latter case, the consequence will be a project that might have a mismatched process. Both these situations will result in disappointment and shock as the organisation's plan to take the product fast to the market does not materialise and hence backfires on them. The solution is to have managers and developers who have good expertise in software development processes. It is absolutely necessary to recognise the type of development, choose the right type of software development life cycle with the correct process deployment at each stage.

The next antipattern to be discussed is associated with the case where, in spite of the utmost care taken by the project manager in planning and scheduling the project with appropriate resources, during the development stage it might slip in schedule and efforts. However, the management may insist on the planned delivery date ignoring all the project management processes. A lot of pressure will be put on the project team for implementation. As William Brown, et al, say, "Slipped schedules can generate project compression faster than water running through a sieve. Project compression creates a gap in the space-time continuum allowing the incompressible to be accomplished in the minds of management. It causes all logical, pragmatic, rational, reasonable thinking to fly out of the window."

This is the typical situation of Myopic Delivery Antipattern. There may be many reasons for getting into such a situation even though the original planning was good.
A typical case could be that a vital member of the team either falls sick or leaves the organisation without any notice. Another possibility that the company is likely to face, is due to a competitor that has hit the market earlier than anticipated. It will be much worse to implement any modification because of the fact that the project is at an advanced stage of the life cycle. A refactored solution for such an antipattern is really complicated unless the project manager and his team had taken the management as a stakeholder of the project right from the beginning.

We will now look at a different type of antipattern, where, in order to salvage one project from disaster, the management pulls out a vital person from another ongoing project. Thomas, McCormick and Brown illustrate this with an excellent anecdote saying, "Hey Rick, your project is doing great! Listen, we have decided to pull Ben from your team for just a couple of weeks to help out on Jerry's project. I know he's your best Java guy, but it's only for a little while, and Jerry's project really needs some help." The antipattern called Domino Effect may be due to the action either from the management or from one project manager who handles many projects at the same time.

With the objective of helping a troubled project, he tries to move the resource, with the hope that he can move it back to the original project. If several dominos are moved back and forth like this, the organisation will court disaster in many respects. The best solution is to avoid such movement of resources from an ongoing project to another one.

On the other hand, if the situation really warrants such an action, a thorough study with reviews should be undertaken with respect to the schedules of both projects, particularly looking at the consequential effects on the project that is going on smoothly, from which a domino has to be moved out to another project.

( To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)