Rants
Questions
Soapbox
Best Practices
Apply today for a FREE subscription to CIO Magazine!
Sun, May 13, 2007 19:48 EDT

|
Posted by: Michael Hugos in Best Practices Topic: DevelopmentBlog: Doing Business in Real Time
Current Rating: |
The best way to launch a project is to deliver tangible business value in the first 30 days. I call this the 30-Day Blitz.
It’s critical to start with fast delivery of something business people can immediately put to use because it provides clear evidence the project is headed in the right direction and will live up to expectations (at least most of them). People are very busy these days and they’re wary of system development projects because they’ve seen so many of them fail. They need to see something positive happen quickly before they’ll really commit their time and support.
This became clear to me some years ago when I was the engagement leader on a project for a company that provided financial reporting services to firms trading in commodities such as agricultural products, fuel oil, and minerals. This company cleared trades and provided trading data to the accounting departments of the firms that did the trading.
Because it was possible for a firm’s traders to do thousands of trades very quickly, the firms felt the need to get better intra-day trading data so they could better track the risks their traders were taking. My client decided to invest in a multi-million dollar state-of-the-art system to provide this trading data in a streaming real-time environment.
But, as often happens with such projects, the work got bogged down with expensive and complicated technology that did not work as expected. I was asked to come in and reorganize and reenergize the project. I plunged in and began investigating the project team and the state of the system that had been created so far. I found a lot of demoralized programmers and very skeptical business users.
The project needed the active support and participation of all parties involved if it was going to stand a chance of succeeding, yet people were reluctant to give this commitment for obvious reasons. The project had been under way for a bit more than a year and had so far failed to meet expectations. Who wants to commit to a failing project?
I've used this same approach repeatedly myself. It is particularly effective in turnaround situations, of which I've managed several. I have gotten into the habit of actively looking for these kinds of opportunities. I like to have a list of possible mini-projects with this kind of value, then I can "seed" my project list with these. Programmers like them because you can see the end product fairly quickly and they produce real value for the customers in ways non-techies can easily understand. And often, it's much easier to quantify the cost/benefit equation of these types of projects because of their tight scope. And because of the small size, the risk is generally small. We have to do the big projects, the transforming ones, but the 30 day blitz project is an important tactical tool to get things going and build credibility.
Thomas M. MacKay
I can't agree more with your thoughts. More and more people are realizing that Agility is key to project successes. The speed at which business changes means that a two year project that delivers exactly what it signed up for will be out of date by the time it is delivered. A key to success is carving out small deliverables that will actually provide benefit to the business quickly. Delivering the highest priority items quickly so the business can immediately begin to use them.
I hihgly recommend you read "Agile Estimation and Planning" by Mike Cohn or any of the Scrum books by Ken Schwaber for more details how and why this works.
In a nutshell, delivering quickly leads to immediate return on investment. Also delivering the highest priority items means you get the most value by what is delivered early. The old 80/20 rule.
Excellent idea, for the reasons mentioned and for another:
Projects can assume such broad scopes that they're often looked at in terms of "all or nothing", or "pass/fail".
Whenever possible, I like to see project design and implementation segmented such that the project is delivered in plateaus. Your example of a 30 day deliverable would be the first plateau in such a scheme.
When it's possible to deliver results this way (and of course, it's not always possible, but I think it's a strategy too-seldom used), it's also possible to ensure that, no matter what happens in later stages, usable value remains behind.
Right on the money. What counts is delivering results fast. Our business users have seen and heard it all before; only rapid results will ensure credibility for the rest of the journey.
The only qualifiers I would add is firstly it needn't be 30 days. 30-90 days is perfectly acceptable, especially when that is what is announced and the deadline is met. And secondly, anything you deliver in this timeframe won't be an end in itself, but only the first phase of a series of new releases, each one building on the other.
Because it was possible for a firm’s traders to do thousands of trades very quickly, the firms felt the need to get better intra-day trading data so they could better track the risks their traders were taking. My client decided to invest in a multi-million dollar state-of-the-art system to provide this trading data in a streaming real-time environment.
Software Download
http://www.usdownload.net/