• If you are new to these Forums, please take a moment to register using the fields above.


No announcement yet.

How to define a project

  • Filter
  • Time
  • Show
Clear All
new posts

  • How to define a project

    Hi folks - new to the forums. Been trying to get a grip on my life with GTD and in that phase (seems many others are) where I am just struggling to develop this into the habit it needs to become.

    The one thing that is confusing me is how to define a project. I am in sales and I use an app called Asana which I find useful. I can define a project and within there, multiple tasks each with its own responsible person etc - great for delegation. But my question is - what is a project?

    Eg in the sales area, would SALES be a project and then each lead is a task with its own subtasks? Or would each lead I am working on be a project and then the tasks go under that? At what level would you work at?

    Thanks for the help.

  • #2
    Big, slow sales to few prospects? Or small, fast sales to many?

    Generally, I would say Sales as a whole is not a project. It will never be completed. You could regard it as an Area of Responsibility, but it is probably too large to be an AoR, unless your job also involves other roles, too, besides Salesperson, such as Sales Team Manager, Adviser to Management (Board member etc), Committee X member etc.

    It seems to me, from discussions in this and other forums, that there is wide variation to what kind of action items people want to put into theirs apps apps, and what kind they want to keep outside it (in some other app or on paper etc). At the one extreme, many seem to want to keep only the now current Next lists etc in the app and all the future tasks (considered as belonging to the project support material in GTD) in some other system. At the other extreme, you have the likes of me, who prefer to keep all action items (including projects etc at higher levels) in the same app (but still be able to see them separately). What is your preference? Your preference will affect how you make best use of the "levels" you have in Asana (Asana has a top level called "Organization" that you could use for whatever you like - are you at liberty to make use of that freely, or is that predefined by your employer?).

    As a first iteration, not knowing either your preferences or the type of sales you do or any other roles you may have at work, I would say that you should define projects for big opportunities/contracts, and complete these projects either when the deal is signed or when final acceptance of the delivery is signed, depending on what kind of sales you do. If you do very large sales, though, e.g. aircraft, each of the prospects may be better seen as a Goal, however, and contain a number of medium-size projects for the various parts of the sales process (e.g. spec, pricing, demo, convince board, convince union, convince pilots, convince marketing etc).

    But for smaller things, it may get clunky to use project. GTD says that anything with more than one step is a project. Fine. This means you will have lots of projects, and that's fine. That's what many people do in their apps, too. Personally, though, I see no need to map my GTD projects exactly to whatever feature happens to be called "Project" in the app. I think "tasks with subtasks" sometimes gives you a neater list, more easily reviewable. (Since in Asana you cannot tag subtasks with a context, though, this approach has some serious limitations, but it may not matter if in your case all the subtasks require a similar context, say they are all desk/computer/phone/office_hours type tasks.)

    One "ugly trick" I use is I use the app's "project feature" for something besides real projects, too. I also use the project feature to keep buckets for single tasks that belong to a given Area of Responsibility - just to make the list more easily reviewable.

    If you have lots and lots of prospects, you could consider using an external system (CRM or Excel lists etc) to manage the high-volume repetitive sales work (cold-calling, sending info packages etc, even contracts for signature). In that case, in Asana you would only need to record the major things. If you want to, you could simply have a single task that says "Work the CRM system for X hours" for all those repetitive things (and you'd probably have addresses, phone numbers etc in the CRM system).
    Last edited by Folke; 12-13-2013, 03:56 AM.


    • #3
      Originally posted by Scooterza View Post
      But my question is - what is a project?

      Eg in the sales area, would SALES be a project and then each lead is a task with its own subtasks? Or would each lead I am working on be a project and then the tasks go under that? At what level would you work at?
      For me the definition of a project is something that will take 2 or more individual tasks to do that can be done independently of any other set of tasks.

      If I adapt that to a sales environment each potential prospect or each major contract or each RFP is a separate project at a minimum and in many cases those may actually be multiple projects.

      So say you have a major client X. There are 2 divisions both looking at your product. Each division would have it's own project and I'd set it up like this: "Division A purchases and installs product Y successfully" And "Division B purchases and installs product Y successfully" And I'd put the various tasks under those projects.

      I don't like having sub-projects. For me it's one layer of projects or I get lost in the weeds trying to move forward.

      Sales would be an AOF for me.


      • #4
        Hi, Scooterza. Welcome to the forum. I'm a salesperson and a struggling GTD'er, so maybe I can help you struggle with GTD and sales. (Actually, what I had termed "struggling" I now recognize as "learning." Trust me, with practice GTD gets easier.)

        Rather than track each lead or prospect a separate project I keep a context called "Calls - Prospects." If I call and leave a message I move the list item over to "Waiting For" and try again after a bit. I mark each prospect complete if I don't hear from them after three attempts or if I speak with them. I note the outcome in the task subject or body so I have a record of what happened.

        If the prospect becomes a potential sale I record that as a project and manage it like I would any other project. I mark the project complete if I win the sale, lose the sale, or the prospect kills the project.

        I have to use a company CRM system. I don't like it because it is cumbersome, cluttered, and more a tool for micromanagement than an enabler of producitivty. So I feed the CRM beast to the extent that I am required to (some salespeople don't enter anything into CRM but I don't believe in ignoring my employer's requirements). But I truly manage all of my activities in my personal GTD system, which "lives" in Evernote.

        I wouldn't lump everything under a project called "Sales" because that's not really a project. It's an Area of Focus. With respect to your job, it's the only AOF that really matters -- but you can never give yourself closure with it which I think would be demoralizing.

        I hope that helps.


        • #5
          One point of clarification: technically speaking if you set your sights on reaching a prospect to probe for sales opportunities that could meet the definition of a project in GTD parlance but -- I don't find it useful to track prospects as a project unless there's a real possibility of a sale. Otherwise you call, you wait, you call again, you wait again -- maybe you reach them, maybe you don't. Technically speaking each call is a separate next action but I don't feel I need a project to track that activity.

          If a prospecting effort is complex or has a lot of moving parts -- for instance, if I'm trying to reach multiple people within the same organization to create a groundswell of support for what I can offer -- I might track that as a project. I make the decision based on what's useful to me.
          Last edited by bcmyers2112; 12-13-2013, 08:42 AM. Reason: Edited to make clear what I do works for me - YMMV


          • #6
            I agree that a project is something that requires two or more tasks.

            However, if you find that you have lots and lots of projects that are practically identical, you may want to look at "cutting" across the work a different way. For example, instead of:

            Project: Sell to John
            Project: Sell to Joe
            Project: Sell to Jane

            you might have:

            Project: Maintain weekly calls to leads
            Project: Track customer orders

            These two projects would be fed by project support material, lists that probably include John, Joe, and Jane, and their orders. They're also ongoing projects with no end, but I don't actually see that as a flaw.

            These ongoing projects might spawn short-term projects. For example, "Track customer orders" may assume that orders are going well. If the WidgetMatic order for John develops an issue, you might break that issue out and create a new project:

            Project: Resolve John Widgetmatic issue
            Next action: Call warehouse.

            Once John gets his working Widgetmatic, that project is closed. But for all of the other orders that were progressing as planned, you didn't waste a lot of time creating a bunch of identical projects.

            On the other hand, it's possible that every single order requires a lot of custom effort--maybe, say, you're selling large groups of theater seats and you're directly involved with the architect and contractor, dealing with custom issues, for every single order. In that case, you might indeed have a separate project for each potential customer, or at least each sale.


            • #7
              Small reflection:

              Of all the approaches presented here, I'd say Oogiem's is the approach most easily recognized from the books. These are all projects, and they all sit at the same (one and only) level. (And if you like to see the relationship between related projects you can always prefix the project names.)

              bcmyers's approach is also totally by the book (at least if there is only one action per lead). Requiring a phone to be able to do the task, or requiring a prospect to be at the other end of the line to be able to do the task, are both valid contextual requirements. Having a "combo context" like "Calls - Prospects" is perfectly valid, by the book.

              The approach that both I and Gardener take - using the app's project feature for other things than projects; things that could be described as AoRs - is also by the book, but much less obviously so. GTD does have AoRs. Most apps do not. The tools you have at your disposal aren't always (or never) complete representations of the entire set of GTD concepts. Some things you'll have to leave outside of your app (and keep them somewhere else) and some things you may be able to squeeze in somehow into your app if you use workarounds (that can be more or less elegant).

              I have used this workaround for a long time, and am very satisfied. I prefix my "AoR projects" with a backslash (\) to clearly see the difference between "real GTD projects" and "AoR containers for single actions". At the Goals level in my current app I use a double backslash (\\) to more easily see those "goals" that are not really new goals, just high-level containers for ongoing stuff that belongs to a certain group of related AoRs.


              • #8
                Just to throw in yet another suggestion... it's also perfectly valid to have more than one Projects list, if it makes sense. If you have a ton of Sales projects that you want to see at a glance, you could create a Projects - Sales list.


                • #9
                  Originally posted by Folke View Post
                  Since in Asana you cannot tag subtasks with a context...
                  One quick thing - in Asana you actually can "tag" subtasks to implement contexts. See the images below this post to see what I mean.

                  I'm a user, like Folke, who uses the "Projects" feature for more than just strictly projects. I have a General Tasks list (for those one-off tasks that are not part of a project), Someday/Maybe list, Good Reads list (because I share the workspaces with co-workers who do not follow GTD like me, we lump articles and such here that are relevant to what we're doing), and an AoR list (Areas of Responsibility list, where we list every project we're working on and who the DRI, or Directly Responsible Individual, is for that entire project). So yeah, I don't just use it for Projects. I color these "Projects" black, put them at the top of the list, and start them with a symbol of some sort to differentiate them from the actual Projects in the GTD sense.

                  Because of the ability to heavily nest subtasks, and the fact that in Asana it's easier to view tasks in a list than projects, I prefer to use the Projects feature for large-scale projects (Launch Website Redesign, Complete December's Newsletter), and tasks for smaller parts of larger tasks (Finalize Homepage Content Layout, Add Blurbs for Main Events) that may or may not have subtasks (what would also, under GTD, be considered a Project). Since switching to Asana, this is one thing I've fudged a bit from the GTD books because Asana doesn't let you have Projects inside of Projects, but my mind prefers to clump these things by an overarching task, not having each teeny little item an individual step in the process (I can't imagine navigating a 400+ task list for a website redesign when that can easily be condensed down into neater packets!). But it flowed naturally and clicks for me, so I've not looked back.

                  I'm a heavy user of the Today/Upcoming/Later features in the My Tasks section of Asana as well, and since subtasks can be assigned everything a regular task can, I can assign subtasks to Today on a per-subtask basis, so it's really no loss for me.

                  Click image for larger version

Name:	Rebrand__Launch_Website_3_0_-_Homepage_-_Asana-29.jpg
Views:	1
Size:	28.1 KB
ID:	1045

                  Click image for larger version

Name:	computer_-_Asana-4.jpg
Views:	1
Size:	31.3 KB
ID:	1044