Doing Business in Real Time
The global economy has a life of its own, it lives in real-time, and we are all part of it. Hello brave new world.
In the last system review on the last day of the design step, our business sponsor had second thoughts about building the system he and his people had designed with us. His company is engaged in a major IT infrastructure upgrade and the bulk of their IT resources are devoted to that work. Yet many of the business units need new applications and cannot wait for 12-24 months while the infrastructure work is being done. So they are experimenting with us on an agile development approach called the 30-Day Blitz™.
The blitz depends on quickly building project momentum by focusing on development of a “robust 80% solution” and putting it into production in 30 calendar days. Then, after people have a chance to use it for a few weeks, we do another blitz and add more system features. This implies three things: the first thing is we have to stick to very tight time lines as there is no slack in a blitz schedule; secondly, we can only build 80% solutions since 100% solutions cannot be done in 30 days; and lastly, business people have to trust IT people when we tell them they will get another chance to add more features to the system after we deliver the first version.
That last thing, the part about trusting there will be another chance to add more system features, is critical to the success of a blitz. When that trust fails, business people start remembering all the times in the past when they fell for the old “Phase Two” ploy. A lot of business people have experienced this ploy and nobody wants to fall for it again. It happens when IT project teams try to manage scope; after a certain point on a project all further system features asked for by the business users are pushed into a future release, something called “Phase Two”.
The problem is, traditionally, the first phase still takes 18-36 months and costs a lot of money and when it’s finally finished, there is no more cash (and often no more enthusiasm) to do another phase of development. So business people wind up being left high and dry, stuck with whatever they settled for in the first phase. This causes them to resolve not to settle for anything less than everything they want when it comes to working with IT again on new systems.
Breaking development phases into 30 day iterations is a way to regain business users’ trust. If the first version of a system is delivered in 30 days, people can believe there actually will be another 30 day phase to add more features. And since there are only about 22 working days in a 30 day period, that means we can only take two days to define what the system will do, seven days to design how the system will do it, and thirteen days to build the system.
So, obviously, things happen fast on a blitz (that’s why it’s called a blitz). If we only have seven days to do system design, people can easily start to feel like they must have forgotten something that should be in the system. They get flashbacks of all the painful experiences where they didn’t get some important feature into a system and had to live without it.
When we see business people do the, “Oh no, did we forget something?” behavior on a blitz there is only one answer we can give them. We have to say, “Yes, you did forget something, and it’s alright. We'll get it in the next blitz.”
We go back to the