Developing plans that are broadly and consistently useful over time can be quite a challenge. Plans are nearly always useful to someone for some period of time, or we wouldn't produce them at all. But like the old line about the difficulty of fooling all of the people all of the time, plans are rarely useful to all of the people all of the time.
Planning is most useful when it properly anticipates the path of minimum rework and maximum collective resource utilization with a minimum of resource expenditures in planning and tracking. Such plans must clearly make decisions about the level of fidelity at which to plan things. Much as the
coastline paradox, the best laid plans don't have a particular length, but do have tradeoffs that they must help accomplish, and constraints which they must satisfy.
We often must plan a project at multiple levels concurrently within an organization. This is especially true when the project is complex, or when its scope or strategies are undergoing significant change due to problems which have arisen. As a result, we often end up using two different types of tools to support these parallel planning efforts - one for the coarse-grained planning, which we use to coordinate efforts across work units, and a different one for detail-oriented planning, which we use to think through and communicate all required actions within a work unit. The coarse-grained tool is used to portray targets for coordinated action. The fine-grained tool is used to manage the work required to achieve those targets. Somehow, the information in these two types of tools must be periodically synchronized. This is one of the key objectives of project management - to sequence work, reconcile problems with prioritization and handoffs, and balance the workload of performing resources in order to shorten a project’s duration.
There are two primary approaches to implement such
project management practices. Under the first approach, organizations expect everyone to plan their own work, and apply these practices in developing their plans. Someone on the project team must still be responsible for aggregating individual inputs and collectively reconciling disconnects to optimize the overall flow of this work, but plans are essentially driven from the 'bottom-up'. This approach works well with smaller teams in which there is limited coordination required between individuals, and where there is a culture of loose accountability and flexible delivery terms.
Under the second approach, the culture, expectations, and historical track record are that performance targets will be achieved. To support this goal, project management specialists are assigned the responsibility for coordinating all aspects of planning activities. When such specialists are thus engaged, they typically craft the overall structure of the plan, and lay out the steps in an orderly fashion based upon interviews and their own understanding of prior efforts and group practices. In this situation, they typically produce an initial sketch for the work unit's plan which splits the available time on the project up into pieces, establishes time budgets for those pieces, and expects responsible groups to fit into this structure, or negotiate for changes to it. In this approach, it's also typical for the status of projects to then be fed back through these specialists, since they are the ones who best understand the often complex dependencies that have been built into this framework. When these specialists organize the planning process in this way, the actual detailed actions required to do the work are often ignored, and as a result, the resulting task durations are often unrealistic, since the nature of the work itself has been idealized, and often hasn't been fully thought through. But this may not be immediately evident, since these top-down, abstract descriptions of work are disconnected from doing the work itself.
These project management specialists are typically supported in developing these plans through the use of industrial strength
project management software. These packages provide analysis and management of the planning information, and help the specialists provide this information in a variety of representations to the stakeholders who are leading the overall effort. Unfortunately, such tools are often not used by the grass roots team themselves, since they have steep learning curves in order to be used effectively. Instead, extracts are periodically produced of plans and status, and published as reports or screen snapshots of schedule baselines. Changes to those baselines are also usually tightly controlled by change management processes, which work to minimize schedule updates, and thus can reduce the relevance of these plans to those who are doing the work.
Microsoft Project and
Primavera are the market leaders of these types of applications. These tools are rich with features to translate effort and resource estimates, manage work at multiple levels of abstraction, support meticulous scheduling and allocation of resources from limited pools and availability constraints, and coordinate complex task interrelationships across many performing organizations. Although license costs for these tools are high, the real costs of planning for their users arises from the regular involvement and coordination between these dedicated project management specialists, and those who understand the details of the work. These communications exchanges involve providing information on a regular basis to update status relative to the original plan, even though that plan may no longer have meaning to those who are doing the work. As a result, two individuals are involved on a regular basis to capture information that has limited utility, and which may even provide a false sense of security.
Problems arise with these plans despite skill and efforts of these specialists. The problems occur since they have been required to produce plans for work that is not yet well understood, and utilizing resources which are dynamically shifting across many tasks within the organization (often according to poorly understood priority changes); yet somehow these specialists are expected to provide immediate and effective mitigations as risks and issues emerge and can no longer be ignored.
Yet something is seriously wrong with this picture. The underlying operating concepts which these tools are based upon do not easily accommodate task
uncertainties which are a part of nearly all engineering work, and are based upon false assumptions that resources are interchangeable and can be delivered just-in-time, as if they were procured raw material. In logic, one might say that the underlying ideas behind these tools are necessary, but not sufficient.
Supplemental techniques have been developed for some of these shortcomings. For example, add-ons for these tools are available which enable use of
Critical Chain Project Management, an approach which can partially address some of the problems which arise with single-point estimates. The CCPM approach requires that time and resource buffers on the project’s critical path be made more explicit and visible. This is believed beneficial since statistically, only half of a project’s tasks should theoretically exceed their 50% confidence estimate, and since delays accumulate over time. Under the approach, these buffers are used as a safety margin across collections of tasks, and provide a means of tracking how much uncertainty is actually being experienced through consumption. The challenge of this methodology lies in getting individuals to actually 'give up' their own contingent buffers which they naturally build into their schedules when they produce their estimates, so that individual contingency can be aggregated into these collective buffers, and then placing these buffers in the appropriate place in the schedule. In my experience, these interventions require considerable practice and difficult changes in perspective for the work group, and require
even more sophistication than normal methods to use effectively on a consistent basis.
The underlying constraints behind planning under the above methods - the causes of uncertainty for performing the work and the work throughput of planning specialists - remains largely unaddressed by these tools. A new offering,
Liquid Planner (LP), promises to offer interesting functionality that fills these gaps nicely. LP is like a task list on steroids. At the most basic level, there is nothing new about task tracking tools. Such functionality is everywhere - in competing products like
Backpack, at the core of most workflow solutions, and even in collaboration tools like
Microsoft Sharepoint. However, LP incorporates novel offerings that go considerably beyond such basic functionality, which are obvious from their depiction of each task as a range of possible completion points for the activity, a depiction which highlights the probabilistic nature of LP's scheduling engine. This concept is at the root of their effort to provide a dramatic departure from traditional scheduling tools, and deliver a toolset that efficiently captures and represents the best information available about current project status and the implications of that on future project performance. Many innovations are involved in pursuing these ends, and are outlined below:
- LP separately maintains information on estimates and commitments (called promises), to highlight the need to manage and communicate gaps between these two values consciously and deliberately.
- Since the long-tail uncertainties inherent in unprecedented work tend to be the primary factor which affects a project's overall schedule performance, LP requires the capture of upper and lower bound range estimates for each task. LP then renders that information for tasks and aggregate activities using the graphic shown above, for both individual tasks, task chains, and aggregate tasks, and provides alerting should recommended promise dates encroach on committed dates.
- LP expects those responsible for the work to provide ongoing, updated best estimates of work remaining (while retaining the full history of prior inputs for accountability). This dramatically improves the effectiveness of communications, the usefulness of the resulting information, and means that the process of producing schedule updates is as lean as possible.
- LP lays out task sequences utilizing a priority-based scheme (rather than just explicit task dependencies) to keep resources working on the most important work throughout the project. By doing this, the tool captures a history of accomplishments, and establishes a projection of future work over time, while providing features to structure the presentation of this work as it unfolds. By separating 'real' dependencies and those resulting from these dynamic task priorities, a more useful communications of the immediate focus of team is available, and task priorities become a legitimate and needed basis for communicating next steps on an on-going basis. Different stakeholders can be granted access to these different schedule controls, in order to involve the right individuals in influencing the order in which tasks are to be performed.
One of the biggest challenges for any team leader is to manage assignments so that work is spread appropriately among those who are available to do the work. Since doing this work often can run up against roadblocks which require waiting for someone else to complete an action, it is important to know which people might be temporarily available for reassignment. One of the most effective productivity enhancements available to groups is to make sure that all team members are kept busy focusing on the most important tasks available to be worked on. Such focus is difficult to maintain, and can rarely be held for long sequences. Groups often find members spending the majority of their time in their hour work week on non-value-added tasks. Such distractions result from things such as inefficient or ineffective meetings, unnecessary email communications, unplanned rework, and other activities which do not directly result in reducing the work in process backlog for the group overall.
Since LP places an emphasis on always estimating the amount of remaining work required to complete a task, it always highlight the potential impacts which this variability can introduce over time. As a result, the Cone of Uncertainty is made visible in the range of projected completion dates and the gap between that and any promises which have been made. Many reports are available (all nicely filtered in the ways that you'd like) which allow you to focus in on the tasks which have the biggest spreads in their estimates, and discover when the work backlog curve stops growing and heads towards completion, an important indicator for completion
LP attempts to go beyond this by deliberately providing something for the people who must make these commitments. It helps them to better communicate more accurate information about their tasks on the project.
This is essential in order to ensure that the information in LP about what is really going on is accurate and meaningful. This is one of several socialization features of LP that seek to improve communications about what it will take to realize the key accomplishments that any project must achieve in order to be successful. While these features are notable and worthwhile, they will only be effective if the team finds them useful, and embraces them. The LP team is a huge believer of the value of the functionality in their releases, and has learned to become quite proficient over time in using the tool's features to accurately project completion dates. By capturing a timelog of all detailed, time-boxed tasks for all members, the tool has helped them retains a historical record of individual and team performance. Over multiple cycles, this information has developed into a meaningful basis for estimating that team members have high confidence can actually be achieved.
Since LP places an emphasis on always estimating the amount of remaining work required to complete a task, it always highlight the potential impacts of this variability over time. As a result, the Cone of Uncertainty is manifest in the projected completion dates and the gap between that and any promises which have been made. Many reports are available (all nicely filtered in the ways that you'd like) which allow you to do things like find who has the biggest spreads in their estimates, or when the work backlog curve turns and heads towards completion.
LP also enables Separately managing plans and promises, and allows burn-down plans for work requirements to be managed and tracked over time. By tracking changes to these plans and dates, accountability is increased.
Techcrunch,
Steve McConnell, and
The Critical Chain all have given early versions of the software good reviews, and the feature set of the software has continued to evolve nicely, since its launch in 2008. LP has been aggressive in pursuing innovations, yet willing to
abandon dead-ends in how they provide their solutions along this journey - a commendable attribute. They are currently chewing on a way to provide the equivalent of earned value tracking within their environment, which will need to tolerate dynamic durations for tasks, while preserving the ability to characterize a single ‘figure of merit’ for CPI as well as SPI. Such openness to experimentation while keeping their eyes on the key information their customers need should positions them well for future growth.
What it doesn't do (at least yet):
Coordinating the flow of work to teams – rather than to individuals - would be nice addition that could provide better support for those implementing lean techniques (with queues, takt time, etc)
Buffer management
Partial effort on tasks; LP always currently assumes you are working on the highest priority task at 100% effort, and will stay focused on it without interruption, when that is an ideal case.that may not always be practical.
A means of selectively tracking sign-off of - the power of using checklists.
A means of summarizing project status for a portfolio of projects (i.e. a dashboard of dashboards) could help keep
Better tie-ins with existing development tools could help better represent the work inherent in those tools.
Earned value - will be interesting to see how they intend to track this.
Recurring tasks
Assigning more than one resource to a task
Critical path computation
