Disclaimer: This is not a regular, “trim-it-down-so-we-can-make-an-offering-to-the-algorithm-god” article but rather an attempt to explain a phenomenon with all its nuances, without dumbing it down. If you can’t handle reading a 15-minute article (there is nothing wrong with it, there are a lot of people with attention spans comparable to a hamster on a hamster wheel, myself included), please scroll down to a section called “The fluffy cream and sprinkles on the milkshake - the Stacey Matrix adapted for software development” and see the key takeaway from my text without the reasoning behind.

Projects that SUCK

Everyone that had some experience with IT projects is well aware of that they do not come out as expected.

Of course, we can “agilify” (more on that later) projects and expected results or spend time and money on detailed planning (which, actually, is almost always a good idea) but the pattern is easily observed - in hindsight, it could have been done much better/cheaper/quicker had we known what we know now. But hindsight is a luxury of time-travellers or people who do not apply linear thinking to work, at least only at the end of the projects.

Anyway, I could tell you that there is a way to decrease the cost of lots of project parameters and you would probably respond with “ Sure, let’s do it by the book” and we’d engage in a conversation about which book we should follow. These books would be called methodologies or frameworks and they would have their pros and cons. Naturally, in the world of IT projects there are nuances that have to be recognised and understood and they greatly influence the project environment. It goeas without saying that if you do not know about those nuances for what they are, you may make a mistake and apply a methodology that only inflicts pain to stakeholders (not in the hindsight, in the present) and makes your project suck despite helicopter money and bringing the brightest onboard.

Below you can find a not-so-short summary of this problem and how one can avoid it. I assure you that it takes time to understand it on the deep level. However, applying the proper measures will bear fruit regardless of how deep the rabbit hole you went. And the main fruit would be not sucking at projects.

How do we avoid the big suck?

Let’s start with some basics:

• Projects are not run-of-the-mill and are never the same, even within the same organisation.

It’s bread and butter for every Project Manager, but possibly a nuance to someone else. There is always something else - location, budget, team, date. Your dog is sick and has to be taken to the vet twice a week and it affects your calendar. It’s raining most of the season and the paint doesn’t dry as normally. The project execution started in summer and suddenly people are taking days off to get some sun. It’s never like on an assembly line (which tends to have outages, by the way). You had a lovely project calendar where every event and milestone made sense, but the main engineer had to fall under a bus. The nerve of some people, huh?

• There will be different stakeholders, both professional and unprofessional and they will have their own masters, puppets, interests and expectations.

This one is also pretty straightforward - new people equal new interests and new problems.

There will be people who are helpful and easy-going and there will be people who sabotage the project or do not know how to use Microsoft Office, let alone more complicated software to manage a project. And they are still part of the team, despite their inability to work with something else than abacus (With all due respect to people using abacuses.)

• The essence of the project and chaos level will be primary factors to consider when picking the most optimal techniques to manage a project.

There will be projects of pure chaos and uncertainty about what is to be done. There will be projects where high-control techniques and well structured communication is a must.

And finally, there will be key players that will treat our little game to pick the right methods as a battlefield to execute their own interests (which is an interesting proxy war method and more on that in another article).

The Cynefin Framework

A guy with IBM Global Services, Dave Snowden (yeah, the other one) created a “sense-making device” to help other managers how situations can be and should be perceived and how to make sense of people’s behaviour in those very situations.

I am not going to dwell deeply on the basis of these works, I’ll go straight to the very domains it offers as context.

Simply put, each situation can be put in one of four domains/contexts:

• Clear domain
• Complicated domain
• Complex domain
• Chaotic domain

Each of these domains can offer an efficient way to process what is going on and how to make optimal decisions (from their own standpoints, naturally). Let’s take a quick glance at each one of them and examine.

The framework also pinpoints another position within the framework called “disorder”. The author omitted it on purpose - it cannot be projectized unless it is transitioned contextually to one of the domains above.

Clear domain

In the clear domain there are stable and well-known situations. The cause and effect is obvious and strict rules are established to manage a situation (A happens -> do B). Snowden's advice is to act via the following procedure [Sense - Categorize - Respond] meaning that once you establish the facts, you can follow with a rule. It is all about finding a proper rule and applying it to the situation. It is a very comfortable situation as most of the actions to undertake are no-brainers and there is always a rule to solve the puzzle. Of course, there are pitfalls and dangers of complacency but as usual - more on that later.

Complicated domain

Simply put - cause and effect isn’t obvious and requires some expertise. The advice is to act via [Sense - Analyze - Respond] - see the facts, interpret them and apply what’s best. Still not a bad situation if you have experts onboard but might be problematic if all we have are newbies as it takes knowledge and experience to navigate through complicated problems.

Complex domain

Here it can get really ugly as usually cause and effect can be determined only in hindsight and the right answers are known when the show’s over. The only way to determine whether our code of action makes sense is to apply [Probe - Sense - Respond] pattern so in other words come up with something that makes sense and see how it performs. It is not an easy domain as it has to have room for failed experiments and butterfly effects all over the situation.

Chaotic domain

Feared and hated by many. Terrible to work with. Sometimes inevitable.

Put simply, cause and effect aren’t linear anymore. To find any sense, you just have to do something, see the result and try to formulate even basic rules so you can crawl out to the complex domain ( act - sense - respond ). It is best put by Snowden -

“(...) manager’s job here isn’t to discover what’s up - it’s to stop the chaos and make the situation manageable.(...)”

Of course, in this domain projects will be, without any doubt, shitshows (spoken from experience) and any type of predictions or timetables can be thrown out of the window as the confusion is too high to keep managerial numbers intact.

Image 1 - Cynefin framework by Martin Berg and Rob Englands

Shortly put, this is what we do in every domain:

• Clear domain -> Follow the rules or establish straight rules.
• Complicated domain -> Analyse and act.
• Complex domain -> See what works and build upon it.
• Chaotic domain -> Stop the bleeding.

Image 2 - Cynefin framework illustration

Alright, cool - and?

Now let’s see how this knowledge evolves into a project management tool.

The Stacey Matrix was published to help people understand that the complexity of projects have different degrees and there isn’t a one-size-fits-all approach to making decisions, because if there were any, I would be out of a job :) (Thanks, AI!)

The basis of the matrix is typical - it has two dimensions :

• Agreement
• Certainty

Image 3 - Stacey Matrix axis illustration

The more we know about the cause and effect, the closer to (0,0) point we get on the Certainty axis. If there is something innovative to be created or at least new, we move right on the axis.

The more organisation ( project ? ) members know about the very objectives and there are no discrepancies (so an agreement?) how to achieve them, the closer we get to (0,0) point on the Agreement axis.

On this matrix, Ralph Douglas Stacey has identified 5 areas with 5 different proprietary sets of decision-making rules.

Image 4 - Stacey Matrix with decision-making techniques for each domain

These areas are:

1. High agreement, high certainty - “we’ve done these projects before, we’ll do them again”. A lot of good quality data lets us schedule a lot before the work starts. Decisions are technically rational and monitoring of detailed plans is usually enough.
2. Medium agreement, high certainty - people can agree on what can be done and how but there are discussions about what's really important. It’s typical for big project environments with a lot of stakeholders. Political decision making, compromise, forming coalitions and negotiations are helpful here.
3. High agreement, medium certainty - everyone’s onboard with what’s important in the established goals but there is no clear pathway how to achieve it. A strong and shared vision of stakeholders is a must and goal-oriented decision making must be employed.
4. “The complexity zone” - a complex management problem - we have some idea what we need to do and some idea how to do it. Levels of creativity and innovations are required here and other techniques that address the above problems.
5. Far from agreement, far from certainty AKA “The chaos zone” - where anarchy is the play of the game and something must be done to get out of here. There is no working technique here as it’s “Shit In and maybe,possibly, if we’re lucky, something of value out”. Impossible to control

What can we derive from the matrix above?

The pattern can be observed by a naked eye - in situations with a great majority of sound data and a minority of unknowns, a favourable approach is to make decisions based on experience. The discussions and in effect, the decisions can be made based on knowledge and technical merit. The ultimate goal and outputs of the project do not change over the course of the project and are designed based on previous experience and knowledge, thus an expectation is formed - project outputs will most certainly lead to achieving the ultimate goal. That is why it is best to make technically sound decisions and stick to overseeing the progress and reacting to deviations. Techniques that derive from negotiations and different standpoints will be proven to be suboptimal as it will be either “reinventing the wheel” as conluding that the organisation has already found an optimal approach or trying out a innovative approach which usually favour flexibility and thus becoming suboptimal in this domain by definition.

Projects of complicated domain would favour politics, negotiations and ideological control so the main pillar of the rationale remains unchallenged - if there is a high agreement on goals but medium certainty, one must stick to ideological control to keep the agreement high, whereas high certainty and medium agreement favours political game to keep key stakeholders happy with the outcome. The techniques of simple domain would be suboptimal here because there is still an analysis how to implement the scope of the project or what shape of scope would benefit the ultimate goal of the project. Some flexibility is required but too vague environment would lead to chaos.

Projects of the complex domain do not have the luxury of high agreement or certainty, therefore need to use techniques supporting whatever they have established - a relatively high level of flexibility must be permitted in order to find out what we want and how to do it. The techniques from simple and complicated domain would be suboptimal as they would try to plan out the unknown and fail.

A hypothesis can be formulated on a basis of the matrix above - there are optimal and suboptimal decision-making techniques to be applied in various situations depending on the level of certainty how to do something and agreement on whether it’s really worth doing it.

It is up to an experienced and educated manager to be able to recognize those domains and make decisions in an according manner. It is also crucial to be able to communicate to the stakeholders these concepts and thus the reasoning behind so everyone understands why a project is managed in such a way.

In other words - one can avoid the big suck by using appropriate techniques in situations that can be sorted into 4 different domains.

The fluffy cream and sprinkles on the milkshake - the Stacey Matrix adapted for software development

The final iteration of this concept has been presented by Chris Verwijs - he has kept the axis and areas intact, but swapped the areas with proposed software development methods/frameworks.

Image 5 - Stacey Matrix adapted for software development by Chris Verwijs

As we can see above, it is a bit oversimplified but provides two great insights:

• The greater the number of people in an IT project, the greater the tendency to shift to chaos.
• There are project management frameworks that can be used with efficiency in all the areas specified by Snowden.

From there we can deduct another interesting nuance:

• Using the wrong IT framework for the project domain will have terrible consequences and make your project suck.

How do we know where are we in the matrix?

The matrix has you and your project but you don’t know in which domain you are placed.

The way to tell for sure is to ask yourself about level of certainty and level of agreement:

1. How well do you understand the requirements of the stakeholders?
   1. Is the project scope well defined?
   2. Is the project scope even defined? (if it’s not and you can’t even define then welcome to chaotic domain and good luck)
   3. Are there time, assets, quality constraints etc.?
   4. Is the organisation mature enough to be of help?
   5. Etc.
2. How well do we agree about priorities and goals?
   1. Is the technology well known to us?
   2. Do we understand how to plan the execution of the project?
   3. Can we plan the risk and its management around the project?
   4. Do we understand the business environment of the project and are we able to manage the stakeholders?
   5. Etc.

What kind of frameworks or methodologies can be used?

There are many methodologies and frameworks out there and none of them will suit your project best - only a tailor-made framework will be optimal so it would be beneficial to at least consider alternative methods or tools to see whether there is a room for improvement.

Methods and frameworks that COULD be used for managing IT projects in Snowden’s domain are listed below (in opinion of the author, of course) :

• Simple Domain - CCPM
• Complicated Domain - incremental project lifecycle frameworks - XPrince, ISO, Prince2
• Complex Domain - agile project lifecycle frameworks - RAD, DSDM, SaFE, LeSS

Few additional notes below:

• “Yeah, well, you know that’s just like, uh, your opinion, man… - these methods/frameworks/methodologies could be used in other domains as well. ” - yes, they could but would require tweaks or bigger changes to reflect the environmental characteristics.
• There are also frameworks that can be applied to each domain because of their high adaptability to the domain - Crystal Methods or TenStep.
• Scrum isn’t listed above on purpose as it is not a management framework - it is a set of rules to plan&execute product backlog, not to manage a project. It is a mistake made by many - if it is said that “ this project is managed in Scrum” it probably means that the backlog is managed in something Scrum-ish and the project is managed somehow else (or not really managed)
• Chaotic domain was omitted on purpose as nothing really works with it. One can use a kanban board to somehow manage the low-quality input and transform it into something workable but should get away from this domain shortly. Or lose his mind trying to move an immovable object. Based on my own experience.

Hit or miss - proper and improper methodology,methods or frameworks applied to an IT project

A simple domain

1. Projects in this domain are easily plannable and prone to a sound estimation as one just follows a project plan that has succeeded many times in the organisation.
2. Project is planned thoroughly in terms of budget, timetable, scope and quite tight tolerance of parameter shifts.
3. The scope is fixed and isn’t negotiable without a really important reason.
4. Communication in the project is report-oriented and does not engage the stakeholders greatly during the execution phase - much of the talk & negotiations takes place during the planning phase.
5. Precisely planned execution phases.
6. Typical and battle-proven quality management standards.
7. Well planned stakeholder and risk management.

What happens if we apply proper techniques/frameworks to a project of that domain?

1. That project is a stick-to-the-plan endeavour.
2. Everyone just follows the plan, there is a procedure for most of the deviations.
3. Stakeholders aren’t perpetually engaged and quite happy about it, because honestly, who likes to not only fund but be also fully onboard on something simultaneously? Answer is : everyone would like to avoid that.
4. Project Manager deals mainly with reacting to deviations and reporting to higher-ups.

What happens if we apply it wrong?

Let me start with obvious consequences:

1. Knowledge and experience within the organisation would be omitted at least in the initiation and planning phases
2. Stakeholders will be unpleasantly surprised about the project progress and would be forced to get engaged more to “calm things down”
3. The project would most certainly not meet its expected parameters
4. Project team and stakeholders would get frustrated as communication would be structured poorly and tendencies to bring project back on track would dominate the chatter which would perpetually decrease the motivation and esprit de corps.

The indirect consequences would be:

1. Failure of project or meeting little goals at the end.
2. Failure to complete a project that could have been a success given the knowledge and experience of the organisation.
3. Burnout of stakeholders and project team as something that could be structured was too loose and thus required constant management and shifting effort.
4. Parameters exceeded by a lot.
5. Someone’s head on a stick. Or a name on a contract termination letter.

How to manage an IT project in a simple domain? (if there are any?)

1. Sense-categorise-respond.
2. Start with sound initiation of the project - the objective, the initial scope, the stakeholders, the initial budget. Figure it out with people that keep money and ask the eggheads about a ballpark estimation.
3. Plan the project with meticulosity, use the organisational knowledge and staff experience to bring down uncertainty. Create a sequenced plan with some tolerance for really unexpected situations.
4. Watch out for the risk of complacency? What if you don’t know? Or you don’t know that you don’t know?
5. Meet with stakeholders to make sure that the plan is understood and accepted. Set up periodic meetings to monitor the progress and react to tolerance breaches.
6. Monitor parameters and react accordingly to plan.
7. After the project is closed, gather up lessons learned and reinforce organisational knowledge and experience on that matter.

A complicated domain

1. Projects in that domain are not as easily estimable as in the simple domain, as they require some analysis and experts’ knowledge on board - they are not run-of-the-mill.
2. Project should be planned in terms of budget, timetable, scope but also incorporate room for possibility of change
3. The scope isn’t fixed and can be twisted to some point but with effect on other project parameters.
4. Communication in the project is not strictly report-oriented and will engage stakeholders during the execution phase to make sure that the goal of the project is being pursued - there might be discussions to shift the scope and other parameters.
5. Roughly planned execution phases with scope and other parameters detailed ahead, but not necessarily at the planning phase of the entire project.
6. Well proven quality management standards could be complemented with tailored solutions to optimise quality management in the very project.
7. Well planned stakeholder and risk management oriented at changing project parameters.

What happens if we apply proper techniques/frameworks to a project of that domain?

1. The project has a plan on how to apply a change of scope.
2. There is a procedure on how to shift priorities or scope.
3. Stakeholders are expecting engagement and provide necessary information and are part of the decision making process.
4. Project manager deals with reacting to deviations, reporting to higher-ups and managing change of the scope.

What happens if we apply it wrong?

There are two ways of handling this domain wrong - by either applying methods that work in simple domain or applying methods of complex or chaotic domain.

Obvious consequences:

1. Knowledge and experience within the organisation would be omitted at least in the initiation and planning phases and/or project is planned too roughly or too precisely based on outdated assumptions.
2. Stakeholders can react in many different ways but mainly they either will be unpleasantly surprised about the project preparedness and would be forced to get engaged more to “calm things down” or would act to make smarter decisions about incoming phases on newly acquired information and thus making the project longer and most costly.
3. There is a risk of complacency meaning that the organisation is used to project in simple domain thus there might be tendency to downplay risks and uncertainty in order to satisfy or woo project stakeholders.
4. The project would most certainly not meet its expected parameters - not in terms of budget and time nor scope - because of ungrounded assumptions some rework is to be expected.
5. Project team and stakeholders would get frustrated as communication would be structured poorly - decisions would be made based on intuition or higher agenda of the powerful stakeholders rather than based on expertise or knowledge.

The indirect consequences would be:

1. Failure of project or meeting little goals and the end.
2. Failure to complete a project that could have been a success given the knowledge and experience of the organisation.
3. Burnout of stakeholders and project team as something that could be structured was too loose and thus required constant management and shifting effort or too tightly planned and needed rework and replanning.
4. Parameters exceeded significantly - definetely to a point when it is brought up by all key stakeholders.

How to manage an IT project in a complicated domain?

1. Sense-analyse-respond, meaning getting experts onboard and using their knowledge to plan the project to the extent of what we know and incorporate tolerance for what we do not know.
2. Start with sound initiation of the project - the objective, the initial scope, the stakeholders, the initial budget. Figure it out with people that keep money and ask the eggheads about a ballpark estimation.
3. Plan the first phases and gather enough information during their execution to be able to plan next phases and introduce positive changes to the plan.
4. Engage with stakeholders to keep them up to date with progress and ensure that project activities still lead towards the agreed goal. Keep them engaged in planning next phases.
5. Monitor parameters and use them to make better decisions.
6. After the project is closed, gather up lessons learned and reinforce organisational knowledge and experience on that matter.

A complex domain

The complex domain is probably the domain where most contemporary projects should be found. Naturally, over the years, there have been a lot of frameworks and code libraries created to help speed up the development process and avoid reinventing the wheel, however, their creation spawned new problems that might go unnoticed by some of “IT people”.

Frameworks and libraries have to be maintained or might lead to a system failure someday, whereas your own code depends on your own ability and eagerness to support it.

They are also not flexible enough to be implemented as is so they either need some twitching or they can only be treated as an inspiration to go home-made.

The much more popular scenario is not being entirely sure what the goals are - building new systems and interfaces can be based on existing frameworks and even life cycles of software which incorporate the very fact that building it should be iterative or incremental because they are human-oriented and thus cannot be designed perfectly at the conception.

That alone implies that the goals aren’t known from the very beginning and in consequence, the initial scope is either quite rough or still to be determined.

So let us determine how an IT project in complex domain would look like:

1. Projects in that domain aren’t easily plannable - how can one plan something that has no scenario outlined?
2. Very rough budget, timetable and scope - more of a guesstimation. However, there must be some basis in order to give out stakeholders some data to make decisions.
3. Project is planned around a chief goal and scope shifts a lot. Execution phases are much shorter in order to shorten the feedback cycle and make reworks and tweaks quicker and cheaper.
4. Budget, timetable scope and tolerances are discussed quite often as situation changes over the short execution phases.
5. Communication in the project is phase-oriented and requires hands-on approach from stakeholders. As the feedback cycle is short, they have to be quite engaged during the entire project lifecycle ( see the stakeholders matrix below and decide for yourself ) and be in touch with shifting priorities and requirements.
6. Execution phases planned roughly and time and product-oriented.
7. Quality management standards differ - sometimes loosened to allow rapid development of code or prototypes. Of course it comes at great risk.
8. Stakeholder and risk management focused on periodical inspections of risks and interests.

Image 6 - IT project stakeholders matrix - https://www.businessanalystlearnings.com/ba-techniques/2013/1/23/how-to-draw-a-stakeholder-matrix

What happens if we apply proper techniques/frameworks to a project of that domain?

1. The project has a clear ultimate goal that can always be brought up when stakeholders are confused about what to do.
2. The project stakeholders know that the plan might change according to greater or lesser understanding of how to achieve the goals.
3. The project has a plan on how to apply a change of scope and how to shift priorities.
4. The project has either a good ultimate goal and a rough scope that is followed or a much precise scope that can be (but not necessarily) tweaked during the execution as new information emerges
5. Stakeholders expect high engagement from themselves and make decisions upon receiving new information.
6. Project manager deals with deviations, ensuring proper communication and decision-making process, reporting to higher-ups and managing change of the scope so it does not derail the project.

What happens if we apply it wrong?

It is bad.

There are also two ways of handling this domain wrong - by either applying methods that work in simple or complicated domains or going chaotic.

Obvious consequences would be:

1. Project is planned too precisely and has no room for change (which will derail the entire operation) or almost not planned (chaotic domain). It can be tempting for stakeholders to focus only on ultimate goals and let the development team focus on the scope.
2. Stakeholders cannot provide necessary assistance in time because they are discouraged by shifting priorities, unrealistic plans, ineffective processes or lack of structure in a chaotic domain.
3. The project will not meet its expected outcome because there isn’t a tangible outcome in the first place or too much rework or replanning has to take place because of ungrounded assumptions made prior to execution phase.
4. Project team and stakeholders would get frustrated as either the project is too unorganised or is too tightly constrained to reach its real ultimate goal.

The indirect consequences would be:

1. Failure of project or meeting little goals and the end - because of too vague or too precise goals and work plans.
2. Failure to complete a project that could have been a success given the knowledge and experience of the organisation
3. Burnout of stakeholders and project team as something that could be structured was too loose and thus required constant management and shifting effort or too tightly planned and needed rework and replanning or was completely absurd in theory and practice.

How to manage an IT project in a complex domain?

1. Probe-sense-respond meaning finding the right methods and right tools that work with the project environment and incorporating enough error tolerance to inform stakeholders about future expected hiccups (of course, one could invest in thorough planning and analysis and bring the project into the complicated domain but there still is a great risk of unfounded assumptions bias).
2. Start with sound initiation of the project - the objective/ ultimate goals, the initial scope, the budget constraints. Make the feedback cycle short and make sure stakeholders and users are satisfied with the products of the execution phases.
3. Tweak the software according to their needs and explain to them why the project was so roughly planned and why their constant engagement leads to the desirable outcome of the project.
4. Plan the next phases of the project on the basis of new information and underline how important it is to listen to the stakeholders and stick to well-founded hypotheses and plans.
5. Monitor the parameters, but remember about stakeholders expectations.
6. After the project is closed, gather up lessons learned and reinforce organisational knowledge and experience on that matter.

A chaotic domain

As can be read above, it is not a project and people friendly environment. In order to keep one’s sanity, there must be an ultimate goal to pursue or it is not a projectized endeavour but a conveyor belt with misunderstood or purely wrong tasks to do and a formulated expectation to “make things work”. So let me break it down in the same manner as the previous domains and projects.

What happens if we apply proper techniques/frameworks to a project of that domain?

1. Again, something that must be stressed enough, chaotic is by definition not to be tamed.
2. A good manager must get away (or jump ship?) to a more structured domain by decreasing uncertainty and/or agreement (as in the Stacey Matrix)
3. Extracting the project from the chaotic domain will be costly and painful as it will require project planning and management of expectations (rewriting / conceptualising / starting over).
4. Applying analytical tools and techniques and making enough planning effort with stakeholders can bring the project to a better domain and lead towards a project success (with new and smart goals).
5. The project can also enter a state where something is worked on but it has no boundaries - no start nor end, no scope and no horizon for things to change for the better. A project-limbo that is a direct effect of lack of planning and which should be ended on sight as an act of mercy for people involved.

What happens if we apply it wrong?

This part is somewhat funny because then we let a formless and directionless expectation parade as a project.

Direct consequences:

1. Project is not planned at all or is planned on totally false assumptions. Both lead to disaster.
2. Stakeholders do not provide necessary assistance because they are discouraged by lack of priorities, lack of plans and lack of structure.
3. Project cannot meet the expected outcome because there is no expected outcome.
4. Lack of goals or technical knowledge leads to further frustration of stakeholders.

The indirect consequences would be:

1. Project-limbo mentioned above.
2. Failure of project as it is not even a project.
3. Burnout and suffering of stakeholders.

How to manage an IT project in a chaotic domain?

1. Act-sense-respond as in trial-and-error. Try to see what kind of techniques respond well to the very environment you find yourself in and try to formulate a pattern.
2. Manage the expectations of stakeholders well. Convince them about making an effort towards planning the objectives and the project.
3. Run away with the project to a better domain or kill the project and break the cycle of suffering.

Conclusion

A theoretically good idea is to pick your framework and stick to it. They provide good rules and baseline for your IT project and thus increase success probability.

However and obviously, every project is different and a good manager would be able to boost the chosen techniques with some changes in order to reflect the project environment better and increase the chances of success even more.

On the other hand, chaotic domain projects are typical for projects (projects-limbos-to-be) that lacked a Project Manager presence and were claimed to be “quick, obvious adventures that the development team could work out and manage themselves.”

I have consulted many projects like these and tried (some succeeded, some failed) to direct them into manageable endeavours with tangible outcomes. It takes lots of effort into replanning and managing expectations of stakeholders to get back on a right track but if the ultimate goal is worth it, it is definitely worth it to spend more money and time for a project manager and planning activities.

Now, without excessive bragging, Visuality has a few seasoned project managers with all the right moves and know-how ready to make your project management a breeze.

We are adept at conducting comprehensive audits of IT project management quandaries, unravelling complexities, and identifying pain points.

We’ve managed to untangle some mess previously - some clients needed a few quick fixes and some needed disciplined and long-term thinking but nearly all of them had a lasting impact and still stick around with us.

If you’d like us to help you with your problems or would like us to manage a project, shoot us an email at contact@visuality.pl and let’s partner up.