Physical entity partitioning


George Sonnemann, Ph.D., P.E., CEO and President, Scone Associates, Ltd.

Physical Entity Partitioning. What does it mean and what does it have to do with project management? To answer that question we need to ask,“ What is project management?”We tend to think of project management as the act of managing a project so that the “desired” end result is achieved and that the cost and time period of execution is within the expected (quoted) framework. This definition rests on the assumptions that first, the end result could be well articulated, second, that the achievement of the project will indeed deliver the result, and third, that contained within the project are steps that can rely on analysis of existing knowledge defined as “inside-the-box” thinking.

Yet, we know that if two teams were tasked with the same project, we could observe different internal path to reach the goal. In part, this is true because software and hardware development and structure is as much an art form as it is a science.

However, there is another class of projects that are not directly related to the above definition. These projects seek an answer, or require an answer, that involves not only technology innovation but also a different approach, which we will call “out-of-the-box” thinking. So the conventional projects rely mainly on “in-the-box” approach and thinking and if proper “Physical Entity Partitioning” is applied, should be successfully completed.

The class of project that only result in success through proper “out-of-the-box” thinking also heavily rely of Physical Entity Partitioning.

Physical Entity Partitioning is the process of taking the total project and partitioning it into physical entities. Each of the physical entities has design parameters assigned which it must meet in order for the total to meet the end result requirement. This partitioning therefore is undertaking by starting with the end result and working “backward” as we identify the entities and ascribe their parameters. It is important to note here that this process unlocks you from the present and extrapolation of the present. In a previous paper, I suggested that this “backward extrapolation” be called “retroplation.”

We now will address the class of projects that require both “out-of-the-box” solutions and Physical Entity Partitioning to achieve end results previously either not considered or were considered improbable for success, and also identify the “in-the-box” solution.

Exhibit 1. Operational Information

Operational Information

Exhibit 2. LASA Project

LASA Project LASA Project

Exhibit 3. Design-to-Cost


Example 1—Operational Financial Information for Property and Casualty Insurance Company

Purpose of Project

Improve delivery of reports from twenty days after close of books to three days. Also, ensure that various reports “cross-foot” to each other, which presently is not the case.

Project Approach

In Exhibit 1, the key requirements are listed in the Physical Entity Partitioning column. Solutions are presented in the next two columns, one the “in-the-box” solution, the other the “out-of-the-box” solution. The fourth column identifies extensions of the existing state of the art and the results. Note that the “out-of-the-box” solution was implemented without any new technology development.

Example 2—Large Aperture Seismic Array (LASA) Project

Purpose of Program

Improve the seismic detection capability of nuclear events. Location for the improved detection capability was in Montana. Improvement of capability required a large number of deep, 180 feet boreholes, into which seismic detectors were to be placed. Data from each borehole detector needed to be processed and then forwarded to a central data collection point for further processing. The total set of seismic sensors needed to be distributed in clusters over a 150 km area.

Project approach to meet requirements and ensure operational high quality and reliability. In Exhibit 2, the Physical Entity Partitioning identifies the 21 Type A clusters each cluster consisting of 25 linked instruments and their basic requirements. These clusters needed to be interconnected so permit the seismic data analysis. Exhibit 2 identifies the challenges and the two possible solution paths, namely “inthe-box” and “out-of-the-box” as well as the result. The ultimate solution allowed one to meet the requirements but also extended the capability without any added direct costs.

Example 3—Design-to-Cost and DoD Specification

Purpose of Program

Develop a new double display unit for Sonar Data Display to DoD specifications plus a unit cost specification. Developer had the ability to recommend some relaxation of specifications to meet the cost target. Total cost of development program was fixed and standard commercial units could not be used.

Project Approach

To meet requirements and ensure operational high quality and reliability the design process was “inverted.” Rather that approach the project in the usual manner of performing a preliminary design and then obtaining a cost, the design process first divided the product into its basic Physical Entities. Column one of Exhibit 3 identifies this aspect of work. The next step was to identity the physical and cost constraints for each partitioned entity. Finally, from this information defined an acceptable design method and implementation. Only then was the detail design initiated.

Concluding Observations

In writing this paper, the example of LASA was provided to me by Harry Sonnemann. As a result he also reviewed the document and asked a very critical question: “Could you do the projects without the Physical Entity Partitioning and ‘out-of-the-box’ thinking?” The listener or reader likely will have the same question. The answer is “yes” but then the various tools to improve and assist in managing projects are that, namely an aid to improve. The thrust of this paper is to portray a methodology that will permit tackling project with breakthrough requirements and a means of organizing the thought process to achieve the desired end result..

Many project today, particularly in the realm of software development, require imaginative thinking. For these starting from the end point desired and going “backwards” or as suggested “retroplating” is a critical change in thinking.

Proceedings of PMI Research Conference 2002



Related Content