This Focused Performance Weblog is a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective. TOC is noted for its applications in Project Management and Multi-Project Management (Critical Chain) and Operations Management (Drum-Buffer-Rope), as well as in Marketing, Strategic Planning and Change Management (TOC Thinking Processes). If you are on an archive page, current postings are found here.
"What does a credible schedule look like? What are the units of measure of credibility for a schedule? How would I recognize a credible schedule is I had one in front of me?"
A couple things I would look for are...
A minimal number of tasks with no successors - Other than milestones related to the delivery of specific, real value themselves, maybe one or two related to getting certain things done by a certain time along the way. Other than that, the existence of tasks in a plan or schedule are only justified if they contribute to the actual "external" deliverables of the project - the project's product.
Range-based promises - If things go better than we deserve to expect, we'll deliver around here, called out specifically in the schedule. If not, delivery could occur at some later point in time, called out specifically in the schedule. The promise is that we'll work to deliver between those two points, closer to the former than the latter if at all possible. Any specific, hard-edge promise is based on the latter, later time. For Glen's idea of "maturing objectives", the fuzziness of promisability can be refined with additional "maturity." (Alternatively, minimally I'd like to see a confidence level associated with a particular promise date, but my preference is to see a delivery window.)
Resource leveling - If task A and task B require the same resource, they can't be scheduled for the same period of time.
Time to fix - One of my pet peeves is finding a "test this" or "review this" task without related "fix if it's broken" and "re-test" tasks, or even another iteration of fix and re-test. If you need to test, you might need to fix, which will take time. And if you're sure you won't need to fix, then why do you need to test or review?
Clarity of dependencies and deliverables - A list of tasks and dates is not a schedule. I want to easily see the dependencies between tasks. The handoffs of "internal deliverables" live on the "arrows" between the "boxes." I also like to see verbose task descriptions that provides information about what the predecessor task is delivering to its successor.
Again, from Glen:
"Planning is a management function. Scheduling is the mechanical production of the sequence of work efforts needed to implement the plan."
To me, a fair amount of the plan can be documented in a network diagram that identifies tasks, resources, and dependencies. Scheduling takes that plan, adds to it information about baseline resource capacity, develops a timeline for the project, then looks further at the resource availability vis a vis other projects, and then applies that timeline to a calendar.
But this planning doesn't end with the schedule. As Glen points out, planning (and re-planning) constitutes the "management" of the project. It involves the process of modifying previously planned methods and schedules when they come up against reality, so that the promises of "maturing objectives" remain "deliverable," while at the same time narrowing down the delivery window as work is completed.
It also involves the process of refining aspects of the original plan and schedule as the objective "matures" and more is known, allowing us to fill in previously fuzzy aspects of the plan.
Periodic, on-going re-planning is how a schedule and its promises are kept credible.
View Frank Patrick's profile
