This article examines an area that is often one of some debate in both IT and business circles; namely issues pertaining to the size of IT teams, the length of IT projects and the ongoing expense associated with both. Here I will attempt to analyse problems associated with the nature of IT work and IT management and to identify the underlying reasons for these. In a forthcoming article I will offer some ideas about how a more flexible approach could lead to more efficient deployment of IT resources and thereby enhanced business value.
The IT cycle
Systems’ development is inherently a cyclical activity. An example of a typical cycle appears in the above diagram. The solid line, bordering the blue area, shows how resource is built up over time in order to develop an application meeting a business need and then requirements for resource fall as the system stabilises and moves into maintenance mode. There are a number of distinct stages: –
|3.||Development / Testing / Deployment|
|•||people in Project X have different technical skills to those in Project Y and so cannot simply transfer and start work immediately|
|•||people in project X may have a different way of working from those in project Y – this may present cultural difficulties which are disruptive to both new starters and existing staff in Project Y|
However, because it is a very positive outcome, I will devote some time to how the obstacles to this option can be negotiated in a later article.
Option B – Try to find more work for the existing project team to do in the same area.
It is a lot simpler to take this approach. People often appreciate continuity more than new challenges. It is generally the case that there will be more work which can be done, the question is rather the value of this work compared to what the same resource could be doing in other areas.
There are some very human factors that can reinforce this approach: –
|•||managerial prestige (or, less kindly, empire building)|
|•||rewards and progression being seen as tied to managing bigger and bigger teams|
|•||job security of the management of the project moving into maintenance mode|
|•||lack of appropriate positions for staff elsewhere in the organisation|
|•||the effort involved in building the project team being seen as wasted if it is “broken-up”|
|•||the desire not to fire staff, particularly those who have served the company well and just completed a major project successfully|
|•||business sponsors wanting to retain “their staff” anticipating further work at some future stage|
|•||“rewarding” past work with more work|
The combination of these factors can modify our resource graph to look more like Figure 2 below.
Here, when the project has notionally reached the maintenance stage, resource does not reduce and may indeed continue to grow. The red area demonstrates the difference between actual staff numbers and what the IT cycle model would predict. This may be seen as excess resource, or perhaps as a loss in productivity in IT. If, instead, this excess resource can be re-deployed, we have an opportunity to increase the overall effectiveness of the IT organisation.
The Budget Problem
The normal budget process can exacerbate this phenomenon. Often the manager of an IT department will start with their existing budget plus wage inflation as a base line. Anticipating future cuts, they may increase this by say 20%. What then follows is a turf war with each IT manager trying to hold on to their budget. While there is no incentive for any given manager to take a more flexible approach, such behaviour is rational and will continue. Of course it should be stressed that IT is not the only area to suffer from this type of problem.
The “Latest and Greatest” Problem
On top of this we can add some attributes of IT staff which, although generally desirable, can have a downside as well. Many IT people want to be involved in the latest and greatest technology – this is not always what is going to add most value to the business. Sometimes, in order to retain the best people, IT management can give in to this trait. At the positive end of the potential results, this can lead to happy staff and greatly enhanced systems. At the negative end are projects to re-write systems in new technology for little reason other than the staff would like to do this and may leave if they do not get the opportunity.
There is no right answer here, what might be seen as indulging IT staff’s whims may actually be the hard-headed, practical thing to do in some circumstances. What is most important is to achieve an appropriate balance between the need to retrain and motivate the best staff and the need to align work to business priorities.
So there are a number of problems facing IT in this area. However I believe that they are all tractable and I will offer some ideas for addressing each problem in a future article.
Continue reading about this area in: Mitigating problems with the IT cycle.
4 thoughts on “Problems associated with the IT cycle”
[…] 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 […]
[…] IT deck and at others there is spare capacity (this is something I address in my two articles on Problems associated with the IT cycle and Mitigating problems with the IT cycle). Now IT departments are normally quite good at […]
[…] have touched on this area already a couple of times. It was one of the issues that I identified in Problems associated with the IT cycle, where I said: “On top of this we can add some attributes of IT staff which, although […]
[…] will also run training classes; and so on. This approach saves money and also helps to deal with the inevitable peaks and troughs of resource requirements at different stages in a project. I would recommend setting things up this way (or looking to stretch your people’s abilities into […]
You must log in to post a comment.