A Common Root Cause of Project Failure is Reliance on Bad ToolsIn examining the management of failed projects, IDEAS found that the root cause of their failure can almost always be traced to the fact that the project managers relied on “project management” tools that did not address the real needs, activities and priorities of users. The “industry standard” software programs that are the center of current project management systems are engineered to look like they are worth their cost, not to make the user’s job easier. Because project managers are so focused on making the tools work “correctly,” they often do not step back from the process enough to assess whether the project was actually on its way to achieving its goal until the goal had been missed!
In addition, we consistently see that these systems do not provide the ability for disparate team members to communicate and collaborate in real time, nor (often consequently) the ability for management to view real-time status on demand. More often than not, the project management software is only used to produce after-the-fact reports that have no relationship to the real course of progress on the project and serve to obscure rather communicate real status.
Traditional project management systems and tools are essentially mechanisms created to work around the core problem of lack of communication between the design tools, the real world and the project management tools. They are not organically related to the project, and never organically connected to reality.
We can illustrate this with an example from the construction industry. Design engineers typically work in the abstract, 2D world of CAD programs. Quite often, they design a structure without ever seeing the site. The project managers receive a design as a given and attempt to direct its execution. Their principal task is to constantly poll the people or companies engaged in execution to determine the status. “Resource allocation,” “resource management” and “earned value” are usually exercises in theoretical mathematics carried out on historical data. Consequently, an inordinate amount of time and money is spent on meetings, conference calls and the preparation of reports that attempt to connect the design to the reality — in other words, to compensate for the lack of true communication and transparency. Because this is such a cumbersome and obscure process, change orders and cost overruns are a common occurrence.
IDEAS developed Working Logic™ from the premise that we could break down the walls between the design, the real world and the management of, first, the construction or development project and, ultimately, the constructed structure or product by using parametric systems with a web-based interface. With the parametric model displaying construction status in real-time, in a format that is easily accessible to all project stakeholders, there is no need for the monthly (or weekly or daily) meeting to check status and verify that everyone is working from the same set of drawings. Those who need to know simply log onto the system through any internet connection and download any documents they need, walk through the 3D model, or observe the current status in an augmented reality webcast of the construction plant or site. Change orders and cost overruns are drastically reduced, because all stakeholders are looking at the same live data.
A fully integrated parametric project model also allows transparent oversight and third-party visibility into the project status. How much would public confidence in public works projects increase if project status were visible to the public on the web in real time? How much would the cost of the performance bond decrease if the insurer were able to log into the project at will to monitor status?
The Principles of Working Logic™
Assumptions and Definitions
- A project consists of —
- a planned program of work that requires a large amount of money, time, effort and planning to complete
- A program of work is —
- a set of related processes or activities
- A project is directed toward a goal —
- the purpose of the project
- A project includes defined objectives —
- tangible or intangible products or outcomes that will be produced
- The project encompasses
- all of the several related workflows required to produce each objective
- Project management is —
- continuous, real-time awareness of progress in terms that permit identification of at-risk or high-performing milestones and the resulting financial risk or reward
- to allow rational decisions about intervention to mitigate risk or promulgation of best practices and
- to ensure the project stays on track or outperforms expectations
- The elements of project workflow are —
- Points in the workflow that are tied to a specific date
- Fixed points that may not slide on the timeline without financial penalty
- May be expressed as an event that “succeeds” completion of a project stage
- Individual components of an objective
- Each deliverable has an individual owner
- Process map of the workflow:
- Describes method for completing a deliverable
- Sequence of activities required to achieve an objective
- Necessarily includes definition of prerequisites/inputs and outcomes/outputs
- Optional transcription of workflow onto a time matrix in a different idiom
To define the requirements of the Working Logic™ system, we went back to basics to spell out the features that we believe are required of a functional project management system. We began by explicitly articulating and examining all of the assumptions that underlie the current practice of project management to test them against our vision of successful projects.
In particular, we examined the “project” and the “management” portions of “project management” separately. Right from the start, we found that most project managers have lost the connection between project and work: a project plan that is not grounded in workflow is not grounded in reality. We also found that overemphasis on project status as the output of project management distracts from the ability to actually manage — that is, direct or control — the project.
Most project management exercises begin with a list of tasks and dates for each task. In our view, this timeline should actually be the last step in the process of defining a project workflow. We focus on workflow because it is reality.
We define milestones as markers. In the conventional language of Gantt charts, we define them not simply as zero-time tasks, but as zero time roll-up tasks that are achieved through completion of predecessor task sets. Milestones are thus the early warning system that allows management to decide when action is needed.
Each deliverable (component of an objective) must be concrete, measurable and “owned” by an individual who is ultimately accountable for completion. The workflow for each deliverable reveals the required inputs and the steps that add value to create the deliverable (output).
Keys to Project Success
- Clear definition of goal, objectives and deliverables
- A project has one goal
- The goal is defined by the customer, whether internal or external
- The goal is clearly stated and described
- The goal statement may reference several objectives
- Objectives are tied to stakeholder needs
- Deliverables are clearly described
- Objectives and deliverables have been circumscribed into manageable modules
- All project participants have explicitly committed to the goal
- Status visibility at all times
- Timeline is baselined so slippages are visible
- Actual completion is documented as it occurs
- Focus is on workflow so that consequences of predecessor completion are evident
- Milestones are related to workflow so it is clear when they are threatened
What We Learned From Failure
Most project management exercises set themselves up for failure before they begin, because the participants do not take the time to examine, discuss and document their assumptions and to ensure that all stakeholders have defined the objectives in the same way. Often, when we are called in as consultants to help “rescue” a failing project, we find that different stakeholders have different understandings of the project goal.
Further, most project management exercises remain simply exercises, because they are not tied to actual activity on a real-time basis. When “project management” becomes after-the-fact reporting, the project cannot be managed. True project management must provide information that is timely and complete enough to be actionable. To illustrate the logic of Working Logic™, we set out to map the process of managing a project.
The first map illustrates the overview of the process. This process map drives home our contention that most projects fail before they begin, because the players jump into the process at the fourth step on our chart — the one we deem optional. Working Logic™ depends on using the many dimensions of parametric modeling to connect the project to reality.
The “sixth dimension” we refer to here is the set of parameters or rules that drive the model: the definition of those parameters is the prerequisite to implementing Working Logic™ and therefore occupies the first three steps of the process. Execution and monitoring are a continuous real-time feedback loop. Working Logic™ is founded on the core quality principle that you cannot manage what you do not measure and its corollary that you cannot measure what you do not see.
Defining the goal establishes the priorities and constraints — the key parameters — for the project. In one case study, a flood control authority, a city and a developer had joined together to build a very large flood control structure that would be required to control the flow of run-off in an arroyo just in front of the entrance to the new development and adjacent to a recreational facility owned by the city.
The flood control authority felt the need to build the structure was urgent, but its bond funds would not be available for two years; the developer wanted to ensure that construction would be complete, including landscaping, prior to the opening of their sales office; the city wanted to add recreational features to the dam site. The developer agreed to lend the flood control authority the money to build the dam immediately in exchange for control over certain cosmetic features and the city agreed to credit the developer's impact fee assessment for the cost of recreational features designed into the site.
In this case, is the goal of the project to build a dam? In fact, the driving force behind the project is the money advanced by the developer. The project goal might therefore be stated as: “to build the portion of the dam that carries the ‘grand entry’ access road to the development and landscape it prior to the grand opening of the development.”
If the project goal had been explicitly stated in this way, then it would have become clear that the objectives must include not only the building of the dam itself, but also the landscaping and the building of the road, and that the workflow must include the steps required to permit landscaping within the specified constraints. This in turn requires that the project plan reference relevant external parameters such as the planting season.
The Second Key Step: Define the Milestones and Objectives
Accurate definition of project milestones is dependent on a clear goal statement. For the cited project, for example, a milestone might be completion of certain sections of the dam prior to planting season. To be able to make informed decisions, management must also be able to see the cost of beating, making or slipping each milestone. In the case study, we guessed that the financing costs for the amount of money advanced against the bond money were $1,479.50 per day.
However, beating specific milestones in this project may or may not yield an equivalent financial reward, depending on whether the developer’s follow-on projects are able to be advanced. Similarly, the cost of slippage may be greater (using our sample calculations, up to $147,950 per day for the total project) if follow-on projects are also delayed.
Financial parameters are a critical input to a project plan that connects to reality. Typically, much time and effort is wasted tracking tasks that are not, in fact, critical. Management is not interested in individual tasks but in achieving the goal, or at most monitoring milestones. From this view, slippage is relevant only if it threatens a milestone.
The strictest application of this principle is Critical Chain methodology, which accumulates all “safety” into a project buffer at the very end of the timeline. This is a radical departure from the practice of adding “safety” to each task, but it is possible to apply aspects of Critical Chain with only minor changes to current practices.
What About Quality?
Traditional project management also does not consider the quality of the outcome, whereas in reality a task finished on time but with poor quality may pose an equal or greater threat to a milestone than slippage. For example, completing a planting in November may require 100 percent rework in the spring, threatening the milestone “attractively landscaped entry by summer.”
Using the fourth dimension of parametric modeling allows the project engineer or manager to incorporate quality into the design from day one. Cost-benefit analysis of different features is hugely simplified as the model simply simulates the outcome in a manner that is visible to all. This greatly increases the likelihood that the project will complete successfully: that is, that the end result will meet, or preferably exceed, the customer’s expectations.
Communication Is the Key
Communication is the hidden keystone of successful project management. We noted previously that almost always there is no ability for disparate team members to communicate and collaborate in real time. Collaboration and communication — with the occasional exception of integrated email — are universally looked at as belonging to a totally separate discipline from project management. In our experience, this is contrary to how real projects actually work.
As the drill-down workflow for step two of our overview process map shown at right makes clear, the first two loops on the project planning work-flow are purely about clear communications, and they support the foundations of the project plan. If those steps are not successfully completed, the entire project foundation is built on a bed of sand and will crumble at the first ill wind. In Working Logic™, these steps are required to establish the key parameters and therefore they can neither be skipped nor ignored.
Workflow Is the Foundation
The actual foundations of the project plan are the workflow(s) that are what really happens to complete the project. Typically, an overall workflow describes the entire project while more detailed workflows are revealed as drill-downs under individual steps in the overview, leading eventually to a sequence of tasks that can be transcribed to a timeline.
The workflow is the reality: the process map is a diagrammatic snapshot of a workflow. The diagrams we show throughout this presentation are hypothetical process maps for managing a project. A properly represented workflow forces examination of inter-relationships between tasks, deliverables and objectives. We have said that each deliverable must be concrete and measurable: this is a prerequisite for management.
The workflow contains the inputs and outputs as well as the intermediate steps. If the workflow is properly integrated into the project management process, then the process map will also be continuously regenerated to reflect the impact of real activity. Thus status should be reflected real-time in any representation of the workflow, which will automatically cause planned future workflow to adjust. Functional project management software would reflect these changes as real-time updates to the process map and consequently to the timeline.
Lean The Process Map and Design In Quality
At the planning stages, the process map plan should be subjected to rigorous quality scrutiny — in other words, the process should be “Leaned” during planning. This is the time to look for bottlenecks and break them, to look for parallelism that can provide buffer time. This is the time to build in quality. Item three on Deming's 14-point list was “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.”
With parametric modeling, the workflow can be optimized virtually: by the time the project is in the real world, the optimal flow has been modeled and tested in simulation. This gives the project manager almost as good an advantage as 20-20 hindsight! But proper management does not stop with proper planning. As the workflow progresses, real-time statusing opens the door for continuous improvement and feedback, so that the model is both validated and refined. The proper role of management is not to micro-manage task status, but to monitor workflow in search of opportunities for improvement.
If a workflow is transcribed to a timeline, the workflow dictates “predecessors” (the inputs) and “successors” (the outputs). If the “network” view in a timeline-based project management software does not replicate the process map of the workflow, the timeline is meaningless because it is disconnected from reality.
If you must use a timeline ...
- Workflow is what's real, the timeline or Gantt chart is simply a common representation, the vernacular of the engineer
- Transfer the workflow as a network diagram
- Verify “predecessors” and “successors” against the workflow
- Explicitly apply timing constraints such as seasons, holidays or external deadlines
- All tasks start as soon as possible
- Milestones are summary tasks
- Assign “resources” (individuals, teams or budgets)
- Allow “buffer time” or safety before each milestone, not within each task
- Baseline the timeline to establish the 1:1 relationship between time and cost
Anchor the Project to Reality
Both the workflow and the timeline must also incorporate as parameters any exterior constraints that impact the workflow, such as seasonal restrictions, holidays that create resource restrictions, dependency on outside events, etc. While the parametric model can incorporate and continually reference the constraints of the real world, such as hydrologic models for example, traditional 2D engineering programs or project management programs cannot.
Suppose in the case study project we cited above that the schedule becomes threatened because a supplier cannot delivered the specified discharge pipe. The Gantt chart can tell you what the schedule impact will be if delivery is two weeks late. It can also tell you what the schedule impact will be if you substitute a different pipe from another supplier who can deliver on time.
But the Gantt chart cannot tell you that if you make this change to the discharge pipe, the downstream result will not be consistent with your project goal or that the substitute pipe is not built to withstand the impact of a flash flood and therefore likely to fail in this application. The risk, of course, is that the project manager on the ground, whose single imperative is to meet schedule, will accept the substitution without consulting the hydrologic engineer, who is off to another project because he has completed his single imperative of producing construction drawings. In fact, similar scenarios happen all too frequently on project sites.
What Drives the Project in the Real World Must Drive the Plan
In the real world, money is the primary driver for activity. Therefore, project management must include cost information. The “baselined” timeline establishes the balance point between time and costs. The plan is only as good as its connection to reality. A timeline that is not tied to resources at some level has no more connection to reality than one that is not tied to other constraints (networked). A timeline that is not baselined is equally useless. The timeline view is useful only as a means to continuously assess threats to the milestones: tasks that threaten milestones are the critical flow, and in the case of a problem on those tasks, the project manager must focus resources on critical or bottleneck tasks. Without the tool of parametric modeling, most project managers simply bounce from crisis to crisis.
Parametric design software simulates the real world by establishing the parameters that define objects or structures and building simulations of them by simulating their assembly from simulated components. Parametric management software allows us to build a simulated workflow that behaves in every respect the way its real counterpart behaves. Such software can simulate in real time the effects on both time and cost of deviations from the planned workflow.
By defining deliverables so they are measurable, planners can identify means of verification that can be fed back into the parametric model in real time, in many cases through automated monitoring processes. This allows management to immediately view the long-term cost-benefit impact of any project activity so that it can make rational decisions.
Workflow is the flow of work — it is neither static nor determinate. The dilemma in connecting workflow to project management has been that until recently, there has been no way to represent workflow symbolically so that it could be referenced away from the work site. Parametric modeling allows just that. So with parametric management software, the project manager has an open window to read status from the real world.
Parametric modeling also allows the introduction of easy ways to reference the relationships that drive the model. It is not necessary to venture into complexity science, which holds that relationships are reality, to understand that changes in an early stage of a project will impact subsequent stages. Managing a project with a focus on the goal requires that changes be validated on the workflow before they can be tested on the timeline. Through parametric modeling, the impact of a change on the end result and all its parameters can be immediately displayed and, equally importantly, quantified. The corollary to “you cannot manage what you do not measure” is that “you cannot measure what you do not see.” Parametric modeling provides a clear window to reality.
- Accurate decision records
- Clear vision of impacts thru documented workflow
- Agreement on priorities
- Easy accessibility
Common definition of milestones, objectives
- Project Management
- Real-time variance to plan always visible
- Plan is able to respond to change
- Ability to interface all players’ plans
- Cross-organizational dependencies manifested
- Don’t spend more time updating the plan than executing it!
The Working Logic™ Solution
IDEAS’ Working Logic™ solution for project management incorporates four simple principles that we have described above:
- Clear and continuous communication is an essential and integral component to functional project management.
- Measurability is a prerequisite to manageability, and the most meaningful form of measurement is money.
- Quality assessment must be integrated into status assessment and the impact of poor quality output made visible in forward workflow.
- Reality is workflow, and workflow includes both deliverables and relationships. True project management is real-time management (direction or control) of workflow.
IDEAS’ Working Logic™ solution for project management adheres to four basic design principles:
- The design of a successful project management solution, as any process design, must begin with usability engineering. If it is not designed to easily and fully integrate with the user’s daily work process, it will not be used and is therefore unusable/useless.
- Different stakeholders require different viewpoints into the project. A manager wants a bird’s eye view on the reality, focused on the final goal; an actor wants a drill-down view that provides actionable details. A manager wants the project to alert her when it is straying from the planned parameters and show the impact on the overall picture; an actor’s daily environment is the project and he wants to be able to focus on particular areas without the distraction of adjacent information.
- Parametric project management must allow the same core information about the workflow to be viewed from any perspective – the overview can be exploded to any level of detail, rotated to any point of view.
- A viewpoint fails if it requires interpretation by another actor to be understood by the viewer. Complete integration of the parametric model and reality is required to ensure integrity of the status reporting.