Define IT Project [Part 2/2]
How models of successful communities helped us shape a different approach.
This post is following Define IT Project [Part 1/2] in which we have identified these 5 major challenges in IT projects :
Unknown & misaligned KPIs
Tech understanding by business + Dynamic orgs
Learning implies mistakes
Uncertainty & visibility
No clear individual responsibility
Delivering IT projects has been painful but also gave us a lot of hope.
As we provided Skilld services for IT projects along the years, we suffered way too much from these paradoxes that the definition below (which was already raised in the previous article) is now deeply imprinted in our minds.
"IT Projects are projects between people who don’t know what they want and people who don’t know what they do”
Behind the nice quote, this is true and costly on so many levels. It impacts human relations and the capacity to keep deadlines, of course, but may also lead to degrading your commercial & suppliers relationships, and ultimately your P&L.
In the meantime, we’ve been increasingly involved in one of the biggest open-source IT communities : the Drupal Community.
This kind of open-source communities that’s open, distributed, fair and also fairly efficient. So as some point, we thought… why not apply the open-source Community model to IT projects & services ?
Over the years, we’ve been more and more convinced this model could solve all the previous challenges we listed above. Since, we managed to implement these principles into our Skilld organization and offering, with our fair share of proven results.
To be more specific, we found out that Skilld IT Community model shows a direct response to the 5 key issues found in every IT project:
Unknown & misaligned KPIs => Proximity & Sense of belonging
Tech understanding by business + Dynamic orgs => Community behavior
Learning implies mistakes => Collective responsibility
Uncertainty & visibility => Raise uncertainty awareness
No clear individual responsibility => Chaos & conflict management
Here are a few examples and concepts to help demonstrate how.
#1 Proximity & Sense of belonging
(Large) companies imply (complex) conflicts
In a very simple way, you have an usual conflict triangle in management and decision making process:
Sales (optimizing current quarter sales funnel) vs Production (avoiding production downtime) vs Finance (optimizing cash flow)
This is more or less related to the fact that each and every business unit optimizes its own KPIs. They do no share the same goals. They are not judged by the same people.
But this is not really a triangle.
Typical conflicts with an IT project
Sales Team: wants their IT project ready asap > for selling more
IT Department: wants to apply security & compliance rules by all means
Future users: want the best features possible (lazy lazy humans !)
Purchasers: want the best “buying conditions” (aka often the lowest price :))
Legal Department: wants to be covered against all legal risks
You thought you only had an “unknown KPIs” issue. However you also have a huge crowd of conflicting people who are not even sharing the same KPIs…
Impossible risk evaluation
If you do not agree on what are you goals, think of math once again, there will be no risk measurement.
You simply can not know if you are on the path of success.
And worse, you can not share this assessment with other project members in order to get a fruitful collaboration.
In order to solve a conflict, you need communication & trust
Without a high level of trust and proximity, conflict resolution is not efficient nor agreeable, often ending in avoidance or accommodation behavior.
Sense of Community
How could you then ensure project success through an aligned team, given the fact that it is already a lack of trust & proximity & conflict within your (large & distributed) customer organization!
Added to that, difficulty is increased by a lot of scaling factors:
Nevertheless, we have a very good example of such successful organizations which are similar to our context : open-source communities, and in particular the Drupal Community.
A lot of competitors (no trust) do collaborate in a worldwide (no proximity) meaningful organization and are happy to meet IRL sometimes.
The idea was to take inspiration from these kind of communities organizations in order to tackle our first KPIs challenge through two main axis :
Increase and leverage a sense of belonging in order to ensure a mindful & trusted collaboration spirit (as much as possible).
#2 Community behavior
Stakeholders and shareholders
If you represent a project as a chain of people, the further you go away from the tech team towards business & strategic level, the less people tend to be collaborative (empathy is related to proximity) & are less able (or willing) to understand your (tech) challenges.
Moreover, organizations are dynamic, people are moving away / new people arrive & so on. And in a typical project, various suppliers are involved at the same time.
In a few words:
You simply can not know all the players. Or at least not very well.
They might not even be willing to communicate and collaborate with you, nor able to understand you.
Competition vs collaboration.
Shareholders vs Stakeholders
You don't have the full vision of the game. You don’t have enough proximity with the ultimate strategic decision level and you have a limited freedom of political move.
The first great idea here was to accept this situation as it is (aka complex & chaotic) and find new ways of aligning people and organizations in an open world through code & automation processes
This is exactly how DAOs work : thank to blockchain process and explicit rules, people can start to collaborate without the need of trusting each other (which takes time).
The second great idea was to develop the collective awareness through personalized risk management processes. If we can not align the KPIs, then we need to personalize the risks assessment for each & every user.
For example : proximity & informal communication :
we have an intensive use of tools like Rocket Chat (like Slack, but open-source) and tend to avoid formal emails as much as possible.
we are able to monitor this informal communication level and detect if there is not enough human proximity between two roles of the given community.
#3 Collective responsibility for individual mistakes
Who is not afraid of the judgment of other people?
Imagine you are a football player in a team. Your success is related to the team success AND your individual performance:
If the team loses, you are all fired
If the team wins but you don’t score, you are fired
If the team wins and you score, you are OK…but do the other team players still like you?
If the organization or the company culture does not allow individual failure then it is a toxic organization. It is not sustainable and only relies on very talented people (aka no mistakes allowed).
But not only: very talented people…who play well together as a team.
In other words for IT projects: it never happens! (for multiple reasons like: scarce resources, rapidly changing tech, immature onboarding processes & so on)
People can not learn & be happy if no mistake is allowed.
So, instead of blaming people, the idea is once again to rely on the community as a whole in order to manage these failures trough various means:
Efficient distributed onboarding processes
Quality control processes
Conflict management processes
Continuous improvement processes
Post-mortem (aka Lessons learned in the PMBOK methodology)
#4 Raising the uncertainty collective awareness
What are estimates ?
Just a simple example so that you will understand how huge structures have a huge impact on this topic:
Imagine you are building a new plane. Like Boeing or Airbus.
The Sales Director will want to sell these future-awesome-low-CO2 planes to customers before you even know exactly how to build it! A380 was quite a challenge for example…
Your customers (aka airlines) will need a delivery date (with financial penalties) in order to communicate & start selling seats on their side accordingly.
Estimates are here to avoid any unrealistic analysis. Not to tell the truth.
Estimates are based on (a lot of) hypotheses.
That’s the responsibility of the project leader to bet on the more likely outcome.
And then the risk management process will imprint deadline pressure on people all along the project.
NB / In a large company, this is tightly related to risk management challenges. (if you are interested, have a look at Didier Gourc’s researcher work)
Avoid sterile conflicts
To negate the need of visibility for shareholders is as dumb as thinking that estimates are the binding truth for stakeholders…
However considering that no stakeholder wants to give the bad news about delays to shareholders is also something to consider.
So the idea in a few words again here is:
to accept chaos as it is (as much as possible depending on the previous scaling factors)
to manage this uncertainty instead of negating it. This means : communicating, sharing information, personalized dashboards & so on.
to enforce conflict management and collective intelligence whenever needed.
#5 Chaos & conflict management
Conflict is normal & healthy
A living organism evolves. Learning implies mistakes. Chaos is everywhere.
However if you blame mistakes instead of acknowledging them, you will only hide reality. Not prevent it from happening. And if you prevent conflict from happening, you will only get a bigger one in the end.
Chaos, Mistakes and Conflict management are part of a sustainable organization.
More precisely : collaborative chaos/mistakes/conflict management
Let’s have a look at the different types of outcome in case of conflict :
How to behave in competitive environments
IT Projects are typically done in a competitive environment:
Blaming other people’s fault is typically the default behavior, although NOT a cooperative attitude (nor helpful for the project, apart politically for yourself)
Collaborative acknowledgment & solving the conflict is the only efficient solution left. (apart from a collaborative compromise)
In this regards, spending a lot of effort narrowing the responsibility down is not very useful, unless used in regards of continuous improvement (vs blaming).
Even more if you consider than some team members are robots in our context of community processes automation.
We are convinced that IT Communities are the future of IT projects.
We are convinced that a new organization is urgently needed.
A new organization which will mean more freedom & happiness at an individual level, and more flexibility & reliability at the organization level.
And that’s exactly why we do what we do:
Building Skilld IT Community with you !