We also have a tendency to be led by trends, or by internal politics. There are almost certainly thousands of iPhone applications being developed for companies across the world just because an influential executive changed phones from their Blackberry. There's nothing wrong about that - the iPhone is a wonderful platform - but you can be sure many of those started with the premise 'we need an iPhone application' and became someone's pet project, as opposed to starting with who the iPhone application will be used by, and what it will achieve for the company.

What Are Your Values?

Value is not necessarily a proxy for ROI, as not every part of a company can be a profit centre. Value is driven by the objectives of the department - the reason it exists in the company - each of which ideally being accompanied by a metric. The metric might be anything from a market share report from some trusted source for a product team, to a count of support tickets over a week old for a support team. There's likely to be multiple drivers, some of which are already in good shape, and some of which have fallen by the wayside. By consciously examining them, defining a goal, and comparing the current status to that goal, we can easily see which objectives are in most need of support.

This high-level view then drives the project focus - which projects have the promise of delivering the most change to the most important objectives. If this has been made clear, then within each project we can say which objectives the project should deliver improvements for, and what effect it's expected to have.

At the next level of granularity, each requirement can be ranked by its value to the overall project goals. Value isn't an absolute quantity, but a relative one. There's no need to say 'this is value 3' - it's more about saying 'x is more valuable than y'. If determining these kinds of values is difficult, it's usually because the requirement is too specific.

For example, perhaps there has been a request to the team responsible for a company's website to add a forum, and an 'email to a friend' feature. If it's hard to choose which one of those delivers more value, that's because they're about the how, not about why. Even if the request comes in that form, understanding that the forum is for improved organic traffic, and the email to a friend is because a competitor's site has it, it should be easy to determine which one should be ranked higher.

All of this can feed into the execution of the project, by providing a source for goals on each iteration or sprint. More so than anything else, it's the delivery of these goals and the business value that shows the true progress of the project. The focus on value even helps guide what should be left out when time gets tight, or the situation changes.

Making the Shift

There are a few tools that can help make the change easier at a per-project level, but an open and honest look at the requirements is necessary, and it can be difficult to question requirements without appearing challenging or hostile to the work already done.

Putting each requirement into a box (such as 'reduces costs', 'increases revenue', 'improves service', 'increases brand awareness') can help, and in fact the more boxes the better, as they encourage a conversation to reveal the true drivers when quibbling between different options. Similarly, looking at existing products that might fulfil requirements and evaluating them for fit can highlight the core values behind a requirement, in a non-confrontational way.

The next step of resistance often comes with the idea that there won't be one all-encompassing list of features that will definitely be included in the project. There are two intertwined concerns here: that important functionality will be missed, and that there is no clear view of what will appear in the end. These are tackled by clearly and precisely defining the project vision - the overall goal in terms of what kind of thing needs to be made in order to fulfil the business objectives. The features, instead of being a hard set, become a flexible backlog of possible improvements, and the detailed plan becomes an initial period of trust, followed by regular demonstrations of simpler, but real, working systems.

The challenge is accepting that the requirements on the project may change over time, and that this change is in fact to be encouraged, not handled or hedged against.

Adding It Up

In the end, the shift in viewpoint to agile methods and a business value driven approach is not an easy one. The value of experienced practitioners and coaches is as much in helping the organisation evolve as it is facilitating the projects that they're directly involved with. However, the rewards for those that can make the move are a much more reliable and flexible development process, and a chain of value-driven views that link the smallest project to the highest-level company strategy.