Another technique I’ve been using to increase Agility in our production process is to be less patient with team members when a customer’s need is not met.  This has shifted the focus of the team directly on creating value to the customer. Agile has breathed new life into this classic management principal, from Peter Drucker (perhaps because Agile ties it directly to project management and a production process rather than remaining an overarching corporate philosophy).

Cultural boundaries have become less important using this approach. We operate in a culturally diverse environment. People have different definitions on what it means to put in a good day’s work. By rating performance directly against customer value, people’s perspectives have started to converge and cultural backgrounds matter less.  Problem solving becomes the focus. Each person brings their unique talent to the table. Constraints like cultural norms or a person’s title fade into the background.

We’ve been adding more Agility into our production process here at Vertabase.  As product manager, I’m leading this effort.  One of the techniques I’m using is to push-back at the development team when they ask me questions, particularly about features.

One of my favorite responses is “Do I need to make a decision on this now?”

The urge to make a decision now is strong, coming from a plan driven background. But it unduly locks-up the team, our customers and our product.

While it is comforting for the team to have me (or a customer, for that matter) make a decision, it makes them less nimble and responsive. It focuses them on meeting a set of requirements, as opposed to the customers’ needs. The responsibility for the feature is no longer in their hands. They can simply follow directions and meet a spec.

So far, the team has been empowered by seeing that a decision doesn’t have to be made nor a policy/spec adhered to, and re-focused instead,  on the simple art of the right feature implemented well.

Here are three mindsets that create non-productive project cultures. They reduce the probability of implementing change successfully and of your project really changing anything. I’ve seen them in different countries around the world, across national boundaries (though some regions tend to exhibit one or more to greater degrees).

1. Harmony Above All
2. I’m the Boss
3. Short-Term Grab

1. Harmony Above All. This mindset shuns conflict (and project truths). Harmony above all denies problems, preferring to report that everything is possible, everything is going great on a project and that everyone is happy. It stems from a belief that pleasing the project manager is dependent on words and deference, rather than results.

2. I’m the Boss. This mindset breeds conflict. It uses any interaction as a mechanism to assert one person’s control over the other. I’m the boss focuses excessively on interpersonal issues and a project’s politics. Truth and project metrics are used subjectively to illustrate the reporter’s point of view. It stems from a belief that a person’s relative position is more important than results and that the highest reward is to be in a good position relative to other people.

3. Short-Term Grab. This mindset is opportunistic and scheming. Participation in a project is viewed as a means to fulfill a short-term need. People take actions to fulfill those needs, regardless of their impact on the project. Interactions are used to attain those needs or position one’s self (or someone else) to attain those needs. It stems from a paucity of opportunities over the long term and an inability to forecast a consistent path to basic-needs fulfillment with any degree of certainty past today or tomorrow.

Creating Change.

These mindsets distort a project away from results. They share a common feature in that failure is viewed as bad and that a project’s result is secondary to the opportunities presented by simply being involved in a project. Only in a culture where failure is acceptable can change succeed. You can strip these mindsets of their power by rigorously focusing rewards on results and accepting failed outcomes (make sure to communicate the consequences of failure to your team, namely, that it’s a learning experience and not the end of their opportunities –of course, these needs to be handled delicately to reduce moral hazard).

I am speaking at this year’s IUE2011 Conference in Ann Arbor, Michigan.

IUE is a four day, international event on user experience design co-sponsored by the Michigan Chapter of CHI. If you are interested in ux designing, this conference is full of solid information, practical strategies and a good dose of future think.

My session (description below) is currently scheduled for 10 am on October 12th (in the “tough act to follow” slot right after Peter Morville’s morning keynote).

Closing the Communication Gap in a Virtual Environment
Fluid communication and user feedback are critical to effective design. Communication challenges are multiplied when working with a virtual team or non-collocated stakeholders. This session will provide participants with clear, actionable ways to improve communication and therefore produce more effective user experiences. Taking to heart the latest research on communication and how professionals learn, this will be an interactive, participant focused session, free of any PowerPoint slides.

Humility can very often be the most right thing you can do on a project.  Sometimes, the more important the work of the project, the greater the need for humility.

The CERN scientists bring this message home in the closing paragraph of their paper on the faster than light particle.

Despite the large significance of the measurement reported here and the stability of the analysis, the potentially great impact of the result motivates the continuation of our studies in order to investigate possible still unknown systematic effects that could explain the observed anomaly.

Rather than touting their results, they are exposing them to further scrutiny -for the sake of finding the truth.

An inspiring statement in the tradition of noble scientists.

(Is there a model for the noble project manager?)

Two remarkable events in the scientific world over the past month shed light on how we can improve projects and deliver the right solutions.

The decoding of an AIDs protein and the publication of the CERN findings on a faster than light particle.

These are incredible accomplishments in their specific domains. However, what strikes me as particularly relevant from the project management perspective is the context in which these events are happening.

They each represent changing paradigms about the context in which knowledge is created. Decoding the AIDS protein occurred under conditions where the data was made public, where strictures on applicable problem solving methods were removed, where the downside implications of a team’s failure were minimized and where there was sufficient information to approach the problem yet not bias potential solutions.  Creativity, cross-domain sharing of tools, techniques, knowledge and processes occurred, and people were rewarded (either externally or by an internal feeling) just for trying.

This is a powerful model for the kind of environment we can create on projects and throughout the life cycle of the project’s objective (its product, service or result).

Similarly, the CERN announcement represents a blended paradigm of traditional scientific knowledge creation melded with an open approach.  The CERN scientists are asking for the world to go at the data to disprove or confirm the results.  There doesn’t seem to be a traditional, silo based aspect.  Given the magnitude of the discovery (and the fact that it was experimentally derived rather than theoretically) the team is putting it out there for the world, professionals and amateurs, to approach.

Take note, having empirical data makes it easier to share the problem across domains. The data, like in the AIDS protein example, becomes a boundary object for cross-domain sharing.

On projects, we can encourage this kind of approach by creating true boundary objects (and not just project artifacts that pm’s, engineers or other specialists can understand).

Creating an environment and artifacts that foster meaningful and useful communication can have a significant impact on the success of the project’s objectives to meet the underlying goal /problem that sparked the project’s initiation.

As a vendor, your contract with a customer defines the project management plan, to a large part. It specifies the how’s, what’s, what if’s and why’s of the project. It becomes the structure in which your project operates.

Don’t leave this all up to attorneys or account managers.

Make sure you, as a project manager, are included in the contract development process.  It will give your project the best chance of meeting your customer’s expectations, and your company’s business goals.

Sometimes you do need to ask a question. You need to make the first move.

• Ask for help.
• Ask for advice.
• Ask for a deeper relationship.

These are the most powerful questions to ask.

When you are open, unafraid and ready to work with other people. Truly work with them, together.  Without judgment or control.

This can be especially scary for a manager who believes their value comes solely from their position on the org chart. (See imposter syndrome and imposter syndrome in project management here and here.)

Foster collaboration instead of direct delegation.

A project is a collaborative endeavor. Everyone has a contribution to make. Your job as project manager is to let people give their best. It is better to lead then to delegate and direct. (Team members are not mini-me’s.)

Create an environment where each individual works with others to bring their unique talent to the project.

P.S. Leadership and vision ultimately are what bind people together to work towards a single goal. Authority alone can’t hold it together over the long-term.

A corollary to “Is a Question worth It“:

Spark a conversation, instead of asking a question.

Use a form of communication that invites the other person to come up with a solution or offer an avenue of exploration on their own.  Present them with the problem you want to solve.  Open yourself up to letting them take the lead.  It puts everyone on equal footing, builds trust and strengthens your relationship.

It helps your team come together, which is a great thing for a project manager. After all, isn’t it about building an effective team that works together to deliver the project’s goals?