Implementing Product Development Methodologies across Cultures and Organizations

Implementing Product Development Methodologies across Cultures and Organizations

After experience at trying to bring various methodologies and ways of approaching product development to different types of organizations in different countries, and often not succeeding as well as I would like, I thought I would attempt at finding some explanations.

I currently think of 3 dimensions that are the most important in terms of how they impact a generic methodology or approach. This is not an exhaustive list, however, after much thought these are what I feel are the key contributors to success or failure of putting an effective methodology or approach in place within an organization. 

Communication

The way that people communicate within the organization or team significantly affects the process of product or service development. Different cultures communicate in different ways, some more "open" others more "closed". Some "hierarchical" others less so.

Language can also be a problem, often nuisances are lost in translation. The same holds true when communication is between differing teams within an organization, i.e between the technical staff and the marketing department.

Key dimensions of communication:

  • Open or closed communication
  • Inter departmental or organizational "translation" issues
  • Hierarchical communication path
  • Conflictual or Non-conflictual 

Planning

Planning is related to communication, but the way in which planning is conducted and the hierarchy of stakeholders, how they get involved and who has the final say, differ. Also the way in which different cultures follow a plan differ, some might use it as a "loose" guide and others might use it almost in a "biblical" fashion.

Some organizations skip the planning stage or do not believe that it is needed or productive. Others won't do anything without a comprehensive plan, they may be paralysed by "not knowing".

Key dimensions of planning:

  • Valued or Avoided ?
  • Loose guide or biblical ?
  • Rapid or slow ?

Decision Making

Who makes the decisions is very important, in some cultures the leaders has the final say and is not argued with, in others he is guided by staff. In some cultures even if an idea comes from a team and is well thought out, any idea that comes from senior staff is immediately seen to be superior (observations in Brazil). Other cultures need consensus (observations in Japan) and things cannot progress until the entire team is convinced of the idea.

Key dimensions of decision making:

  • Leader driven or consensus
  • Logical or political
  • Rapid or Slow

Summary


Comments

  1. UnknownJuly 25, 2014 at 1:47 PM

    Hi Avron

    This article struck a cord with me as it is something I am thinking a lot about at the moment and it is very interesting so see things from your point of view, particularly in this case how you have separated out these three important factors, all of which I had considered as the part of the bigger picture but had not spent much time thinking about as isolated concepts.

    My initial thoughts are that in all of these areas a very delicate balance needs to be found; Open communication facilitates ideas but control of that communication, particularly in a business environment, is likely to be important. Conflict may typically be a bad idea but can also open up otherwise unexplored paths. In my opinion planning is absolutely essential, but definitely shouldn't be so strict that we spend all our time planning and none of it implementing. Decisions have strength given by a hierarchical leader and that is critical, but wisdom comes from listening to a range of opinions.

    I would be very interested to know what has worked for you in practice and thanks for the blog post - very interesting.

    Thanks

    Nick

    ReplyDelete
  2. AvronoJuly 26, 2014 at 12:41 PM

    Nick, thanks for the comment. I think the three dimensions mentioned in the post are complex and so is their inter-relationship. I am trying to become more aware of how the organization "works" (to some extent) and not how the organization is laid out. By doing so, I can get a better idea of a strategy that might have a chance of succeeding. Unfortunately, I don't have a great answer to your question as yet. As soon as I do I will let you know, if one exists !

    ReplyDelete
  3. UnknownJuly 27, 2014 at 12:36 PM

    Very true, bridging the gap between reality and the perfection of a flow diagram is where the real work happens. But I'm sure there is an answer, even if it is a separate answer for each organisation.

    ReplyDelete
  4. AvronoJuly 28, 2014 at 1:56 AM

    Work in progress, would be interested to hear your thoughts ....

    ReplyDelete

Post a Comment

Please post your comments, I am interested in your views

Popular posts from this blog

The pitfalls of share options in the technology startup

Draft 1 PLEASE NOTE: I  am a simple engineer and this document should not be taken as legal advice in any way whatsoever.  Please feel free to comment or relate your stories here. All feedback is more than welcome Over the last few weeks I have been involved in trying to get a fair outcome for some options that I have in one of the many startups I have worked with over the years. As I continue to push my case forward I thought I would write some thoughts whilst fresh in my mind.  Many of us are attracted to startups due to the promise of shares or share options in the company we are joining. Many people work at reduced rates or no pay in exchange for these contracts, with the hope that one day they will materialise into some value for us. For startup companies, options are a vital currency. Initially cash is tight and using options is a means to attract the right people to help launch the company or take it to the next stage in it's evolution.  In recent weeks, I hav...
Read more

Hire for Engineers not for Frameworks

I have been faced with hiring great engineering teams on a number of occasions, I am constantly amazed at home many hiring managers and recruiters seem to focus on particular technologies and experience in those technologies. My experience has taught me to hire engineers and I have always viewed the technology as a secondary consideration. I always focuses on a grasp of engineering fundamentals and not on information about some current or past technology. In our current world these technologies are out of date by the time the ink on the contract is dry. Recently, I was approached by a leading company for a very senior role. The in-house recruiter laid on his wonderful resume with world leading software companies before affording me the chance to explain my career-to-date. He then proceeded to ask me a number of questions on specific Java libraries and how they were used. This is all information that is readily available on reference sites and in API documentation and does not ...
Read more

Insights & Suggestions For Effective Software development

I decided to note a few observations on software development based on my experiences with a number of clients over a long career, this is work in progress and would appreciate any further input or comments. Topics Data science needs systematic approach Without Specification you are in trouble Interview for excellence Agile does not mean "do nothing" Devops first is not always productive Too many resources is as bad, or worse than too little Design before Develop, before Deploy 1. Data Science needs a `Systematic Approach` We live in a `Data Science` age, it's a buzz word. We have always had data science in some form or another, it's just that the availability, techniques, compute power and volume has exploded over the last few years. Principles are not new, they are standard engineering practises, however, in the new generation of `Data Science` these standard practises are often overlooked. Here are some general rules-of-thumb I have noted down : It makes no sense to...
Read more