Principles use in Projects

[PY8]

Hello:
Any guidance on use of principles in projects?
The best I have for it: the project's deadline, budget dollars, qualifications of the outcome, e.g., for a project to complete an intellectual property license, principles include that the license be exclusive, that it give the company control over branding, that up-front payments amount to less than 20% of the total, that windfall royalties be covered, etc.
regards,
PY

 

[Brent]

Depends on the project, doesn't it?

I have a project to catalogue my music into certain playlists. I don't need to specify budget dollars for that.

 

[Tony Osime]

Principles - use in projects

The usefulness of principles lies in their universality. A useful outcome for this thread would be a list of principles we could all agree, apply to all projects. Any time we set up a project, we could quickly check to make sure we have observed the principles. This should result in better projects for everyone.

A good test for a principle is to simply ask the question "why?" repeatedly and see the direction it takes you.

 

[Brent]

Interesting! Okay, here are all the Projects that aren't part of my fulltime job. What principles do they share?

Categorize music by mood
Go out on five dates this month
Close JVDS account
Develop Scholarly Database working prototype
Draw thirty heads from various angles, especially profiles
Read through both Japanese course books
Sign up for ING Direct checking account
Download all remaining files from {URL redacted}

 

[madalu]

Interesting! Okay, here are all the Projects that aren't part of my fulltime job. What principles do they share?

Categorize music by mood
Go out on five dates this month
Close JVDS account
Develop Scholarly Database working prototype
Draw thirty heads from various angles, especially profiles
Read through both Japanese course books
Sign up for ING Direct checking account
Download all remaining files from {URL redacted}

I'd agree Brent. Why should it matter if these projects share or don't share principles? I think principles are an intuitive part of project planning--you don't always have to think through them mechanically.

"Go out on five dates per month." You probably have a lot of ideas about the type of individual your interested in getting to know, what constitutes a good date, etc. These are going to be unique to you and to this project.

"Sign up for ING Direct Checking Account." You probably have certain ideas about how you want your checking account to function, what type of balance you should keep in it, etc. Likewise, you probably have some reasons/principles for choosing an online banking account (ease of use, fees, etc.).

Re: Tony's post. There's no science of principles. I don't think that there is a list of principles that all of us could agree on. We might, of course, have certain moral principles that should come into play on all our projects. For instance, I don't want to hurt or take advantage of anyone; I want to spend my time and money responsibly; etc. But beyond that, principles are going to be utterly unique.

 

[Tony Osime]

Principles - use in projects

Interesting! Okay, here are all the Projects that aren't part of my fulltime job. What principles do they share?

Categorize music by mood
Go out on five dates this month
Close JVDS account
Develop Scholarly Database working prototype
Draw thirty heads from various angles, especially profiles
Read through both Japanese course books
Sign up for ING Direct checking account
Download all remaining files from {URL redacted}

Thanks for the challenge Brent: Since our objective is to improve our project management, we should should not simply state what principles your projects share but also consider what principles your projects "should" share, just in case they could be improved by using principles. On this basis consider some principles of goal setting:

Principle One: Goals should be specific outcomes not activities.
Other goal setting principles we could consider for projects:
Goals should have a quantitative and qualitative measure of success.
Goals should be time bound.
Goals should have the best measures (metrics) for their success.
Goals should have the "right" amount of stretch.
Goals should be viewed from different perspectives.

So let us look at each of your projects from this set of principles:
Categorize music by mood
-outcome yes (but only just)
-time bound: no (i.e. by the end of the month)
-measure of success: no (i.e. so that I can..."you complete the objective saying why you want to categorize music")
-right amount of stretch: not much (look for a new goal that comes from the project such as learning something new about moods or categories)
-viewed from different perspectives: no (how would your spouce see this project? -how can we improve this project using your spouce's perspective?)

I have just looked at one of your projects using one (set) of principles. There should be several other principles we can use to assess projects.

Over to you Brent!

 

[Tony Osime]

I'd agree Brent. Why should it matter if these projects share or don't share principles? I think principles are an intuitive part of project planning--you don't always have to think through them mechanically.

"Go out on five dates per month." You probably have a lot of ideas about the type of individual your interested in getting to know, what constitutes a good date, etc. These are going to be unique to you and to this project.

"Sign up for ING Direct Checking Account." You probably have certain ideas about how you want your checking account to function, what type of balance you should keep in it, etc. Likewise, you probably have some reasons/principles for choosing an online banking account (ease of use, fees, etc.).

Re: Tony's post. There's no science of principles. I don't think that there is a list of principles that all of us could agree on. We might, of course, have certain moral principles that should come into play on all our projects. For instance, I don't want to hurt or take advantage of anyone; I want to spend my time and money responsibly; etc. But beyond that, principles are going to be utterly unique.

--------------------------------------------------------
Hi Madalu, interesting comments and a nice challenge.
We can be happy with where we are, or we can choose to do better. If we choose to do better, we might try a positive attitude that looks for things we can use to become better.

I think principles should eventually become intuitive but to reach that stage may take a lifetime of development. In fact, the reason why we use principles is to short circuit the lifetime of learning by trial and error. For simple things, we can keep everything in our heads. When they get more complex, we need checklists. We could, one day, know the checklist so well we do not need the physical list -we just use our mental list.

Incidentally one criticism of principles is that they limit your creativity -so thinking outside the box should be one of the principles!

I have rambled a bit here -but simply put, everything comes from something more general; we define principles as going back along that path until we reach a useful point or perpective to look at other items and compare.

I hope this helps...

 

[Brent]

Thanks for the challenge Brent: Since our objective is to improve our project management, we should should not simply state what principles your projects share but also consider what principles your projects "should" share, just in case they could be improved by using principles.

Seems to me that this is applying an external set of theoretical principles to an existing reality. Wouldn't it be better to extract principles from reality? Why do you think that these principles should apply to any given set of projects?

On this basis consider some principles of goal setting:

Principle One: Goals should be specific outcomes not activities.
Other goal setting principles we could consider for projects:
Goals should have a quantitative and qualitative measure of success.
Goals should be time bound.
Goals should have the best measures (metrics) for their success.
Goals should have the "right" amount of stretch.
Goals should be viewed from different perspectives.

Not to be combative, but could you please explain, for each of the above principles, why you chose them?

For example, let's take the project, "Categorize music by color." I have no need to do that by any given date. It's a huge project anyway; I have about 2,600 songs to categorize. I don't know how long it will take. I don't need any sense of urgency. What would I gain by setting a deadline?

 

[TesTeq]

Deadline helps to get it done.

What would I gain by setting a deadline?

Dealine is a negotiated agreement with yourself and forces you to get it done. If it has no deadline it is Someday/Maybe. With deadline it becomes active project.

 

[Brent]

Dealine is a negotiated agreement with yourself and forces you to get it done. If it has no deadline it is Someday/Maybe. With deadline it becomes active project.

Heh. No offense meant at all, but who is this "you," Kemosabe? Deadlines don't force me to get anything done. It's just a date; it has no force.

But I don't want to get into too much of a refutation of this here, as I fear derailing this thread. I'm very interested to read Tony's reply.

 

[Tony Osime]

Principles - use in projects

Seems to me that this is applying an external set of theoretical principles to an existing reality. Wouldn't it be better to extract principles from reality? Why do you think that these principles should apply to any given set of projects?

Not to be combative, but could you please explain, for each of the above principles, why you chose them?

For example, let's take the project, "Categorize music by color." I have no need to do that by any given date. It's a huge project anyway; I have about 2,600 songs to categorize. I don't know how long it will take. I don't need any sense of urgency. What would I gain by setting a deadline?

Yes, you are partially right - I am applying a set of principles. Are they external? It depends on how you categorize them. Are they theoretical? It depends on your experience. The principles I am applying here came from reality and have been personally tested with my projetcs.

The reason I chose the principles is that they have worked for me and for others. I deliver training courses on subjects such as leadership and teambuilding. In one of my exercises I ask participants to apply a set of principles to their best results and their worst results. In about 99% of the time, most of the principles applied to their best results and were not applied to their worst resuts. As there were a number of principles (about 12) and very different situations, not all principles applied in every situation. But as a set, we were looking at over 90% effectiveness. I have done this exercise with hundreds of people.

To use your deadline case: I might use the principle that 90% of projects will be more successful if they were time bound. By applying a deadline, you bring into focus other aspects of your project that you can manipulate in a creative way to achieve your superior results.

If we applied the principle of creative tension (Setting targets that stretch us) we might choose a deadline that needs some special effort or creativity on our part. We might ask some friends (on the internet?) if they have done this same activity in an unusal way. This could lead to a new way we had not thought of that allows us to complete the task much faster.

 

[TesTeq]

Self-imposed deadlines do force me to get things done.

Deadlines don't force me to get anything done. It's just a date; it has no force.

I do not agree. Every agreement made with myself and not broken is an element of my self-esteem building and maintenance process. Dealine is one form of such agreement. Since I prefer to think that "I am the man who keeps promises", self-imposed deadlines do force me to get things done. For me it is an essential part of my GTD implementation.

 

[unstuffed]

Yes, you are partially right - I am applying a set of principles. Are they external? It depends on how you categorize them. Are they theoretical? It depends on your experience. The principles I am applying here came from reality and have been personally tested with my projetcs.

The reason I chose the principles is that they have worked for me and for others. I deliver training courses on subjects such as leadership and teambuilding. In one of my exercises I ask participants to apply a set of principles to their best results and their worst results. In about 99% of the time, most of the principles applied to their best results and were not applied to their worst resuts.

Forgive the semantic nitpicking, but I think what you're describing there is not so much the application of principles as the observation of attributes. Your participants look at their best and worst projects and see which of them possess the attributes you mention, and from there they presumably take the lesson that crafting a project with those attributes works better than without.

To my mind, that sounds similar to the process creating specific, action/verb-based, Next Actions: if they're not specific, they're not really Next Actions, they're sub-projects or goals or whatever.

So, in your case, you're describing attributes of a project specification that make the project more likely to succeed. Is that about right?

 

[unstuffed]

I do not agree. Every agreement made with myself and not broken is an element of my self-esteem building and maintenance process. Dealine is one form of such agreement. Since I prefer to think that "I am the man who keeps promises", self-imposed deadlines do force me to get things done. For me it is an essential part of my GTD implementation.

I think I'm with Brent here: deadlines that I set arbitrarily have no force. Let me explain...

If I have a project on which other projects depend, or if I have a genuine reason for setting a deadline, I'll set a deadline (kind of). An example might be marketing: I have to do some, and as soon as possible, because I need the money that will (hopefully!) result. So I'll consider that a project of prime urgency.

But there are some things on which I'm quite happy pottering, doing a bit here and there, and with no attempt to set a deadline. In these cases, since there's no urgency, I see no need for a deadline.

I've found in the past that if I try to impose arbitrary deadlines, I just ignore them. There's a fundamental dishonesty there, for me: I know that there's no real need, either internally or externally, so the deadline doesn't work.

Perhaps this is because my work/life fluctuates fairly dramatically, so that items flow into, and out of, the urgent category fairly often. Arbitrary deadlines just make me lose faith in the whole system, so now I only use deadlines for things that really have deadlines. YMMV.

 

[TesTeq]

Self-imposed deadlines.

I think I'm with Brent here: deadlines that I set arbitrarily have no force. Let me explain...

So let me explain too.

There is no external deadline requirement for "Clean my garage" project. But it is useful for me to set a deadline (for example April 30th, 2007) for this project. This dealine sets a timeframe for this project (as you know every task can take any amount of time that is available).

If I will not treat the "Clean my garage" project deadline seriously I would have to come to the conclusion that:
- I am not reasonable, or;
- I am not honest with myself.

 

[Tony Osime]

Principles - use in projects

Forgive the semantic nitpicking, but I think what you're describing there is not so much the application of principles as the observation of attributes. Your participants look at their best and worst projects and see which of them possess the attributes you mention, and from there they presumably take the lesson that crafting a project with those attributes works better than without.

To my mind, that sounds similar to the process creating specific, action/verb-based, Next Actions: if they're not specific, they're not really Next Actions, they're sub-projects or goals or whatever.

So, in your case, you're describing attributes of a project specification that make the project more likely to succeed. Is that about right?

This is fascinating. It has made me think more about the whole process.

Yes you are right in that we can look at the principles as "Next Actions" (I am new to GTD). And most principles would have started out this way. However, what separates a "Next Action" from a principle is that principles are universal -they should apply to every project. Many "Next Actions" are only specific to a particular project.

By the way -what is the best way to get up to speed on GTD? Is there something I can read on the internet?

 

[unstuffed]

This is fascinating. It has made me think more about the whole process.

Yes you are right in that we can look at the principles as "Next Actions" (I am new to GTD). And most principles would have started out this way. However, what separates a "Next Action" from a principle is that principles are universal -they should apply to every project. Many "Next Actions" are only specific to a particular project.

By the way -what is the best way to get up to speed on GTD? Is there something I can read on the internet?

Sorry, I didn't explain myself properly. I wasn't saying that principles were Next Actions: I was saying that your definitions of useful principles/attributes was similar to the definition of useful principles/attributes for Next Actions.

So in the same way that Next Actions need to contain action verbs, be specified and achievable, etc, projects need to be well-defined using similar attributes/principles. It's not that you're applying principles to projects, which to me sounds like an active process: it's that you recognise that a project must have certain attributes to be successful.

Does that make more sense?

As for getting up to speed on GTD, if you haven't read the book, you must. It's all there. Fora like this one help to work out the implementation details, but the meat of the system is in the book.

 

[Tony Osime]

If I were to say what principles should I apply to projects (possibly another word for principles might be useful here) I would say:
"GRIP": G=Goals; R=Roles/Resources/Decisions I=Interpersonal Realtionships P=Processes. Each one of these will have a series of sub principles-3 for each.

G=Goals
1.Goals are specific outcomes not activities?
2.Goals are understood and committed to by all?
3.Leadership towards goals is shared?

R=Roles/Resources/Decisions
4.Resources are sufficient and they are used optimally?
5.Everyone knows their roles?
6.Decisions are based on best information & expertise?

I=Interpersonal Realtionships
7.Trust and openness in communication and relationships?
8.Conflict approached openly and constructively?
9.Needs of everyone has been met?

P=Processes
10.Work is organized to accomplish the goals?
11.Processes are modeled and rehearsed first?
12.Work & communication processes are optimized?

 

[Todd V]

re: Principles, Motivators, & GTD

BE CAREFUL ON USE OF THE WORD "PRINCIPLES":
The use of the word "principles" in this thread so far really is more accurately called values or universally shared attributes. In the same way that gold is the universally shared attribute of three gold statues, so three projects/goals may share the same universally shared attributes -- specific, measurable, etc. BUT, and here is one important thing to remember: This word means something different in GTD. In GTD, "principles" stand for the "standards" for any given project. The principles/standards for the project finish the phrase: "You would give free rein to others to handle all aspects of this project as long as they made sure…". So a minor quibble, but it's important to know that the word "principle" means something very specific in GTD. See pg. 58-59 in the book for more. I'm not against the use of "principle" that has been discussed in this thread so far -- just want to point out the difference between that use and that in the book for clarity's sake.

MOTIVATORS & DEADLINES
It is actually better to talk about "motivators" than it does to talk about deadlines. One of the questions David Allen asks on the 30-50,000ft checklist we all review (or are supposed to review) weekly, is "What motivators exist for you in current reality that determine the inventory of what your work actually is, right now?" For me these break down into the following:

(1) Deadlines put on me by others
(2) Deadlines put on me by myself
(3) Wanting certain desired outcomes
(4) Not wanting certain undesired outcomes

I've found that (1), (3) and (4) are what motivate me the most. (2) rarely motivates me at all. I've given up explaining why and have just accepted the truth about myself. If I'm not motivated by (2) then I have to push those projects and tasks into (1), (3), or (4) in order for me to get them done.

Number (3) on desired outcomes as motivation is also one component I think many GTDers miss in the system. They tend to review their Project Support files and make sure they've got new next actions related to each of their Projects, but they don't make the regular habit of reviewing the desired outcomes on their projects -- "Describe the successful outcome of the project. Envision wild success. And what new things would having this project complete make possible?" See pg 58-59 in the book.

If you don't have problems with self-imposed deadlines, then that's great. Use them to motivate you to finish the project. But if self-imposed deadlines aren't motivating for you, ask yourself what *does* motivate you. Hone in on that, make sure that you review that motivator weekly with your weekly review, and you'll be surprised at how much more progress you see on your lagging projects. Get some fresh momentum on your Projects this week by clarifying their successful outcomes in richer detail and reviewing them regularly. Trust me, you'll be surprised at the results!

 

[Cpu_Modern]

great post. I will definetely review my motivators.