Outcomes and Actions...Too simple?

Some of the feedback on my previous post, about a new and simpler definition of the word "project" has been that the definition may be too simple. How could something as complex as a major business project be defined by something as simple as "outcomes" and "actions?" My answer comes in five parts:
(1) Outcomes and actions can be combined in a staggering number of ways, not unlike the way protons, neutrons and electrons are combined to form matter. Consider Agile PM, where outcomes are defined by a backlog of user stories (with story points) and executed in fixed time bins (iterations). Consider how Agile actions are guided by daily stand-up meetings. Consider large government projects where interim outcomes are described in "work packages," are defined and refined into a complex performance measurement baseline (PMB), placed under tight change control, and tracked with various pre-defined earnings rules. Consider how outcomes include widely-agreed concepts of "deliverables" and "creating unique products, services or results." And yes, intended outcomes and next-actions help guide personal decisions as well. It is a very scalable definition of projects -- more scalable, in fact, than the traditional definition of a project.
(2) There is a lot of room for improvement, even in traditional projects, for how we define, control and track intended outcomes and how we translate those outcomes into front-line action. Consider how many projects have failed because day-to-day actions were not connected to clearly-defined intended outcomes. Not so simple, is it?
(3) It takes extra effort to decide if a project activity should be defined by its end state (outcome) or is simply a means of moving us forward (action). If we don't go this extra mile, we may create an amorphous and confusing froth of outcomes and actions that is a source of miscommunication and waste. Outcomes and actions should be distinct, yet linked. And that is far from simple to do.
(4) One of the things I've learned about outcomes and actions is that they are entirely different beasts. Outcomes are the realm of control. God bless order and structure. Outcomes need to be comprehensive and mutually-exclusive, which is not so simple to implement, but very important too. Actions will never be comprehensive and mutually-exclusive. Actions are the realm of knowledge worker freedom of choice (which is why they are knowledge workers). Actions are messy, but God bless the mess.
(5) In upcoming posts, I'll show how this definition helps with respect to the next great frontier in project management, which is Management by Project (MBP). This simple definition, although written by a personal productivity guru, has surprising power with a topic that is beyond the scope of the PMBOK Guide.
Is the outcome/action definition simple? Yes. But it explains and predicts a lot of things from personal management, to project management, to MBP.
/Garry