What is your value add when budgets are tight? Somewhere in there, some business value needs to be delivered, even if you are using this period to renew the portfolio.

But everything during this time must be lean. Previously, we’ve discussed the value of a small development team, in “Two Pizzas ... and No More”. What we are now seeing emerge in the marketplace is the idea of the lean project. Some firms call this “blitz delivery”, others “agile development”. There are some common ideas that underlie the way they are working:

1. Their CIOs are releasing small amounts of money at a time, and finding qualifying efforts to absorb that money, rather than working to a plan developed a few months ago based on requests that are even older. The CIO is going to the business and asking each part, “what’s the one thing that would mean the most to you?” — not the project from the plan, but the capability they want most.
   
   

2. When money and a target are released, architecture swings into action to do solution architecture. They blend with the analysis capability and design team to scope what will be delivered. The total project duration will not exceed thirty days start to finish (requirements are pruned to fit, or the effort doesn’t start). The architect/design phase is done in the style of a charette, a technique commonly used by New Urbanists to handle the architecting of a whole community in the space of a weekend. The business is expected to fully participate — again, if they’re not willing to work seriously, the project doesn’t happen. The rapid cycle of thirty days, in turn, makes the promise of “release two” far more relevant.
   
   Where numbers allow, multiple projects proceed in parallel.
   
   

3. The design is frozen and delivery work begins. Note that packages are almost never part of this delivery model: the only practical way to handle such a rapid cycle is with bespoke code. The goal is to deliver the basics: “just the capability and no more”. Small teams are used, never more than eight in total. The goal is a functional system by the end of the third week.
   
   

4. Week four is used for testing and interface refinement. Delivery occurs by the thirtieth day.
   
   

What makes this approach work is that it puts the pressure on everyone. Most IT projects languish in large measure because the business is allowed to wallow: to miss meetings, to constantly reconsider its decisions, to have new requirements brought forward (and everything given equal relevance and urgency). What the CIO commits to is a process: we will deliver in thirty days so that you have the capability you need; you will participate and make decisions on command or we kill the effort and move on to someone else. Everything else is stripped down to the basics.

While this is a culture shock to both IT and the business, the paybacks are worthy of consideration. First, a thirty day project by definition simply can’t consume a lot of money, especially if the small team approach is enforced (and, frankly, we have yet to see a corporate IT group that can routinely use a medium- to large-sized team and stay within the time limit of thirty days). The resulting system therefore has practically no depreciation associated with it: it can be pitched out and replaced literally within a year or two. This means the premium on “getting it right” or “making it complete” goes away: if it does what’s needed in the short run, it can later — when monies allow — be replaced by a packaged solution, or a more complete offering. Second, the discipline this brings to both IT and the business pay dividends later with larger projects. After several cycles of rapid decision-making and cut-off thinking, larger efforts will face far less wallowing around. Third, the business gets benefits rapidly. This reduces the angst over “picking the right business case” and makes a round-robin priority scheme actually a moderately productive approach.

One important point, should this sort of approach be taken up: the promise of “release two” must be kept. In other words, later the same year that second release (also produced on the thirty-day cycle) must be scheduled and executed. This, more than anything else, builds a real belief within the business that deferring a requirement is not losing a requirement. Architecture, in conjunction with the client service or relationship management function, should keep an evolving calendar of releases, make it public — and hold to it.

From an architectural point of view, key “componentware”, to integrate the portfolio, advance the future state, and prepare for transitions, can be scheduled into this flow as well. This ensures that the underpinnings the company will require in the future can also be built as a part of the project calendar.

The charette/rapid project approach will not be for everyone; those who firmly believe that IT must be subservient to the business and “wait until told” will never have the firmness required to make the thirty-day cycle work. For those who can summon up the courage to do something different, however, this approach offers the promise of delivering far more each year of essential function with most of the fluff stripped away, and within a tightened budget and with lower depreciation build up for the out years. All in all, worth an experiment.