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?

As project managers, we ask a lot of questions.  But we need to ask ourselves if questions are the right form of communication.

When developing a communication management plan (PMBOK Guide, 4th Edition, Chapter 10) it’s helpful  to define how people like to communicate.  This encompasses both their preferred medium (email, phone, meetings) and the form your communications should take to be most effective.

It may seem harmless enough, but a question is not always the most effective way to communicate.

When soliciting work performance information we may ask about the status of an activity or deliverable. In the role of project leader or representing the voice of the customer we may ask about alternative solutions or push the edges of solutions/methods presented by team members.

But different people take questions differently.

• To some, a question is a direct request. What you mean as an exploration of a topic is taken as a demand or request to do something.

• To others, a question is a direct affront to their role.

• And questions about money, to non-money people, can raise uncertainty in your leadership and cause discomfort.

Like all communications, what matters is what listener takes away, regardless of your intent.

Pay attention to the effect questions have on various stakeholders and determine whether they are an effective form of communication with that person. Once you learn that, add it to your communication management plan to keep as a reference.

Use your questions wisely.

Projects don’t run themselves. Leadership takes active engagement with your team and stakeholders.

Anything else is usually rationalization or procrastination until you figure out a way to lead (or how to get off the project).

A corollary to “Planning is Easy.”

The difference between planning and executing a project is that the former can be done by one person.

The latter, doing the work, is done by a team. Each team member is an expert at their job and  may not see the need for anybody else’s input on their work.

That’s why communication is important.  If you want your planning to have value, a project manager needs to be a good communicator.

Without communication skills, planning is an illusion.

There are 20 management processes when planning a project and only 8 for doing the work (PMBOK Guide, 4th edition).  Yet, an overwhelming percentage of total resources and dollars are spent in doing the work.

That tells you how well defined planning can be and how messy it can get to do the work.

But everything important that happens for the customer, the whole reason for the project, is the work itself.  Get that right, and the project is a success.

Manage expectations better by entering issues into an issue log (like the one in Vertabase project management software).

This will keep them from falling through the cracks.

You’ll be reminded of open issues by due date and be able to find issues by client before your next call with them.

Clients will feel better knowing that you are on top of issues affecting their projects -particularly issues that they may have brought up.  You’ll know about them and be able to set expectations based on the latest status.

Even if the issues were mentioned verbally, in a meeting or in the hall, enter them into a centralized issue log.  Though an issue can lay low, remaining unmentioned for weeks,  it can come up and bite you sooner or later.