Technology As Innovator

Drill Down

Category: Decomposition

How to use

Write the problem. Next, write the next level detail on the problem. Recursively break down each item into details.

Example

A restaurant quality problem can be broken down:

Advantage

This tool helps you break down a complex problem into workable pieces.

Previous volumes of the series

1. Introduction
2. Reversal
3. Appreciation

Appreciation

Category: Creativity

How to use

Staring with a fact, ask the question “So what?”. Keep on asking until all possible inferences have been drawn.

Example

Fact: the scope expands and we are lacking a resource for the newly discovered functionalities.

• So what? We might need overtime to meet deadline.
• So what? We will be tired.
• So what? Moral will be affected.
• So what? More mistakes may be caused.
• So what? Product quality will be affected.
• So what? Less return from customer.
• So what? Moral even deeply sinks.
• So what? Attrition.
• So what? Chaos
• So what? To control this, shadow resources and resource backup must be planned.

Advantage

This tool helps extract maximum information from original facts. More information can be used to solve the problem.

Previous volumes of the series

1. Introduction
2. Reversal

A limitation is not a defect

A defect is defined as non-conformance to requirements.

A limitation of a system is something a system does not accomplish, either due to technology not being supported, time constraint budget limit, or nature of business model.

Ideally, limitations should not exist in a system. However, in engineering discipline, certain limitations are accepted. This article seeks to explore ways to manage a limitation.

Scenario: a simplified example of a Customer Relationship Management System

Business domain level

An Opportunity is created from a Contact when Sales representative has approached and make a proposal to that Contact. If an Opportunity encounters difficulty, it is converted to a Lead and requires more attention. If the Opportunity is done successfully, it becomes a Contract and Price is calculated. A Lead, if done successfully, can become an Opportunity when meeting certain criteria or become a Contract. If a Lead fails, it is dismissed.

System level

The object is a Transaction. A Transaction has 3 statuses: Opportunity, Lead, or Contract.

System allows changing status of Transactions.

An issue is raised: Does the system allow changing from Contract to Opportunity? Does the system allow changing from Contract to Lead?

The impact could be huge. The system must handle Price and Invoices. This concern is accurate.

Back to Business domain level

However, back to Business level, the situation may not affect the operation at all. In reality, when a Contract is signed, it does not have to be switched back to Opportunity or Lead. The customer may not even care for this scenario.

What do we (the project development team) do to address this gap?

Widely accepted principles of system development and project management

To address the issue, let’s get back to principles of project management

• The system should be able to satisfy customer requirements.
• The system should be able to handle exceptional cases.
• The system should be within budget and time frame with given resources.
• 80/20 rule applies. In certain cases, 80% efforts are spent for functions that users use only 20% the time.

How different roles view a limitation

A natural engineering approach of this gap is to restrict changing status of a Transaction from Contract to Opportunity.

However, when the proposal is put on the table, the chance maybe that it is not accepted. Firstly, the client doesn’t want a restriction in the system. Next, the client doesn’t want the development team to spend much efforts and time on a functionality that will not be used frequently.

This leaves a limitation in the system: it still allows converting Transaction status from Contract to Opportunity or Lead, but it won’t fix the Price and Invoice. This limitation leaves it to the hand of user to manage data themselves.

Manage a limitation from different perspectives

• System Analyst: this limitation is put in Supplementary Information section in a document.
• Technical Writer: this limitation is noted in User Manual.
• Business Consultant: communicate with client on this issue.
• If any issue arises, it is to be escalated to the Project Manager.