features from fastrak consulting

click here for the features menu

Managing the TBT projectpixel.gif (807 bytes)

pixel.gif (807 bytes) When trouble brews
pixel.gif (807 bytes)
HOWEVER HARD YOU TRY, you’re going to end up with some problems on your project. One way of dealing with problems is to treat them as opportunities, but as one senior IT executive once told me, ‘my life is full of insurmountable opportunities’. Another way, is to follow a logical problem-solving process:

Problem definition
The major hazard in problem solving is ‘jumping to cause’ – assuming you know what has caused a problem without a thorough analysis. The correct first step in problem solving is defining the problem - being specific about what the problem is. What is happening? When is it happening? Where is it happening? With whom is it happening?

If the problem is particularly complicated, you might also ask: when, where, with what and with whom else might you expect the problem to be occurring, but it is not. When you know exactly what the problem is and what it is not, you can begin to narrow down the distinctive elements of the problem situation. You might also identify if something has changed that might have triggered the problem.

Identifying the cause
You may identify a number of possible causes of your problem. Test each one of these out against the facts. Does it explain why the problem is occurring with this but not that, at this time but not at other times, in these places but not other places, with these people but not others?

Performance analysis
Performance problems are particularly danger-ridden. It’s all too easy to jump to conclusions without assessing all the options. There are many possible causes for performance problems, many of which are nothing to do with the performers - the members of your project team. Depending on the cause, any of the following may be required to resolve a problem:

  • repairing, updating or replacing software tools and equipment
  • improving the physical environment
  • providing the appropriate level of resources – time, money, materials, labour
  • refining policies, methods and procedures
  • clarifying roles and performance objectives
  • modifying the job to better suit the aptitudes of the people involved
  • providing training
  • moving people who have no aptitude to learn the job to other jobs
  • providing more appropriate incentives
  • removing disincentives
  • providing more timely, relevant and adequate feedback on performance

Research conducted on software projects provides some interesting findings:

  • the single greatest motivator for software developers is the alignment of interests with assigned work
  • don’t try to motivate developers with cheerleading campaigns, impossible challenges or monetary rewards
  • productivity levels of developers who work in private, quiet, one or two-person offices can be as much as 2.5 times greater than the productivity of those who work in open work bays or cubicles

Corrective action
The first priority in any corrective action is to tackle the cause – the situation that created the problem in the first place. Without doing this, the problem will continue to occur and the effect on the project will get worse. If the problem has caused the project to get behind schedule, you will also need to take action to address this. Your options include:

  • adding resources: this solution will not bring immediate results as new people have to be found, orientated and integrated into the team; it also adds to your budget
  • increasing effort: assuming team members are already working flat out, this will usually mean working overtime, adding to your budget; this situation can only be sustained for so long, as tiredness and lowering productivity are inevitable consequences
  • moving completion dates: if the client will permit it and the consequences are not too severe, then this is an option
  • sacrificing product features: like moving completion dates, this is a way of ‘moving the goal posts’; you may reduce the scope of the content or cut ‘nice to have’ features

Beware of over-optimism when you revise your estimates. A 1991 survey of over 300 projects, found that projects hardly ever make up lost time – they tend to get further behind.

footer2.gif (845 bytes)
                                                     Fastrak Consulting Ltd, 1999. All rights reserved.                                Last revised 21/2/99