Working Up

Working Up in Project Management, Systems Engineering, Technology, and Writing

Working Up header image 1

Excellent Maintenance or No Maintenance Required

February 20th, 2017 · No Comments

by Dwayne Phillips

Excellent maintenance sometimes indicates a faulty product or service. Sometimes, no maintenance indicates a superior product or service.

I first encountered this over 20 years ago. We had purchased similar products from two companies, let’s call them Smith Inc. and Jones Inc. for now.

The conversation went something like…

“What happens when a Smith Inc. widget breaks?”

“We call their 800 number, an expert answers, they talk us through the situation, and if necessary a team of technicians is on the road in 15 minutes and be at our location as soon as possible.”

“What happens when a Jones Inc. widget breaks?”

“Don’t know. Never had one break before.”

So, which product would you rather buy? Which company is better for customer service and product maintenance? Which product would you rather build?


→ No CommentsTags: Analysis · Customer · Failure

The Production Crew or We Got the Band Back Together

February 16th, 2017 · No Comments

by Dwayne Phillips

I recommend an organization for the future or work as we know it.

This is the new company. It is an agile team that has worked together on many software projects. The Team has learned much on all these past projects. The Team has become high performing (it “jelled” a long time ago). The Team can do what seems to be amazing stuff in a short time.

Hire The Team, not individuals.

How do you hire the team? Simple. Here is their “interface” or contract:

Give us an room (size specified) with Internet access via ethernet ports on the walls (access speed specified). We will bring the furniture, computers, white boards, etc. We setup the room the night before work begins. We’ve done this setup many times and have learned how to do it efficiently.

The Team arrives at dawn—seven persons. You supply someone who can describe the desired product. You pay $10,000 a day.

Life as we know it: Groups of persons work on agile projects. They learn how to work with one another. The group becomes more than the sum of its parts. The project ends; the group disbands, and the individuals go to other groups to work other projects. Start at zero again with the learning and growing.

Life as it could be: Let The Team stay together. Let them use what they have learned. One way to do it is for The Team to form it own company. Yes, this is like “two guys and a truck” and a movie production company and a band that has played together since high school.

Why can’t we do it in software development or in developing any other intellectual product for someone? I suppose there are reasons why the band can’t stay together. Perhaps we can learn from those heart-crushing breakups.


→ No CommentsTags: Management · People · Success · Synergy · Work

Persons, Products, and How We Discuss Them

February 13th, 2017 · No Comments

by Dwayne Phillips

We thank the person. We comment on the product. And we let everyone know that is what we do here.

Persons accomplish the work in endeavors. Persons use tools, sometimes they are really cool and expensive ones, but persons ultimately accomplish the work. The outcome of the work is a product (sometimes we call the product a “service”).

So, we have persons and products. How do we discuss them? What do we say to the persons?

I believe we can judge a product. I can hold a pencil in my hand. I can feel it, smell it, feel how it leaves marks on surfaces, see those marks, and sometimes taste the pencil. I can set the criteria for the pencil—how it feels in my hand is more or less important than anything else. I can comment on the product.

I believe we cannot judge the person who accomplishes the work. I don’t know what is in their mind. I don’t know much about the 3/4s of their life that they are not “at work.” I don’t know what and how they feel.

What can I say about the person? Almost nothing.

What can I say to the person? “Thank you.”

I believe this is how we should talk: We thank the person. We comment on the product. We let everyone know that this is how we talk.

Naive? Probably. Common practice? No. Still, I think these are worthy aspirations.

→ No CommentsTags: Authentic · Communication · People · Respect · Work

Analysis—The Difference that Makes a Difference

February 9th, 2017 · No Comments

by Dwayne Phillips

Analysts seek to find the difference that makes a difference. What can be vexing is that often there is no final difference.

I believe that technical analysis and the analysis of technical systems comes to one question:

What is the difference that makes a difference?

Is it temperature that makes one system work and another fail? Is it humidity? Is it size, weight, power, color? What is it?

One of the great issues that makes analysis so difficult is that in many situations, there is no final difference. No system will move 1,000 people 1,000 miles in one hour on one gallon of gasoline. No system will move people to Mars in three hours.

Consider professional sports franchises. They draft people to be on their teams. What is the difference that makes Michael Jordon or Tom Brady the one player who will provide long-term dominance for their franchise? A major problem is that there is no one out there who will provide that. Maybe 10 or 20 years from now, some young person will be born with the ability and desire to dominate. Maybe not.

The analysts are searching for someone who doesn’t exist. They fail year after year and maybe generation after generation. The analysts and their methods are despised for their failures.

Continue to look, listen, smell, touch, and taste. Continue to observe. Continue to search for the difference that makes a difference. Understand, however, that there may be nothing to find.

→ No CommentsTags: Analysis

Everyone Agrees about That, So…

February 6th, 2017 · No Comments

by Dwayne Phillips

Take great care when everyone agrees about something.

Once the world was plagued with the longitude problem. Long-distance sea travel was dangerous and fraught with the great unknown, “where are we?!?!?!?”

Everyone agreed on the solution to the longitude problem. Everyone, that is, except the carpenter who solved the problem. For background, see the Wikipedia article on John Harrison—the carpenter who solved the problem, and the problem in general and the culture surrounding it in another Wikipedia article.

Of course the history is slanted because some people won with the solution and some people lost with the solution. That is the nature of science, engineering, and solving problems. I recommend the hours required for detailed reading. This was a real problem that tilted the world’s economy.

One lesson from this history: Take great care when everyone agrees on a problem. This is especially true when we can’t measure the problem and have to use a lot of approximations and extrapolations.

Consider climate change. The world’s economy rests on this issue. The temperature curves we have use a lot of approximations and extrapolations. The persons doing these approximations and extrapolations are well educated, smart, and caring people. All those people who knew the answer to the longitude problem were also educated, smart, and caring people. They held the great majority of opinion. They were wrong.

This happens with great unknowns. When we “solve” climate change, some people will win big $$$ and some people will lose big $$$. There will be great debate, controversy, and all sorts of grievous vexations.

→ No CommentsTags: Engineering · General Systems Thinking · Ideas · Observation · Science

Systems Engineering—The Piece of Paper Test

February 2nd, 2017 · No Comments

by Dwayne Phillips

What is systems engineering? One answer is, “you can do it with only a pencil and piece of paper.”

I have been plagued with the question, “What is systems engineering?” for too long. As a job seeker, a common job opening is Systems Engineer. A quick reading of the job description shows that many so-called systems engineering jobs are really system administrator jobs.

Systems engineering job descriptions often have words like: CDR, PDR, CONOPS, requirements, design, eliciting information, DOORS, and RVTM.

System administrator job descriptions often have words like: server, Linux, Windows Server, install, setup, configure, VMWare, and Solaris.

One thing I have noticed about systems engineering:

you can do it with a pencil and piece of paper

I’m not saying that would be easy. Computers and applications make many jobs easier, and systems engineering is not an exception. DOORS and its related products from IBM make the systems engineer job easier, but the job can be done with pencil and paper.

The system administrator job cannot be done with pencil and paper. The system administrator quite simply administers computer systems. You can’t install a server without having the server. You can’t configure a server without a server and a computer terminal connected to the server. The pencil and paper can help, and I find them woefully under-used, but they are not sufficient.

So, when trying to decide if a job should be called a systems engineer or a system administrator, ask, “can I do this with a pencil and paper?”

For a few more details, see the International Council on Systems Engineering at

→ No CommentsTags: Systems · Work

Systems Engineering—Opening the Black Boxes

January 30th, 2017 · No Comments

by Dwayne Phillips

One function of systems engineering is to open the black boxes, look at the entire system, and apply some wisdom.

We often build systems by connecting existing systems and subsystems. These existing pieces are black boxes, i.e., we don’t know or don’t care to know what is inside them and how they work. These black boxes have defined interfaces and a history of functioning per these interfaces. These properties allow us to combine them into something that does what we want.

There comes a point, however, when building a system from black boxes doesn’t work or doesn’t work as well as we wish. At that time, the systems engineer opens the black boxes and peers inside. Hmm, we only this this part of this black box. We can discard the rest. That black box, well, we need all of it. That black box, we only need one little part of it. That black box, well, we don’t need any of it given that we are using only select parts of the other black boxes. And so on.

The systems engineer considers all the parts of all the black boxes and applies some wisdom. The result of wisdom is a new system that is more efficient, has fewer parts, is more maintainable, and lots of other better attributes.

The systems engineer’s job isn’t easy, and it isn’t easy to find a person with the required knowledge and experience. The hunt and application, however, are worth the effort.

For more on this and other aspects of systems engineering, see this short, free book on the subject.

→ No CommentsTags: Adults · Analysis · Engineering · Systems · Technical Debt

People are (the most important) Part of the System

January 26th, 2017 · No Comments

by Dwayne Phillips

Sometimes we have to update the technology even when old technology still does the job.

Requirements are real. We work to meet requirements in systems. Once the requirements are met, that is it. But what about the people?

Many years ago, I worked with a system that used old technology. It was embarrassing how old it was. Several people proclaimed, “Come on! We have to replace that with current technology!”

A senior manager replied, “The old technology meets the requirements. Current technology will require a new design, implementation, test, integration, test, etc., and that means money, money, and more money.”

Several years later, I had the same experience. We used technology so old that it was embarrassing. People wanted to replace it, but it met requirements. A young engineering hit me with, “But it’s 20xx. If we are stuck with this technology, I’m gone.”

There are times that the morale and pride of the people who work with systems become paramount. Old technology can truly be embarrassing, and there is a point when people won’t work with it. They will leave.

This is another example of including persons in the definition of a system. No persons, no system. Project managers and others must accept that.

→ No CommentsTags: People · Systems

Systems Engineering and Interfaces

January 23rd, 2017 · No Comments

by Dwayne Phillips

Systems are commonly built by connecting smaller systems. This requires that the systems are connect-able, and that requires a defined interface.

Most of the time, we build systems by connecting large boxes together in a system diagram. There are exceptions, and another post will discuss some of those. Still, connect the boxes with lines and arrows and such. The boxes may represent hardware, software, or persons.

To connect boxes, the boxes must be connect-able. This means the interfaces of the boxes must match. We can’t connect a 110-volt electric outlet to a water hose. The interfaces don’t match.

The systems engineer is the person responsible for ensuring the interfaces match. Each box needs to have a defined interface. This documentation can take many forms (paper, audio, video, etc.), but it must exist. In technical terms, the defined interface is called an Interface Control Document or ICD. Again, it doesn’t have to be a paper document, but it must exist.

Some people think of the ICD as a contract. Others think of it as a UML diagram. Others think of it as a service-level agreement. All these work fine in the appropriate circumstances. The ICD should be visible and usable. There are no secrets here. The secrets are inside the boxes (what is there and how it works). The services provided by the box must be openly visible.

This may seem obvious and common sense to most persons. It is not, however, common practice. Lots of angst on systems development occurs because the ICD is…well, it doesn’t exist and persons think it is bureaucratic nonsense.

This is yet another answer to, “Why do we need someone called a systems engineer?”

→ No CommentsTags: Adults · Communication · Engineering · General Systems Thinking · Systems

The Good Hackers

January 19th, 2017 · No Comments

by Dwayne Phillips

The original hackers were the good guys. Some of today’s hackers still are.

Nintendo recently brought back a handful of old video games in a clever packages called the NES Classic Edition. They sold a boat-load of them. The trouble is, you can’t add any games to it.

Enter good-old hackers who add functions to computer hardware and software. Now we can add games to a supposedly closed box.

Yes, there are good guy hackers. They take open source code, or reverse engineer code that is not open source, and add to it. They augment the functions of computers. Almost everyone wins here. Game players will have more games to play on their clever little box. Nintendo, who should have made the box’s source code open, will sell more units. Someone out there will write a few new games to run on limited hardware and might make enough money to buy a lunch or two. A lot of younger people will learn something about video game systems and software.

I trust that no one will ruin all this by calling a lawyer.

I suppose there is a moral to this story and I’m supposed to provide it. Let’s try this one:

You have a good product. Let persons see the inside. You never know what they might do that will benefit a lot of others and you, too.

→ No CommentsTags: Customer · Fun · General Systems Thinking · Programming