Tag Archives: Project Management Triangle

VIsual Aids for Communicating Project Management Concepts

With project members and stake holders, I occasionally find that it’s difficult to communicate the benefits of using certain project management tools or methods. For example, conversations about the benefits of using SCRUM or Test Driven Development (TDD) to improve a project’s probability of success are occasionally met with blank stares or even friction. For these meetings, it’s good to have a few visual aids to help digest how using tools can mitigate certain kinds of risk. Below is a sample of some of the visual aids I’ve used over the years.

The Triple Constraint

Triple ConstraintThe first diagram is typically the one almost everyone knows. The Triple Constraint, also known as the Project Management Triangle, is a good visual aid for communicating how a project’s cost, scope, and schedule relate to each other. Changes in one or two of the three metrics will adversely affect the remaining metric(s). For example, reducing cost will negatively impact the project’s scope or schedule. Limiting the schedule will negatively impact the scope or cost. Widening a project’s scope will negatively impact the schedule or cost. Trying to control all three constraints simultaneously is impossible. Additionally, there is significant risk to a project’s success if you materially change which constraints are most important. Successful projects – i.e. on time, on schedule, and within scope – strike a delicate equilibrium between the three constraints.

Product Management Trap

Product Management TrapAnother visual aid I like to use is the Product Management Trap diagram. In this diagram, the stakeholder controls the value axis while the development team controls the complexity axis. Often a project will have a wide portfolio of features or components. Identifying where features rank helps stakeholders focus on risk versus ROI. When trimming scope, focus on low value, high complex features. When trying to balance resource schedules, add or remove low complexity features. If possible, when negotiating scope, features should be removed in descending order (4, 3, 2, 1), so that you eliminate the most difficult features first. Be mindful, however, that although quadrant 3 contains difficult and complex features, trimming here could significantly change the overall ROI for the project. There is a great YouTube video by sketchcaster about this chart.

POS Vs Complexity

POS Vs ComplexityVisualizing the relationship between probability of success (POS) and complexity is useful when communicating the effectiveness of project management methodologies or tools (e.g. SCRUM, Kanban, TDD, etc.) The POS versus complexity diagram illustrates how utilizing proven methodologies and tools can positively improve the POS without significantly affecting complexity or scope. For example, SCRUM improves POS (on the y axis), but complexity (on the x axis) remains relatively unchanged with or without SCRUM. The relative improved POS for using project management methods and tools becomes more pronounced on projects of higher complexity. For projects of low complexity, the benefit is marginal.

Time Vs Complexity

Time Vs ComplexitySimilarly to the previous graph, time to develop versus complexity is a good tool to communicate the effectiveness of good project management methodologies and tools. Typically, the more complex a project, the more time it takes to complete. The introduction of effective project management methods and tools can often be compounding and, therefore, affect time in a logarithmic way. Low complexity projects only benefit marginally, but high complexity projects experience a significant time improvement. For example, a good TDD (Test Driven Development) strategy continuously exercises code and reduces the likelihood of bugs introduced by refactoring or changes in scope. Finding and fixing bugs before they surface in Quality Control (QC) translates to reduced communication (e.g. tickets, emails, phone calls, and meetings), reduced context switching, and reduced follow-up testing for QC agents. Over time, these improvements are compounding and can significantly reduce the overall time needed to develop a project.

Efficiency Vs Flexibility

Efficiency Vs FlexibilityFinally, efficiency versus flexibility is a good visual aid for illustrating that highly flexible systems generally perform less efficiently than rigid systems. I typically break out this diagram when I hear requirements that suggest the need to create a system that can do everything. For example, requirements might suggest users to be able to process data from lots of different data sources; or, requirements might propose that the users be able to dynamically build, customize, and maintain reports; or, requirements advocate that users be able to view and manipulate the data from multiple front end systems. Beyond the fact that these requirements may add significant complexity to a given project, the typical trade-off for these requirements is inefficiency in resource consumption. Disk space, memory, and CPU consumption is greater in highly flexible systems. As flexibility increases, views or reports typically shift from real-time to deferred, or batched. Also, highly flexible systems are more complex and therefore take longer to build. Ultimately, the currency to measure the efficiency in such systems is time. How fast does the system need to perform and how fast do you need it built?

I have many other visual aids that, unfortunately, I’ve omitted here for brevity (e.g. risk versus complexity, supportability versus complexity, etc.) Also, there are a whole host of artifacts generated in well managed projects (Gantt charts, burn-down charts, etc.) that are great communication visual aids. For now, I’ll save those for future blog posts. Until then, I’ll leave that homework up to you.