What the business could learn from IT

Business departments wanting to improve their processes should take a hard look at what their IT departments are doing, says Danny Bradbury. They may have a lot to learn.

To many business managers, the IT department is a dark underground place where Morlock-like beings slave over mysterious methodologies and sinister software tools.

Not so the bright, glittering world of the business department, where smartly dressed workers perform the day-to-day tasks of the real world.

Businesses may find the machinations of the IT department alien to them but in reality they may have more to learn from IT managers than they think.

Project management is a case in point; good IT departments have it honed to a fine art, whereas business departments are generally less structured than IT departments when it comes to project management, argues Neil Allcock, a technology integration partner at Deloitte. "There isn't as much structure in a business-driven project unless it has a distinct process to it," he warns.

The problem is that many business activities aren't given a process-like structure by managers, according to Dan Rossner, senior consultant at PA Consulting: "Defined projects in the IT space have a clear start, middle and end, and a finite lifetime, as opposed to business initiatives merging in with the rest of business as usual."

Some business departments will view things as discrete projects but it's hit and miss, says Rossner, and it depends on the business scenario. When dealing with such an amorphous environment, where it becomes difficult to separate one activity from another, is there anything that the business can learn from the way the IT department does things?

While it may be a painful process, redefining appropriate business activities into a clearly defined set of projects is the best place to start. This would make it easier to address some basic principles which should be universally applicable. Rossner cites clear definitions of scope, a view of the project stakeholder and formal risk-management as the ideal foundations of business and IT projects alike. Given that IT projects address these issues as a matter of course, the IT department could guide business managers who haven't mastered these basics.

But while such techniques should be the basic tenets of any project, there are other IT-specific methodologies that have evolved within IT departments as a means of interacting with business departments more thoroughly.

A good example of this is Agile development, which departs from more rigid traditional development methods that concentrate on project milestones, often spaced a long way apart. A disadvantage of traditional development practices is that they can leave IT departments out of touch with internal customers, failing to recognise changing business needs. Agile development, which is a broad term for many different methodologies including Extreme Programming, focuses on regular, frequent reviews of an IT project with business stakeholders.

"You could lift out a number of those principles to ensure that the business projects are more successful," says PA's Rossner, giving paired programming as an example. Paired programming, which is a central feature of the Extreme Programming methodology, involves two programmers working on the same piece of code, one checking the other's work as they go. The trade-off for lower productivity is better quality code, which ideally doesn't need to be reprogrammed later. "If you're doing things in pairs with two sets of eyes poring over the same problem, there might be [business] areas where that's beneficial," Rossner observes.

How aware are business departments of the benefits inherent in applying the IT department's more structured approach to their own activities?

"They're aware, but they don't know how to do it yet," says Compass' White. "They've gone through the first generation of that, which is activity-based costing. The second generation tried to import quality management into the process but they're only aiming at driving cycle time," he says. "No-one is yet facing up to the need to have a 360-degree view of all this and to predict what the future holds."

One way around that may be to embrace portfolio or programme management. Smart IT departments have known for a while that projects don't exist in a vacuum. Rather, by gathering projects together under broader business objectives, they can manage change more effectively. "Several of the organisations I've worked with have seen what's been done in terms of portfolio management for IT and said 'let's manage the rest of the company like this'," says Allcock.

This sounds good on the surface but there are obstacles, Allcock adds. The problem is that unlike the IT departments, they don't have a single resource pool from which to allocate expertise, meaning that to be effective in the wider business, such IT-led innovations need to be carried out with support from human resources.

Technology tools may be able to help business departments embrace IT project management techniques to a certain extent but you have to be careful what you pick, warns Rossner. Forget the Unified Modelling Language (UML - a developer notation tool designed to help people define technical architectures in business terms). "The IT people are more comfortable with use cases and UML artefacts. I'm not sure it would be appropriate [for business managers]."

In fact, outside project-centric sectors like construction, project management tools are poorly deployed, says White. "When you get into the back offices of financial services environments, the response is less coherent." There are some industry-specific point solutions for sectors like retail, where companies are gathering specific metrics like customer shopping patterns, but generally the opportunities to introduce efficiencies by using project and performance management tools are high.

But before they get to that stage, businesses must adopt the basic project-led mentalities that the IT department has adhered to for years, not just in obvious areas like new product development and innovation but in the less tangible back-office activities too. Making that leap will be difficult because it can involve a drastic rethink of organisational and process structure - but those who follow their IT department's lead have a lot to gain.