Introduction

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: –

1.	Feasibility
2.	Preparation
3.	Development / Testing / Deployment
4.	Maintenance

Each of these is stages characterised by, amongst other things, different resource levels (these stages are described in detail in Appendix A – Description of project stages, and the levels of resource required are described in Appendix B – Resources required during different project stages).

The above may be seen as a somewhat idealised – and certainly simplified – view of a project. For example, a project may have more than one phase, the first could roll out basic functionality, the second enhance this with less time-critical (but none-the-less important) functionality, the third could extend use of the system to other business areas or locations. In these cases, the point at which the project first goes live is not the beginning of reducing staff numbers. Instead at this point two teams are needed, the first to support the live, phase one system, the second to continue to build phase two. This would frequently lead to a resource increase at this stage.

Also by the time that the system is deployed, business focus may have changed, leading to substantial requirements for modification or enhancement. This is essentially the same model as phased delivery of fixed requirements, it is just that the planning of the overall project is more fluid.

Nevertheless, such refinements of the model do not change the basic message. At some point (possibly extended by planned or unplanned phased deliveries), the system will meet the majority of the business requirements and new development activity will offer diminishing returns. At this point, the system needs to be put into maintenance mode and less staff will be required. This is the essence of the IT cycle.

I will now consider some problems that the IT cycle can lead to.
 
 
The Basic Problem

Having reviewed some aspects of the IT cycle and explained how this applies to all systems development, regardless of how extended this might be, we can now focus on the basic problem that this model presents.

This basic problem can be seen as one of inertia – the tendency of things to persist in their current state unless impacted by some external force.

Over the first three stages of the IT cycle, focus has been on developing a strategy, building a team to execute it and then realising the vision. Anyone who has been involved in this process will attest to the collective pride and comradeship that develops with the team. A feeling of “us against the world” can take hold, followed by an immense sense of joint achievement when a system is successful. People often also grow through such a process, junior analyst/programmers become senior analyst/programmers. Designers become more experienced. Project managers become battle-hardened. As a result of this, at the beginning of what would be the maintenance phase, the IT organisation is left with a group of people who are creative, successful, focussed on development rather than support and have the mindset of wanting more challenges. Such people have a high value in the market and are more than aware of this.

Therefore, the IT organisation has both a challenge and an opportunity. The successful project has resulted in more experienced and able people being available, but where will their next challenge come from? This situation can be addressed in two ways. The former is harder to achieve and less often practiced, the latter is the path of least resistance and more prevalent than many IT managers would like to admit.

Option A – Assess what the current, pressing business priorities for IT are and devote the best people from the completed project to these.

It is likely that there is more than one area to which they could contribute. Maybe they will be able to take on a more senior position in their next project. This option is not as easy to achieve as it might seem. Consider two projects, X and Y. The former has been very successful but is going into maintenance mode and requires less staff. The latter represents a current business priority. Assuming the goodwill of the managers of both projects, potential obstacles to behaving this was would still include: –

•	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.