Archive for January, 2011

Making progress when the business won’t

January 31, 2011 Leave a comment

Successful IT projects demand commitment from the business customer. But what do we do if they are committed enough to find (say) £5m for a new system, but not committed enough to free up any resources to be involved?

This has been a recurring issue for me over the years, including a recent project which was very cross-functional with no single clear business owner. Despite a legal requirement to meet a clear deadline which all parties agreed must be met, at one point deadlock was reached when every stakeholder involved agreed that it was somebody else’s responsibility, and nobody within the business was prepared to drive progress forwards. So at times there was a lot of drift, and no decisions.

We found ourselves facing an immovable deadline and a large degree of uncertainty about the requirements. Ordinarily this might be a good candidate for using an agile approach to development, but in our case we didn’t have the commitment from the business, so we had to try to fill the gap ourselves. We have found that the following approach works

  • Subject Matter Expertise. Understand the subject matter well – preferably better than the business themselves. Then most of the decisions will be the same as the ones that the business would make. (But not all of them).
  • Propose solutions for ratification, don’t ask. If you ask what the requirements should be, it will take months to get a decision. We couldn’t afford to wait – offer up something for a yes/no decision. But expect sometimes that the answer will be no.
  • Make lots of Assumptions. Compile a large assumptions list as a basis to get started, and verify as you go along.
  • Good documentation. This is a must so you don’t lose track of where you are as priorities change. This doesn’t apply just to requirements documents, also to design and code baselines.

There are also some dangers. We made some mistakes when our assumptions were wrong, resulting in some wasted effort. Some early design decisions turned out to be sub-optimal, when the rationale was undermined by a later emerging requirement. However, had we waited until we had a perfect set of requirements we would have delivered months late. There is also a risk that what inevitably becomes an IT-led solution doesn’t meet with widespread acceptance from the end users (but if they were largely excluded from the process, what do they – or their managers – expect?)

To stand a chance of success, this needs a good team with extensive business knowledge, which can’t be acquired overnight (so an established core team needs to be in place already). Luckily we were able to retain the core team from a related project in the same area. It also takes a lot of effort to manage all the business stakeholders; in our case this was the Programme Manager’s role, leaving the IT Project Manager to face inwards to the team and other IT stakeholders.

Of course this doesn’t stop somebody coming up with a completely new requirement only a few weeks before the Go-Live date…

Categories: Work Tags: ,