A few years ago, I was working as a freelance test manager for JPMorganChase in London and at the end of the contract I was invited to work on a problem project in New York. The project in question was having difficulties delivering to an aggressive schedule that required new releases every three months, with each release having a six month life cycle. This meant that at any given time there would be at least two releases in development.
The team on the project were very good, including a project manager, David Hodges, with whom I had worked before and held in high regard. At the first meeting we sat down and had a rather dispiriting couple of hours look at the project's history, where it was now and the future requirements.
Applying a bit of common sense, we decided on an initial release that was limited to correcting some live issues and started a conversation with the business unit to whom we were delivering about what they really needed in the very short term. Understandably, and given the frustrations they had endured, the business team wanted as much as possible in the next release; they had been waiting some time for important functionality.
So, we explained the challenges we had on our side and in the end, with their cooperation, we defined a manageable release. When we sat and looked at it, it didn't look too ambitious and, indeed, it was delivered on time, fully tested and functional. This set the pattern for subsequent releases and, despite their initial misgivings, the business unit ended up very happy with a steady stream of change, delivered every three months as required.
Yesterday my colleague, Steve Parker, sent me the following link: http://www.wired.co.uk/news/archive/2010-06/28/project-canvas-youview
Of course, I was interested in this from a technology point of view and also for the details of the predictable spat over the question of public money distorting the private market for which I have some sympathy (although little for Virgin and BSkyB, specifically). However, what really caught my eye was the following sentence: "If all that's met, and the project doesn't go more than 20 percent over its budget (which has also been prohibited by the BBC Trust), then Project Canvas is expected to launch in the early part of 2011."
This strikes me as symptomatic problems with IT development in the public sector. i.e. the acceptance that IT projects will go over-budget. Whether it is conscious or not, the trust is tacitly approving a budget overrun of 20%. This means those running the project, who should be responsible for the budget, won't begin to worry until that figure of 20% is approached. They certainly won't worry at the point where they are approaching the limit of the official budget.
Furthermore, previous experience tells us that if the budget limit is reached, no one will want to throw away millions of pounds worth of work and more (licence payers') money will be found to shore up the project. We may get the minor satisfaction of seeing a slapped wrist or two.
The point of this blog, as you will probably have guessed by now, is that there is no reason IT can't deliver to a budget, whether it's a financial or, as in the case at JPMorganChase, time limited. If the BBC have a budget for this development, then their suppliers, whether they are in-house or external, should learn to work to that budget. To deliver a successful IT project, it is important to be realistic, not ambitious. Software development is both technical and creative and consequently there is plenty of scope for issues to arise and cause slippage. Furthermore, technology is a moving target and their is no doubt that the environment around this development will evolve as it progresses. The BBC should set their project milestones now, so that this project can be cancelled early if it is not going to deliver to the proper budget and they should remove the 20% safety net immediately.
No comments:
Post a Comment