In our last post we looked at making a high-level system design for a paper about a project, arguing that a proposed design change would make it impossible to complete a hypothetical project by its original due date. The design called for a four-paragraph structure that flowed as follows:
P1 – Introduction: If we make the proposed change we will have to extend the project deadline by at least 30 days.
P2 – We have 90 days to complete the project by the current deadline.
S2 – Today is March 15.
S3 – The project is due o be completed by June 15.
S4 – That gives us 90 days to work.
A1 – Assuming we do not add shifts.
A2 – Assuming we do not add workforce.
P3 – The proposed change will take an additional 45 days.
P4 – Conclusion: If we make the proposed change we will have to extend the project deadline by at least 30 days.
As we look at the structure we have created, we might decide that P3 needs to be expanded. After all, that is where the “meat” of our argument resides. It might become:
P3- The proposed change will take an additional 45 days.
S1 – The proposed change will require the completion of Tasks A, B, C, and D.
S2 – Task A will take 20 days and must be complete in order for Tasks B and C to begin.
S3 – Tasks B and C can be worked simultaneously.
S4 – Task B will take 10 days and Task C will take 15 days.
S5 – Task D can only begin when B and C are complete and will take 10 days.
S6 – All of these tasks are additional work and cannot be combined with the existing project tasking.
Some of these points might need support as well. Our original design with the main points as the lead sentences of the paragraphs might now become a multi-section document with the main points as section heads and the supporting sentences as new paragraphs under those sections. This might look something like:
Section 1 – Introduction: If we make the proposed change we will have to extend the project deadline by at least 30 days.
Section 2 – Current Schedule
P1 – We have 90 days to complete the project by the current deadline.
S2 – Today is March 15.
S3 – The project is due to be completed by June 15.
S4 – That gives us 90 days to work.
P2 – Assumptions
S1 – Assuming we do not add shifts.
S2 – Assuming we do not add workforce.
Section 3 – Scheduling the proposed change will take an additional 45 days. P1 – The proposed change will require the completion of Tasks A, B, C, and D.
P2 – Task A will take 20 days and must be complete in order for Tasks B and C to begin.
P3 – Tasks B and C can be worked simultaneously.
P4 – Task B will take 10 days and Task C will take 15 days.
P5 – Task D can only begin when B and C are complete and will take 10 days
P6 – All of these tasks are additional work and cannot be combined with the existing project tasking.
Section 4 – Conclusion P1 – If we make the proposed change we will have to extend the project deadline by at least 30 days.
The point here is that the writing follows a logical design. The number and division of the elements should be controlled by the logical architecture and structured in a way to make the argument flow in a readable fashion. Sections and paragraphs should each become a distinct piece of the overall argument. They should provide a channel through which the argument flows naturally.
Sometimes the writing task may call for writing into a defined structure as when we answer an RFP that sets our specific questions to be addressed. This should be treated as a boundary issue. The boundary of the writing may be defined as paragraphs in response to queries. The length may be limited. These format requirements should be handled as boundary definitions and our structural response should address them appropriately.
By approaching the writing systemically, the writer can design a more effective product – one that is clearer, more powerful, and more readable. These are the virtues of good expository writing. Systems engineers, with their heightened awareness and predisposition to the systems view, should have no excuse for obscuring their own logic and conclusions with disorganized prose.
