"Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity." - Charles Mingus

Project Management

IT Project management is evolving, with many feeling that current methods are too complex. The detailed frameworks and rigid methodologies can create a maze of processes that hinder innovation and agility. While these practices aim for thorough planning and risk mitigation, they can lead to convoluted workflows and administrative overhead that distract from the project's main goals.

Practices like ITIL, PMBOK, and Scrum can add complexity with their unique language like "sprints" and "burn-downs". Similarly, Lean, Kanban, and PRINCE2 have their own jargon and procedures, creating barriers to understanding. While this idiosyncratic language can have benefits for branding or the establishment of group bonding by way of exclusive understanding. Ultimately, this reliance on specialized language can steepen the learning curve for newcomers and hinder rather than facilitate communication, creating only the illusion of value.

Memory Overload

The effect of this idiosyncratic language is that it places an excessive load on an individual's cognitive resources. When project management practices become overly complex, parties need to constantly refer back to documentation or training materials to understand or remember specific terms. While this complexity may not be an issue for Project Managers themselves, asking non-project managers to learn entire disciplines, in addition to their normal duties, can detract from their primary responsibilities and areas of expertise.

Most modern systems are typically organized into a flat and expansive list of concepts with no internal coherence or mnemonic structures, this places large loads on memory and constrains one's ability to mentally track the state of a project at any given time.

In "The truth about Unix: The user interface is horrid", Cognitive Scientist Donald A. Norman wrote a critique that can be applied to any flat system, but especially to modern project management.

Human memory is a fragile thing. Actually, for most purposes it is convenient to think of human memory as consisting of two parts: a short-term memory and a long-term memory ... Short-term memory is, as the name suggests, limited in duration and quantity: about five to seven items is the limit. Thus, do not expect a user to remember the contents of a message for much longer than it is visible on the terminal. Long-term memory is robust, but it faces two difficulties: getting stuff in so that it is properly organized and getting stuff out, so that it can be found when needed. Learning is difficult, unless there is a good structure, and it is visible to the learner. The system designer must provide sensible assistance to the user so that the material can be structured. There are lots of sensible memory aids that can be provided, but the most powerful and sensible of all is understanding. Make a system so that it can be understood and the memory follows with ease.¹

It's important to acknowledge the merits of specialized language, notably, communicative efficiency within tightly aligned groups. But all too often specialized language is used because, as Gary Simmonds MD MS FAANS wrote, "it kind of feels good once mastered. Fluency signifies that we are part of the club, a member of the guild."² Project Management, by virtue of the fact that it must operate in-between groups is best served by using natural, every-day language wherever possible.

What is needed therefore is a means to simplify the process and to remove overhead while maintaining the sought-after protections of traditional project management. This can be accomplished by structuring your teams and work flow so that it can be intuitively understood and it's processes predictable. That is, you can move the workload from the people to the structure so that efficient task management, whether project or issue related, emerges naturally; minimizing the need for centralized controls.

Laying a project management process over an organization is like creating a city, then cutting out by-ways to build the roads. A properly planned city begins with the grid, laying out both major and minor roads, and only then do the buildings go up. Likewise, processes and lines of communication, in accordance with Human Nature, must be established first. Only then can the structures can be built around them.

Indeed, the solution to the complexity of project management may not lie in creating yet another new or better process, but rather in rethinking what project management means. It's about understanding that project management is ultimately about achieving goals. It's about empowering teams to work effectively, rather than burdening them with complex processes and jargon. It is not by redefining project management, but by eliminating the need for it, that we can create a more efficient and enjoyable work environment. Project Management, in the old sense, would no longer necessary.

The Magic Number

The main cognitive ability responsible for enabling understanding of a complex system is short-term memory. When we are able to hold all the relevant "moving parts" of a system in our minds simultaneously, it becomes easier to understand the inter-working of the component parts. But short-term memory has limits.

The "Magic Number"³, often referred to as Miller's law, is a concept first introduced by cognitive psychologist George A. Miller. It suggests that the number of objects an average human can hold in short-term memory is around 7 ± 2. Fortunately, this limit can be expanded somewhat through "chunking".

Chunking is a process in cognitive psychology where small individual pieces of information are bound together to create a meaningful whole. The chunks, by which the information is grouped, are meant to improve short-term retention of the material, thus bypassing the limited capacity of working memory and consequently the information can be retrieved more easily due to this grouping.

Ultimately, if we seek to define an environment and process that best facilitates understanding, we must first work within the confines of and account for human nature and human limitations.

Why "Fractal"?

Fractals are infinite patterns that are self-similar across different scales. They are created by repeating a simple process over and over in an ongoing loop. Fractals have been employed to describe diverse behavior in economics, finance, the stock market, astronomy, and computer science. Fractals describe geometric patterns that can be split into parts, each of which is a reduced-scale copy of the whole. Fractal patterns are also frequently found in nature due to the their ability to generate limitless patterns from a relatively small set of instructions.

^{Fig. 1 - Fractals in Queen Ann's Lace}

Fractals have also been used in man-made constructs from the pre-industrial era to the present. The anthropologist Ron Eglash⁴ noticed these patterns while studying aerial photographs of a traditional Tanzanian village. He found that the huts were organized as a series of nested circular clusters. This arrangement, which he recognized from his former days as a Silicon Valley computer engineer, is a characteristic of fractals. Eglash argued that the fractals in African villages are not simply accidental; rather, they serve specific practical needs by facilitating the management of the village and by communicating vital information directly through the lay-out of the village itself.

^{Fig. 2 - Village fractal lay out}

In the process of organizing entities into nested fractal sets, we are fundamentally establishing a hierarchy of structures that exhibit self-similarity. Each subsequent tier in this hierarchy is a scaled-down replica of the one above. This characteristic facilitates the prediction of the appearance of the next level. Furthermore, the inherent similarity across all levels allows for an intuitive comprehension of the entire structure through the examination of any single component. This principle underlies the frequent utilization of fractals in the modeling of intricate natural phenomena such as coastlines, cloud formations, and snowflakes. Despite the high degree of complexity inherent in these phenomena, their fractal properties render them more comprehensible and "self-documenting".

Coincidentally, systems organized in fractal patterns naturally lend themselves to "chunking". Fractal structures facilitate the division of complex information into manageable chunks as levels of the hierarchy, is a self-contained unit that mirrors the structure of the whole, thus reducing cognitive load. This allows for more efficient processing and recall of information. Therefore, fractal organizational techniques, by their very nature, optimize our cognitive capacity as outlined by Miller's Law.

Specialist vs Generalists

Often misrepresented by the media, the "10,000-Hour Rule"⁵ is a concept derived from the research of psychologist K. Anders Ericsson and popularized by Malcolm Gladwell in his book "Outliers". This rule postulates that achieving mastery in any skill requires a minimum of 10,000 hours of practice.

Although more recent findings have called into question some of the specifics of the 10,000-hour rule, the broader claim, that both quality and quantity of practice are important, still holds true.

This form of practice is known as "Deliberate Practice", which according to K. Anders Ericsson is defined as individualized training activities that are highly structured, effortful and, most importantly, highly specific. Ultimately, it is this form of practice that is required to achieve mastery over any given subject.

It therefore stands to reason that siloed departments, given more deliberate practice time, develop a deeper skill level, therefore avoiding the pitfalls of inefficient and slow to market solutions. But this high-quality output can have a cost in that siloed structures can result in communication gaps and competing goals.

Conversely, full-stack organizations, where each team or individual is responsible for a range of tasks across multiple domains, can foster a comprehensive understanding of a project. This can lead to better coordination, faster decision-making, and increased flexibility. However, the breadth of knowledge required in full-stack structures comes at the expense of depth of expertise.

It's evident therefore that the optimal structure would utilize a hybrid approach; an approach that combines in-depth knowledge with communicative efficiency while avoiding competing priorities and disunity.

Desire Paths

"Desire paths" refer to the informal trails created by repeated human or animal movement, often representing the shortest or most convenient route between two points. The term is sometimes attributed to the French philosopher Gaston Bachelard, who referred to them as les chemins du désir ("pathways of desire") in his 1958 work The Poetics of Space. However, the concept has been widely embraced in fields like urban planning and landscape architecture, where these paths are seen as organic expressions of human behavior and preferences. They highlight the contrast between planned design and actual use, offering valuable insights into how spaces are navigated and experienced.

^{Fig. 3 - A desire path in a park}

Just as physical desire paths reflect the most intuitive routes chosen by individuals, virtual desire paths in business processes ensure that the correct way to complete a task is also the simplest and most efficient. By observing workflows and identifying friction points, managers can redesign processes to naturally guide employees toward desired outcomes, reducing unnecessary steps and improving productivity. In essence, it creates a synergy between human instinct and organizational structure, offering an organic yet impactful way to streamline operations.

Scalable Team Interface and Capacity Model

This framework offers a portable governance pattern that any department or silo can adopt to balance local autonomy with system-wide coherence. Rather than prescribing specific tasks, it defines layered responsibilities with controllable interfaces that make workload movement and accountability explicit across teams. The result is a universal operating model that preserves frontline decision‑making while systematically reducing friction and inefficiency through coordinated visibility and bounded handoffs. Executives gain predictable throughput and managers gain practical levers for tuning capacity, staffing, and workflow boundaries without adding bureaucratic overhead

^{Fig. 4 - Example organization based on fractal sets}

Level 0 - Engagement and Coordination

This role handles all external communication and functions as a single point of contact for the group. It is responsible for assigning and prioritizing all work within the group, consequently, offsetting some of the day-to-day steering normally done by a manager, allowing groups to run semi-autonomously. This function, in conjunction with the other Level 0 personnel act as a distributed "PMO" but instead of adding an addition "dotted-line" layer of management, this role assists and serves the needs the group they support.

This role does not need a high level of technical expertise but does require a high degree of communication and organizational skills.

• Receives all external requests
• Acts as a single point of contact for the group
• Manages internal delegation
• Coordinates internal and inter-departmental activities
• Tracks group progress
• Owns all tasks assigned to the group
• Monitors overall workflow and productivity
• Advises L3 on necessary workflow boundary and staff adjustments

Communication via L0 channels must simultaneously be the easiest or desired mode of communication, bottlenecks or delays introduced at L0 must be address immediately

Level 1 - Supports

This role is responsible to keeping the existing environment operational and requires an intermediate skill set in a specific field.

• Responsible for keeping the existing environment operational
• Addresses all operational issues
• Submits feedback from the field and informs Engineering and Architecture of any environmental changes
• "Tactical" engineering
• Advises L0 on support and user interaction changes

Level 2 - Implements

This role is responsible for implementing all production changes and requires an expert level skill set in a specific field.

• Escalation point for L1
• Produces all automation
• Manages all ongoing automation and automated maintenance
• User acceptance testing
• Implements all production changes
• Advises L3 on technology improvements

Level 3 - Designs

This role evaluates and certifies all new technology, architects all integrated solutions and maintains operational efficiency.

This role consists of mostly full-stack engineers with expert level skill in multiple fields.

• Escalation point for L2
• Produces "Proof-of-concepts"
• Monitors the industry trends
• Evaluates emerging technologies
• Manages work responsibility and silo boundaries
• Responsible for all technology "steering" and strategic planning
• Responsible for making all necessary adjustments to workflow boundaries and staff allocation as required to prevent bottlenecks.

Team Lead/Management

With L0 managing daily operations and L3 guiding technical direction, management is freed up to focus on strategic initiatives, human resource issues, staffing and corporate alignment. This delineation of responsibilities facilitates a flatter organizational structure, enhancing decision-making efficiency and streamlining communication channels. Moreover, it empowers front-line teams with greater autonomy, thereby cultivating innovation, agility and responsiveness.

Virtual PMO

Each department embeds an L0 role charged with end-to-end tracking of its internal work and all external communication. Rather than centralizing project management, these L0s form a constantly synchronized network—effectively a virtual PMO—so that individual contributors stay focused on delivery rather than status updates.

Since each L0 role is embedded directly within its own department, there’s no need for constant reporting and ambiguous dotted-line reporting to other managers. This direct alignment ensures that L0s prioritize the department’s goals without being pulled in conflicting directions.

Ownership, Escalations and Communication

In most IT organizations, an escalation becomes the safety valve for issues that frontline teams can’t crack. However, when key performance indicators such as ticket close rates or mean time to resolution become rigid targets, they can distort behavior—a phenomenon described by Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.” Support teams under pressure to meet those metrics may be tempted to escalate prematurely, not to achieve genuine resolution, but to preserve their statistics. This misalignment of incentives undermines both service quality and the development of first-line responders.

To preserve the integrity of escalations as a learning and problem-solving tool, every request for assistance should be logged as such, while the originating team retains full ownership and accountability for the task. In practice, this means that both the frontline and assisting staff be present throughout the entire process. Only in cases where the ticket was demonstrably mis-assigned should formal ownership transfer occur; and in those instances it should be treated as a lateral transfer, not an escalation.

To ensure that assistance still fulfills its pedagogical purpose, the assisting party retains ownership of a subordinate "Assistance Task" which spells out mandatory knowledge transfers and skill-gap tracking.

By embedding these guardrails, organizations can ensure that escalations remain true to their purpose—resolving complex incidents while simultaneously up-skilling frontline support staff.

Thresholds and "Auto-scaling"

The L3 team owns end-to-end workflow health: they continuously monitor throughput and cycle-time metrics, then dynamically adjust SLAs, refine handover thresholds, and recommend targeted training or staffing changes to smooth out capacity swings. Much like an auto-scaling microservice spins up instances when load spikes, L3 scales human resources and tightens hand-off criteria when bottlenecks loom—ensuring that work flows between teams without friction, service commitments stay within agreed limits, and overall productivity remains rock-solid.

This approach requires an organizational design where people can be flexibly seconded across departments without formal job transfers, backed by cross-functional training and clear role charters. This can be a departure from traditional headcount models, hinging on transparent governance and broad buy-in.

Communication Channels

Communication channels are the primary mechanism for streamlined coordination: clear, dedicated pathways carry user and work requests, assistance calls, priority updates, status reports, capacity metrics, and up‑skilling signals. L0 teams operate those channels, transforming raw inputs into concise artifacts and routing them to the appropriate consumers so engineers receive only actionable, contextual work. The vPMO ingests normalized channel outputs for cross‑silo visibility and priority tuning without reworking departmental data. Consistent cadence, minimal artifact sets, and strict data minimization keep noise low, preserve delivery focus, and make every priority change traceable.

^{Fig. 5 - Noisy communication}

^{Fig. 6 - Efficient channels of communication}

Self-Service

Self-Service is crucial to any IT organization, but sadly no IT process has been more misused. What was originally intended to allow teams to bypass encumbrances can rapidly devolve into a means of off-loading responsibility.

An arduous self-service experience is a failure regardless of the outcome as the emotional memory of a frustrating interaction will persist even when the issue or request has been technically resolved.

Emotional memory refers to the recollections tied to events that elicit an emotional response. It consists of learning, storing, and remembering the events associated with a physiological and emotional response. The American Psychological Association (APA) states that memories could be implicit (non-conscious) or explicit (conscious), and memories connected to strong positive or negative emotions are retained better due to activity in the amygdala region of the brain.

Guidelines

To ensure that Self-Service tools produce maximum results follow these guidelines:

• Look at the "Concept-to-Cash" value stream. How many teams does the process have to go through? If the Self-Service tool or process does not shorten the value stream, consider another solution.
• If the end-user is not better-off with the proposed self-service tool in their estimation, consider another solution.
• All the information required to use the process or tool should be found within the four corners of the form. Do not require users to go elsewhere.
• Take the user's perspective! Ask for information in accordance with the user's priorities and knowledge; and avoid using terms unfamiliar to non-specialists.
• Follow good user interface practices. The field of UI development is very robust and has been the subject of much research⁶, leverage this information wherever possible. Some examples...
  • Stick to one direction, never zig-zag. E.g. Left to Right, or Top to Bottom.
  • Always provide a progress indicator for multi-stage processes.
  • Never make a user wait for more than three seconds before providing some visual queue that something is happening (E.g. "spinning beach-ball").
• Get buy-in from all affected parties before implementing a self-service process where work ownership or work thresholds may not be clear.
• Never ask for information that you can obtain by other means and never ask for the same information twice throughout the entire user experience. Remember that you are not the only party interacting with the end-user.

Process Improvement

The ultimate "mission statement" of IT is simply to ensure that the clients are as productive as possible. That being the case, the L1 group, being closest to the user will always be the best positioned to report on user state.

L1 is responsible for promptly reporting scaling, SLA, skills gap, work‑threshold, and other environmental impediments to the appropriate technical tier (L2 or L3 by domain) using a concise artifact that includes observed symptom, frequency, user impact, recent changes, and any interim mitigations. L0 may normalize and forward these artifacts for cross‑silo visibility. L2 and L3 must triage reports, perform root‑cause analysis, and deliver process or technical remedies; every recommendation must be logged, assigned an owner, given measurable success criteria, and tracked to closure.

Post‑implementation verification by L1 is required to confirm user‑facing improvement and to surface remaining up‑skilling or handoff adjustments; where fixes require staffing changes, L3 may reallocate existing resources and management approves new headcount.

Priorities

The importance of directing efforts to high priority tasks is a well beaten path; but what is still often a point of contention within organizations is when priorities conflict between new and remedial work.

Therefore, in order to unite an organization it's necessary first to define a holistic and objective prioritization blueprint. In this manner we can assign consistent prioritization across all types of labor whether it is issue, request or project related.

Defining priorities for tasks relating to external customers is outside the scope of this document and is typically the responsibility of Finance in collaboration with Product and Data teams. Operational owners should surface measurable signals (KPIs) and cost inputs to support financial attribution, but formal ROI modeling, CLV calculations, and investment approvals belong to cross‑functional financial processes.

Loss vs. Degradation

The ultimate arbiter of priority must always be to what degree the end-user is able to fulfill their job function, as every moment of degraded or lost service equates to diminished or lost revenue for the organization as a whole.

A loss of service is limited to job critical functions.

New Services

Determining the priority of a new product or service is a bit more complicated as there is no existing state to check, rather it must be compared to the ever fluctuating standards set by the industry at large.

This means that users experiencing a level of service that does not meet that which the competitor's users enjoy, are said to be in a degraded state. Likewise, users who lack a product or service that is mandated by law, or the absence of which represents a critical security risk, are experiencing a loss of service.

_{Table 1 - Priority Matrix}

While it is acceptable that work can entail reducing the severity of an issue from a loss to a degradation of service, such "stop-gap" efforts should be done only in extreme cases and the issue must never be considered closed.

Number of Users Affected

The second variable to consider is the number of users affected by the loss or degradation of a service. Rather than assigning arbitrary buckets such as "single user" or "multiple users", this value is best represented by an actual and very simple calculation of the % of the users affected.

Records must be task-centric, not user-centric. Therefore, a new user with 5 missing services would result in 5 tasks.

VIP

Some systems set priorities based on "VIP" status. But if we stop to ask what makes a person a VIP, we typically discovery that it is defined by the fact that a VIP acts a resource for a number of people who would otherwise not be operating to the fullest capacity. So in this sense, a loss or degradation of service to a VIP is a loss or degradation of service equal to the number of people that report to them down-stream within the organizational hierarchy.

The Math Part

To derive the priority P of any given task, first we define the current state S as either .5 for degraded or below industry mean service level () or 1 for loss of service, or missing regulatory or critical security requirement. Then we multiply by the percent of affected users U either directly or indirectly by way of management hierarchy.

P = S × U

In this manner we can construct single unified task list with priorities that directly correlates to corporate profitability, while greatly simplifying task management.

The fuller meaning and usage of  is reserved for future Fractal IT™ software platforms that will automate the task or prioritizing upgrade efforts.

Examples

Assuming an organization with 1000 users...

• A web site is slow for a single user.
• A new user requires access to a non-critical service.
• A single user requires an upgrade to an application that has fallen below industry standards.

.5 × ((1 × 100) ÷ 1000) = .05

• A user can no longer, or has yet to be granted, access to a job critical application.
• A user requires an upgrade of a service in order to satisfy a regulatory requirement or to mitigate a critical security risk.
• A new user requires a new job critical application.

.5 × ((1 × 100) ÷ 1000) = .1

• 10 users cannot print to their primary printer but can still access a secondary printer.
• A manager with 9 down-stream reports is missing a non critical application.

.5 × ((10 × 100) ÷ 1000) = .5

• 10 users lost access to a job critical application
• 10 users have an application that has a zero-day security flaw.
• A manager with 9 down-stream reports cannot access the payroll website, a job critical function.

1 × ((10 × 100) ÷ 1000) = 1

• A department head with 99 down-stream reports requires a secondary monitor.

.5 × ((100 × 100) ÷ 1000) = 5

• The current Single-Sign-On solution, that is used by all members of the organization, has significantly fallen behind industry standard of functionality.

.5 × ((1000 × 100) ÷ 1000) = 50

• Internet connectivity is down for the entire organization
• A critical security flaw has been discovered that could potentially put all end-points at risk.

1 × ((1000 × 100) ÷ 1000) = 100

This process intentionally leaves out new services not explicitly intended either to meet or exceed industry standards, to meet regulatory compliance or to mitigate a security risk. Upgrading without an underlying business justification is not advised. If such work is nonetheless undertaken, it should be assigned a status of less than .5.

Mathematical processes can sharpen decision-making, but they demand cautious balance: Goodhart’s law reminds us that once a measure becomes a target it ceases to be a good measure, and heavy mathematical aggregation amplifies data errors, bias, and opportunities for gaming while erasing contextual nuance. Over‑aggregation produces reassuring averages that mask edge cases and create brittle policies that fail under novelty or stress. Responsible use pairs quantitative signals with documented data lineage, explainable models, regular human review, and governance that preserves qualitative judgment and accountability so numbers inform choices rather than replace them.

Footnotes & Citations

1. Norman, D. A., Department of Psychology and Program in Cognitive Science Center for Human Information Processing, University of California. (1981). The truth about Unix: The user interface is horrid. Datamation. http://www.ceri.memphis.edu/~smalley/ESCI7205F2009/misc_files/The_truth_about_Unix_cleaned.pdf
2. Simmonds, G. MD MS FAANS (2023, August 28). We Use “Specialized” Language too much. Psychology Today. https://www.psychologytoday.com/us/blog/rich-encounters/202308/we-use-specialized-language-too-much
3. Mathy, F., & Feldman, J. (2011, December 15). What’s magic about magic numbers? chunking and data compression in short-term memory. Cognition. https://www.sciencedirect.com/science/article/abs/pii/S0010027711002733?via%3Dihub)
4. Eglash, Ron. (1998). Fractals in African settlement architecture. https://www.researchgate.net/publication/242911162_Fractals_in_African_settlement_architecture
5. Clear, J. (2019, June 10). How experts practice better than the rest. James Clear. https://jamesclear.com/deliberate-practice-strategy
6. Penzo, M. (2006, July 12). Label Placement in Forms. https://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php