Forum

  • If you are new to these Forums, please take a moment to register using the fields above.
Announcement Announcement Module
Collapse
No announcement yet.
Projects - prioritizing feature requests Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Projects - prioritizing feature requests

    I've been reading about and slowly starting to follow GTD for about 6 months now.

    I'm a bit confused about organizing my projects.
    I'm a software engineer - so often a project contains subprojects as well as requests. We are a small team of 3-5 people.

    For example:

    Project: Complete version 1.2 of software
    Subproject: Get latest compiler
    Tasks: Download
    Tasks: Install
    Tasks: Test
    Subproject: Fix account login
    (etc. you get the picture)

    I've thought about switching to a project management software for the overall picture, but how do I integrate that with GTD in my task scheduler, etc.

    And how does one handle requests and meetings?
    e.g. User feature requests - "add new user type" - would I just add a new "subjproject" as needed?
    e.g. Get updated xyz from Miriam at next meeting.

    Maybe I'm missing something, but it's all just a little confusing. =)

    TIA,

    Becky

  • #2
    Becky, the difference between Projects and longer term activities can be a subtle one. Perhaps you have read it, but if not, this article from David might help.

    http://www.davidco.com/tips_tools.php#

    HTH,
    Gordon

    Comment


    • #3
      Many people have had good things to say about Shadow, although I don't have any experience with it. It you routinely have projects that have subprojects which in turn have their own subprojects, Shadow seems to be designed to handle that.

      As far as what I do personally, each subproject is a different entry on the projects list. If needed, the overall project is also an entry.

      Comment


      • #4
        Projects - Prioritzing Feature Requests

        "Maybe I'm missing something, but it's all just a little confusing. =) "

        becky -

        I clearly identify with your confusion and desire to find the "missing link(s)". I believe Jason captured a key in an earlier post (follow cosmo's link). It's about letting your brain do some connecting of relevant Next Actions <> Projects. Vital to my system's success is applying the relevant keywords or keyphrases. I will intentionally Copy/Paste portions of my Project subject line and use them in my Next Action subject line. This allows me to quickly relate them, or to use the Find function very effectively when needed. If I want to capture a few actions that are 2 or 3 steps down the road I may capture them in the Note attached to the Next Action and migrate them to the subject line to replace those I accomplish.

        Complex projects do benefit from tools like MS Project. However, don't try and have the lucid simplicity and power of the GTD system be or duplicate those other tools. Rather, let it lead you (via ticklers, etc.) to those tools at the appropriate times. I've managed multimillion dollar projects this way as well as refinishing the table in my garage. It works, just keep it simplel.

        Comment


        • #5
          Projects - Prioritizing Feature Requests

          Becky,

          I'm a systems architect, and I'm using GTD. Although GTD's treatment of project has an elegant simplicity and is very useful for a large number of day to day projects, it doesn't scale up well when planning and executing complex projects. So here is my two cents worth.

          If your projects are running in excess of 100 hours or you are planning the work of a team, you should probably use project management software anyway. Project management software allows you to easily build a hierarchical work breakdown structure plus it enables you to determine the parallelism in the project work. (More on that later.) However, unless you plan your projects down to the granularity of a next action, it will only get you so far. Most people don't, by the way, because in many cases, it's just impossible to do. You really don't have a clear idea about how to do some things until just before (or even some time after) you have started doing them.

          A project plan is essentially a project tree. It starts with an overall project like "Build a Global Sales Data Warehouse for ABC Company." The top-level project is then detailed out in successive levels of sub-projects. For any project in the tree (X), its sub-projects answer the question "How do I do X?" Its parent project answers the question "Why am I doing X?" So in our example, if I ask "How do I build the warehouse?" the answer is "I gather requirements, design, build, etc. etc." If I ask "Why am I gathering requirements?" the answer is "Because I am building a global sales data warehouse for ABC Company."

          It is this recursive decomposition of projects into sub-projects that the GTD theory doesn't handle too well.

          Another wrinkle is that projects can be decomposed not only into subprojects that must be performed sequentially, but also into sub-projects that can be performed in parallel. It's the parallelism in projects (even simple ones) that means that a large project can have several next actions. I've read posts that say that a project can have only one next action, but I think that's a mis-reading of GTD. A next action is the next physical thing that you can do to move a project forward. A project can have as many next actions as there are parallel tracks in its plan.

          So what do you do?

          Plan your project using either project management software or an editor that can easily make outlines. Plan it down to the level that you can really plan, and you're not just whistling in the dark.

          If you have project management software, also put in the task dependencies so you can easily see the parallelism in a PERT chart. If you are using some kind of outliner, use a mark-up scheme to show you the parallelism. For example, you can bullet parallel items and number sequential items.

          Keep track of the active sub-projects on the plan, i.e., the ones that are currently being worked on - or could be. You can do this by putting them on your project list, or by highlighting them somehow on the project plan.

          Work each active sub-project just like a small, individual project. Appointments go on the calendar. Time-delayed items go in the tickler file. Next actions go on the appropriate action lists.

          When you finish an active sub-project, mark it as done and then return to the project plan and see what sub-projects on the plan can be activated. Activate them and keep on trucking.

          What this approach does is to only present the active sections of your project plan for action. The rest of the sub-projects remain hidden. Your project plan acts in a sense like a Someday/Maybe list for the project.

          Also, if a sub-project "explodes" into something more involved, you can always extend your project plan by decomposing the sub-project into a number of sub-sub-projects and process each of those as outlined above.

          Hope this helps.

          Scott

          Comment


          • #6
            Thanks to everyone for their suggestions. I've been starting to plot out bigger things in a project management software and transfer tasks from that to my action list.

            Scott, looking at each sub-project as an individual project helps understand how to use GTD with this, but manage the complexity of the larger project.

            I have a more specific question, for yourself or others who handle this sort of thing. I'm kind of new to managing projects and other people - I work at a small academic institute and am pretty much the "senior" person on the project. I'd like to make our work a success, but have few resources to draw upon here for advice or feedback, so reading this list is a big help.

            Another major concern in software planning is handling customer requests - that is, the requirements that arise *after* requirements gathering is done, but customers realise that they want something else added. My thought is to maintain a list of these requests; review and prioritize them at my weekly review, and then add them to the project plan as needed. Does this sound reasonable and flexible enough?

            Thanks!

            Becky

            Comment


            • #7
              Gathering and Prioritizinig Client Requests

              Becky,

              Another major concern in software planning is handling customer requests - that is, the requirements that arise *after* requirements gathering is done, but customers realise that they want something else added. My thought is to maintain a list of these requests; review and prioritize them at my weekly review, and then add them to the project plan as needed. Does this sound reasonable and flexible enough?
              The short answer is "yes."

              When items like this crop up during a development project, we track them in an "issues log." The log tracks when issues arise, to whom they are assigned, when they are resolved, and how they are resolved. "Resolved" means different things depending on the issue. Client questions are resolved when they are answered. Reported problems are resolved when they are diagnosed and a solution is either put in place or added to the project plan. New requirement are resolved when their impact on the project is assessed, a decision is made as to whether or not to add the requirement to the current release of the system, and the work of "retrofitting" the late requirement is added to the appropriate plan.

              Adding late requirements as new sub-projects is really useful to show the client how much work the late requirements are causing. You will need this in order to renegotiate (or at least reset expectations about) the cost and duration of the development project.

              Scott

              Comment

              Working...
              X