Andy, a colleague and friend, commented on one of my previous posts where I posted a decision tree for the busy manager, assisting a decision whether a meeting is worth attending or should be ignored. In his comment Andy noted, quite correctly, that this types of decision should be governed by a company’s policy. He was also kind enough to provide a link to a post in Feld Thoughts titled “Urban Airship Meeting Rules“. Urban Airship has 9 “meeting rules” that are, in the main, common sense.

Check this out:

0. Do we really need to meet?

1. Schedule a start, not an end to your meeting – its over when its over, even if that’s just 5 minutes.

2. Be on time!

3. No multi-tasking … no device usage unless necessary for meeting

4. If you’re not getting anything out of the meeting, leave

5. Meetings are not for information sharing – that should be done before the meeting via email and/or agenda

6. Who really needs to be at this meeting?

7. Agree to action items, if any, at the conclusion of the meeting

8. Don’t feel bad about calling people out on any of the above; it’s the right thing to do.

Think about it!

Today’s Twitter Gem is courtesy of Craig Brown who provided a link to an article written by David R. Law from the William Glasser Institute, titled “Appraising Performance Appraisals:A Critical Look at an External Control Management Technique“.

The gist of the article is that though performance appraisals, being a key concept associated with the Management by Objectives (MBO) movement, have been around since the early 20th Century, their usefulness and benefits are cast in doubt.

Some of the key issues identified with performance appraisals by various researchers include the following:

  1. Deming refers to Performance Appraisals as “the most powerful inhibitor to quality and productivity in the Western world
  2. Appraisals have been said to “..inspire hatred and distrust among employees…”
  3. Performance appraisals systems are based on a set of widely held, invalid assumptions. For instance, differences between people’s performance is more likely to be a result of the system in place rather than the individual’s actual performance
  4. They can be detrimental to team work as individuals can be “turn between actions that would benefit the team and its goals, and actions which might place the employee in good light for the appraiser“.
  5. They represent a form of external control. “As employees, we dislike performance evaluations because, as human beings, we are hard-wired to resist external control“.

 So, are there alternatives to performance appraisals?

W. Edwards Deming is considered to have been one of the most influential thinkers in the management field..when asked what an organization should do in place of performance appraisals, Deming is reported to have replied: “If your performance evaluation system does more harm than good, just quit doing it. You don’t have to have an alternative to make an improvement.”

Some alternative approaches suggested by various studies include:

  1. Self appraisal by the employe rather than external evaluation by a superior
  2. Establishment of a “two-way conversation between the manager and employee which involves a change of ideas rather than judgments, and which is devoid of elements of ranking, competition and compensation“.

If we accept that a primary goal of management is to improve future performance, then the communications between manager and employee must avoid affixing blame. Instead of past-orientation, the conversations should focus on the present and particularly on the future…quality is improved when we improve processes, not by increasing inspection.

Think about it!

 

Elizabeth Grace Saunders  has a wonderful post in HBR titled “Break your addiction to meetings“.

She contrasts the traditional definition of a Manager, with the modern-day definition, defined by Elizabeth as follows:

An individual who races through the halls in a frantic attempt to make the next meeting on time while also answering e-mails on his or her mobile device.

The issue Elizabeth is attempting to tackle is the endless and back-to-back meetings most managers need to endure during their day at the office.

What I liked the most in the post is the following decision tree, relevant to all managers (including project managers):

Should you attend that meeting

Makes you wonder, doesn’t it?

Think about it!

Every once-in-a-while I come across a tweet that dumb-founds me. I don’t intend to reveal the identity of the tweet’s author (though you are free to search for it if you are really interested) as my issue is with the message not the messenger.

So, without further ado, today’s ‘Twitter Duh of the Day’ is:

If you want certainty around ‘when’, don’t estimate. Invest in an infrastructure that allows fortnightly (or quicker) delivery. #agile #pmot

Without context and an example (that can at least get discussed and critiqued) this is simply nonsensical and nothing more than a meaningless statement.

Think about it!

Today’s workforce environment is as exciting and stimulating as it has ever been. Gender equality (well almost) and increased levels of multiculturalism mean that the average project team’s social and gender mix is as diverse and colorful as it has ever been.

I was pondering this point after being approached by Dan. Soft spoken and gentle giant, Dan was one of the business analysts working in my project. Given the nature of the project I had a team of 10 business and process analysts assigned to me, all of whom reporting to Julia, the BA’s team lead.

“I have a problem I need to talk to you about”, Dan said.

“Sure, what’s the problem”.

“I can’t work with Julia. She is driving me and the team crazy. She is micromanaging me and continuously interferes with my work. She needs to let go, I can’t work like that”.

“Ok”, I said, “let’s see if we can get to the bottom of this. Can you give me an example of the last such behavior that made you decide to come and talk to me”?

“Easy”, Dan said, “we just completed our standard analysis review. During these reviews we collectively look at the various models that have been worked on in the last cycle and make sure they are all properly and correctly integrated. Each member of the team walks through their section of the model and the team provides feedback, asks questions and give comments and suggestions. What drove me crazy today is the fact that as I was going through my presentation, Angela kept on asking the team – somewhat aggressively if you ask me – to find issues with my work. Not sure what was her problem, if the others don’t have any comments to make why does she have to push them to find issues”?

“I think I understand your point”, I answered. “You feel that Angela is picking on you for no fault of your own and you are hurt that she does not trust the quality of your work”.

“Correct”, Dan said, “so are you going to ask her to calm down a bit”?

“Well, I am certainly going to have a chat with Angela. In my experience there are always two sides to each argument. Let’s see if we can settle this peacefully”.

The matrix nature of my organization meant that most of my resources were assigned to my project by functional managers from different disciplines. Angela, like the rest of the business and process analysts, was a member of the business analysis center of expertise. I didn’t know her very well, beyond the fact that her line manager thought highly of her and assured me “she was the right person for the job”. From a project perspective I was comfortable with her performance given that her team’s deliverables were produced in accordance with the plans in a quality and timely manner.

I caught up with Angela later that day and described to her what transpired during my meeting with Dan.

“Interesting”, Angela said, “I have a different recollection of how the review meeting went. Want to hear about it”?

“Of course”, I said, “I am keen to get to the bottom of this”.

“Well”, started Angela, “over the past few weeks I’ve started noticing that some of the team members are not actively participating in the discussion. Two are uncomfortable voicing their opinion in a group environment and three others are relatively new to this country and are not culturally inclined to display what they perceive to be confrontational behavior. This means that out of a group of 10, 50% of the team does not actively participate in the discussion, putting in doubt the our ability to ensure we are producing a quality output.”

Angela paused for a minute and they continued.

“After I realized what was going on I decided to take control of the meetings and prompt the team to provide their input. Sitting on the fence is no longer an option and everybody need to voice their opinion”.

“I wonder if there was another way to resolve this situation”, I said. “if I understand correctly, you want to increase participation to ensure the quality of your team’s work if properly reviewed. The issue you are having is that not all members of the team take part in this discussion. Some are disinclined to speak up due to their personality and some due to cultural factors”.

“Correct”, said Angela.

“Your challenge is to increase participation without alienating the team. I would recommend you have one-on-one discussions with your team and explain the importance of having frank, open, non-threatening and constructive quality reviews. In the meantime I will have a chat with the HR team to see what training opportunities are available that might be useful for some of your team. I can think of things like ‘public speaking’, ‘conflict resolution’. There might be other opportunities as well”.

“Sounds good”, said Angela. “I will get to it right away”.

“Sure, and let’s keep this discussion going. This is now a project issue and we need to ensure our mitigation strategy is working before we can close if off”.

*Disclaimer: This is a fictional story and is meant for educational purposes only. Any resemblance to real persons, living or dead is purely coincidental.

Quite often, while browsing through my Twitter feed, I am reminded of the following quote by Mark Twain:

Noise proves nothing. Often a hen who has merely laid an egg cackles as if she laid an asteroid.

Nevertheless, and in spite of the unbelievable noise that one can encounter while exploring for valuable content, there are many gems out there, providing references to valuable and noteworthy material.

This week’s gems acknowledgement belong to the following tweeps:

1. Caroline McDonald (@cmcdonald_Risk) for a link to an article titled “How to map your risks.

The article, by John Bugalla, James Kallman, introduces and discusses the merits of using risk Value Maps.”A Value Map is a graphical illustration of both threats and opportunities. Because threats and opportunities are two sides of the same coin, a value map also has two sides. Threats (negative outcomes) are plotted on the left side of the map, while opportunities (positive outcomes) are located on the right side.”

A Value Map is used to illustrate not just the a single point but rather a range of values a risk (or opportunity) can take. The article does not explain how these ranges are derived. Another interesting point about a possible use of the Value Map is that risks can be shown with their progression over time, representing the different states that risks can have as a result of external circumstances of mitigating activities and controls introduced to manage them.

2. Carlos J. Pampliega (@CJPampliega) for a link to an article titled “Exposing god-like advisers“.

The article, by Dan Rockwell, tackle the situation where advisers provide advice that would possibly work for them without taking the effort to tailor to their advice to their target audience, that is YOU.Dan distinguishes between two types of advisers; the arrogant ones and…yes you guessed correctly…the humble ones.Humble advisers, Dan suggests, help mold you into your best self, not their. He goes on to suggest 6 components of humble advice.

3. sandra biggerstaff (@sanloubig) for a link to a publication by the Canadian Institute of Chartered Accountants, titled “20 Questions Directors of Non-Profit Organizations should ask about Risk“.

The publication objective is “to help members of not-for-profit boards of directors understand their responsibility for the oversight of risk”. The document “assumes that members of not-for-profit boards may not be familiar with business practices and terminology and would appreciate explanations and examples that are more relevant to the not-for-profit sector“.

The document provides key questions board members need to inquire about, and splits them into three categories:

1. Risk Context and Policy – “describes how the board can prepare itself to oversee the management of risk, support a risk-aware culture, and establish risk-related policies.”
2. Managing Risk - ”describes what the board should expect to hear from staff about their techniques for identifying and assessing risks, and developing strategies and procedures for managing them.”
3. Monitoring and Learning – “discusses the information the board should expect to get from staff on the measurement of risk and performance, and their learning from crises and other experiences. The section also discusses how the board can evaluate its own effectiveness in overseeing risk management.”

 4. Jose Bermejo (@josberco) for a link to an article titled “Have you heard of Risk Breakdown Structure (RBS)?“.

The article provides a timely reminder of the importance and use of a Risk Breakdown Register.

5. Bob Hartman (@AgileForAll), retweeting @AgileRamblings, with a link to an article by Dave White titled “A Rant about Estimation – When Will We Stop Being Crazy“.

I found Dave’s article interesting even though I didn’t agree with his analysis or his conclusions. The article is a rolling rant about a commonly used process for establishing the estimated number of hours for an Epic. Dave challenges the logic behind some of the underlying assumptions behind this process and suggests it is not a valid way for estimating delivery timing.

Hope you enjoy these references.

Let’s face it, most blogs – including my very own – are repetitive, made up of remixed ideas and concepts.

This, in itself, is not really a problem. Ideas need to be repetitive, open for public debate and evaluation before they can be internalized. As different people get exposed to different ideas at different times it is necessary to bring these ideas up so readers would be able to be exposed to them and have the opportunity to evaluate their content and their validity.

The competitive nature of today’s blogosphere gave rise to social media experts and the proliferation of ‘how to’ guides for maximizing the number of clicks coming your blog’s way.

For instance, one of the ‘trick’s recommended by the experts is publishing posts with titles (and content) that conform with the following construct:

7 Must-Have Project Management Skills for IT Pros

or

11 Simple Concepts to Become a Better Leader

Got the idea? As Twitter mentality takes over the thinking world – making us all think in batches of 140 characters – ideas and concepts need to be simplified into pre-digested and well chewed up lists.

Another observation worth mentioning here is the proliferation of platitudes.

In the last 12 months we have seen an explosion of articles and opinion pieces dealing with the very important topics of leadership and innovation. While some of them are intellectually stimulating and thought-provoking; many are, well…just repetitive. It is as if the author felt compelled to write a piece containing this two words just to ensure his/her audience is aware of their interest in this topic.

In my research for writing up this post I have come across an interesting HBR post by Greg McKeown, titled “If I Read More Platitude Filled Mission Statement, I’ll Scream“. I am taking the liberty to adapt Greg’s recommendations and tailor them to my observations above.

If you intend to publish an article incorporating the concepts of Innovation or Leadership AND you want me to read and internalize your thoughts, please adhere to the following principles:

  1. Be specific, not generic – make sure your suggestions are practical and actionable
  2. Provide concrete ideas of how your suggestions could be measured
  3. Move from “pretty clear” to “really clear” – don’t use abstract language – be coherent and don’t fluff around.

Think about it!

Stuart Ritchie, the talented guy behind 1.00 FTE has this beautiful insight to share:

are-non-disclosure-agreements-a-retention-strategy

My immediate take from this was:

If you can’t articulate it, you can’t deliver it.

If you are planning to deliver a project output but you can’t say what it is, what it will look, feel and smell like when it is complete, you will not be able to successfully deliver it.

Think about it!

It’s 07:38. ​
 
I just stepped out of the train taking me to work when my phone rang. “Raj is looking for you”, told me Darren, my project administrator. “He asked me to urgently let you know that while his off-shore team is scheduled to commence integration testing later on today, over night security incidents in the city will prevent the majority of his team from getting to work. Given the internal political situation it is not clear when regular, normal, work will resume”. 
 
The preparation for the integration testing phase has taken a considerable amount of time and required the collaborative effort of quite a few resources, representing the core technologies and support teams involved in the new infrastructure deployment. While planning was carried out both on-site and off-shore, testing itself was planned to execute using a predominantly off-shore resource pool across a number of geographical locations, thus allowing for testing to proceed almost around the clock.
 
This is not the first time one of my infrastructure projects is impacted by off-shore events. Heavy rain and flooding in one of our regional data centres in South East Asia has caused me major headaches in the past. The transition to the new data centre has just taken place few months earlier and the risk realisation of weather impacts and how to prepare for them has not yet sunk in. This lack of proper risk identification has caused my project major delays and cost overruns as I have had to divert some of the project operations to a different site.
 
This time I was much better prepared. Though not specifically targeting security risks on my risks register I did investigate the possibility of delays due to regional issues like weather conditions, terror threats and alike. I have involved the company’s risk department in the project’s risk reviews and assessments and have prepared a mitigation strategy I could invoke should such circumstances arise.
 
The risk documented in my risk register was documented as follows:
 
Local circumstances (e.g. unusual weather conditions, political tension or terror activities) at offshore site1 could result in major delays to scheduled activities due to inability of local resources to reach the office and perform their allocated tasks“.
 
Offshore Site1 has not experienced devastating weather conditions since the one I mentioned above and having consulted weather forecasts indicated that the likelihood of such event re-occurring during the lifetime of my project was very low.
 
The political tension in the area however has been steadily rising over recent months and security experts consulted on this matter have estimated the likelihood of a disturbing incident taking place at being likely, or about 60%.
 
From a project perspective, the consequences of not being able to execute the testing on time was quite severe. The project outputs were directly contributing to a business outcome whose needs were based on strict regulatory requirements. Not meeting those requirements could result in harsh financial penalties and loss of public credibility.
 
It was clear from the outset that this risk cannot be accepted and that an operative mitigation strategy needs to be put in place in order to have it controlled.
 
The plan of attack for mitigating and addressing this risk was basically agreed as following:
  1. A second, alternative, team will be put on stand-by on-site to be able to pick up the testing should the off-shore team become unapproachable.
  2. The off-shore team will be provided with remote access capability (mobile phone and laptops) so they could execute their test scripts remotely if required and be able to communicate with the team as required.
  3. Operational instructions and guidelines were distributed and reviewed by all respective teams, on site and off-shore, so they are aware of the communication plan and execution plan associated with invoking the alternative mitigation plan.
“Thanks Darren”, I said, Please convene the project risk committee so we can discuss and obtain an approval to embark on plan B, and execute the communication plan associated with it”.
 
In a bizarre way, our previous failure to deal with a similar event in the past has made us aware of the scenario and allowed us to better prepare for the event we’re just facing now. Lesson learned well executed.
 
Think about it!
 
*Disclaimer: This is a fictional story and is meant for educational purposes only. Any resemblance to real persons, living or dead is purely coincidental.
 
P.S. After publishing this post I discovered that Chris O’Halloran published a post with a similar message (see HERE).

Different organisations have different project status reporting requirements. If you manage a project in an organisation that does not enforce strict reporting template, or lack such standards altogether, here’s one advice I have for you – make your report easy to understand by using the traffic light metaphor to highlight the status of various components of your project.

Status Report traffic lights

While the above is a proposed sample only it does contain the content I propose you use. It includes the current status and the previous status (i.e. the status as reported in the previous reporting period) and includes a high level summary explaining the nature and reasons for the current status and the reasons for changes (or lack of) in the status from the previous period.

Apart from being a useful communication tool, this representation will provide you, as a project manager, a good view of what your project looks like and where your pain points are.

Think about it!

%d bloggers like this: