Long time readers of this Blog are familiar with my “4^th Sigma” series on building simpler, easy to implement process improvement. I’ve argued against training for (and using) all of the tools that Six Sigma offers. It’s not that the tools don’t work, they do! Many managers are put off by the sheer abundance and complexity of these tools. Most corporate projects can do just fine with a much smaller set of simpler and “pre-fab” tools. In today’s blog we’re going to discuss a concept that runs through all project management, project improvement and software development methodologies. It’s called… Decomposition… the process of breaking down a big task into several smaller, easier to understand tasks or processes. OK, now let’s dive in!

Does everybody remember the 70’s TV series, the “Odd Couple”? In a memorable episode, one of the main characters (Felix) is in court and pulls out a blackboard to write out “ASSUME”. He then separates the letters “ASS” “U” and “ME”, saying, “when you assume, you make an ass out of you and me!” The lesson being that assumptions are often wrong. What is an assumption? An assumption is our  attempt to figure out what’s going when it looks like something we’ve seen before or when we try to guess about the information that’s missing. Because different people use the same words for entirely different things, a group can walk away after a conversation believing they made entirely different agreements.  Groups of people (such as project teams) can be fooled into believing they have an agreement (or an understanding of coming events) because key words in an agreement are unclear. An example will help explain this point.

Let’s say that you are working on a project, and you have a task on your project schedule… “obtain approval for software”.  Pretty simple, right? You just need some guy to say, “Yes.” What should that take… a week? That’s where the assumptions begin!  For this example, let’s assume that your firm is buying an accounting application from a commercial third-party firm. Further, this software has features that link into email and Microsoft Excel.  Pretty simple? Let’s dig deeper:

• Additional Licenses: You talk to IT and find that the simplest process is to add (or upgrade) licenses for existing products. IT has a list of official software and the approvers. If a user needs a license, the head of the user’s group needs to send the approver a request, and the software will be installed within 72 hours. However, you have a new product so this process doesn’t apply.
• Server License: Server licenses are handled by a different group, with a different list of approvers. There is also a form that needs to be filled out and approved by the IT approver and by the head of the requesting department. Your project requires a cloud-based product. That’s a bit of a problem. Your firm hasn’t done many Cloud projects yet, so there is confusion over who approves what. Luckily, you spoke with IT at the start of the project and worked this out. It now has an assigned an approver for Cloud requests. You’ve been told that it will take a week to approve a new request.
• Multiple Approvals: IT has a formal software approval process, after all big part of their responsibilities center around software. Business unit have infrequent software projects and a less formal process for approval. When a key approver in the business unit is away, requests may need to wait. You knew that the head of the department planned an extended overseas business trip, followed by a vacation, so you’ve scheduled time with the approver before he leaves the office.
• Large Approval: While IT has a formal approval process, it can still be affected by other corporate processes. For example, the accounting department has set a $50,000  limit for item for each IT approver. If an item is more, it goes to a committee to approval. Your software originally cost $38,500. A last-minute change raised the cost to $41,250. You are well below the $50,000 cut-off so you don’t need to worry, right?
• Unofficial Processes: Start worrying! IT believes that accounting is about to lower approval levels to $40,000; it believes that accounting will require re-approval for any already approved software costing more than $40,000. Your approver didn’t mention this earlier, because your software was under $40,000. Now it must go through the approval committee. The committee meets every other week, but always approves or rejects all software that was scheduled for review. To be scheduled for review, you need to submit your request at least 3 business days before the meeting. You now know that it will take 5 to 12 days (2 days for the business department, and from 3 to 10 days to get into the meeting) to get approval.

OK, the worst case of 12 days isn’t that bad. You’ve checked everything you are responsible for. But when you look at the whole project list, you see that some other tasks are a bit vague and haven’t been sufficiently decomposed. You ask a few questions to clarity these tasks. Here’s what you find:

• PC Software: Because you are buying a Cloud based application, not a lot of time was spent looking at  users’ PCs. Then you remember that email and Excel are somehow involved. Email is largely server-based, and everyone in the firm has the minimum version to use your application. Good! But you also find that your firm is running many different version of Microsoft Excel. A few users do not have the minimum version of Excel the Cloud application needs. Make sure that checking the version of Excel is on the project schedule.
• Server Hardware: It’s a Cloud application, so you don’t need a server. But you check anyway, just in case it’s a “sort of Cloud” application that does need some sort of hardware on your side. Looks like you’re OK here.
• PC Hardware: Because everyone has a PC, and the application is supposed to be Cloud based, no one checked the hardware on the PC. You ask IT for PC specifications which say, “A dual-processor computer is strongly preferred.” Hmmmm… 10 computers do not meet this requirement. Who decides if the “preference” for dual-processor is a requirement? Sounds like you need to send this back to IT for clarification.

As you can see, when tasks are not fully decomposed, what appears to be a one task can be two… or more. And entirely different sets of tasks can go by the same name. How do you ensure that you have correctly decomposed your tasks?

Owner: Is the task simple enough to assign accountability to a single individual? If the task clearly falls under two or more individuals, it is probably two or more tasks.

1. Time: Is there enough information on the task to know how long it will take to perform?
2. Cost: Can you assign a cost to the task? If not, is it because there is not enough information or are too many tasks?
3. Single Process: Are you sure that this is one task and cannot be broken into two or more tasks? Is anyone on the project team still asking, “What is that task?”, or similar questions that cannot be answered?
4. Numbered List: As you decompose tasks, assign each task a number. For example, your top level might be purchases = 4, training = 5, and hiring = 6. So, item 4.3.5 might mean: 4-purchase; 3-software; 5-accounting. Numbering tasks makes them easier to track, and easier to eliminate duplicates. Poorly decomposed tasks hide processes… that may duplicate other tasks on your schedule. Once these tasks are decomposed and arranged on a numbered list, if there are duplicates they are now placed closely together and are easy to visually spot… and eliminate.
5. Written Process: For common approval processes that your PMO (or improvement groups) performs, write out a simple process description. A page or less would describe all the variations of software approval processes and perhaps a list of the key approvers. This would give you a common glossary of terms and a common understanding of the requirements of each approval. That’s much better than figuring it out on your own!

There we have it. A key tool, or perhaps mindset, is that every project needs to be decomposed into specific, unambiguous tasks. Decomposition reduces or eliminates assumptions and makes it easier to see if adjacent processes link up correctly, or are missing. Decomposition is a very simple process, but one that you need to apply consistently until you understand each and every task in your project. Never ASSUME that someone else on the team will eventually figure out how a task works.  And that’s my Niccolls worth for today!