GTD and (software) engineering projects

[CoffinDodger]

I'm new to the forums but did scan to see if this type of question had already been asked. Please forgive me (and provide a link!) if I'm going over old ground!

I've been using GTD for a few years and am a big fan of the system, it really works for me.

Professionally I work in the software industry, and we run projects lasting 9-18 months with teams of 5-10 software engineers. The company does not use or advocate GTD.

In terms of goals/responsibilities/personal projects/next actions I do fine with GTD.

In terms of team leadership activities (review staff, write proposals, produce presentations etc) I do fine with GTD.

However the projects my team work on will have hundreds or thousands of "work items" and "bugs to fix" in a database, with project planning done statistically by people outside of my team, including gant charts and other planning tools. Some of these work items will be assigned to me, some I am waiting for, and a lot I don't care about.

As it's database driven, I can call up a list of items assigned to me easily, but there the similarity with GTD stops. There's not a "waiting for" list analogy in the system. Separate features of the software have their own work items within each software project, but even these can be man-months of work and a great many items.

I'm looking for a way to co-exist the two systems. How on earth do I reconcile these "super projects" with the GTD system?

There is inevitably more to do than I will ever have time for, so making contextual and priority choices about what to do right now is difficult for me.

Really I'm looking for feedback from others who manage large long-term projects and the like. I can get by as I am, but I can always learn some new tricks!

Thanks!

 

[kewms]

GTD deals with finer granularity than most project management software. That is, your project management tool might have "get customer signoff on prototype design," but it probably doesn't have "@call: Joe Customer to schedule signoff meeting."

Thus, you might be able to use the project management tool as part of your project list and/or project support material, with your personal GTD system residing one level down.

Katherine

 

[dschaffner]

As it's database driven, I can call up a list of items assigned to me easily, but there the similarity with GTD stops.

Do you need to export those items assigned to you to your GTD system? Can you add a recurring task to your system called "reconcile GTD with database?"

There's not a "waiting for" list analogy in the system.

Can you just manually add the waiting for items to your system, and as above, reconcile on a regular basis?

- Don

 

[Cpu_Modern]

I would put the big slices of the huge corporate project into my GTD-system as 20k-level Areas of Responsibility.

 

[ellobogrande]

Intelligently define intermediate outcomes and milestones as projects

This is a really good topic. I also work in the IT profession and face the same challenges. Here's my two cents.

I treat my assigned "super-projects" that represent department or company sponsored efforts to implement a software solution the same as any other project. My company assigns release numbers (ex. R12345) and a title to each formal project effort, and those end up on my Projects list (e.g. @R12345 - Billing and Payment System 2.0). I also like to prefix the "super projects" with a character that causes Outlook to group them together. I don't get to mark it off as "done" until either the project formally closes and/or I'm released after fulfilling all of my assigned duties and commitments to that project.

A project release number on my list projects usually doesn't trigger the necessary next actions to move it forward, so I usually have one or more associated sub-projects on my project list. Each sub-project defines the very next intermediate outcome(s) or milestone(s) that I've committed to achieve. I only generate sub-projects that I can actively move on now, not ones that are scheduled to start after a dependency is met or weeks down the road. Most of the time I derive it from the project schedule or gantt charts, which I use strictly as project support material; I only refer to it as needed to generate new sub-projects and next actions.

For example, I would capture the creation of a specific deliverable (which is a typical project "task" with a due-date) as an individual project and add it to the Projects list, and I don't get to mark it off as done until the deliverable is formally authorized. I typically prefix these sub-projects with the release number so that I can identify the associated project at a glance (e.g. R12345 - DES - Physical Interface Design Document). I then generate a next action to serve as the "bookmark" to kickstart the work ("Call Fred re: R12345 design document" or "R12345 - Draft initial design document").

During the course of the project it's possible to have defects assigned to me, especially when testing begins. In my company, each project has or uses a particular defect tracking database in Lotus Notes. When a defect is assigned to a person, an automated e-mail message is sent to his/her inbox. When I receive such a notification, I open the defect using the link in the e-mail, read it, and process it same as I would any other input. If I decide that it's mine to fix, then I add a project to my Projects list (R12345 - D00001 - Defect Description) and define the next action to move it towards closure. I don't get to mark it off as done until its marked "closed" by the originator (that means that the fix was made, implemented, and verified). The defect record in the database then becomes support material that I use to document the fixes and update status.

One frustrating thing about these projects is that sometimes there is no next action from week to week. Often times I finish coding and unit testing but have no other assigned tasks on the schedule except to wait and see if any defects or other requests show up from project team members. However, by keeping the open loop on my Projects list, I review it objectively each week and decide that there is nothing more I can do now, but not let it bug me that there may in fact be something that I should be doing (other than waiting).

I hope that helps...best of luck!

 

[toremor]

Keep it in one system

Very interesting post. I actually planned on posting a similar question some time ago, but never got to it.

I have a partly similar situation. We have a database-based system, named bugzilla, for keeping bugs and wishes from customers.

As David Allen says that you should only have one system which is a complete inventory of projects and next actions. I have found this to be the best way to do it.

My GTD system is always mirroring the bugs/wishes from the other system. If it's a project (in the GTD sense) I add it to my project list and decides the next action. The project name always starts with the number from the other system, like "#9456 make barcodes prettier" Sometimes it ends up in someday/maybe.

During my weekly review I always check the status of all the active projects against my system. I have a someday/maybe project that might automate this check, but I very rarely find differences between them.

Tore

 

[jknecht]

the projects my team work on will have hundreds or thousands of "work items" and "bugs to fix" in a database, with project planning done statistically by people outside of my team, including gant charts and other planning tools. Some of these work items will be assigned to me, some I am waiting for, and a lot I don't care about.

As it's database driven, I can call up a list of items assigned to me easily, but there the similarity with GTD stops. There's not a "waiting for" list analogy in the system. Separate features of the software have their own work items within each software project, but even these can be man-months of work and a great many items.

I'm looking for a way to co-exist the two systems. How on earth do I reconcile these "super projects" with the GTD system?

Our issue tracking system sounds very similar to yours, and unfortunately, the best I've been able to do is treat it as a self-encapsulated little part of my overall GTD system.

When an issue is assigned to me, I figure out the next action and record it in the comments section right in the issue-tracking tool. The main downside to this is that I don't have a consolidated view of all my next actions for a given context: so, there are many conversations with myself like, "oh crap, why didn't I leave the query editor open so I could get info about these other 3 issues while I was in there?" Then again, I'm not that granular with my context lists.

In any event, I find it more palatable than copying much of this stuff into another set of lists.

When I assign issues to members of my team, I use the "follow issue" feature of the tracking tool instead of recording it in my @waiting list -- if I didn't do this, my @waiting list would contain a couple hundred items. This feature sends me an email any time someone updates or comments on the issue, and it is very easy for me to query the issues I am following. Maybe your tool allows for this too?