What's so special about your project?

By Andrew Clifford

We have all seen projects and systems treated as special cases, but in many ways all projects and all systems need to be managed the same.

IT encourages us to move from the specific to the generic.

You can't get much more specific than individual people. Each one of us is a unique entity. Within the organisation we have different roles and responsibilities, and different contractual arrangements. But an IT response to this, in a personnel system, is to move from the specific to the general, and to treat everyone the same.

This generalisation lets us communicate meaningfully about people in the organisation, and to control the organisation's staffing. By treating people the same, we can automate the mundane parts of personnel management (like calculating payroll), and concentrate on the more specific, more unique, more valuable (or more challenging) parts. Although every person is a special case, a degree of generalisation enables us to work more effectively.

We are learning to apply generalisation to IT.

For example, individual projects have many differences in business drivers, technology, project approach and resourcing.

Sometimes we treat a project as a special case, but it is usually a mistake. My favourite is, "This project is strategic so it doesn't have a business case." I always reinterpret this as, "We have no idea how this project delivers value but we can't cancel it because it is politically motivated".

Mostly, though, we have learnt to generalise projects. We define projects, give them codes, assign responsibilities, and have standard processes for communicating, evaluating and controlling projects. Generalisation does not stop every project being special, but helps us manage the mundane parts of projects better and leaves us more time for the creative parts.

When we look at technology and systems, we are still in the dark ages of special cases:

• "These are legacy systems, we don't know much about them."
• "The Sun server has a different disaster recover policy."
• "We document Java in the code and don't have any system documentation."
• "The direct sales applications support team don't have the resources to maintain test suites."
• "We don't have database design standards, but the DBA looks at each case."

We would not tolerate this degree of specialness for managing projects, or even for managing people.

Because we manage each area of technology and each system as a special case, we can not discuss them meaningfully and control them. Our management effort is frittered away on day-to-day point issues. We never get to grips with value-adding activities such as setting direction and establishing control. We never engage our business colleagues meaningfully about technology and systems.

To rise above this sea of detail, we need to generalise our IT systems and our technology, to see them in many ways as the same. Every area of technology needs principles and standards that align with business objectives. Every system needs to fit those principles and standards, and to be supported by processes that maintain that fit for the long run. We need a common management framework across them, like system quality management, like we have a common management framework across projects. Although every technology and every system is special, it is not a special case.

Subscription