I recently managed a project for a new client of mine where a significant cultural issue came into the picture. Let me share it with you. The project involves integrating a number of my client’s products (lets call this company “A”) to one of their customers (lets call it “B”) in France. My client is based in another European country and the resource center, providing much of the deployment resources is based in yet another European country. In total I have about five different nationalities working on my project and located in 4 different countries.

One of the immediate impact is difficulties of communications:

My team of 15-20 people is based in 3 different countries, face to face meeting are hard to organise and so a lot of the communication is done by emails, conference calls or direct one to one calls. There is no facility to create a project workspace on the company’s intranet.
The working language with the customer is english but it does no go without difficulties. The langage barrier is pretty obvious and being bilingual helps as I am able to sometimes switch to french to ensure that the communication is clearly received and interpreted.
All this is actually a fairly standard set of issues in multi-lingual, multi-location projects. And with good-will things get done and we all overcome the language barrier and get one with the communications difficulties.

There is however a larger issue that surfaced on this project about culture, not related to country or individuals but linked to the project management culture, or the different pratices around project delivery between the two companies.

Some few background information to set the scene on this particular case:

The end customer has been already buying from my client but this time they had very specific requirements about how the project should be delivered, its documentation, its test phases and on top of that some very strong “non-functional” requirements that happened to be rather unusual in comparison to my client’s standard delivery practices.
My client has a fairly standard system integration project delivery approach for their product, meaning that the work packages to deliver follow a standard description, this is particularly true for: documentation, installation and acceptance procedures. All these are in the quality system and known to all project staff.
The end customer has a very strong set of project delivery requirements and the attention for details is significant.
None of the parties involved is using PMBOK as a reference.

What company “A” is used to do? … and not.

Company A is used to do standard deployment of its products. This means following a set of procedures and practices to build hardware, install its product, configure systems and follow a standard acceptance procedure. This is what they do all year long and in a lot of countries. The product is good, leader in its area and the deployment fairly standardised.

What company A does not do very often is the deployment of custom solutions, with complex requirements impacting the deployment of products and hardware such as backup and security requirements, with special software development requirement, with more than one product to be delivered. When it comes to this level of complexity then company A is faced with the nasty symptom of “my experience kills my creativity and adaptation”, indeed, because company A is mastering its standard procedures for deployment, it is such a habit that doing something different becomes actually very difficult. The adaptation is very difficult because complex solutions integration has not been addressed as a specific process.

What company “B” wants?

Company “B” is the customer of the project. What they want is documented in a big pile of documents – the contract – and signed by both parties. The contract has specific sections describing how they want to the project to be delivered: what are the documents they are expecting, what are the test phases the project should go through. They also have some technical requirements that are pretty unusual for company “A”.

Culture mix and shock?

The two companies project management culture meet with this project. And the encounter is painful because they do not share the same experience and habits on how to deliver projects. What “B” expects is not what “A” is usually doing and because company “A” did not see this adaptation as being a pre-requisite to the project from the outset the adaptation is happening as we go along, as we learn during the project. Obviously this does not go without troubles, delays and re-work. This could have been partially avoided if this was recognised as a particular challenge from the outset, at pre-sales stage, this would have required also that the quality department of company “A” to be involved to assess impacts on the processes but also on the resources needs for the project. Indeed with increased complexity of solutions deployment comes requirements for differents skills for the project, for example, there is no test manager skills in company “A” as testing is done by deployment engineer, but with complex solutions comes complex testing and standard tests, product based are just not good enough anymore. Examples like this are legions and all related to the same issue: both companies do not talk the same language as far as project management is concerned and adaptation to higher project delivery expectations is not an easy task.

Fixing this

There is no quick fix. When it comes to the fundamentals of how we do things there is no quick fix. And the solution is not only down to the project but involved more fundamental changes within the organisation: in the quality system, in the skills of the workforce, on the standard project procedures and it could also impact the company’s organisation as well, to better fit this type of project.

The likely output if a set of new procedures, guidelines, in other words everything that describe how company “A” does things for this type of project.

Once this is done there is still an exercise to be done: mapping company “A” project approach to company “B” project approach. Because both company has then got pretty strict discipline it is necessary to map them the make links between items like milestones, documentation, test phases.

There is therefore no quick fix and none of them, or very few of them could be implemented as part of the project because this scope of work was not identified in the original scope, and the change required cannot be fully implemented as part of the project.

What could be an outline action plan to implement those changes?

Suggested action plan

1. Review what I call the projects “topology”, i.e. identify the type of projects that company “A” has to deliver (this needs also to look into future projects). Identify projects and group them into groups.

2. Look at the “organisational process assets” – everything company “A” uses for its project and identify

3. Design for each group of project a custom (or not) delivery process (what are the main project phases, inputs and outputs, skills required, etc…). Look at what company “B” and others are doing in this area.

4. Identify actions needed to implement these new processes within the organisation. Needless to say: get backing up from management.

5. Implement it: update standard documentation and templates, recruit new skills, train people to the new processes, implement organisation changes. This is the hard part!

6. Finally, map with company “B” processes. At this stage this should be easy.