“If sponsors are too busy (…), I recommend project managers camp out – take their laptop and work in the lobby outside the sponsor’s office, if need be, until they can get an audience.” – Corinna Martinez
Source: PM Network, May 2012

For projects managed on the customer’s side, where there’s typically more need for an active Sponsor, setting up a recurring update is a useful practice (e.g. weekly or biweekly – depending on the project’s length, among others).

When problems occur, we shouldn’t expect our executive to become engaged, if we haven’t kept him or her interested in the initiative while there were none whatsoever.

Knowledge Management is a beautiful concept. And a poor practice.

It comes naturally with a fixed team or an operational setting, thanks to employee networking. Even here conscious knowledge transfer is a rare thing (i.e. knowledge transfer standards, knowledge maps, sound databases, menthoring and the like).

Knowledge Management is particularly useful for temporary organizations. Typically known as projects. Here the organization is often disbanded upon closure. Deliverables remain (hopefully). And so does knowledge. Why not store it?

Why isn’t knowledge treated as a project deliverable by itself?

Transferring knowledge requires standards or even better — habits. Best if the PMO or the Sponsor are keeping score. As a Project Manager, we’d do best to obtain early buy-in from them, agree with the team, and make sure we codify the knowledge according to the PMOs requirements (e.g. information needed, categorization by process groups, standard project phases or governance rules etc.).

Here’s an important thing… We talk about lessons learned at the end of a project usually. Why not make it a regular practice during weekly updates or daily stand-ups (in Scrum we perform a retrospective for every sprint.), i.e. adding the following questions when synchronizing with the team:

  • What went well?
  • What could we improve?
  • What have I learned?

We could then make use of our dust-covered lessons logs (described e.g. in PRINCE2) and make sure we have something to share with the organization upon the project’s completion.

How would you build a habit?
You wouldn’t put your tools in a closet, would you? Better trip over them than forget.

How would you make sure you’re heard?
You’d use vocal variety, pitch, tempo, and vivid images, appealing to logic and emotions.

How would you make sure everyone’s on the same page?
Among others, you’d make it… visible.

Explicit works best — boards (e.g. as in Kanban, Scrum), printed, large dashboards, avoiding attachments in correspondence, but rather embedding additional content as thumbnails-teasers (with links).

The threshold to build momentum is substantial with electronic tools. That’s why Lean practitioners prefer analogue.

I made a mistake. It involved relations between stakeholders in a project. I hope I will be able to sort it out, but it’s already in the “issue” bucket.

At the end of the day my wife reminded me that we can only look back for lessons learned — to learn as much as possible from a given experience, to prevent it from occurring again.

Sometimes all it takes is a wrong forward or carbon copy of a message for hell to break lose. Even with good intentions, even with hopes to resolve an ongoing dispute. Mistakes come in different forms and flavors.

“Between stimulus and response there is a space. In that space is our power to choose our response. In our response lies our growth and our freedom.”

— Viktor E. Frankl

Sometimes it feels we cannot wait, but even then we should consider waiting

Consistency is supported by restraint. A consistent person maintains a steady stance, using emotions like a tool rather than to be driven by them. It takes time to become proficient at that. But it’s a good road to follow.

Mitigate using the strongest communication tool and limit the parties involved

I prefer picking up the phone or an informal F2F to solve a delicate or more complicated issue. If there is an ongoing “flame war” and I see a chance to settle the case, my “lessons learned” is to radically decrease the number of recipients in any follow-up or summary (especially the “for information” type). And definitely double & triple check before pressing “send.”

“Don’t drive drunk”

Even if drinking is not the case, we have to assess our ability to think clearly. A brewing illness or little sleep can seriously impact our thinking, emotions in particular. Especially then, it is advisable to wait and reconsider.

Differences between project environments never stop to astonish me. Having experienced a number of approaches to project management, I can’t help thinking there’s so much more to a project than what’s described in a typical manual. In fact, I often wonder — is there anything common about project management apart from a couple of definitions?

I have recently come across construction “projects” where hardly any scheduling was expected — everything process-based, depending on sequential document updates and approval steps, preferably tightly supported by workflow tooling. Project managers? A handful, basically pushing “their projects” from step A to step B, often taking care of more than two dozens of such activities.

Then, there are projects without a Steering Committee whatsoever or depending on a common body — doing both basic portfolio management and project / program steering and treating projects in a FIFO manner.

There are stories of Project Managers who used to work with their teams in an operational-like manner and discussions about virtual teams becoming predominant in our times.

Or construction PMs acting more as salesmen and account managers, depending on site managers to do “typical project management”.

Why are various project management implementations so different? Why can’t one find scheduling, risk management, change management or let alone earned value management in most settings?

Even if we are understandably against “silver bullets,” what are best practices for?

A while ago I opened my email to find a fresh, consitently regular information from Cornelius’s PM Podcast service (hope you feel better now, Cornelius). This time the topic of the podcast was about changes to PDU (Professional Development Units) categories made by PMI. If you feel like learning about this, please take a look here…

I wanted to spend a moment to reflect on this PDU thing. Some of you might have come accross PDUs a while ago and wondered why did they exist in the first place or what was their value?

Project Management as an ever-changing discipline

There is a lot of “art” in Project Management. In that sense I find it similar to medicine. “Evidence-based” is more of an ideal, difficult to reach in practice. The complexity one finds in a typical project allows only basic support from project methodologies and business processes (applying methodologies — often complex by themselves — also requires experience). The best advice is then to constantly learn and re-learn, to “stay in touch” with our métier, pick different “angles” – methods, tools, and disciplines. Our toolbox needs to be challenged all the time. Continuous learning and improving one’s effectiveness and efficiency at that is a good option.

Nothing helps better than a healthy dose of routine

As a PMP one has to gather a number of points in a defined period — based on seminars, conferences attended, volunteering etc. To reach that goal regularity is advisable.

If you add the fact, that PMI Communities of Practice give countless learning opportunities free of charge (I’m a big fan of webinars, BTW), one can only appreciate the “healthy push.” The more we value others sharing, the more we feel the need to give back, to join this “best practice-generating cycle.” Involvement is where the fun starts.

I have read an interesting statement about project objectives recently:

Question: “How does a successful Project Manager effectively communicate the vision and objectives of an organization to the project team?”
Answer: “Some of the most successful projects I have been involved with, both leading and as part of the project team, have also asked the team members what their own aims and objectives are.”

(The discussion took place in a closed group — I decided to remove the names of the authors in this case.)
project_team_individualAs project managers we aim to deliver expected results with focus on the following:

  1. Project objectives
  2. Team
  3. Individual members

Of course, one could argue we should consider all known constraints, knowledge areas or themes. Understood. There are many project-related aspects to juggle with, but the above focuses on a leadership perspective — overall project, team, individual members.

No. 1 — project objectives — is a no-brainer. We launch projects to “translate” business objectives into reality. To reach these objectives we form a team (no. 2), a team composed of individuals (no. 3).
When a project is launched teams and members are closely considered. With the deadline behind the corner, however, it’s common to neglect some of the PM’s team-related duties, the project manager is less likely to give team members enough attention. This is why I find the idea — to consider both project and team member objectives — useful throughout the project.

We might not need to communicate team member objectives in the same way as project objectives, but it helps to know them and return to them at regular intervals, e.g. team meetings or discussions with our colleagues.

“How do you understand the objectives of the project?”
“What are your personal goals related to this project?”
“What do you want to achieve as a member of our team?”

One can say that we should apply the same strategy for the project team as we do with other stakeholders — define attitude, influence, and expectations — objectives (among others). Moving a step further, i.e. keeping the team’s objectives closer to overall project objectives, might help us maintain stronger focus throughout the project.

Other suggestions:

  • Use the kick-off to communicate project objectives and their link to strategy (bottom-up), link to deliverables (top-down); use the occasion for the sponsor to endorse you, make you his or her representative
  • Put project objectives in a visible place throughout the project — board in meeting room, presentation / document templates, email signatures etc.
  • Repeat project objectives when possible / review at phase gates
  • No need to repeat that, I suppose — make sure project objectives are S.M.A.R.T., linked not only to deliverables (traceability), but also the business case

What are your favorite practices, techniques with regard to project and/or team objectives?

Interesting posts on the topic:

DandelionIn life — nothing seems permanent. As it was famously described by Steve Jobs in his Stanford Commencement Address:

“… death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away.”
Source: http://news.stanford.edu/news/2005/june15/jobs-061505.html

I’ve previously written about the “3 things that matter”. It occurred to me that there is an extra layer about things, ideas and people — permanence.

Things age. All of them. Attaching oneself to things is plain shortsighted.

Moving on to ideas. Most of them age as well — it takes perspective to see that, but man’s history is littered with dead ideas, which back in their time felt permanent. They weren’t.
Some ideas evolve.

All relationships can become timeless. Throughout our lives — and this is certain — we work on relationships so that they can evolve and develop, for the common good. When we look at “famous people,” their likely impact on our lives, on history, was through connecting with others — leading them, helping them, serving them.

Things age, most ideas become obsolete, and relationships — have the potential to be timeless.

“We take a little piece of every person we meet with us, wherever we go.” — @marcandangel

How does this matter?

Personally or professionally, what we do allows us to connect, serve, and inspire other people. By learning to recognize the importance of relationships in our actions, we embark on a journey towards timelessness.

Construction by caribb

Photo courtesy of flickr.com/caribb/

Can’t you simply develop an application, write a business procedure, set up a point of sales, build… another Dreamliner?

The problem is either too big, too complex or there is not enough time for operations to deal with it.

I used to think ‘projects’ were but a modern buzzword stolen from the construction business. After all, we used to build buildings, roads, bridges, for quite a while (these were big). By the same token, we now farm, hunt clients or execute (things, hopefully).

I used to think good operations would be able to manage (or execute, for that matter) the kind of change that is expected from a project — thanks to sound business processes and continuous improvement.

And yet, if projects are a means of putting someone’s vision into life, the TO-BE can differ significantly from the AS-IS, and it may be that a vision is almost oposite to any “business as usual”. A broad perspective then, a different set of skills or know-how, combined with orderly, persistent execution, are the kind of ability you look for in a Project Manager.

Product, customer or operational excellence — according to M. Treacy and F. Wiersma one of these three directions is a choice every company needs to make in order to succeed on the market.

… Apple is all about products — solid, shiny artifacts.
… Amazon is about customer intimacy — top-notch service and support. 
… Walmart is about operations — quick, low-cost, “reusable” business processes.

You cannot be all three. If you want your brand to stay meaningful, you better chose.