Summary
Explore modern IT work organization — particularly project management, operations management, and product development.
Projects are temporary efforts to deliver unique outcomes. They’re best managed using frameworks like PMBOK or PRINCE2.
Operations are ongoing, repetitive tasks (e.g., running a service desk or continuous software updates), guided by principles like ITIL and process management frameworks (e.g., COBIT, BPM CBOK, Lean, KANBAN).
Sometimes, hybrid approaches are most effective—for instance, treating a large migration as a project while executing repetitive parts with operations-style efficiency, e. g. a “migration factory”.
Product development overlaps both domains. Customer-specific software is typically project-driven, while standard product evolution often uses agile methods like SCRUM.
The challenge is choosing the right structure: Project, operations, or a hybrid—based on the nature of the task. The text sets the stage to explore decision-making concepts like the Cynefin Framework and Stacey Matrix to guide this choice.
Preface
Babel Fish, Hitch Hikers Guide Through Galaxy
Generated by deepai.org
I belong to the baby boomer generation. Those who were still allowed to drink water from garden hoses, grew up offline, and had to be at home when the streetlights came on. The big bang of the IT universe was already history in 1962, and the IT universe began to expand unnoticed. Today, IT is omnipresent.
Do you know the Hitchhikers Guide Through Galaxy? The Hitchhiker’s Guide to the Galaxy is a comedy science fiction franchise created by Douglas Adams, 1978. The IT nerds among us already know: In 2025 the Babel Fish (“is small, yellow and leechlike, and probably the oddest thing in the Universe. It feeds on brainwave energy received not from its own carrier but from those around it.”, taken from Hitchhikers Guide through Galaxy by Douglas Adams) which can translate spoken words, is thanks to artificial intelligence, cell phones, and in ear headsets as technology available.
In our IT universe we live in the management galaxy. Several suns try to outshine each other with their radiance: IT project management, IT process management, IT Service Management, IT operations management. The suns are orbited by several planets: PMBOK, PRINCE2, KANBAN; SCRUM, NEXUS, COBIT, TOGAF, ITIL, … Obviously, there are gravitational forces between the planets.
You want to setup an IT project? You don’t know if you follow waterfall or agile approach? You are not 100% sure if your planned rollout is a project because a lot of steps consists repeatable tasks? May operations management fit better to a rollout?
Don’t get lost, continue reading the guide through our management galaxy.
Theory is not an end in itself!
It merely serves to improve our understanding of practice.
The Theory:
It is generally accepted that a project is a temporary effort undertaken to create a unique product, service, or result. It has a clear beginning and end, and it’s usually constrained by time, budget, scope, and resources.
In contrast operations are ongoing and repetitive (like running a factory or providing customer service).
Project management and operations management can be considered as two different domains.
Simple projects can be managed within the line organization.
For more complex projects you should establish a temporary project organization which manages the project. People working in the project report in their operations role to line manager, and in their project role to the project manager. This setup is known as matrix organization. At the end of the project, the temporary project organization is dissolved. Remaining tasks are handed over to line organization.
In Practice Borders Are Blurry
Activities frequently start in the line organization, e. g. the implementation of improvement measures. The team learns and gains better understanding.
Due to increasing complexity, the line management might be overwhelmed with coordination of project related activities, and a project is initiated.
The start of the project can be seen as the start of the work in the line organization or the start of setting up the project organization. The “official” start, the date stored in the project management artifacts, is often somewhere in between. It is important that the results of the line organization’s preliminary work are documented and considered as a prerequisite for the project.
If the remaining work no longer justifies the additional effort involved in project organization, the project organization can be dissolved before the end of the project, and the project can be completed within the line organization.
The end of a project can be set to shutdown of the temporary project management organization or to the date of completion of the last deliverable.
Example 1
An incident tickets operated in a service desk can convert into major incidents and might require a project to resolve the service interruption.
On the bright side: at the end of the day, it’s all just work that needs to be organized.
Example 2
A mailbox migration, e. g. a migration from a legacy to the future email system or a migration from mailboxes of an acquired company during a merge, would be considered as a project (one time undertaken).
If we narrow our focus to technical mailbox migration and plan how to migrate 20,000 mailboxes, it makes sense to fall back on tried-and-tested production control methods. Welcome to the domain of operations!
How would you organize this?
You can apply a hybrid approach gives you control and efficiency. Treat the overall mailbox migration as a project but design setup a “migration factory” using operations management principles. Design and manage the actual mailbox migration process.
You can apply a hybrid approach gives you control and efficiency. Treat the overall mailbox migration as a project but design setup a “migration factory” using operations management principles. Design and manage the actual mailbox migration process.
Example 3
A new end user device (notebook, operating system, standard applications) needs to be introduced globally. The overall undertaken is a projects, the rollout steps executed country by country / legal entity by legal entity are repeatable.
A hybrid approach looks promising. The projects delivers blueprints and for a rollout factory and manages the overall progress, upcoming escalations, and general issues. The country organizations implement the factories and execute the rollout on the sites.
The Product Development Domain: Agile Vs. Waterfall
What about IT product design and development, is this a 3rd domain?
The design and development of IT products is related to the project management and the operations domain.
Following the classic “waterfall” approach we see a process encompassing requirements specification, solution design, implementation, testing, and deploying.
For a customer specific software application to be build and delivered in x month project management in combination with product development should be applied.
In contrast, the development, further development, support, and maintenance of a standard software product normally is not covered by the project management domain. For a standard software product management and product development principles could be applied.
For the development as such agile approaches like SCRUM are frequently used.
The introduction of complex standard software (e. g. SAP, ServiceNow, …) at customer sites is usually organized as a project.
The implementation of updates, upgrades, patches at customer sites streamlined processes are required. Continuous deployment would be good choice. Operations management would apply here.
Conclusion
The examples mentioned before show that choosing the right organization to manage work to be done is no trivial task.
Project management, Operation Management, and Product Development are overlapping.
How should you manage the work to be done?
You can apply the following rules of thump:
- Apply project management frameworks/methods to manage projects. The PMBOK (Project Management Body Of Knowledge) or PRINCE2 (Projects In Controlled Environments) will guide you.
- Apply IT operations management frameworks/principles/methods to menage your operation. The ITIL (IT Infrastructure Library) is a good guidance. To optimize operation processes, apply process management frameworks. BPM CBOK (Business Process Management Common Body Of Knowledge, COBIT (Control Objectives for Information Technologies), KANBAN, or Lean Management serve as a starting point.
- IT Product development is a wide-ranging field with multiple frameworks. It will not be considered further here.
A second dimension relevant for a setup, is the question if waterfall or agile methods should be applied to organize work. Continue reading to learn how the Cynefin Framework and the Stacey Matrix to choose the right setup.
Stacey Matrix
The Stacey Matrix is a decision-making framework that helps leaders and teams determine the best approach to managing a situation based on two key factors:
- Level of certainty (how well we understand the problem/solution)
- Level of agreement (how much people agree on what should be done).
The matrix has two axes:
- Horizontal axis: Level of certainty (from high certainty to uncertainty)
- Vertical axis: Level of agreement (from high agreement to disagreement)
This creates four general zones:
- Simple (or Clear) – High certainty, high agreement.
→ Best handled with standard processes or best practices. - Complicated – High certainty, lower agreement or specialized knowledge required.
→ Needs expert analysis or multiple good practices - Complex – Low certainty, low agreement.
→ Requires experimentation, learning, and agile approaches - Chaotic – No clarity or agreement.
→ Immediate action is needed to stabilize the situation before analysis
The Stacey Matrix is widely used in agile, project management, and organizational leadership to decide:
- How to approach a problem
- Whether a traditional or adaptive method is best
- When to use innovation vs standardization
The difference between complicated and complex is that complicated is difficult or convoluted while complex is made up of multiple parts.
From a certain point on, complex problems can no longer be resolved, can no longer be presented, and thus can no longer be understood.
This must be accepted, just like complexity itself.
Accordingly, the solution, the chosen approach to the problem must have variables and options, and it must be iterative. Trying, correcting, trying, correcting, … That’s how you learn to deal with complexity. Just like in life.
Cynefin Framework
Cynefin is a Welsh word meaning habitat, haunt, acquainted, or familiar.
It was developed by Dave Snowden in 1999 at IBM and published as article “A Leader’s Framework for Decision Making” in the Harvard Business Review by Dave Snowden and Mary E. Bone in 2007.
The framework offers decision-makers a “sense of place” from which to view their perceptions.
The framework assumes that there is a relationship between a cause and an impact.
The analysis of the relationships between causes and effects lead to five domains.
A recommendation can be made for each domain on how decisions should be made.
The five domains are:
- Clear
- Complicate
- Complex
- Chaotic
- Confusion
Cynefin Domain Clear
The domain “Clear” represents the known known.
There are known rules in place which specify the relation between cause and effect: When the sun is shining and it is raining, you can see a rainbow.
How to make a decision::
- Sense: establish the facts
- Categorize the facts and select applicable rules
- Respond: follow the rules, apply best practice
This domain encompasses operations. For IT service management most of the companies apply the ITIL (IT infrastructure Library) framework.
Cynefin Domain Complicate
The domain “Complicate” represents the known unknown.
Relations between cause and effect exist. The must be analyzed to understand them.
The decision workflow consists of:
- Sense: assess the facts
- Analyze the facts (requirements, constraints, solution concepts)
- Apply an appropriate solution, if possible derived from good practice.
This domain is the home for technical experts, software developer, and other specialists.
This domain we find typically IT projects that are handled according to the waterfall approach: Analyzing requirements, developing and implementing solutions.
Cynefin Domain Complex
The domain “Complex” represents the unknown unknown.
Relations between cause and effect can only deducted retrospect, “right” answers are not available.
How to make a decision:
- Probe: try an experiment
- Sense: assess the results
- Respond
This domain is typical application of agile approaches applied in volatile, uncertain, and ambiguous environments.
A detailed planning for projects in the domain complex is “muda” (the Japanese word for a pointless activity, the absence of meaning or usefulness). A detailed planning most likely cannot be implemented. A possible reaction is an increase of micromanagement. More control leads in complex environments to more time loss. It is highly inefficient in a dynamic and untransparent environments. Empirical approaches are more appropriate.
The product development where we often have uncertainty about the final product and uncertainty regarding the solution development is a candidate living in the complex domain Here the application of Scrum is advantageous. From sprint to sprint we learn, we understand relations between cause and effects better. We can adapt to changing requirements by refining the product backlog.
Cynefin Domain Chaotic
The domain “Chaotic” is characterized by unpredictability or randomness.
The decision workflow consists of:
- Don’t loose time to identify patterns and understand relationships.
- Establish order. If possible, push the reset button.
- Move the situation from the domain chaotic to the domain complex.
- Follow the decision workflow of the domain complex.
Example: After a major incident, a complex IT system is unavailable. Technical experts analyze log files. Due to existing complexity, the impact of countermeasures like installing of patches, restoring database is unpredictable. The manager on duty decides to reboot all systems to move the situation from the chaos domain to the clear domain. Operators can follow the runbooks for restarts.
Cynefin Domain Confusion
The domain “Confusion” complements the afore mentioned domains.
It is not clear which of the afore mentioned domains one is in.
The recommendation here is to carry out a breakdown and assign the resulting sub-situations to one of the other four domains to make decisions there in accordance with the recommended procedures.
Stacey Matrix Vs. Cynefin Framework
The following table outlines the mayor differences between the Stacey Matrix and the Cynefin Framework:
| Criteria | Stacey Matrix | Cynefin Framework |
|---|---|---|
| Purpose | understand agreement and certainty in decision making | determine how to approach problems based on their nature |
| Structure | show matrix based on agreement and certainty | specify domains based on the known known, known unknown, and unknown unknown |
| Use Cases | in product development or project management: decide which approach, waterfall or agile, fits best | more general, in problem solving and decision making |
Location of Management Domains in the Cynefin Framework
The map shown on the right visualize which solution approach fits to which domain.
Domain Clear
The clear domain is a candidate to apply operations management:
- Setup a factory
- Apply best practice
- Think in more operations management than in project management
- Optimize flow by applying KANBAN
Domain Complicate
The domain complicate is a candidate to apply project management, most likely applying waterfall approach:
- Setup and staff a project team
- Specify a solution phases:
- Requirements analysis
- Solution Design
- Implementation
- Testing
- Deployment
- Handover to operations
- Hypercare
- Manage the project
- Mitigate risk to fail by implementing a prototype
- Limit project duration, for long running projects changes are more likely which undermine the solution design
- Continuously check if the project is moving from complicate to the complex domain (Stacey Matrix)
- Consider a premature project closure and a restart in an agile product development
Domain Complex
The domain complex is a candidate to apply product development, most likely applying agile approach.
Here…
- A project organization is not recommended
- Setup a product development organization, staff required subject matter experts
- Establish an agile approach to manage the product development
Example For A Hybrid Setup
A legacy SharePoint environment should be migrated to a new platform. A standard migration tool does not cover all business requirements. Some customizations and interfaces need to be implemented. Once the tool is available the migration will migrate SharePoint server country by country.
Setup a project organization to manage the migration end to end.
Setup a sub-team which will customize the migration tool, applying SCRUM.
Setup a migration factory which manages and execute the global rollout. KANBAN will be applied to optimize the migration flow.
Both factories are interfaced with the overarching project to monitor the progress.