Information systems strategy should be viewed as supplementing business strategy, helping to apply technology better in order to underpin the aims and competitive advantages pursued. As with any strategy, it must identify the future situations towards which a company wishes to move (potentially quite different from the current situation), defining a framework for these objectives (consistency) and using Strategic Planning to chart an appropriate direction for the movements to be achieved in order to reach those goals.

One often finds that companies with well implemented commercial, product or distribution strategies nonetheless neglect their information systems, or leave them solely in the hands of technical staff.

"Es preciso contemplar beneficio de disponer de una forma sistemática de planificar estrategias de negocio con los sistemas de información adecuados para soportarlas."

The importance of having in place the right information systems strategy design, ensuring that this occupies an appropriate mind share at executive level, should not be based simply on the proportion of an organisation's budget which IT costs represent: consideration must be given to the benefit of systematically planning business strategies on the basis of appropriate information systems.

In conceptual terms, an information systems strategy is built up in a similar way to any other business strategy, through an external, market-facing component and how this is to be incorporated, and a separate internal component which adapts your organisation and resources in order to achieve your goals.

From the external perspective, an information systems strategy may be broken down into:

1. 1.  Technology Sphere.  As with a corporation's business area, which takes decisions about the products and services it delivers to market, the technology sphere focuses on those technologies which are critical in developing and consolidating the business they support.
   2.  Technology Competencies. These are the attributes which IT contributes to the development or consolidation of the business, in the same way as those competencies which allow a company to stand out from the competition in terms of the products and services it releases onto the market. This includes such aspects as stability, interconnectivity, flexibility, etc.

From the internal perspective, three core components would be:

1. 1. IT Architecture: the hardware, software and communications configurations used to define policies, rules and standards. As with business infrastructure, this would comprise the administrative structure.
   2. IT Processes: which define the portfolio of applications supporting business operations, running on the aforementioned architecture.
   3. IT capacities: options regarding the recruitment, training and development of the people handling and operating IT resources.

This series of articles focuses more on the external perspective, in other words the Sphere and Competencies involved in technology, and how they can be directed by means of a management model.

Organisation of the Information Systems area

Within the sphere of strategic planning of information systems, at some point one must decide on the organisational model to be adopted in order to implement the plans.

If the aim is to achieve appropriate alignment with the business, it is vital that not only the scale but also the capabilities of the members of the information systems department should be consistent with the key capabilities demanded by the business strategy.

If the technology sphere is a reflection of the products/services provided by the company, and if the technology competencies reflect the key competencies to be developed, then the structure and capabilities of the individuals employed must correspond to these concerns.

As with other areas, there are different options, including a joint decision within the Information Systems sphere to be reached in the planning process: the degree of outsourcing.

As this is a matter of options, criteria must be applied to establish the business strategy once again, and as usual there is no one size which fits all, as the outsourcing decision depends to a great extent on this strategy and the service market which would meet the company's potential needs.

Expectations, training and change management

"Technology is a weapon for the benefit of the business strategy"

A typical ERP implementation project in the USA is budgeted at around 20.5 million dollars [1], and although this figure would not be applicable to the typical Spanish company, the proportion of the components involved could well apply. One conclusion drawn from this component analysis is that 36% of the cost of a large-scale project at a company is allocated to training, expectation management and changeover support. The alternative, in other words a failure to allocate either economic resources or management efforts, will lead to a fruitless and ongoing struggle which will ultimately prove expensive and frustrating both for those wishing to see their expectations fulfilled, and those attempting to satisfy them.

Technology is a weapon for the benefit of the business strategy. It is not a panacea; it does not offer competitiveness or improve processes in itself. It is a facilitator which must be properly administered by and for the people who belong to the organisation.

[1] Forrester Research (1998)

Many project managers (who follow McGregor’s X Theory) think that members of their team need to be kept on a tight leash, that they will produce better work if they are made to feel constant pressure from the start. The more hours they get from the team (unpaid, of course), the better they consider themselves as managers. They start to get a sense of satisfaction when their teams are also working some weekends.

But what if these people actually like their work? Standing over an employee, paying attention to whether they are working or not, continuously hassling them… this might be appropriate in a fast-food restaurant but is certainly not the right approach when managing a project where the work is done with the mind and not the hands. Applying some pressure will get people moving but it will not make them think better or faster.

A number of studies on software projects show that, beyond a certain limit, working more hours does not increase overall productivity. Once you get above 120 hours per week, productivity can actually fall into decline (more rework is required than actual original work). There is an optimum productivity range of between 60-80 hours per week. However, nobody can keep going for much more than 40 hours per week at the pace and effort required by creative work. People under pressure do not think any faster.

An occasional pressure increase and overtime can be useful tactics to keep people focused and increase the perception that their work is important, but prolonged pressure is always a mistake.

It has been shown that overtime is offset by fewer productive hours, or undertime (for example, a working Sunday is followed by a relaxed Monday; if work is done through the night, the following morning is unproductive due to meetings that cannot be finished). Given that these hours are unpaid, overtime is never seen on anyone’s timesheets. Undertime is equally invisible, but it would be reasonable to assume a correlation of one hour of undertime for every hour of overtime.

Many project managers demand overtime simply to avoid being accused when a project fails

Some authors compare overtime to sprinting in a race. Sprinting makes sense in the last 100 metres of a marathon (for those with the energy left) but no-one would recommend you start a marathon with a sprint. Forcing people to sprint will only lead to a loss of respect for the project manager. The best workers have been through it all before; they know enough to keep silent while the Project Manager spouts something about the project needing to be finished by an impossible deadline. Then they take their compensatory undertime when they can, and will probably end up putting in 40 hours of real work each week.

A dreadful suspicion: many project managers do not use overtime to finish the project on time but rather to protect themselves from accusation when the project inevitably fails.

A project manager cannot be proactive without an up-to-date and credible plan, i.e. without knowing what is going to happen on their project next week, next month, etc. This is serious. Not only because doing otherwise tells people you are an ineffective project manager but also because of the demoralising effect it has on team members.

There is no excuse for a project manager not to have a plan prepared (written down or in their head) for organising themselves first and foremost but also to make available to anyone who needs it.

If the company does not require a plan in a specific format, the project manager should propose one proactively. There are many templates and examples available so as not to invent one (everything a project manager needs has already been invented). The best format will be the one that meets the communication objectives set by the projects director. A Gantt Chart is usually the most appropriate but a list of outstanding tasks might suffice, or a list of deliverables, a list of risks, etc.

Let’s not assume that planning is only done at the beginning of a project. Planning is useful at any stage and possibly most useful in the final weeks before completion when deliveries need to be formalised.

Of course, the best situation is one with good planning from the outset that has been agreed with those involved and the experts, starting with having a clear idea of who is sponsoring the project, who else is involved, what is the basis, deadline, budget, risks, scope, milestones, activities, costs, etc.

Our project manager would say something like: “That’s enough improvisation. I plan my projects. On Monday, I will plan the activities for this week and then those for the week after…”.