We have reached the point where just about every management job involves using technology in some way. Email and word-processing are ubiquitous, and most medium and large-sized organisations have software systems that schedule and control their day-to-day activities. Communications between organisations, their customers, suppliers and staff are routed via the Internet.
Whenever managers need to make decisions the information they base their decisions on is likely to arrive electronically. The better the information they receive the better their decisions are likely to be. It is the responsibility of every manager to improve the information they receive and so make better decisions. This means that it is the responsibility of every manager to make sure that their information systems are designed properly. Where software development is managed through projects the manager will be the Sponsor or Senior Responsible Owner for projects within their area. Managers need to understand the implications of this, and ensure they have the skills to fulfill that role.
In the last five years or so a new technique has come to dominate new software development projects. The traditional "waterfall" development techniques is largely being replaced by "agile" methods. In the waterfall approach a systems-analyst would intervie users (or more likely their managers) and gather system requirements. These would be taken away and used to develop some software. After some months (or years) the finished software product would be handed over to the users. Agile methods have a different approach. Users still give their list of requirements but often they speak directly to the programmers. After a fixed period of time the programmers deliver some software. Not the finished product but something that the users can look at and evaluate. This cycle of requirements-gathering, programming and evaluation is repeated until the project sponsor is satisfied with the product and calls a halt.
The impact of this on the users is that there is much more intensive and frequent comunication between them and the programmers. If requirements change or are better understood the software evolves to meet them.
The impact on on the users' managers is that they need to build these meetings into their schedules. More significantly for some is that in their role as project sponsors they are unambiguously responsible for the success or failure of the development projects.
Being held responsible for success or failure of software projects should concentrate the mind wonderfully. It should prompt managers to learn how to do this well. Unless the manager has recently (that is within the last five years) completed a business or IT degree this probably means retraining. For managers who entered business after an arts or humanities degree this might be their first real IT training. Managers who think that being able to reply to emails and word-process a memo makes them IT-literate should think again.
Managers who are going to undertake business-change projects should consider project-management training both for themselves and their managers. At the very least they should understand the role of project sponsor. If the projects are likely to involve software development they should also consider training in the basics of software-engineering. Just what training is required will depend on their employer's project-management and software development standards.
Bernard Peek