What does “a system” mean?
This is “not as simple as it seems,” and we often get stuck when finding the answer. Probably, it may be “a combination of several elements that play a certain role as a whole. For example, “an integrated kitchen system,” stoves, a sink, and storage space help cooking, while “a physical distribution system” is a system in which those who are responsible for pickup, storage, and shipping deliver things.
Likewise, “an information system” is merely “a mechanism to output information, involving hardware, software, and communication networks.
However, “sales,” “list of royal customers,” “a latest business manual,” and “Top 3 of customers’ comments on the new product,” … As we may know, information that humans would want to know is not enumerable. That’s why numerous system integrators are needed in the society.
Complaints of Entrusters
Here are Top 4 of the moments when entrusters feel dissatisfied!
- [Proposal Stage] Low quality of proposals. There is almost no proposal.
- [Acceptance Stage] Low quality of products. I want to know how it was tested.
- [Design Stage] I don’t know what’s happening with the latest specification.
- [Operation Stage] Late response to inquiries. Sometimes responses are totally irrelevant.
These are all based on my experiences, but not more than my personal guess. I do not have any statistical data at all. And, needless to say, of course, entrusters must feel dissatisfied at various moments, for example, when they receive a technical explanation, when they sign a contract, when they see an estimate (!), and so on.
Well, to begin with, I would like to meet “entrusters’ dissatisfaction” by focusing upon a Process related to “delivered product inspection.” The reason why I chose this is simple; that is because, compared to other Processes, many Tasks in this Process are almost independent of human ability. For example, even if the Process related to “Proposal” is not well-organized, some people win “the entruster’s satisfaction.”
Here, members make reports to their project manager upon completion of each “outcome” in the fields that they are engaged in, such as module development, module integration, establishment of production environment, etc. Triggered by those reports, the Inspection Process starts.
In this Process, after the brief confirmation by the project manager, two inspectors, who are chosen arbitrarily, inspect the outcomes and record the inspection reports. Of course, the project manager has to decide, based on his/her experience and discretion, how often and at which timing the outcome reports are to be made.
Contents of Tests
“Including the intermediate inspection report, all should be delivered.”
There are few project managers performing such an act of chivalry. But, as a general rule, “the inspection report per element” of delivered products should be submitted with the system time stamp on it.
Figure 2 (Reprinting)
In fact, anyone would hesitate to say, “Let’s take CMMI(*).” But, we have to be brave enough to say, “Let’s submit the inspection report of products.” (CMMI: Capability Maturity Model Integration)
In this case, if there are 100 elements in a product, because there are two inspectors for each element, “(100 + # of re-inspections) * 2 sheets” of the inspection report will be generated.
For your information, as a whole SI business, necessary cost for tests and inspection should occupy at least 20% of the total cost. Roughly speaking, there should be 20 inspectors in an organization of 100 people.
Existence of “the inspection report” is helpful especially for the sales person in charge. Actually, many sales people can’t grasp what the produced products are like. And, they can not do anything but accepting the complaints.
However, with “the inspection report,” it is possible for sales people to compare inspection items that the entruster was not satisfied with when examining delivered products against inspected items written in the inspections reports. That is to say, it is possible to compare claims of the entruster and ones of the entrustee.
Explicit Specification and Implicit Specification
The “inspection report” rescues sales people to some extent, but it doesn’t solve “the problem of implicit specification,” which is an eternal issue for humans.
More specifically, it is a problem that occurs in case “the entruster believes certain specifications must be realized” even though RFP, Demand Specification, Requirement Definitions, and any other documents do not mention them.
We have no other way to avoid such a problem but to keep a log of agreed specifications in detail. But, what is “a well-recorded/easy-to-record Process”? I wonder.
When Process output is insufficient:
- Are executors wrong?
- Is the Process itself wrong?
The Process Owner has to discern which the cause of the problem is. Probability of most human-caused accidents, including information leakage, and misconceptions, can be minimized by improving Processes (in other words, systems).
Now, the situation in which “the final agreed specification is not shared” can be more or less changed by improving document management Process. We must improve the current situation in which after discussions on the basis of drafts, minutes of meeting and reviewed drafts are sent by e-mail and moreover indications about the implication in a long meeting minute are sent repetitively by e-mail.
The stance of this Process Owner is that:
- You can hold meetings as many times as you want.
- Moreover, you can discuss by e-mail as much as you like.
- You can do anything as long as you can “keep a log without omission.”
- However, you have to follow the specific rule only as for “the final decision Process.”
Therefore, there are few rules. Moreover, the rule just obligates to make the final decision online. The procedure itself is similar to Diet sessions. Concerning tiny typos or mistakes, all you need to do is to clearly include errata in the online meeting minute. Every stakeholder says “OK,” it’s done. So, there is no need to change the actual document or to discuss again.
Incidentally, the project manager had better throw herself/himself into the role as chairperson. Also, obviously, enough consensus-building in advance is expected in order to conduct “a calm chat.”
What’s called “rule” should be simple. Depending on business, the kind and number of specification to be defined in the project differs. In some cases, the number of files would excess 100. Moreover, some specifications have to be updated in the middle of the ongoing project.
However, all laws, regardless of a new law or an amended one, must pass the Congress. Similarly, any modified specification should also always get approved through a Process of “final agreement of specification.”
That is to say, it is not preferable to search around each individual’s e-mail box when a trouble occurs.
Besides Specification Determination and Acceptance…
Well, I would like to offer some suggestions, focusing only on the conclusions, regarding the remaining two “moments of dissatisfaction” (1 and 4).
- 1.[Proposal Stage] Low quality of proposals. There is almost no proposal.
- 4.[Operation Stage] Late response to inquiries. Sometimes responses are totally irrelevant.
Timing to Brush Up a Process Itself
“A Process” is namely “a rule.” A rule should not frequently be changed. In many cases, we can solve problems by changing personnel allocation and so forth. But, if we can not eliminate “stagnation” or “mistakes” by any means, the Process Owner may take courage in making a decision to change it. [The End]