No limit to efficiency?

I got fooled. I tought there was no limit to efficiency. I was wrong. And it’s not simply the inability to do faster or more things at once. You can process things faster, to some extent. You can do more, but only to a certain degree. There is a price in the long run and that is something we tend to ignore. When dealing with people, pushing the effectiveness bar too far and overloading the employee might influence the atmosphere at work, result in burn-out, and generally — decrease job satisfaction.

Every knowledge work needs introspection — the time & space to… 

  • Incorporate new knowledge
  • Build on latest experiences
  • Link between different domains
  • Gain strength to improve further

Routine helps greatly. It creates space. But most important is to simply allow time. To limit work in progress. To allow play.

Many words have been written & said about the “myth of 100% effectiveness.” I have learnt my own share and cannot stress how destructive this kind of belief is. While adding to the burden helps improving one’s tools and processes to some extent, it destroys too much to be justified in the long run.

Where is your PMO?

Where are project portfolio decisions made in your organization? Where are priorities set up — say, based on strategic goals and key development areas? Finally, where is the PMO located in the org’s structure?

Surely, it depends.

IT rulez!

Some organizations do not face many portfolio-related decisions (of the “what do we do with our strategy” type). These might have never reached a high level of push on projects — due to a lack of funds, complex structure with competing goals, and/or decision bodies. Oftentimes, they do not have a PMO at all. If anything — there’s one scattered on the IT side, dealing with both Business and IT projects. At some moment in time, infrastructure projects may be separated from the rest. That’s it. There’s hardly any development inhouse — most of it done by external suppliers.

it_rulez_small

Neither the Business nor IT know much about what the other does in “that other black box”.

Too much money?

There are organizations where there’s so much money that IT becomes a bottleneck. It’s costly, incomprehensible, always asks for more time, and… “why can’t these guys dress up in the first place?” Portfolio decisions are then made on IT level — what goes, what stays, obviously with management involvement, but with a very important stake in IT altogether. I’ve come across organizations where there was hardly a need for individual steering committees for that reason. What for?! We need to process financial decisions in a FIFO manner on portfolio level. Not if but who gets the money. Weekly, no! biweekly if needed.

At some moment the Business understands that there is more to say from a strategic perspective and a Business-level PMO might come into play.

Business-IT discussions

Then, there are organizations which managed to build a management-level PMO deciding about corporate standards, aligning reporting up to top management, not to mention — facilitating portfolio decisions, based on key factors for the organization, e.g. strategic goals, products, channels, markets, client groups, you name it. There might even be a balanced scorecard somewhere, KPIs and KSIs aggregated from team to board level. The relations between Business and IT might be based on budgets and resources (budgets again) — to see what’s available for the business portfolio managers to share for their initatives (in accordance with strategic priorities).

discussion

Obviously, this has to mature — mapping the processes, setting up simple indicators and reporting, identifying the links between processes and projects to gradually improve parts of these processes (e.g. automation), aligning this with the IT architecture and portfolio of applications. This takes time, consistent systems, streamlined reporting, and above all — positive & involved people (aka corporate culture).

At some moment, someone high above might say: “Humbug! This is all overhead! Let’s disband the whole structure, rightsize, and transfer the remaining ‘dinosaurs’ to operations!”

Bottom line

There is no bottom line. It’s just that every now and then, in the history of management and corporate life, someone exclaims “our clients are most important!” And so the story repeats itself. Most likely, there are more facets of the cases mentioned above. Care to share a few?

The ‘How’ in Project Management

Two basic need drivers:

  1. Hope
  2. Fear

Products and services aim at one of the two. Most self-help, personal development books carry a promise, they give hope. Rarely does the reader find in them the tools needed to put the content into practice. The same goes for most trainings, especially seminars and conferences.

Is experience the only teacher?

We sometimes complain that project management does not give the expected results, but do we provide enough guidance on the “how to do it” part? Please note, I’m not talking about “best practices” of what should be done (as in PMBOK), but how to apply these best practices in a set of circumstances.

How were the top 2% of Project Managers described in Andy Crowe’s book able to differentiate from the rest? Experience? As in — they managed to evade failures big enough, they bounced back faster than the rest, they managed to build up their own how?

Did they have someone to help them?

Call for mentors

Mentors are one option. I don’t think they address the root cause of the problem described above (i.e. how to make a field with lots of general knowledge, “best practices” and soft elements more applicable?). But they shift the focus towards application / practice and guidance.

Let me end with an example. Toastmasters International focuses on improving a general competence — public speaking [and leadership]. Apart from providing a certification path, developing a community, tools to focus on self-practice, it encourages its members to learn in a step-by-step way, and embeds the role of mentor into its educational program.

Is your Sponsor interested?

“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.

Is knowledge a project deliverable?

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.

Do you make it visible enough?

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

ErrorI 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.

What Is Common About Projects?

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?

Development With PDUs

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.