One size fits all? No way!

The difference between a good wine and a top wine is in the nuance. The same applies to the approach to an IT project. Generalising turns out to be an insidious trap. There are indeed differences, however subtle. After all, one office is not like another. And the same goes for suppliers and the solutions offered, of course. Time to dispel the ‘one size fits all’ myth.

If I have learned anything in the 25-plus years I have been carrying out projects for law firms, it is that missing any nuance in this industry quickly leads to total outrage.

An example

A firm is disappointed in the supplier of a software package. It has not delivered what the firm says was agreed upon. The supplier then fails to understand the dismay and the commotion that follows.

Anyone can surely picture such a situation. It is too easy to then just say that both parties should have communicated better and managed expectations. Especially if it turns out that they do not speak exactly the same language and even operate in completely different perceptions. This is simply not always immediately clear to the parties and there you are with your best intentions.

Assumptions: the mother of all 'f*ck ups'

No matter whether or not you are hindered by any awareness of the prevailing hierarchy and office dynamics. And who you'd better not step on toes as you dance with complexity and conflicting interests. As long as you try to avoid assumptions. They are the death knell for any project. Therefore, we list the top 5 most common assumptions.

The 5 most common assumptions within IT projects

Assumption 5: We speak the same language
Anyone who has something to sell makes sure they speak the language of their target audience. That should be obvious. But that doesn't mean you actually understand each other. This applies not only to the relationship between the office and the supplier, but also internally. Is the goal, the desired result and what needs to be done to achieve it interpreted in the same way by everyone? Is it also clear who does, what, when and what the consequence is if it is not done?

Assumption 4: Hassle must be avoided
By definition, a project creates a change, however small. However, as soon as hassle arises, every effort is made to quell it and projects are even stopped. While hassle indicates that the project is being taken seriously. Otherwise, why bother? Does something need to change and do the instigators speak the same language? Then anticipate hassle. Without friction no shine.

Assumption 3: We know what we are doing
The work processes that a project touches need to be redescribed. But by no means is there always a lot of thought given to how those processes actually run and what problems arise in them. While it is precisely those problems that the project needs to solve. Incidentally, a supplier cannot always help with this. Think of it as a chef who has to prepare a culinary masterpiece in a foreign kitchen. This can only be done if everyone knows what is expected when and there is access to the right resources at the right time.

Assumption 2: It can be done on top of everything else
At the start of a project, a representative composition of employees is often sought very enthusiastically. But a representative reflection is not enough. Appointing an internal project leader, who finds managing a waste of time, or letting team members join without commitment, time and knowledge is nonsensical and counterproductive. Not everyone has the right skills to make a useful contribution to a solid project. And those who do have them need to be freed up to do so.

And the prize for most the common assumptions goes to: one size fits all!

There is always a tension between self-interest and the interests of the group. The key is to find the right balance. This is different for every office and a delicate process. Acceptance leads to embedding the new situation in the organisation. So for every project, the degree of user acceptance determines whether the project is a success or not. Experience has taught me that all too often the difference lies in the nuance.

Looking back at assumptions 5 to 2 mentioned above, if you want to avoid them, the following control questions belong there to elaborate on:

• What is the goal, the desired outcome and what needs to be done to achieve it? Is this unmistakably clear to everyone?
• Is attention being paid to hassles arising from individual differences in perception? In what way is this addressed?
• Are work processes clearly and comprehensively described and is there an overview of the bottlenecks that need to be resolved?
• Does someone internally have the necessary skills to lead the project? And is there the necessary knowledge internally to provide input to the project? Can sufficient time be freed up for these people for this?

The interpretation of these questions is different for each office. But a ‘one size fits all’ software package or a ‘one size fits all’ implementation project offers little or no scope for this. When it comes to a software package, a ‘one size fits all’ package is often still fine for the somewhat smaller offices, but also absolutely not for all offices! So at best, I would speak of a ‘one size fits many’ package. However, when it comes to the introduction of a software package - of any kind - after all these years, I dare say that no two such projects are the same. There are differences, however subtle. If you don't acknowledge that, you also overlook the distinctiveness of offices that is being worked on so hard these days.

So as far as I am concerned, the ‘one size fits all’ myth may be number 1 on the list of common assumptions.

Dare to differentiate

By finding relevant differences, you can differentiate and highlight the distinctive nature of the office. It is not for nothing that more and more offices are bringing in an external project manager to achieve the desired results. An external project manager can effectively translate between supply and demand and provides added value for both an office and a supplier. It is preferably someone who speaks the language of both the office and the supplier. Someone who is able to differentiate and bring in the necessary nuance. Someone who guards against assumptions and functions as a liaison between the business and IT. But someone who, based on experience and knowledge of the market and its players, knows what is to be gained or lost.

 

Greetings, Marjan