coneblog

A wise colleague of mine, who specializes in IT governance issues, observed at breakfast the other day that “Chunking” was a key project management skill.

By “Chunking”, my friend Don means that activity done in the pre-project phase in which the prospective project is divided into “chunks” that are digestible by the IT organization, or the enterprise as a whole.

Chunking is critical because it is where the broad scope outlines of the project are set. It is also where low-hanging fruit might be identified and addressed, and where some parts of the effort might be deferred in order to attack other parts.

My experience, and that of others, is that when projects fail, often the causes of failure are baked in at the beginning, and not really the result of execution failures (see “A Project Manger’s Prayer” earlier this year). A common cause is mis-scoping a project, or, in Don’s words, “failure to Chunk”.

If Software is “The Art of the Possible”, then Chunking is where the broad project outlines are laid out, and the question “what is most possible?” is asked.

• There are different approaches to chunking in different project contexts. These include: Geography, where you start with one area and work to another;
• Interfaces, where you deal with a few interconnections, and leave others until later;
• Users, where you replace a business process for some users first, and others later.

In all chunking exercises, there is a tension between the Interconnectedness of Everything, which leads to big chunks, and the benefits of taking small bites. A good practice is to map your proposed benefits to the potential chunks, and try to deliver first that smallest possible piece that will allow complete delivery of significant benefits.

The dilemma is that if that Chunk was easy, it would have probably already been done…

Next, let’s apply Chunking Thinking to our current study project, the War in Iraq.