Focusing on projects ruins your business

I have seen product development projects used as tool to extract results from the organization. It has been chosen to solve an organizational problem. It worked in certain conditions, but when the organization grew and outside competition became harder yesterday’s solution became today’s problem.

I try to explain my point with a lifecycle of an imaginary organization. My real life example companies vary from 15 people to thousands.

Startup phase

Once upon a day a group of engineers started to develop a product. In the beginning everyone knew each other and there was fluent informal communication. The techno-cultural foundation was laid. The business started to grow.

Growth and the first coordination crisis

Money comes in and the organization grows. There is more coordination work, so some developers become managers. The organization develops “naturally”, creating specialized roles and competences. There are more customers and releases. Ownership of the product gradually becomes scattered. There are bottleneck resources.

At some point the “professional project management” steps in. It is solving the coordination problem, one project at a time. The project manager has permission (by role) to demand results. She becomes powerful member of the organization, getting credit for creating order and bringing money in. Often the personality of the project managers support this specialization. Portfolio management still works or is less important. Business does well.

This is a critical bifurcation point, a leadership crisis of unrealized significance . There is still an opportunity to start a Lean evolution. My example goes to the mainstream way. From the psychological perspective this is the easiest solution. It requires least personal change from the most of the people.

Gradual Scattering of the organization

Eventually there are several parallel and sequential programs going on at the same time. Each project is re-built and re-learned every time, because they surprisingly are different from the previous one. The projects becomes a separate powerful dimension of the organization.

The projects become a kind of device extracting money out of the complex and uncontrollable organization. The business management alienates from the R&D, because the real value seems to come from the project device – the development can be replaced, off-shored, outsourced. Long term development of the R&D is seen risky and difficult. Frustration and distrust grows at both sides.

You may recognize one or more of the following characteristics:

Short term rules. Quick fix. Avoid conflict. Nonproductive feedback. Gap between business, customer and development. Continuous reorg. Exploit development. Specialization and separation of responsibility. Cling to nonfunctional ERP. Clear social classes within the organization. Big power differences. Command and control. Waiting. Big plans. Wish for predictability. Slow and vague feedback. Learning and improvement don’t work. Projects compete of resources. Cost management. Number management. Measure hours. Maximize resource utilization. Knowledge and power seems always to be elsewhere.

Market saturation and the productivity crisis

Now the product (family) is growing old. And there is competition. The business management is facing a situation where the portfolio management is very difficult because of the complicated product and organization; lack of transparency and flexibility.

Even in this situation, I have seen the management to grab the tool that used to work, trying desperately to improve the project management. This is very painful for the project managers.

My point here is, that in product development you may do excellent “conventional” projects, and fail. Even fail because the projects have been successful.

My vote for the one word root cause would be overspecialization.

Please comment and share experiences, I have not emptied this subject.


The unbelievable power of the Organizational culture

Suddenly bumped to an old lover… reading Liker’s “Toyota Way”. On page 299 he quotes Edgar Schein’s definition of the organizational culture. This is heavy, please meditate carefully.

Organizational culture is the pattern of basic assumptions that a given group has invented, discovered or developed in learning to cope with its problems of external adaptation and internal integration, and that have worked well enough to be considered valid, and, therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to those problems.

Originally in Edgar Schein, “Coming to a New Awareness of Organizational Culture” in Sloan Management Review 26 (winter 1984): 3-16. and in the book “Organizational Culture”.


Knowledge waste in organizations

Why do people and organizations do what they do? What is the wisdom in the stupidity? Making sense of this helps to find primary questions, root causes or basic assumptions. Knowing those helps to make synthesis and applicable new solutions. And it helps to be merciful towards oneself and others. I will be blogging about models that I have found useful.

First I want to present two jewels of organizational thinking, real diamonds. They point out sources of knowledge waste in product development organizations. Originally they were presented in the book Ward, A., 2006. Lean Product and Process Development, Lean Enterprise Institute. The book contains really careful and valuable thinking. It is mandatory reading for anyone working with organizations.


1. Sources of knowledge waste are:

  • Wishful thinking
  • Scatter
  • Handover

2. In relation to Scatter Ward explicitly mentions:

  • Whenever you separate Knowledge, Responsibility, Action and Feedback, there will be knowledge waste.

These are easy to keep in mind – you will see them everywhere.

Wishful Thinking is of course wasting knowledge, resources and money in huge lumps. It also makes you to choose organizational models, that cause Scatter. Scatter in time and space is causing Handover, which is the massive observable source of knowledge waste. And Scatter makes you loose the ability to decide – real power is always elsewhere.

Obviously wishful thinking comes from ignorance, complacency and fear; not knowing or not admitting, increased by loss of knowledge. A vicious circle.

From this perspective, doesn’t it seem obvious that learning together is the medicine? Seek wisdom, go and see. Having yet another strong management role, separate, does not solve the problem. Power lies with the knowledge!

Please check how Vasco Duarte’s blog PMI and the meta-planning process looks from this perspective.

Just to give some food for thought I list the specific knowledge wastes under the three major ones (italics my brainstorming).

  • Wishful Thinking
    • Discarded knowledge
    • Testing to specification. (Interesting explicit mention by Ward!)
  • Scatter
    • Physical, social and skill Barriers

      • Distance, time differences, data formats
      • Culture, language and organizational culture
      • Busying oneself
      • High power differences – “classes”
      • Continuous organizational change
      • Overspecialization – narrow roles and competencies
    • Poor tools and processes

      • Mechanical or narrow information channels
      • Manual duplication
      • Poor communication tools
  • Handover
    • Useless information

      • Extraneous documentation and communication, Lost knowledge, False information
      • Relearning
    • Waiting

      • Milestone, investment decision, technical decision, …
      • Meeting scheduling, resources, …
      • Plans, specs, information, comments, permission …
      • Test results, bug fixes, dependent components, integration, service from tool provider/IT, …

Projects and project managers in Agile SW development

Clearing some mess around project in Agile context. Thanx for Glen B. Alleman in his blog for the impulse and discussion.

A project “is a temporary endeavor, having a defined beginning and end.”

In SW development the development work, the actual knowledge creation, design decisions, stories, whatever, is best to do in flow, small batches. The work is complex in nature and benefits from really tight feedback and conversation, including the end user. Does not sound a typical project.

However, a release in most cases fits a definition of a project. Especially when we draw the system envelope so that it includes the paying customer. The new SW to be taken into use is causing a one-time change in the socio-techno-economical system of the customer and end user. It will be considered carefully before the investment decision. In some cases this can be a sequence of improvements, a flow. In most cases, I argue, it is a big change, definitely a project. (In this perspective every project is an organizational change project.)

Now, what is so bad about the concept of a SW development project? It comes from the experience of doing it in a stupid way:
- command and control projects, bad interaction, “resource management” approach
- focusing to a one time solution in a messy org, ignoring long term learning and portfolio management
- wishful up-front planning, ignoring the complex nature of SW development
Agile, look at the values, is a counter-argument against this stupidity. I think the question how much value PMI and other institutions add, is how the learn and cope these experiences.

In other words, a “traditional” project is a bad metaphor and practice for creating software. A project done wisely is often a good way to manage customer requests and releases.

I hope to blog soon why we have messed up with projects in the course of organizational evolution. People always make wise decisions in their local context.

Then the worry of the people and the organization; What to do with the project managers. Scrum does not mention a project manager. Clearly, based on the above, the product owner does that work. But the work of the PO is increasing, a natural place for the ex project managers’ contribution. They might be called customer project managers.

I often hear a suggestion that the project managers would become Scrum Masters. Dangerous generalization. In most cases I have seen, the project managers move naturally to some kind of a product owner role. Some human oriented PMs become good Scrum Masters. Then also the organization needs to relearn the role of these persons.

What is clearly disappearing in both cases is the resource coordinator/management role. So the ex project managers will be working more with the product substance. One overspecialized role less, provided that the whole organization is improving.


Work overspecialization by requesting knowledge instead of service

Just writing down a small and simple idea I got while looking John Seddon http://vimeo.com/4670102

Overspecialization is extremely common, and expensive to overcome once established. It has often grown to the extent that everyone in the organization feels helpless in front of it. Changing this requires widening both roles and knowledge.

Culture and knowledge are accumulated from small real incidents. The following could be one practical piece in building wider knowledge and new culture by small steps.

Overspecialization is supported by the basic assumptions of the culture, like:

  • it is more efficient and safe that people do only things they know already (realized and expressed)
  • bottlenecks are handled by external resource planning (realized and expressed)
  • features delivered is value, knowledge and quality is not (realized but denied)
  • avoiding conflict to keep people (=me) happy is more important than organization’s needs (realized but denied)

Overspecialization accumulates by repeating automatically the pattern:

I as the designer with skills limited to MyArea need to implement something that touches YourArea. I add a request to Your backlog and wait. I work to get priority in Your queue. Then you make your change and it hopefully works with mine. Maybe some iteration is needed to finalize.

Result eg.:

  • I own MyArea, you own YourArea
  • I learned the external behavior, “interface”, of YourArea
  • Maybe the changes in YourArea were done more safely and efficiently from YourArea perspective. Maybe.
  • Waiting, handovers and other stuff familiar from lean studies

The key idea is to request knowledge (created together), instead of service (created by You):

I own the change/feature, also what happens at YourArea. I request consultation, advice, knowledge, pair work etc. from you. We need to schedule the co-work. There is however more flexibility in adjusting the interaction and how much effort is needed from You.

Result, eg.:

  • creating new knowledge
  • more short term cost (?assumption?), but even more value
  • overlapping ownership
  • I learn more
  • more possibilities to optimized solution
  • small risk investment, owned by designers

In a similar way, when the business and the team work together with critical details, it creates understanding of the others’ perspectives and values.


Sadomasochistic organizational cultures

I have lately been interested in power, and remembered a very interesting point of view. I am sorry that I cannot give references, this is based on a memory of an article, written years ago by a researcher in a Finnish magazine “Aseman Lapset”.

Just knowing this pattern and being able to recognize it may reveal nonfunctional organizational (sub)cultures and bad leadership.

There are many organizations, whith two distinct classes of power users and targets:

  • hospitals: staff and patients
  • schools: teachers and students
  • prisons: guards and prisoners
  • army: leaders and soldiers

The phenomenon has been recognized first in the extreme settings, but is easily seen in normal companies when you know the pattern:

  • companies: work supervisors/bosses and workers
  • product development companies: business (decides) and designers (deliver promises)

One characteristic of these organizations is that the powerful class is causing pain to the targets. It may be forcing to work, physical pain, restricting fulfilment of different needs. This is painful for both parties, and people need mechanisms to relieve the pain.

One facet of the cultural solution may be a sadomasochistic interpreatation of pain and dominance as pleasant.

  • heavy use of humor, even harsh
    • pigs and chicken in Scrum?
  • seeing “us” better than “them”. Assuming the other class does not know or understand, is stupid or stubborn.
    • For example prisoners regard guards inferior to them.
  • communicating across the class boundary in a way that prevents emotional connection.
    • using alienating language

What is relevant in organizational setting is that this kind of situation constrains heavily the Organizational Conversation (Term as used in Complexity Theory in Organizations). It also reinforces the status quo, class boundaries and limited dialogue. This causes:

  • loss of talent, creativity and learning
  • loss of relevant feedback
  • not recognizing weak signals
  • loss of work satisfaction and commitment to work

Some cure, if you wish to move to more self-organizing, self-motivating direction. Please remember, that changing habits and culture is very hard!

  • open discussion and recognition of the specific situation
  • in bad cases competent facilitation needed
    • conflict resolution, debriefing and reconciliation
  • changing power settings
  • start to improve the concrete pain points 

Measuring and rewarding individuals

At the SOL conference some time ago I attended the workshop by the brain researcher Kiti Muller and happened to mention how harmful measuring and rewarding individuals is.

It rose huge interest, so here you have the reference - Robert D Austin: “Measuring and Managing Performance in Organizations, Dorset House, 1996.

Just to brief some points of the book:

Measuring and rewarding individual performance, especially a knowledge worker, is always distorting the performance, and is potentially dysfunctional.

Dr Austin  acknowledges, that measuring organization is essential, and gives advice for constructive measurement too. Unfortunately it is difficult.

Here a brief of one critical flaw in rewarding based on individual performance:

To create value the knowledge worker does A, B and C. His/her knowledge of the detail enables balancing these.
The manager is able to:

  • know and measure A
  • know B
  • don’t even know  C

C is truly significant. There are a zillion small real decisions, that gradually make reality.

With all good intentions the manager measures only A. He might understand that this is only an indicator. Result:

  • People game. Even some that don’t game in the beginning, gradually will. A will get done in excess, even to dysfunctional extent. There are zillions of cases, even extreme. Like measuring volume of sales instead of profit. Just imagine the result.
  • The working relation narrows from co-operation to trading, degrading commitment.
  • This kind of power setting suggests, that the manager knows better, and the knowledge worker should NOT use judgement. Subtle, but very powerful and harmful, reinforcing the command and control culture.

Measuring is necessary, complex and dangerous. In principle, rewarding teams and organizations based on throughput time, customer loyalty and business is healthier. Mary Poppendieck has some advice in her books and webpage.

PS. Lively disussion at http://www.reddit.com/r/programming/comments/7sh4x/measuring_and_rewarding_individual_performance/

PPS. Check also Alfie Kohn: “Punished by Rewards, The Trouble with Gold Stars, Incentive Plans, A’s, Praise, and Other Bribes”


Echoes from SoL Finland conference

I attended the 2 day conference by the Society of Organizational Learning in Finland a few days ago. (www.solconference.com) The arrangements were  interactive with well over hundred participants and guests from France and Australia. The arrangements could easily handle even more participants.

Some things that left echoing in my mind… 

SoL France has made a study of several succesfull big cultural transformations. One key finding I want to publish here: In all cases there was a close co-operation of internal and external consultant. In every case. I have experience of this and can wholeheartedly support the finding. And here the internal consultant means really a coach, not just a managing contact person. Full time for organizations over 1000 people. Please compare with the Scrum Master role in Agile SW tradition.

I have quite strong background in working with groups and individuals. Learning Organizations tradition seems to emphasize leadership actions and other things concerning the whole. For me the experience reminded of how leadership affects local phenomena. And the Learning Organization mainstream might benefit from remembering classical (unconscious) group phenomena, like dependency, group defenses etc.

Also A close study of Toyotas practical practises might bridge the gap from values and visions to everyday work and local interaction. Also Agile software development has very valuable experiences tho be shared with other fields.

Finally this proved again that a big conference can be made interactive, inviting into participation and resulting to great energy and feelings of connectedness.


Follow

Get every new post delivered to your Inbox.