Introduction
 
This article is the second of two focused on problems arising from the IT cycle. The first piece, which may be viewed here, talked about what can sometimes be the unfortunate aftermath of a successful IT project; the team seeking new work rather than the allocation of resources to the most pressing business needs. As previously explored, the problem is basically one of human nature and therefore addressing it is not straightforward. However here I make some suggestions that could possibly help.
 
It is not possible to totally “solve” the problem of the IT cycle; however there are some steps which can be taken which can reduce its impact. Happily, several of these are also positive for the organisation in their own right.
 
 
The Basic Problem
 
1. Communicate better about projects

A prerequisite to not building up monolithic, inflexible IT departments is awareness of opportunities elsewhere in the organisation. Where people have some perspective of other current and future projects, they may see opportunities for advancing themselves which, in turn, can provide opportunities to mitigate the IT Cycle problem.
 
2. Use similar technologies / development methodologies

The more similar the approach taken in different teams, the easier it will be for people to migrate between them. Obviously using similar development tools is one area; however it is perhaps even more important that teams adopt similar development methodologies. People can adapt much more quickly to doing the same sort of thing in a different development environment than they can adapt to doing something quite different in the same development environment. Having said this, the best case would clearly be to work in a new team in a similar way and with the same tools.

Different tools will always be needed when, for example, development of reporting and transaction processing systems. Even here, it will be helpful to enhancing flexibility if the same databases are used and if the same terminology is adopted for business objects.
 
3. Cross train staff

This is pertinent to development environments where these differ between teams. However, even if all teams share a common development tool-set, cross training can give people an appreciation of systems which they did not develop, both their technical architecture and business purpose. This will stand them in good stead should they be required to work on these systems.

Cross training does not have to be extremely time-consuming and extensive in scope. Much could be learnt by 30 – 60 minute seminars held at lunch time. Such work not only prepares staff for changing teams, finding out more about other systems and projects it may also encourage them to consider other roles within IT.
 
4. Cross train managers

At least of equal importance is making managers aware of what is happening in other teams and how. With the right attitude, such information can be the genesis of a more flexible attitude to staff deployment and career development.
 
5. Make use of temporary secondment

The nature of IT work (or most other kinds of work if it comes to that) is that what was a priority last year may not be one this year, but may become important again in six or twelve months. This volatility argues for some flexibility in resourcing. If department X has a trough in workload which is anticipated to last six months and department Y has a peak which is also anticipated to last six months, then seconding some of department X’s people to department Y may be an answer (this of course assumes that people’s skills are transportable – see the last two points). Of course the peaks and troughs will not always coincide so conveniently. Nevertheless, secondment can be a tool in both increasing the breadth of knowledge of IT staff and in managing fluctuations in demand for people between different departments.
 
6. Make appropriate use of contractors

Particularly when there is a focus on expense, contractors are often seen as a bad thing. They cost a lot, they have little commitment to the company, any intellectual capital which they accumulate during an assignment is not retained by the company when they leave, and so on. However some of these criticisms could also be applied to at least a substantial section of permanent staff. Contractors are expensive because they offer specific skills at short notice and do not require much commitment from the company. Replacing contractors with permanent staff reduces our ability to cope with the IT Cycle (though clearly when managers retain contractors beyond their useful life, this contributes to the IT Cycle problem).
 
 
The Budget Problem
 
7. Build IT budgets from the ground up

Rather than starting with the existing IT staff in their existing departments, a potential approach might be to assess the priorities for each year and then allocate resources accordingly. This might introduce a note of instability to IT, but this could be managed and the process would also better reflect business realities.
 
8. Rank projects by business benefit

If the above is not practicable, it would still be beneficial to rank the business benefits of projects undertaken by different departments. The difference here is that the assessment comes after budget submission, rather than before. However the results might be somewhat similar. If one department’s new projects all ranked lowly, then thought should be given to reallocating some of their staff to higher priorities.
 
9. Have departmental IT budgets vetted in detail by other IT managers

It is difficult and time-consuming for non-IT people to assess the intricacies of projects. However IT professionals are familiar with these. A review of an IT department’s budget by an IT manager who is not part of that department can improve the likelihood of the budget being closely aligned with business value. This need not be an adversarial process if seen as a method by which to enhance the quality of the budget.
 
 
The “Latest and Greatest” Problem
 
10. Identify what new technologies are most applicable to the organisation

As well as exciting IT professionals, the “latest and greatest” technologies may often have solid business benefits. However the state of the art in IT moves forward so fast and in so many simultaneous directions that it would be nigh on impossible to keep apprised of all of them. A better starting point might be to assess what capabilities are the basis of an organisation (e.g. an organisation might decide that the expertise of its staff and the quality of the relationships with its customers are fundamental) and then investigate what technologies best support this. This can lead to a good alignment between employing newer technologies (happy IT people) and focused business benefit (happy profit centre managers).
 
11. Be prepared to let some people go

Ultimately, if people want to be into the latest cool thing then sometimes we will have to let them go a do that elsewhere. It is better to try to build a culture where success rather than use of “cool stuff” is important. IT staff with a strong appreciation of the organisations business and how to support it will ultimately be a more valuable resource than a group of talented technicians.
 
 
A General Suggestion
 
The above problems are all essentially managerial in nature. The final strategy addresses this head on and is perhaps a prerequisite for progress on the other ideas.
 
12. Provide incentives to IT Managers who effectively manage staff numbers

People are after all human and nothing helps quite so much in aligning the goals of the corporation and the individual as targeted incentives. Such incentives can be direct (e.g. bonuses for re-deploying staff) or indirect (e.g. annual objectives including one pertinent to this area or the manager’s attitude to effective use of resource being a criteria for advancement).

If an organisation is suffering from the problems inherent in the IT cycle, then I would recommend this final step as the first one to take.