Outcomes, Deliverabl

D

dulichbonbe2

Guest
Hi,

I'm a "project manager," so "project" has a particular meaning for me. I'm trying to clarify the distinctions I need to make at different levels of organization; trying to keep the distinctions meaningful to the "workflow process."

A lot of tasks come to me, beyond the "projects" I am also responsible for; so clearly I need a category that is smaller than what is a "project" for me. As a place-filler I've been using "Projects" (e.g. "remodel community building") and "projects" (GTD-type).

The GTD template from M Lines uses the category "Outcomes" in a way that seems to me to be comparable to "projects" in the book. At one point in the book the term "deliverables" is used -- though there is nothing in the index, so it must not be a part, per se, of the system. Likewise "components" (as parts of a project.)

The long-and-short of it --

I'd appreciate a discussion of the concept of "project" especially in relation to "outcomes," "components (of projects), goals, objectives, deliverables, etc.

John.
 
Last edited by a moderator:

mcogilvie

Registered
Hi,
I'd appreciate a discussion of the concept of "project" especially in relation to "outcomes," "components (of projects), goals, objectives, deliverables, etc.

John.

A gtd-style project is a desired outcome which requires more than one next action. There is the natural planning model, which gives a simple approach to planning. That’s about it. It’s simple and generic, and works well at many scales. No objectives or deliverables. Some goals, if you please, which lead to projects and next actions.
 

Gardener

Registered
For me, a "project" in everyday language--either a work project or a personal project--generally spins off multiple GTD projects.

If the larger project can be divided into multiple streams of actions, I'll likely put each stream into a project. If one of those streams has a large delay, I'll generally put the tasks after the delay into a separate project. If a project has groups of actions of a fundamentally different nature, that MAY drive a separate project, because it may seem to me that the planning for some of those actions is a very different set of thoughts for the planning for others.

A non-work example:

Real-world project: Get autumn garden in

GTD projects:
Project: Get row 12 ready for roses
Project: Acquire roses
Project: Plant roses
Project: Get row 5 ready for overwintering vegetables
Project: Start/acquire overwintering vegetables.
etc., etc.

Or, if I rephrased to outcomes, which I generally don't:

Real-world project: Autumn garden successfully launched

GTD projects:
Project: Row 12 is ready to receive roses
Project: Roses are acquired, in holding, and ready to plant when the rains start.
Project: Roses are planted
Project: Row 5 is ready for overwintering vegetables starting July 1.
Project: Overwintering vegetables are ready to plant at their final spacing at the times recommended by Rogue Valley Gardening
etc., etc.

(Part of my problem with outcome phrasing is that my phrases are too darn long.)

Now, the first three projects might be one action on somebody else's plan. ("Get rose row planted.") For me, they're three separate full projects because I like small actions, because the row prep will happen months before the planting, and because the acquiring can progress at any time and it starts out as a research task.

"Get row 12 ready" might have actions like:

- Get landscape fabric off row 12. (I did this a few weeks ago.)
- Fork beds C through K. (I just did this Monday.)
- Check bed A--prepped?
- Amend beds C through K and A if it needs it.
- Plant that stray rose in bed A now.
- Design and implement a removable landscape fabric scheme. (This might spin off to a project, but probably not.)
- Get more mini-valves.
- Set up a mini-valved soaker for beds A through K. Turn them off.
- WAITING FOR the garlic in bed B to come out.
- Remove the garlic watering.
- Re-fork, amend bed B.
etc., etc.

"Acquire roses" might have actions like:

- Spend an hour looking at rose varieties.
- Research rooting cuttings.
- Find out if ForestFarm still allows pickup.
- Plan ForestFarm order
- Set up watering and shade for holding area.
etc., etc.

If "research rooting cuttings" makes me decide that yes! I want to try to root my own roses! then that will spin off yet another project.
 

mcogilvie

Registered
For me, a "project" in everyday language--either a work project or a personal project--generally spins off multiple GTD projects.

If the larger project can be divided into multiple streams of actions, I'll likely put each stream into a project. If one of those streams has a large delay, I'll generally put the tasks after the delay into a separate project. If a project has groups of actions of a fundamentally different nature, that MAY drive a separate project, because it may seem to me that the planning for some of those actions is a very different set of thoughts for the planning for others.

A non-work example:

Real-world project: Get autumn garden in

GTD projects:
Project: Get row 12 ready for roses
Project: Acquire roses
Project: Plant roses
Project: Get row 5 ready for overwintering vegetables
Project: Start/acquire overwintering vegetables.
etc., etc.

Or, if I rephrased to outcomes, which I generally don't:

Real-world project: Autumn garden successfully launched

GTD projects:
Project: Row 12 is ready to receive roses
Project: Roses are acquired, in holding, and ready to plant when the rains start.
Project: Roses are planted
Project: Row 5 is ready for overwintering vegetables starting July 1.
Project: Overwintering vegetables are ready to plant at their final spacing at the times recommended by Rogue Valley Gardening
etc., etc.

(Part of my problem with outcome phrasing is that my phrases are too darn long.)

Now, the first three projects might be one action on somebody else's plan. ("Get rose row planted.") For me, they're three separate full projects because I like small actions, because the row prep will happen months before the planting, and because the acquiring can progress at any time and it starts out as a research task.

"Get row 12 ready" might have actions like:

- Get landscape fabric off row 12. (I did this a few weeks ago.)
- Fork beds C through K. (I just did this Monday.)
- Check bed A--prepped?
- Amend beds C through K and A if it needs it.
- Plant that stray rose in bed A now.
- Design and implement a removable landscape fabric scheme. (This might spin off to a project, but probably not.)
- Get more mini-valves.
- Set up a mini-valved soaker for beds A through K. Turn them off.
- WAITING FOR the garlic in bed B to come out.
- Remove the garlic watering.
- Re-fork, amend bed B.
etc., etc.

"Acquire roses" might have actions like:

- Spend an hour looking at rose varieties.
- Research rooting cuttings.
- Find out if ForestFarm still allows pickup.
- Plan ForestFarm order
- Set up watering and shade for holding area.
etc., etc.

If "research rooting cuttings" makes me decide that yes! I want to try to root my own roses! then that will spin off yet another project.

Gardener's example highlights one aspect of GTD that is highly dependent on personal preference and on the technology one uses: whether to have one large project with sub-projects or many related projects. Gardener's post also illustrates how important phrasing may be: "Acquire roses" versus "Roses are acquired, in holding, and ready to plant when the rains start." A lot of this is also personal preference, but some of it is experience.
 

Longstreet

Professor of microbiology and infectious diseases
A gtd-style project is a desired outcome which requires more than one next action. There is the natural planning model, which gives a simple approach to planning. That’s about it. It’s simple and generic, and works well at many scales. No objectives or deliverables. Some goals, if you please, which lead to projects and next actions.
Excellent response! My mantra is always keep it as simple as possible.
 

Oogiem

Registered
I'd appreciate a discussion of the concept of "project" especially in relation to "outcomes," "components (of projects), goals, objectives, deliverables, etc.
GTD Projects are typically smaller than what most project managers consider a "project"

There might be a large project "Build a new house" but in GTD terms that would be an outcome that is the end result of many smaller GTD projects with discrete simple things you can do. "Review current blueprints with architect" could be a project with its next action "email architect with 3 possible meeting times re blueprints". "Decide on builder" is a project but the next action might be "call 3 references for each of the 2 possible builders" and so on.
 

TesTeq

Registered
GTD Projects are typically smaller than what most project managers consider a "project"
I don't know why most project managers have a problem with GTD Projects. According to Wikipedia:
Wikipedia said:
A project is any undertaking, carried out individually or collaboratively and possibly involving research or design, that is carefully planned to achieve a particular aim.
It is a very similar definition to the GTD Project definition. The difference? GTD Projects are rather carried out individually and planned as much as needed. And "a particular aim" is "an outcome".
 

Gardener

Registered
I don't know why most project managers have a problem with GTD Projects. According to Wikipedia:

It is a very similar definition to the GTD Project definition. The difference? GTD Projects are rather carried out individually and planned as much as needed. And "a particular aim" is "an outcome".

At my company, "project" tends to be something pretty large--something that would probably spawn dozens of GTD projects--or subprojects, depending on how you do your organizing. For example, a whole new payroll system would be a "project".
 

TesTeq

Registered
At my company, "project" tends to be something pretty large--something that would probably spawn dozens of GTD projects--or subprojects, depending on how you do your organizing. For example, a whole new payroll system would be a "project".
I understand but for me it is still just a difference in size - not in the definition. "A whole new payroll system" Project has a clear outcome ("A new payroll system implemented") and more than one Next Action. Yes, there is a difference in managing 10 thousand Next Actions versus five Next Actions but for me this difference is quantitative not qualitative.
 

Gardener

Registered
I understand but for me it is still just a difference in size - not in the definition. "A whole new payroll system" Project has a clear outcome ("A new payroll system implemented") and more than one Next Action. Yes, there is a difference in managing 10 thousand Next Actions versus five Next Actions but for me this difference is quantitative not qualitative.

I'm uncertain about what you mean. Would you not divide this into subprojects? That is, would you have all of the possible next actions for the payroll system in a single list, even though there could be a dozen or more very separate threads of effort? Or would you have subprojects, so that this is mostly about having hierarchies or not having hierarchies?
 

Cpu_Modern

Registered
The particular meaning the word "project" has to you as a project manager is probably false. Neither is the particular meaning the word "project" has in the GTD book "right", rather an all-encompassing understanding should be acquired.

There is no particular industry that has the "copyright" on the word "project". Thus the word per se should not be linked to a specific. A project is just a development - that's it! That's the meaning of the word.

Usually when people hear the the word "project", they think of a specific type of project based on their respective prior experience. For instance a real estate agent probably connects the word to a site that has to be "developed" by doing construction work on that piece of real estate. A software developer typically sees his programming work as a series of projects. The social worker refers to social housing as a project. The advertising creative refers to the work for each of his clients as a project; and so on.

The reason why each of these very different things is called by the same word, project, is of course because they are, seen from the perspective of the person who does the work, projects.

I have never encountered the job title "project manager" except in software development and web design, and there often as a misnomer. Most of the project managers would be called product managers, but because the agency is in client services they can't do that. Sometimes they come up with better ideas, in most cases they just should be called consultants. But that of course has again many other connotations, specially software dev, were a consultant is what is normally called a contractor except in design/advertising etc where they settled on freelancer.

And all of this is only a problem when people don't form their words from concepts but from parroting. The solution to that problem: patience with each other.
 

TesTeq

Registered
I'm uncertain about what you mean. Would you not divide this into subprojects? That is, would you have all of the possible next actions for the payroll system in a single list, even though there could be a dozen or more very separate threads of effort? Or would you have subprojects, so that this is mostly about having hierarchies or not having hierarchies?
I'm talking about a definition, you're talking about an implementation.
At the definition level there's no qualitative difference between a project to fix a kitchen door and a huge project to build an airplane. In both cases you have to define a successful outcome and then approach this outcome doing Next Actions. The difference is quantitative: 5 Next Actions / one person versus 5 million Next Actions / 20,000 people. In both cases you can use subprojects but for a ktichen door problem it is rather unnecassary.
 

Gardener

Registered
I'm talking about a definition, you're talking about an implementation.
At the definition level there's no qualitative difference between a project to fix a kitchen door and a huge project to build an airplane. In both cases you have to define a successful outcome and then approach this outcome doing Next Actions. The difference is quantitative: 5 Next Actions / one person versus 5 million Next Actions / 20,000 people. In both cases you can use subprojects but for a ktichen door problem it is rather unnecassary.

Ah, this is producing thoughts for me, thoughts that amble far, far way from the initial topic, though they may circle back.

For me (and presumably not for you, and I think it depends heavily on the work), I'm also talking about a definition. I tend to think of the smaller projects as, yes, projects, to a degree that I DON'T see the larger encompassing project. And I think that the difference in definition does affect the implementation.

I hadn't consciously realized this before, but I prefer that my parallel projects/subprojects be efforts that are worth doing even if the overall project doesn't get done. I like them to be neatly bounded chunks of completed work.

For example, in my sample gardening project/subproject thing, preparing Row 12 for the roses is worth doing even if I don't get the roses this autumn. It's worth doing even if I don't end up wanting roses there at all--it's a chunk of prepared ground that I could use for many purposes. For various reasons, I want all of Row 12 (a 6 foot by 60 foot strip) to be doing the same thing. But I might change my mind as to what I want that thing to be.

So that adds another concept--the idea of making decisions at the "last responsible moment". I'm going to throw the definition in here, for my own reference:

“A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision"

https://effectivesoftwaredesign.com...before-and-after-the-last-responsible-moment/

I could have organized the work differently--I could have had a mini-project of "prep and plant rose bed 12A" and "prep and plant rose bed 12B" all the way to rose bed 12J. But if I organized the work that way, I would be making decisions well before the last responsible moment. And if I did change my mind, that early work would not be useful.

I drift toward the topic of Kanban and Work In Progress: Because I want Row 12 to all be doing the same thing, if I did this bed by bed I would have a big chunk of WIP going on for a long time. The fully prepped row is "done done"--if I had a Kanban board, it would be on the right. A row with a rose here and a rose there and a half-prepped bed there would be the In Progress column for a long time.

So maybe that's the ideal project definition for me: A neatly enclosed chunk of work that's worthwhile on its own, that I can get to "done done" as quickly as possible. It's not always possible, but for me, it's desirable.

In programming, the chunk of work might be a reusable library, or a sprint, or a Minimum Viable Product.

In writing, it's hard to find such a unit. And I'm realizing as I write this post that this is probably a big part of why I tend to polish each scene in my novel to a high shine before I move on to another scene, even if I'm not at all sure that the scene will even end up in the novel. A well-edited scene has less of a feeling of Work in Progress, and it also feels like there's inherent value in the exercise--I've exercised my writing ability all the way from first draft to final polish, I've gotten some practice in creating a satisfying chunk of writing with a beginning and end, and so on.

And I think that whether the unit of work is or isn't truly useful on its own, the perception that it is, is somehow experienced positively. I'm thinking that this is somehow related to the Zeigarnik effect--which, I believe, links us back to GTD.

So. I now know what a project is for me. And luckily, much of my work, both paid and hobby, can be divided this way.
 

Popp2018

Registered
Hi,

I too have a role as a Project Manager in my company, and have also struggled with the tension between GTD Projects and project in the wider sense for a number of years. The key for me came with reading a post on a GTD forum pointing out that GTD is actually not a project management tool, it is a workflow management tool.

Professionally I work in the construction design industry, so a project is typically a new building, anything from schools or airports, with a programme of anything up to 8 years from start to finish. So much longer that the GTD 12 - 18 months timeframe, and with much more to track than just the next action. After much trial and error, I settled on my work projects, eg ‘School XYZ’ being at the Area of Responsibility level, with the day to day actions eg ‘Meet with Architect to review drawings’ at the (GTD) Project level.

The management of the bigger project (School XYZ) is done using professional tools such as MS Project, which effectively forms my projects support material. I also do use the GTD Natural Planning model as part of my personal project notes, and Kanban boards to identify and track actions which are not necessary my own personal ‘Next Action’, again as part of Project support material.

Hope this helps...?

Apopp
 

GTDengineer

Registered
Hi, new member here. I've been using GTD on/off for several years. I thought I'd throw in my 2 cents. Hopefully it is relevant:)

Building off of what Popp2018 stated, there should be no tension between GTD projects and business projects. They way I understand and use GTD, each GTD project should normally only have one action in the next actions list at any moment in time. This is because GTD does not attempt to track a long sequence of events on a next action list. Next actions only represent a "bookmark" in the project's sequence, so you never forget where you left off.

To manage a business project, you will naturally use checklists or maybe gantt charts to plan out a sequence of steps, just like a non-GTD colleague might do. These tools are stored in your project reference material. The difference for the GTD practitioner is, when starting a work period, you know exactly how to get yourself going by reading your previously recorded next action from the list. No wasted time trying to remember what you intended to do the last time you did the work. Then you may get into a work flow based on your project material, checklists and gantt charts and perform several project tasks in a row, while your GTD next action list is hidden and sitting idle in the background. You may add many more tasks you think of planning for the future on these project tools. But at the end of a work period you don't want to forget where you left off and try to memorize the details for the future. You just jot down the next action in your GTD list, and move on to another project, meeting, change of location, meet a new person, deal with an interruption, or end your work day.

So, to explain with an analogy, each GTD project is a book, and the GTD next action is only a bookmark. The print on the pages of these books is your project reference material (checklists, gantt charts and other reference materials), and it might take a library of books (i.e. multiple GTD projects with different outcomes) to have sufficient level of detail to remodel that community center.
 

Longstreet

Professor of microbiology and infectious diseases
Hi, new member here. I've been using GTD on/off for several years. I thought I'd throw in my 2 cents. Hopefully it is relevant:)

Building off of what Popp2018 stated, there should be no tension between GTD projects and business projects. They way I understand and use GTD, each GTD project should normally only have one action in the next actions list at any moment in time. This is because GTD does not attempt to track a long sequence of events on a next action list. Next actions only represent a "bookmark" in the project's sequence, so you never forget where you left off.

To manage a business project, you will naturally use checklists or maybe gantt charts to plan out a sequence of steps, just like a non-GTD colleague might do. These tools are stored in your project reference material. The difference for the GTD practitioner is, when starting a work period, you know exactly how to get yourself going by reading your previously recorded next action from the list. No wasted time trying to remember what you intended to do the last time you did the work. Then you may get into a work flow based on your project material, checklists and gantt charts and perform several project tasks in a row, while your GTD next action list is hidden and sitting idle in the background. You may add many more tasks you think of planning for the future on these project tools. But at the end of a work period you don't want to forget where you left off and try to memorize the details for the future. You just jot down the next action in your GTD list, and move on to another project, meeting, change of location, meet a new person, deal with an interruption, or end your work day.

So, to explain with an analogy, each GTD project is a book, and the GTD next action is only a bookmark. The print on the pages of these books is your project reference material (checklists, gantt charts and other reference materials), and it might take a library of books (i.e. multiple GTD projects with different outcomes) to have sufficient level of detail to remodel that community center.
This is quite elegant! Thanks for sharing - I think you are right on target! :D
 

Popp2018

Registered
So, to explain with an analogy, each GTD project is a book, and the GTD next action is only a bookmark. The print on the pages of these books is your project reference material (checklists, gantt charts and other reference materials), and it might take a library of books (i.e. multiple GTD projects with different outcomes) to have sufficient level of detail to remodel that community center.

I like the book analogy. Very helpful.

Thanks
 

John Forrister

GTD Connect
Staff member
Hi, new member here. I've been using GTD on/off for several years. I thought I'd throw in my 2 cents. Hopefully it is relevant:)
....
They way I understand and use GTD, each GTD project should normally only have one action in the next actions list at any moment in time.
....
So, to explain with an analogy, each GTD project is a book, and the GTD next action is only a bookmark.

Hi GTDengineer, welcome, good to have you with us. Great analogy with the bookmark. The next action makes it easy to pick up where you left off. I have one refinement about the number of next actions. A project should have at least one next action (bookmark). But a project can have multiple next actions, as long as they are parallel rather than sequential. You may have a project that has several actions that you could take, none of which are dependent on each other. It's fine to have those on your next actions lists. Where we most often see people tripped up is when they have items on their next actions lists which are in fact dependent on something else happening first, so they're not truly "next" actions. Those would go back into project support, brought forward to the next actions list when the dependency is out of the way.
 

John Forrister

GTD Connect
Staff member
Although, on second thought, if you want to limit the number of actions that you see, having only one next action per project might appeal. I can really appreciate that approach. For me, limiting the number of actions that I see doesn't outweigh the chance to move one project forward on multiple fronts (contexts), by having multiple next actions listed. After I've paid the switching cost between contexts, I want to plow through as many actions as are available.
 

Oogiem

Registered
Where we most often see people tripped up is when they have items on their next actions lists which are in fact dependent on something else happening first, so they're not truly "next" actions. Those would go back into project support, brought forward to the next actions list when the dependency is out of the way.
Or put directly in your tool if it allows a way to hide dependent actions. That's why I disagree with the Omnifocus set-up guide on making the default for new projects as parallel rather than sequential. It's easier to mess up as a new user if you allow that sort of parallel actions but you can change the default and that tends to enforce good GTD practice.
 
Top