I love it when my associate Sonia tells me in her direct, to-the-point way that she really doesn't like a course segment I put together. It's sometimes uncomfortable to hear, but I find criticism invaluable -- and worth acknowledging.

When I ask Sonia what she doesn't like about what I have put together for a program, for example, her reasons are solid, helpful and almost always merit making a change.

Who needs a "yes" person, when a person who tells you the truth, even if it is uncomfortable to hear, can really make a difference to the achieved results?

Ginger Levin, PhD, PMP, PgMP, drove this home in a note that she sent me a few weeks ago:
 
"Recently, I gave a program management boot camp. As it seems too often be the case, people in the class found some items that they felt needed change. I thought this was wonderful and I was so pleased that they had pointed them out to me. One person pointed out the majority of the changes, and I decided to send him a small present as a token of my appreciation. I also thanked each person who did so. One person in the class remarked that such thanks had not been given in previous courses she had attended. I welcomed the comments, as they can only help me improve next time."
 
Can you imagine being given a gift for the criticism you deliver to a colleague? I believe this is a rather rare response to such feedback -- too rare.

Wouldn't project excellence be much more commonplace and achievable if we all responded similarly? And it takes a master like Dr. Levin to truly value this kind of input to keep herself in a mode of continuous improvement.

So let's acknowledge those who tell us the truth -- and make us and what we do better! Their integrity, their commitment to excellence and their unwillingness to shortchange the end result by accepting the mediocre are their gifts to us! 

Trust is a fascinating element of business and relationships. Where trust exists, all that's needed to manage most work is a brief conversation to ensure understanding and a handshake -- real or virtual. It's lack of trust that leads to the constant measuring and checking of performance, writing complex and detailed contracts, and meeting with people.

Trust speeds everything up and lowers transaction costs. As the level of trust goes down, the speed of doing business goes down, costs go up and relationships and communications are largely ineffective to the point everything has to be proved or validated.

Interestingly, it would appear trust is not a fundamental element of a relationship. Relationships can work with remarkably low levels of trust, as long as both people have a common objective, and at the beginning of any new relationship there is little to base trust upon.

Within both personal and business relationships, trust tends to build as the overall relationship is established. It is built over time and is based on your observation of the other person's actions within the relationship. The effectiveness of the relationship progressively improving as trust between the two people builds.

According to Stephen Covey, PhD, author of The Seven Habits of Highly Effective People, trust is built on three behaviours:

- Transparency: Tell the truth in ways people can verify and validate for themselves.
- Keeping commitments: Do what you say you will do.
- Trusting others: Extend trust to your team and they will trust you in return.

Trust that has taken years to build can be destroyed in minutes and rebuilding trust is far harder once it has been lost.

The first challenge facing project teams and their stakeholders is to identify a pragmatic level of trust that will allow the work of the project to proceed effectively but to also have sufficient checks and balances in place to insure against untrustworthy behaviours.

The second challenge is to create trust quickly enough to allow the teams to function in the early stages of a project. This is particularly true for virtual teams.

How do you manage trust with a new team of people you don't know well and may never meet? Post your advice and I will combine them with a few of my suggestions in my next post.

If PMI ever invites me to rewrite the risk section of A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) I think there are two things I would change.
 
The first deals with the inclusion of "upside risk," or opportunity, as part and parcel of risk management. I don't think it belongs. As my exhibit A, I cite the Oxford English Dictionary definition of risk: 1 a situation involving exposure to danger. 2 the possibility that something unpleasant will happen. 3 a person or thing causing a risk or regarded in relation to risk: a fire risk.

As author Mark Twain said, "Beware the man who would win an argument at the expense of language." Beyond the semantics, though, let's consider the three most prevalent ways of analyzing risk and see if they apply in managing a proposal backlog (a listing of an organization's outstanding and upcoming job bids -- or opportunities).

The simplest (and crudest) risk analysis technique is classification, in which you basically go through your work breakdown structure at whatever level and assign high-, medium- and low-risk classifications to the tasks. Associate each classification with a percent, e.g. high may mean 50 percent, medium 25 percent and low 5 percent.

Multiply the percentages by the original budget/time estimate, and you've done a risk analysis (of sorts). Try this with the proposal backlog, and you'll inevitably look astonishingly inept.
Then there's decision tree analysis. For each activity, assign alternative endings, with their impacts and odds of occurrence. Unfortunately for "opportunity" management, the only two possible outcomes of a submitted proposal are that you either win the work or you don't. Data on the gray middle is pretty useless when there's no gray middle.

Finally, Monte Carlo analysis is essentially a decision tree on steroids, with lots of statistical chicanery thrown in.

My second objection has to do with the use of risk management after the cost and schedule baselines have been set. I agree that prior to the finalization of the baselines, risk analysis is crucial to identifying and quantifying cost and schedule contingency amounts. The risk analysis can lead to informed decisions on how much and what type of insurance to buy, and what sort of alternative plans should be in place if a contingency event occurs.

But once the baselines are final, persisting in risk management strikes me as institutional worrying expressed in mind-numbing statistical jargon. To what end? Unless the response to a contingency event (in-scope, uncosted) was to significantly change from how the project team would have reacted normally, what difference does it make if it was anticipated?

I'm looking forward to the responses to this, and not necessarily from just the risk management aficionados.

Update: Risk management experts and enthusiasts are encouraged to join PMI's new Project Risk Management Community of Practice. 

Generally, an IT project schedule is divided into three phases: 30 percent requirements, 40 percent coding and 30 percent testing. But have you ever noticed that in the coding phase, 60 percent of the effort goes into unplanned bug fixing?

I read somewhere that in the software industry, 90 percent of the tasks take 10 percent of the time, while the other 10 percent take 90 percent of the time due to rework. If as a project manager you can control this rework effort, I am sure that your project will be successful in terms of profit value, customer satisfaction and team motivation.

The project I am currently working on is no different. We had the same rework problem. So based upon data analysis from the last 4 to 5 months, the team came up with a list of preventive actions that will help us in reducing rework.

But I was still looking for something to keep them motivated to avoid rework. I prepared a logo and it was pasted on all desks.

 

What do you say, is it going to help us?

The more than 40 comments on my last post Hey Boss, What About Work-Life Balance? provide an interesting mix of views. Here are my thoughts on how to work effectively and build a relationship with someone like "Sebastian." This input comes from a position of advantage since I knew the real person.

The first key to building any effective relationship is to avoid stereotyping. Sebastian was a very effective, upwardly mobile manager with a focus on being promoted to the main board. Interestingly, most people liked him as well as respected him. It's just that he had a different life focus, which is not uncommon in successful senior executives.

The second key is to recognize that in every relationship there is a power dimension. How a manager like Sebastian would use his power is to an extent a generational issue. Many younger managers would see nothing wrong in you setting reasonable boundaries and procedures, as long as they understand their purpose. Managers with more experience are used to operating in a command and control environment are likely to react negatively to a "junior" pushing rules upwards.

The third key is mutuality. Team members need to understand what he or she needs from the relationship (support, resources, backing) but also what Sebastian needs from the relationship. Then, work to negotiate mutually beneficial outcomes that meet both sets of requirements.

For the team member discussed in the post, the requirement was time-related; Sebastian's requirements were not defined in the original post. However, by defining what's important to Sebastian, then linking your requirements to the achievement of his requirements, you can start to achieve real communication inside an effective relationship.

Finally if you wish to be taken seriously, you need to develop a reputation for credibility. Senior management needs to recognize that if you say something, it is backed up by facts, and if you commit to something, it is delivered. Credibility is earned by performance, but there is no harm in quietly making sure your performance is noticed in the right places.

In the end, relationships all depend on the situation. But mutuality and credibility are the two keys to advising upwards. If you are seen as a serious contributor to the organization's success and can link your needs to the needs of senior management, there's a high probability of achieving your desired outcome and benefiting the organization at the same time.

Getting team members committed to the project scope, budget and schedule is a matter of removing any roadblocks and helping resolve any conflicts.
 
Sounds simple enough. It's what project managers were trained to do, more or less.
 
But while the project manager has a lot to do with getting everyone aligned on the right approach, how team members manage themselves impacts the project outcome just as much.
 
Here are some things project managers and team members should keep in mind to make sure the outcome is what everyone has planned:
 
--Think twice before engaging extra team members. Be ready with a plan of what you need from the resources and whether they're in a position to provide it.

--Treat external staff members that help out with the project as if you had to pay for every minute of their engagement from a mini budget that you will be held accountable for.

--Make sure you're aware of how your role and your deliverable contribute to the final project result. And validate that role and deliverable with the rest of your project team to ensure you're only working on what's going to add the most value to what is required.

--Be able to account for the work you've done and prove that it directly related to the scope and activities assigned to you. Be completely responsible for everything you commit to along the way -- as if you might be audited.

--Create your own measure of success and communicate it to the team. Be ready to show the results of your work, whether you're asked for it or not.

--Be aware of time wasters -- they eat away from the time you have available to deliver your assigned tasks. Make your own efficiency one of your accountabilities.
 
When each individual manages his or her time and tasks with these basic rules, the entire team is better positioned to deliver on time, on budget and within scope.