A common approach to "getting things done," in the project world is to do the work at the last minute. This is happening all the time on nearly all our projects. David Allen's Getting Things Done is a "must read" for anyone in the getting things done business. While Allen's suggestions have tremendous merit for individuals and possibly organizations, in the project world there are some interesting impediments:
- If the project plan is not a guide to work, instead if the project plan is a mere suggested path for work, then the project team is free to perform the work in their own manner. This is possible "within" a work package or withing a Scrum iteration. But outside these boundaries, if work is not performed in some logical sequence, then work piles up at the end and "the last minute" rule is invoked.
- If we can't measure our capacity for work, our physical progress to plan, our "rework" or "do over" rates, then work piles up and the "last minute" rule is invoked.
- If we are not prepared to "start" work on time, then we'll probably not finish work on time. This is the basis of the Lean Construction "make ready" concept.
The paper "Getting Things Done: The Science of Stress-Free Productivity," Francis Heylighen and Clemet Vidal, the Getting Things Done Principles are outlined. They are:
- Collect
- Process
- Organize
- Review
- Do
In the collect phase, things that catch your attention as potentially relevant are captured and made ready for the next phase.
But in Project Work, the things that catch your attention are already present. They are in the Integrated Master Schedule (IMS) as Tasks, Work Packages, deliverables, and their business or technical outcomes. Yes there may be "blue birds" that fly in the window. Unanticipated rework, possibly new requirements that have not made it into the IMS, unfunded directives, or possibly event things that you forgot about until it comes time to do the work.
Planning is the "making of a strategy for the successful completion of the work needed to deliver the value expected by the stakeholder, on-time, on-budget, and on-specification.
Just so we can head off the folks that believe otherwise...
The act of planning and the resulting plan makes absolutely no assumption that the plan is fixed, unchangeable or in any way static. Planning is the emergence of a solution in the presence of changing requirements.
A Plan without the ability to update the plan in the presence of uncertainty is not a Plan. It's a Power Point presentation. It's also BAD project management.
SO WHAT'S THE REAL PROBLEM HERE?
With the GTD book in hand, why is project work still hard. Behind schedule, over budget. Some have suggested the underlying processes of project management - PMBOK for example - are flawed in some way. This of course is unlikely, since the PMBOK processes are used on successful projects as well as unsuccessful projects. But that's another issue all together.
So what is the problem? Let's look at some of the source of project difficulties. But first a high level concept of "executing the plan":
- Executing from Left to Right in the schedule means new work becomes visible. The "coming due" report is a handy tool
- Planning from Right to Left, predefines the "coming due" work and assures the Plan (remember the Plan is a Strategy subject to external influences of reality) has the proper mitigations, sequences, resources, etc. to be at the right place at the right time with the right deliverables.
Now what happens if you don't start on time? That is there are "late starts." Usually this means a "late finish." Once there is a Late Start, the Plan is now jeopardized to the extent that the "Planned Schedule Margin" is eroded faster than is planned.
The First Problem
So this is the first issue. You must start on time. In order to start on time, you must finish the previous activity on time. In order to finish on time, you must start on time. Etc. Etc. Etc. Hal Macomber's "make ready" can be seen in the wonderful paper "Securing Reliable Promises." Now all of this is really nice theory, but the practice is likely difficult for the following reasons:
- A description of "what's coming due" needs to represent reality. Reality of a plan that is credible in the sense that promises can be made and kept against it.
- Maintaining the description needs to be fast and cheap. Fast and cheap in that effort and cost to make changes to the plan can be paid back by the time the deliverables from the plan are delivered.
So one approach is only plan to some level of granularity in the master schedule. This can be done at the Work Package level. Since a Work Package may be new to some here, it's simply:
- This is a generic term for a unit within a work breakdown structure (WBS) at the lowest level of its branch, not necessarily at the lowest level of the whole WBS.
- A subset of a project that can be assigned to a specific party for execution. Because of the similarity, work packages are often misidentified as projects.
- The set of information relevant to the creation of one or more products. It will contain the Product Description(s), details of any constraints on production such as time and cost, interfaces and confirmation of the agreement between the Project Manager and the person or Team Manager who is accountable for the delivery.
So if the planning and the supporting schedules are done to the Work Package level, then sequenced, this will be a really good representation of what needs to be done at what time.
The Second Problem
The second issues above starts with not defining the entry criteria needed to start the work. Most often we focus on the "exit criteria" and assume this is sufficient for the follow on activities. This bi-directional exchange between two sequential activities is the basis of success. At least success in fully revealing the dependencies.
GETTING THINGS DONE ON PROJECTS
Using the concepts of GTD, projects already have a list of arriving work. From that point on the GTD processes can be used.
Everyone back to work
