There is an interesting effect being noted in terms of larger scale change: the bigger the effort and the longer the time period required to execute upon it, the more likely it is that results will be delivered via many small projects.
I’m seeing this with things as big as massive jumps forward on products like SAP, and on wholesale replacements of application portfolios.
There are great advantages to avoiding the “megaproject” and instead having a program management approach to small projects.
First of all, work can begin without knowing how all the steps will unfold.
I saw one organization enduring an ongoing debate about the virtue of tablet PCs as “work slates” in a property and casualty claims office. The small project approach would simply equip some claims offices with tablets and send out observer teams to see what difference having a tablet makes, rather than trying to think through tablet-specific applications first.
What’s the advantage of thinking this way?
First of all, if the device itself is a problem rather than at least the equal of the existing way of working, you find that out quickly. How many break? Would a clipboard with paper and a scanner be a better solution?
You’ll never know if you don’t try it — especially where an older workforce that mistrusts change is involved.
Second, user interface changes to existing applications will arise from the experiment.
These are probably easy and cheap to deliver, but have field benefit — and mask off the older application so that it can be changed out without affecting the workplace significantly at a later time.
Many nagging issues of long standing can be eradicated through this technique, whereas the new “master solution” approach leaves little to no room to make changes once it is delivered.
In fact, the incremental approach looks like progress; the “one big change” approach can’t help but dissatisfy people.
I saw another organization, over three years, undertake 35 separate small “replace the mods with modules” efforts to ready their old version of SAP for the jump forward at the end. As each module was delivered, pent up change requests could be honoured as new releases of that module in parallel.
127 projects later (over three years) they’d gone from SAP R/3 to the latest release — and cleared most of the backlog around SAP.
Risk is managed this way. Each addition potentially has its own value — but, if it doesn’t, it can be discarded without needing to stop and rethink a major effort.
Gained by many small steps, some will lead nowhere (or will be useful elsewhere but not here); gained by one big leap, it must be “right” or the enterprise is at major risk.
If there is one constant in the world, it is that outside events create unanticipated change.
Small steady steps allow for the integration of such change and even its exploitation; one big project experiences scope creep (and often scope elimination) in response to events.
The reality of competition is that most businesses must undertake major renovations to their current portfolios to remain competitive. As a result, big change is back on the table. Why not think small when facing big?
This leads to the idea of the lean project. Some firms call this “blitz delivery”, others “agile development”. The odd thing is that you can “waterfall” one of these fast projects, because all you’re doing is restricting scope.
There are some common ideas that underlie the way they are working:
- 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.
- 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.
- 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.
- 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, I 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 for all the areas of the enterprise.
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.