Bogorad on the basics of Change Management – TechRepublic

TechRepublic linkedin

As always any LinkedIn.com links require you to be a member of the site and the group links require you to be a member of the group.

In recent weeks, I have posted two pieces relating how a discussion thread on the LinkedIn.com Chief Information Officer (CIO) Network group had led to an article on TechRepublic. The first of these was, The scope of IT’s responsibility when businesses go bad and the second, “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic.

This week, by way of variation, I present an article on TechRepublic that has led to heated debate on the LinkedIn.com Organizational Change Practitioners group. Today’s featured article is by one of my favourite bloggers, Ilya Bogorad and is entitled, Lessons in Leadership: How to instigate and manage change.

Metamorphosis II - Maurits Cornelis Escher (1898 - 1972)

The importance of change management in business intelligence projects and both IT and non-IT projects in general is of course a particular hobby-horse of mine and a subject I have written on extensively (a list of some of my more substantial change-related articles can be viewed here). I have been enormously encouraged by the number of influential IT bloggers who have made this very same connection in the last few months. Two examples are Maureen Clarry writing about BI and change on BeyeNetwork recently (my article about her piece can be read here) and Neil Raden (again on BeyeNetwork) who states:

[…] technology is never a solution to social problems, and interactions between human beings are inherently social. This is why performance management is a very complex discipline, not just the implementation of dashboard or scorecard technology. Luckily, the business community seems to be plugged into this concept in a way they never were in the old context of business intelligence. In this new context, organizations understand that measurement tools only imply remediation and that business intelligence is most often applied merely to inform people, not to catalyze change. In practice, such undertakings almost always lack a change management methodology or portfolio.

You can both read my reflections on Neil’s article and link to it here.

Ilya’s piece is about change in general, but clearly he brings both an IT and business sensibility to his writing. He identifies five main areas to consider:

  1. Do change for a good reason
  2. Set clear goals
  3. Establish responsibilities
  4. Use the right leverage
  5. Measure and adjust

There are enormous volumes of literature about change management available, some academic, some based on practical experience, the best combining elements of both. However it is sometimes useful to distil things down to some easily digestible and memorable elements. In his article, Ilya is effectively playing the role of a University professor teaching a first year class. Of course he pitches his messages at a level appropriate for the audience, but (as may be gauged from his other writings) Ilya’s insights are clearly based on a more substantial foundation of personal knowledge.

When I posted a link to Ilya’s article on the LinkedIn.com Organizational Change Practitioners group, it certainly elicited a large number of interesting responses (74 at the time of publishing this article). These came from a wide range of change professionals who are members. It would not be an overstatement to say that debate became somewhat heated at times. Ilya himself also made an appearance later on in the discussions.

Some of the opinions expressed on this discussion thread are well-aligned with my own experiences in successfully driving change; others were very much at variance to this. What is beyond doubt are two things: more and more people are paying very close attention to change management and realising the pivotal role it has to play in business projects; there is also a rapidly growing body of theory about the subject (some of it informed by practical experience) which will hopefully eventually mature to the degree that parts of it can be useful to a broader audience change practitioners grappling with real business problems.
 


 
Other TechRepublic-related articles on this site inlcude: “Why taking a few punches on the financial crisis just might save IT” by Patrick Gray on TechRepublic and Ilya Bogorad on Talking Business.
 
Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc, a management consulting company located in Toronto, Canada. Ilya specializes in building better IT organizations and can be reached at ibogorad@bizvortex.com or (905) 278 4753. Follow him on Twitter at twitter.com/bizvortex.
 

Two pictures paint a thousand words…

IT / Business Alignment
IT / Business Alignment

versus

IT / Business Integration
IT / Business Integration

Which is more likely to lead to sustained success?
 


 
See also: Business is from Mars and IT is from Venus and The scope of IT’s responsibility when businesses go bad.
 
Note: I have just had it pointed out to me that I missed out HR from the above diagrams. I hope that none of the HR professionals who read this blog will be too offended by my oversight.
 

Some thoughts on IT-Business Alignment from the Chase Zander IT Director Forum

This Chase Zander seminar, which I earlier previewed on this site, took place yesterday evening in Birmingham. There was a full house of 20 plus IT Directors, CIOs and other senior IT managers who all engaged fully in some very stimulating and lively discussions.

As I previously mentioned, our intention in this meeting was to encourage debate and sharing of experiences and best practice between the delegates. My role was to faciliate the first session, focussed on IT-Business alignment. I started by sharing a few slides with that group that explained the research we had conducted to determine the content of the forum.

Click to view the introductory presentation
Click to view the introductory presentation as a PDF

After sharing what in my opinion was a not wholly satisfactory definition of IT-Business alignment, I opened up the floor to a discussion of what IT-Business alignment actually was and why it mattered. We used some of the other slides later in the meeting, but most of the rest of the evening was devoted to interaction between the delegates. Indeed the ensuing conversations were so wide ranging that the theme was also carried over to the second session, hosted by my associate Elliot Limb.

Territory initially covered included the suggestion that IT should be an integral part of the business, rather than a separate entity aligned to it (a theme that I covered in my earlier article Business is from Mars and IT is from Venus, which interestingly I penned after a previous Chase Zander forum, this one focussed on change management). The group also made a strong connection between IT-Business alignment and trust. A count of hands in response to the question “do you feel that you have the 100% unqualified confidence of your CEO?” revealed a mixed response and we tried to learn from the experiences of those who responded positively.

The relationship between IT and change was also debated. Some felt that IT, with its experience of project-based work, was ideally placed to drive change in organisations. Others believed that change should be a business function, with IT sticking to its more traditional role. Different organisations were in different places with respect to this issue – one attendee had indeed seen his current organisation take both approaches in the recent past. It was also agreed that there were different types of change: positive change in reaction to some threat or opportunity and the less positive change for change’s sake that can sometimes affect organisations.

Suggestions for enhancing IT-Business alignment included: being very transparent about IT service level agreements and trends in them; focussing more on relationships with senior managers, the CEO and CFO in particular; better calculating the cost of IT activities (including business resource) and using this to prioritise and even directly charge for IT services; applying marketing techniques to IT; learning to better manage business expectations, taking on more realistic workloads and knowing when to say ‘no’; and paying more attention to business processes, particularly via capability maturity modelling.

It was agreed that it generally took quite some time to establish trust between a CIO and the rest of the senior management team. This might be done by initially sorting out problems on the delivery and support side and, only once confidence had been built up, would the CIO be able to focus more on strategic and high value-added activities. This process was not always aided by the not atypical 3-5 year tenure of CIOs.

Later discussions also touched on whether CIOs would generally expect (or want to) become CEOs and, if not, why was this the case. The perspective of both the delegates and the Chase Zander staff was very interesting on this point. There was a degree of consensus formed around the statement that IT people liked taking on challenging problems, sorting them out and then moving on to the next one. While there was some overlap between this perspective and the role of a CEO in both having their hand on the tiller of an organisation and challenging the management team to meet stretch goals, there was less than a perfect fit. Maybe this factor indicated something of a different mindset in many IT professionals.

In the context of forming better relationships with business managers and IT trying to be less transactional in its dealings with other areas, the question of why there were so few women in senior IT positions also came up. This is a large topic that could spawn an entire forum in its own right.

Overall the meeting was judged to be a success. From my perspective it was also interesting to meet a good cross-section of IT professionals working in different industries and to talk about both what the different challenges that we faced and what we had in common.
 


 
Continue reading about this area in: The scope of IT’s responsibility when businesses go bad
 

Tactical Meandering

Meanders
 

  tactics /táktiks/ n.pl. 2 a the plans and means adopted in carrying out a scheme or achieving some end. (O.E.D.)  
  meander /miándər/ n. 1 a a curve in a winding river etc. b a crooked or winding path or passage. (O.E.D.)  

 
I was reminded of the expression “tactical meandering”, which I used to use quite a bit, by a thread on the LinkedIn.com Business Intelligence Group forum. The title of this was Is BI recession-proof? (as always, you need to be a member of both LinkedIn.com and the group to view this).

The conversation on the thread turned to the fact that, in the current economic climate, there may be less focus on major, strategic BI initiatives and more on quick, tactical ones that address urgent business needs.

My take on this is that it is a perfectly respectable approach, indeed it is one that works pretty well in my experience regardless of the economic climate. There is however one proviso, that the short-term work is carried out with one eye on a vision of what the future BI landscape will look like. Of course this assumes that you have developed such a vision in the first place, but if you haven’t why are you talking about business intelligence when report writing is probably what you are engaged in (regardless of how fancy the tools may be that you are using to deliver these).

I talked about this specific area extensively in my earlier article, Holistic vs Incremental approaches to BI and also offered some more general thoughts in Vision vs Pragmatism. In keeping with the latter piece, and although the initial discussions referred to above related to BI, I wanted to use this article to expand the scope to some other sorts of IT projects (and maybe to some non-IT projects as well).

Some might argue (as people did on the LinkedIn.com thread) that all tactical work has to be 100% complementary to you strategic efforts. I would not be so absolute. To me you can wander quite some way from your central goals if it makes sense to do so in order to meet pressing business requirements in a timely and cost-effective manner. The issue is not so much how far you diverge from your established medium-term objectives, but that you always bear these in mind in your work. Doing something that is totally incompatible with your strategic work and even detracts from it may not be sensible (though it may sometimes still be necessary), but delivering value by being responsive to current priorities demonstrates your flexibility and business acumen; two characteristics that you probably want people to associate with you and your team.

Tactical meandering sums up the approach pretty well in my opinion. A river can wander a long way from a line drawn from its source to its mouth. Sometimes it can bend a long way back on itself in order to negotiate some obstacle. However, the ultimate destination is set and progress towards it continues, even if this is sometimes tortuous.

Oxbow Lake Formation
Oxbow Lake Formation

Expanding on the geographic analogy, sometimes meanders become so extreme that the river joins back to its main course, cutting off the loop and leaving an oxbow lake on one side. This is something that you will need to countenance in your projects. Sometimes an approach, or a technology, or a system was efficacious at a point in time but now needs to be dropped, allowing the project to move on. These eventualities are probably inevitable and the important thing is to flag up their likelihood in advance and to communicate clearly when they occur.

My experience is that, if you keep you strategic direction in mind, the sum of a number of tactical meanders can advance you quite some way towards your goals; importantly adding value at each step. The quickest path from A to B is not always a straight line.
 

An invitation to Chase Zander’s IT Director Forum

Please click on the image to view the full-sized invitation
Please click on the image to view the full-sized invitation

Some time ago I posted about about the IT Director Forum that I was helping Chase Zander to set up. This is happening on the evening of March 26th in Birmingham, England.

Seminar topics: People who should attend:
  • How Business and IT be better aligned?
  • How IT can add more value while being more cost effective?
  • IT Directors
  • Managing Directors
  • Senior Business-Facing IT Professionals

A summary of the research that led to developing these topics may be viewed here.

Rather than just making presentations, the objective is to have round-table discussions with delegates sharing their experiences. I will be facilitating the IT / Business Alignment session and Elliott Limb will be handling the Adding value with IT session. Elliott is an IT and Business Leader and Author of forthcoming book Credibility – Bridging the IT / business divide.

At present, there are a few places still available. Any UK-based IT managers who are interested in attending can contact Emily White (emily.white@chasezander.com or 0870 997 9014) to make a reservation.
 

Some reasons why IT projects fail

© Alex Messenger - http://www.alexmessenger.co.uk/
© Alex Messenger - http://www.alexmessenger.co.uk/

Having yesterday been somewhat disparaging about the efforts of others to delineate the reasons for BI projects failing, I realised that I had recently put together just such a list myself. By way of context, this was in response to being asked for some feedback in a subject area where I had little expertise and experience. Instead of bailing out of answering, I put together a more general response, a lightly edited and mildly expanded version of which appears below.

Please note that there is no claim on my part that this list is exhaustive; in common with all humans, us IT types can be very creative in finding new ways to fail, I am sure there are some out there that I have not come across yet.
 

  1. The objectives of the project not being clear. By this I mean the business objectives. There are two layers of problems, the actual business issues may not be understood well enough to form an effective response and, if the business knows what it needs to do in general terms, IT may not fully appreciate this for a number of reasons (mostly down to lack of communication) or may be unable to translate this into a suitable programme of work (possibly because of a lack of knowledge of how the business operates). Where IT is not part of the senior management team, or sees itself as a department apart, this issue is more likely to occur.
  2. Strategy formation being skipped. If you don’t understand what a project is meant to be about, it is difficult (to say the least) to form a strategy. However, if the test in point 1. is passed, then it may be tempting (or there may be pressure applied) to get to the end game as soon as possible without either forming a strategy for the project, or fitting this into both over-arching business and IT strategies (which one fervently hopes are complementary). As I know all too well, the strategy formation step can be tough one and people may sometimes be keen to skip it. The current economic climate may lead to this happening more frequently and my opinion is that this will be storing up trouble for the future.
  3. Fragmented systems’ landscapes. Related to the above, it is often very difficult to make progress when there is a patchwork of different systems and approaches throughout an organisation and little desire to address this short-coming. Often some sort of revolution (albeit sometimes a quiet one sustained over many years) is required to move forward. Sometimes this requires some crisis, internal or external, as virtually every organisation is inherently conservative; no matter what their marketing spiel may claim to the contrary.
  4. Lack of Change Management. Projects often also have an organisational change aspect (what else are they for?) and the problems here are: a) people do not like change and resist it; and b) many otherwise able managers are not experienced in change – indeed we tend to educate most managers to be efficient in a steady-state environment. Even when this aspect is recognised, it is often underestimated and work does not start until too late in the game.
  5. People. Aside from these, the main other problem is people. Projects, even small ones, are difficult and not everyone is up to running them. Simple errors in execution can derail projects that otherwise tick all of the boxes.

 
Of course any passing Gartner analyst is more than welcome to rip this to shreds if they see fit.
 

“Gartner sees a big discrepancy between BI expectations and realities” – Intelligent Enterprise

Doug Henschen
 
Doug Henschen at Intelligent Enterprise reports from the Gartner Business Intelligence Summit in Washington D.C., explaining that Gartner analysts John Van Decker and Kurt Schlegel cited five reasons why BI projects do not live up to expectations (article link here):
 

  1. No IT-Business Partnership – “We have to get away from thinking of it as a vendor-customer relationship,” said Schlegel.
  2. No Link to Corporate Strategy – BI team have to listen to the executives and develop metrics and measures that are aligned with their goals.
  3. No connection to the Process – “BI has been overtly disconnected for too long,” Schlegel proclaimed. It’s not enough to deliver the right information to the right users. You have to insert those insights into the processes and interfaces that business users live in every day.”
  4. No Governance or Too Much – It has to be just the right amount of governance. BI grew up departmentally, so it’s all too common to have many silos of BI. At the other extreme, some companies are so uptight about data standards that companies can’t get their data into the warehouse.
  5. No Skills – Business users often lack skills, chimed in Van Decker, citing the one area where the business side was said to be falling short. “Most companies have very sophisticated capabilities available that folks just aren’t taking advantage of,” he said, pointing to corporate performance management (CPM) software as a leading example.

 
I come close to the situation of words failing me when I read a list like this (though not close enough to prevent me penning an article of course). I appreciate that maybe a public seminar is not the easiest place to provide deep insights (I present a lot myself), but the commentary against each of the problem areas seems odd to me. I’m not sure that these are really the five reasons for BI continuing to disappoint in some organisations, while it continues to delight in others, but here are my thoughts on each headline.
 

  1. No IT-Business Partnership – We have to stop talking about IT and Business as if they were two parties trying to negotiate a cease-fire. IT is a business department, it carries out business projects. It would be ridiculous to say that there needs to be a Sales-Business Partnership, it should be equally so with IT. I expand on this theme in the very first article on this blog.
  2. No Link to Corporate Strategy – There should not be a link to Corporate Strategy, BI does not exist as a separate entity that requires linkage. Instead BI work should be an expression of Corporate Strategy (as should any IT project), what else is it an expression of? This is not about listening to executives (though that is important) it is about IT being part of the senior management team of an organisation and not some semi-detached entity, focussed only on the beauty of its own navel. I give some indication of how to go about ensuring that this is the case in two articles, one focussed on a European environment and one spanning four continents.
  3. No connection to the Process – I agree that embedding good BI in a coporoate culture requires effort (indeed I have written a series of articles on the subject, starting with this one), however I struggle to see how any BI team could fail to realise this and pay the area due attention. If this is truly a reason for failure, then it is because of a lack of basic project and change management skills in BI teams.
  4. No Governance or Too Much – I’m not sure that achieving the Goldilocks approach to Governance is the issue here. BI’s impact on an organisation is directly proportional to how pervasive it is. This means that silos of BI reduce value and the walls need to be knocked in. Does this have to be all in one go? of course not, there are always benefits in a balance between incremental progress and paradigm shifts. Any organisation who has gatekeepers who refuse access to the warehouse because of and overly rigid approach to data standards is going to have problems. Equally where systems are developed with little thought to the information that they provide and data is simply thrown over the wall to the BI team, this is going to destroy value. As ever, there needs to be a sensible balance struck, one that yields the greatest business benefit for the lowest cost.
  5. No Skills – “Business users often lack skills”, this seems both incredibly patronising (are only IT people smart enough to get it?) and also a poor excuse for BI teams not paying enough attention to education (see point 3. above). If business people truly lack the skills to use good BI, then they are probably unfit to be in business as the tools are pretty intuitive (if not over-engineered by an approach that is too technology-focussed). More likely, training has been poor, or the BI deliveries have failed to be tailored to answering questions that the business wants to ask.

 
In summary, I don’t have five reasons for BI failing to live up to expectations, I have one. I firmly believe that BI done well is both the easiest of IT systems to sell to people and has one of the highest paybacks of any IT initiative. BI done badly (at the design, development, implementation or follow-up stages) will fail.

The issue is basically a simple one: just how good is your BI team? If a BI implementation fails to deliver significant business value, then instead of looking for scape-goats, the BI team should purchase a mirror and start using it.
 


 
Continue reading about this area in: Some reasons why IT projects fail
 
 
Doug Henschen joined Intelligent Enterprise as Editor in 2004 and was named Editor-in-Chief in January 2007. He has specialized in covering the intersection of business intelligence, performance management, business process management and rules management technologies within enterprise applications and architectures. He previously served as Editor-in-Chief of Transform Magazine, which covered content management and business process management challenges.

I comment on another Intelligent Enterprise article, this one by Cindi Howson, here.
 

The Top Business Issues facing CIOs / IT Directors

 

chase-zander-h78 cio-magazne

I am collaborating with Chase Zander to set up an IT Directors’ Forum for later in the year. Rather than focussing on technology issues, our idea is to focus on the nexus between IT and business, something that I am obviously interested in given my background.

In the IT and change projects I have led, I always prided myself on going an extra mile to understand user requirements. One way in which the group of us organising the seminar is trying to get such user feedback is from LinkedIn.com and specifically the CIO Magazine group (you will need to be a member of LinkedIn.com and the group to view this).

The question that I posed there is as follows: –

I’m looking for business-focussed topics for a CIO / IT Director forum that I am helping to arrange. I would be very interested in what areas are at the top of people’s priority lists.

The forum is for senior IT people, but it is not going to be focussed on technology (there are enough SOA seminars out there already). Instead possible areas would include:

  • Managing the ever increasing pace of business change
  • IT / Business alignment; IT Governance / prioritisation
  • Managing IT in the current economic climate
  • The interplay between IT strategy and shorter-term tactics
  • Increasing the influence of IT at the board level.

Of course some of these overlap. The seminar is meant to be a forum for discussion between delegates, not just presentations. If you were to go to such an event, what topics would you like to discuss? Thank you in advance for your help.

Peter

There has been a lot of very interesting feedback to this question, showing once more how helpful the on-line community can be in addressing issues.
 


 
UPDATE: The results of this survey are now available and may be viewed here.
 

Mitigating problems with the IT cycle

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.
 

Problems associated with the IT cycle

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

Figure 1 - The IT Cycle
Figure 1 - 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.

Figure 2 - The problem with the IT Cycle
Figure 2 - The problem with the IT Cycle

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.