This page is devoted to news, tips, and any other information the Project Management community may find useful or interesting.
An article in the December issue of PM Network by Sarah Fister Gale deals with the public relations issues that companies engaged in the extraction of oil and natural gas reserves by the process of fracturing, or "fracking” as it’s called by the industry. The issue is basically one of distrust: people concerned about the affect of toxic chemicals on their drinking water distrust the extraction companies. They suspect that the chemicals they use are poisoning their water. In some cases they may be right but in the majority of cases, their suspicions are unfounded. Unfounded or not, these suspicions have a negative impact on the drilling projects. The same suspicions caused by a lack of facts can impact on IT projects, especially those introducing a new process or replacing existing systems. Before I examine the affects of communication on those projects, let me bring you up to speed on the issue Sarah Fister Gale wrote about.
Fracking requires the extraction company to dig a deep well through intervening layers of shale or other hard deposits and flush the gas or oil to the surface by pumping pressurized water, sand, and chemicals into the well. The pressure created opens up fissures and flushes the gas or oil to the surface. If fracking only relied on water and sand to achieve results, there would be no issue; it is the toxins that are sometimes used in conjunction with these natural agents that are the issue. Because the process requires the flushing action to be carried out at a level that is usually lower than the water table there is a risk that any toxic chemicals used could contaminate the drinking water. This fear is compounded by the exemption that American companies enjoy from the Safe Drinking Water Act. The amount of public resistance to fracking projects has led to the postponement or cancellation of some projects as politically savvy environmental protection groups exert pressure on politicians to intercede.
Companies who have enjoyed some success in countering these campaigns have done so by treating the communities whose water the project could affect as stakeholders and treating communications with the communities as a project deliverable. An example of one such communications campaign involved newspaper ads which included photos and descriptions of all the equipment and materials used in the project. This approach presupposes that the materials and equipment in use does not introduce harmful chemicals to the drinking water. Communication with these stakeholders from the initiation phase of the project is another key to success. pmp certification
Fracking projects are not the only ones that can fall prey to the fear of the unknown. Many IT projects run the risk of meeting user resistance because the effect of a new system on their jobs is an "unknown”. Users fear that their jobs are going to be made more demanding or that they will lose functionality with the new system. They may also fear losing their jobs as a result of a new software system making their jobs obsolete. Project managers responsible for projects which implement new software systems should take a page from the fracking industry’s book. The tools used to communicate may differ but the same principals that make the fracking communication effective can make communications for the IT project effective.
The first rule of effective communications is to treat the user community as a project stakeholder that must be communicated with. The primary user community will be immediately obvious, these are the folks the system must be rolled out to and who must be trained in its use, but look beyond that initial community. Are there any folks downstream or upstream of this primary group whose work could be impacted by the new system. Even if the work products are substantially the same, could slight differences affect their work? Could differing delivery schedules affect them? The use of process flow charts can help you identify hidden stakeholders. Don’t stop at the edge of the chart; check out the groups at the other end of those "off the page” markers.
Make communications with these stakeholders a project deliverable. Large extraction companies frequently employ whole groups of people whose only job is communications. They are seasoned veterans of project communications and can manage all aspects of this work from identifying stakeholders, to defining the best strategies, to composing the right communications. Smaller, less sophisticated, IT projects must manage this activity on their own. Make sure your project has a communications management plan, identify all the stakeholders and then find out what information each stakeholder group would be best served by. Another trick we can learn from the extraction sector is to engage these folks as early as possible, don’t wait until the week before implementation.
The stakeholders you must communicate with may include workers whose jobs will be eliminated when you deliver your new system. You may be tempted to discount these people – after all, they won’t be around to trouble you after your new system is implemented. Often the best and brightest of these folks get re-assigned to other jobs that you may come in contact with so treating them with respect is in your best interests. Even those who will leave the company will have an impact on those left behind. If the perception is that these people are treated fairly, included being kept informed, the effect will be positive. If the perception is that they are deliberately being deprived of information, the effect will be negative.
Now for the $64,000 question: exactly what do I say to people whose jobs will disappear when the new system is introduced? Firstly, don’t try to hide or cover up the fact that jobs will be eliminated; your dishonesty will be discovered and from that point forward you will have lost everyone’s trust. Work with your HR organization to develop information to be communicated. These are the people who understand which policies affect that type of communication. They should also be experienced with putting these types of communications packages together. Secondly, get all the facts around job eliminations. Which jobs will be eliminated? Which jobs will be opening up because of the change? How do workers go about applying for other positions in the company? Your HR organization should be able to help with all these questions. Include what you know about the project. What were the reasons behind building the new system? How will the new system benefit its users? How will it benefit the company? There may be information that is sensitive and can’t be communicated until the public has been informed. This information is usually of the type that would tend to influence stock prices. When you are unable to share this information, inform your stakeholders of the reason you can’t share it with them. It is very likely that communications for a new system that is part of a major change in business will be managed at the corporate level. Your communications should form a part of that larger plan.
Be honest in your communications. Give people the facts they are interested in or that they need. We are often tempted to gloss over any negative impacts the new system may have on the user community. We don’t deliberately mislead people but we tell people things we think they want to hear. Don’t be afraid to mix the good news with the bad. Frequently new systems require users to endure short term pain to enjoy long term gain. Don’t shy away from communicating information about the short term pain. Your user community is smart enough to figure out the value proposition. Just remember that once the cat is out of the bag it is very hard to put it back in. Know who has overall responsibility for communication in your company and always seek for their blessing of the information you want to communicate and the timing of that communication.
Timing is everything with communication. Being communicative with your stakeholders at a time when they aren’t particularly concerned with your project is wasteful of your project’s communication resources. Communicating a welter of technical details about the new system a year before implementation won’t be seen as honesty, it will be seen as noise and ignored. Good communications should give your stakeholders the information they want when they want it. This criterion must be balanced with the information available and when it becomes available. Communicate a description of the new system in a few sentences, along with the business reasons for choosing it in your first communications. You can also communicate changes to existing processes and procedures in very broad terms. This information should answer the question: how will the new system affect my work, but only at a very high level. Communicate project progress and any "wins” the project experiences during your build phase. Communicate the specifics of how the new system will impact work to specific groups of workers as the project gets closer to delivering.
Training on new systems is critical to their delivery of the value envisioned in the business case. Training sessions can also present you with opportunities to communicate to the trainees. Include the reasons the new system is being introduced with training in how to use it. Use the information you have available to support your communication and start out as you mean to go on. Let the stakeholders know when you will be communicating with them and if possible what you’ll be communicating (your communication management plan). During the initiation phase of your project you’ll have very little information available, but you will have the Business Case and Project Charter to use. The benefits, both tangible and intangible, the new system will bring to the organization is a good start and you should have that information to hand. You may want to tailor that information to suit your audience. Filter the benefits to make them specific to the group of stakeholders you are communicating with.
Slipping delivery dates for the introduction of a new system that will cause stakeholders some discomfort can leave these people feeling like they are being drawn through a knothole backwards. Realize that there are many different reasons that a final delivery date could change that have nothing whatever to do with the project or your management of it. The people who are paying for your project have every right to change the final delivery date when they have good business reasons for doing so. I wonder how many dates were changed as a result of the fallout from 9/11. Don’t paint yourself into a corner with your communications. Let stakeholders know that the delivery date chosen for the project could change down the road if business needs dictate. If you have to communicate a change in date, be sure to communicate the reasons for the change. Don’t just say the new Acme time tracking system will not be delivered on April 1st as originally planned, but on July 1st, tell the stakeholders that priorities have shifted to take advantage of a business opportunity that will increase revenue by 15%. This shift means that project work is being delayed and this will move final delivery to July 1st.
Treating project communications as a key project deliverable probably won’t eliminate all the fear and loathing of the new system you are building, but it should succeed in eliminating it for those stakeholders capable of viewing the project objectively. At the very least it will trigger questions that will provide you with an opportunity to refine the information you give your stakeholders.
The terms used to describe the various aspects of risk
management are bewildering, even to an experienced project manager. At least I
find them bewildering. I'm going to examine some of the terms used to describe
risks and the way they are managed and hopefully shed some light on what they
refer to and what they mean. I hope to clear some common misconceptions up at
the same time.
The first misconception I'd like to address is the meaning
of the word "risk". We tend to view that word, especially in the project
world, as having a negative connotation. Frequently it does imply a negative
consequence, but not always. Actually a risk can have a positive outcome such
as when we risk money on a lottery ticket and our ticket wins. Risks that have
a positive outcome are called opportunities and risks that have a negative
outcome, such as when we refer to the risk of a car accident, are called
threats. We take action to encourage our opportunities, such as buying lots of
lottery tickets, and we discourage our threats, such as when we get inoculated
against the threat of a flu virus. Both opportunities and threats are forms of
risk, the key difference is our approach to managing them.
There is a great deal of confusion around the terms used for
our difference approaches to managing risks. We commonly refer to our
management of risk as "mitigation". The dictionary definition of this
verb is "to make less severe: to mitigate a punishment",
or "to lessen in force or intensity, as wrath, grief, harshness, or pain; moderate". While it is true that we mitigate
some of the risks to our projects, mitigation is just one strategy used to
address potential risk. Sometimes we choose to avoid a risk altogether, such as
when we respond to the risk of encountering a traffic jam on an expressway by
choosing an alternate route (we may still risk encountering a traffic jam, just
not the traffic jam on that
Transference is another term used to describe our response
to risk. The classic example is when we buy insurance on our car to deal with
the risk of an accident. We aren't necessarily reducing the chance of an
accident, or even reducing the impact of the accident, we are simply reducing
the impact on us should the risk event (the accident) happen by sharing the
financial burden with the insurance company. There are other types of
transference. Outsourcing work to an organization with more skill and
experience in performing the work than we have is another example. In that
case, our intent is to reduce the likelihood of the event happening by having
someone more skilled and experienced do the work. We may also be reducing the
impact on ourselves, depending on the type of contract we choose.
Mitigation is the strategy we use when we can't avoid the
risk altogether and we can't transfer the risk, or don't want to. Mitigating
the risk requires us to take some action that will reduce the severity of the
impact of the risk event if it should happen. Another way of looking at our
traffic jam scenario is the relative likelihood of a traffic jam occurring on
the expressway as opposed to the alternate route. If the alternate route has
never experienced a traffic jam we could view that response as avoidance. If
traffic jams happen on the alternate route less frequently, we've simply
reduced the likelihood of being caught in one, or we've mitigated our risk. This
is where common usage departs from the dictionary. We commonly refer to any
strategy that either reduces the impact of the risk event, or the likelihood of it happening.
Contingency plans are a specific type of mitigation. The
contingency plan differs from a other mitigation strategies in that no action
is taken until the risk event happens, unlike other strategies that require the
action to be taken before the risk event can happen. Taking the alternate route
is only effective if we plan our trip that way. It isn't much use when we find
ourselves in a traffic jam on the expressway. A contingency plan to deal with
our expressway traffic jam might be bring along a flask of hot coffee or cold
drinks to refresh ourselves while we wait for the traffic jam to clear. A term
that should always be associated with a contingency is trigger. Trigger refers
to the circumstances, or set of circumstances that will cause us to deploy our
contingency plan. Pouring ourselves a cup of hot coffee from our flask while
we're cruising down the expressway at 60 mph is not a good idea, it is likely
to cause a crash and involve us in a traffic jam, the very event we seek to
avoid! We shouldn't indulge in the hot coffee until our car is stopped and we
can see from the traffic ahead that it isn't likely to start moving again
anytime soon. This set of circumstances is referred to as the trigger.
Another common response to a risk is to simply accept it. We
usually do this when the probability of a threat happening or its impact if it
does happen make it impractical to spend any money or effort on a response.
I've planned to walk to the bus stop to catch a bus and the weather forecast
calls for a 50% chance of showers. It's summer, I'm wearing jeans and a tee
shirt - do I want to buy an umbrella to avoid getting a wetting? Probably not,
I'll probably be hot by the time I get to the bus stop and a rain shower may be
refreshing! In this case I'm simply accepting the risk. Another term sometimes
used to describe this response is "assume", as in I assume the risk.
Assume means to take on or to appropriate. I'm doing neither when I walk to the
bus stop without the umbrella. The risk is already there, I don't have to
appropriate it. When I hire an insurance company to protect me against a
collision, they assume the risk, or at least the financial impact of the risk.
When I choose not to respond to a risk, I'm accepting it.
"For every action there is an equal and opposite
reaction". The actions we use to respond to opportunities are just about
the direct opposite of those used to respond to threats. Instead of avoiding
the opportunity, we exploit it. Exploit is not the grammatical opposite of
avoid, strictly speaking. Seek or confront are probably closer to opposite.
Exploit is used in reference to risk management because it more accurately describes
the action we take. Whenever a poker player sits down to play the game for
money there is an opportunity to make money. A cheat, or card
"mechanic" will exploit this opportunity by fixing the cards so they
can't lose. Potential victims of the cheat can avoid falling prey to their
exploitation by avoiding playing in a game with the cheat. If there is a chance
that a telecommunications company can capture a large market share by being the
first to market with some new technology, they will exploit that opportunity by
shortening the time to market.
Rather than transfer a risk to someone else, we share an
opportunity. Usually we share the opportunity with someone, or some
organization, whose strengths are uniquely compatible with our own and our
partnership will improve the chances of realizing the opportunity. This is
corporations enter into joint ventures. Each corporation can contribute
something to the venture that their partner cannot. Singly they cannot deliver
what the project calls for but collectively they can. The opportunity in this
case is may be a contract they bid on together, or the capture of a market share
for a product they jointly produce.
Instead of mitigating a threat we enhance an opportunity.
Enhancement takes a very similar approach to mitigation. We may do something
that will increase the impact of the opportunity if it occurs. For example, we
will prepare an ad campaign that boasts of our being first to market with our
new technology. This does nothing to improve our chances of getting to market
first, but will increase our market share even more if we do get there first. Alternatively,
we may choose to improve our chances of getting to market first by shortening
our development time, or we may do both.
The term accept has the same meaning for both threats and
opportunities. In both cases acceptance of the risk means that we do nothing to
avoid it, exploit it, transfer it, share it, mitigate it, or enhance it. If it
happens, great, if it doesn't, that's OK too. We may be able to enhance our
chances of winning the lottery by buying many tickets (although not much), but
most of us are willing to accept the opportunity presented with a single
I hope this clears up any misconceptions you held about
risks, threats, and opportunities. Just remember two things: risks include both
opportunities and threats, and mitigation is only one response to dealing with
The Toronto Star reported today (Dec. 10/2010) that
Integrity Commissioner Christiane Quimet has resigned her role with 4 years
left on her term. Ouimet was nominated for the job by Prime Minister Steven
Harper. Her job was to protect people reporting on misconduct in the federal
government ("whistleblowers") from reprisals. Ouimet actually
resigned in October but the reasons for the resignation were revealed yesterday
by the Auditor General, Sheila Fraser. Fraser performed an evaluation on Ouimet
and concluded that she failed to do her job (protecting public servants from
reprisals) and that she was abusive to her staff.
Ouimet left in the midst of Fraser's investigation; Fraser
was responding to 3 complaints about Ouimet's conduct. Fraser's investigation
continued despite Ouimet's absence and she reported on her findings yesterday.
Among the transgressions Fraser reported:
- 170 complaints from potential whistleblowers
without a single complaint being followed up before closing the file.
- files on the 170 complaints were closed without
any review or serious inquiry.
- a staff turnover rate of over 50% during her 3
years on the job.
- complaints that Ouimet "yelled, swore and
also berated, marginalized and intimidated certain ...employees, and that she
engaged in reprisal actions."
- carrying on a vendetta against employees who
left the commission.
- disclosing personal information about an
employee to a previous employer, senior government officials and a private
sector security consultant. The employee had left the commission 6 months
previous to this and Ouimet believed he had filed a complaint about her.
- preparing and circulating information about the
same employee within the commission. Information included 4 binders comprising
96 documents and more than 375 pages.
- circulating 50 e-mails with information about
the same employee.
- a turnover rate of 41% (18 employees) during one
12 month period.
Ouimet defended her actions to investigators working for
Fraser by characterizing the employees who complained about her as incompetent
or ineffective, but could not be contacted for comment by the Toronto Star
reporter. The results speak for themselves. Unless Ouimet was acting on a
secret mandate to get rid of the commission, her record of staff turnover would
indicate that her leadership skills need improvement. I won't pass comment on
her effectiveness because I don't know if there was pressure exerted on her to
bury complaints from whistleblowers.
Christiane's may be an extreme case but it should serve as
an object lesson to the rest of us of what can go wrong when we give free reign
to our emotions when dealing with our employees. Let's look at her dealings
with her employees, while they were still her employees, first. Yelling,
swearing, berating, marginalizing, and intimidating employees are all behaviours
that are guaranteed to result in increased staff turnover. A certain amount of
staff turnover is to be expected. In some circumstances you may even want to
encourage it. Let's take, for example the employee who through hard work on the
job and increasing his or her skill set becomes attractive to other employers.
You don't have the opportunity to place this employee in the position they have
prepared themselves for so losing them to another employee who can offer what
you can't is inevitable. Your only option is to make certain that employee
feels appreciated by you and your organization and would return given the right
opportunity. Coaches of minor professional sports teams do this all the time,
in fact they take pride in having one of their players promoted to the
"show". There are other circumstances when employees should leave:
retirement, downsizing, etc. You may also want to replace the employee in which
case having them leave will simplify your job.
Managers should seek to retain employees in all other
circumstances. The reason is simple: your organization invested money in the
employees entrusted to your care. Someone (possibly yourself) invested time and
effort to ensure the right person was hired for the job. Money was spent in
training, coaching, and mentoring the employee. Your organization doesn't want
to see this investment squandered by having these valuable assets walk out the
door. This is especially so in organizations who have invested money in
employee retention programs.
Remember that you are dealing with employees, not machines,
computers, or friends. They have a job to do and your job is to make certain
that they are as effective at that job as it is possible to make them. Your
behaviour should mirror this. Remember also that what you perceive as
constructive criticism may be perceived as berating, or even intimidation by
your employee. If your employee complains to you to you, or someone else, that
they feel berated or intimidated, correct that feeling. Once you get past their
feelings you can begin communicating with them about how to improve their
performance. You won't achieve any performance improvements until they are past
those feelings. This is not to say that poor performance or bad behaviour must
be tolerated. It is not to say that a certain amount of intimidation is not
appropriate in some cases. For example, when you have caught the employee
intimidating another employee it is appropriate to describe the negative
consequences of continuing the behaviour and the description might well leave
that person feeling intimidated. Where intimidation is inappropriate is where
you are trying to get the person to perform a task differently, or prioritize
their work differently, or achieve some other form of improvement.
Managers are only human and we can feel frustrated at times.
Nothing can be more frustrating than being disappointed by an employee's performance
or behaviour. The trick is to not let that frustration stand in the way of
improving the performance or behaviour. There is an old trick to use when
dealing with frustration: "count to 10 then....." Even better, don't
deal with the employee until your frustration has abated, then think about what
it is you need to say to them. Envision the result. Your approach should focus
on the goals and objectives you want the employee to achieve, taking for
granted that the employee is desirous of improving their effectiveness. Speak
in a normal tone of voice and choose language that you would feel comfortable
with if the shoe were on the other foot. Check for understanding when you have
finished communicating. Don't say "Do you understand?" or "Do
you hear me?", try "Let's talk a little more about the
actions/remedies/solutions I've just mentioned, how would you implement
them?" instead. Your purpose here is to ensure understanding.
Your Human Resources department may already have implemented
360 performance reviews in which case your employees will have a chance to
evaluate your performance. Your HR group may also provide you with guidance on
how to use this input to improve your own performance. If not, or if there is
no 360 performance review in place, implement your own version. The key to this
process is to make the reviews anonymous so as to get the most objective
feedback possible. Allow anyone who wishes to, to identify themselves. This
will help you come to grips with the specifics of any complaints or suggestions
for improvement. You may want to review the results of the feedback in
aggregate with your team to ensure that any actions you define as a result will
be effective in improving your performance. There are concerns about 360
performance reviews, one of the foremost being that the review comes at the end
of a cycle rather than during it. To rectify this shortcoming, encourage
feedback at all times. Establish a culture that encourages honesty and openness
so that you will be the first to know if there are any problems that you can
correct. Foster this culture by responding to any criticism in a thoughtful
manner. This doesn't mean you must act on every criticism, but provide your
reasons when action would be inappropriate. You should also inform your team
when a criticism or suggestion results in a change.
It is very likely that you will be aware of problems on your
team long before those problems result in a high staff turnover rate. In case
you aren't and you are alerted to an unacceptably high rate by your HR
organization or your boss, here are some tips on reducing turnover:
- Realize that your influence over pay is limited.
Fortunately, so is the positive effect of a pay increase. Employees need
opportunities to grow in order to remain happy. Each member of your team should
have a career path established which encourages growth in the direction they
- Define each employee's path specifically. This
means identifying their next job and a reasonable schedule for
promotion/change. Also define the milestones and objectives that will see them
to that next job.
- Make certain that each of your employees feels
that they are a valued member of the team.
- Provide training opportunities for your
employees. You may not always be able to approve the expense of an external
course (see item 1), but there are other ways of providing the training such as
coaching and mentoring. You may even be able to provide some coaching.
Receiving training will increase the employee's feeling of security which will
improve their morale.
employees of a company are some of its most valuable assets. Treat them
accordingly or you may find yourself keeping company with Christiane.
The U.S. Supreme Court ruled on Monday, November 29th 2010,
that Microsoft would be allowed to appeal a District Court ruling that awarded a small
Toronto, Canada, based company $290M for patent infringement. The appeal will
be heard by the Supreme Court; no date was announced for that hearing. The
small Canadian company doing the suing is i4i headquartered at 116 Spadina
Avenue in Toronto. The company is small, having a workforce of just 30
employees. The concept that it could be owed $290M for any kind of business
losses the patent infringement could have caused seems a bit extreme.
The i4i patent in question covers technology created by i4i (x4w)
that allows a user to separate the XML mark-up language embedded in Word
documents from the document which makes editing the document easier. Documents
are marked up with XML for the purposes of making documents "machine"
readable which makes them exchangeable over the internet. x4w allows a user to
strip the XML language from a document, edit it without interference, and then
re-introduce the XML. Microsoft developed a similar tool and packaged it with
MS Word 2003 and 2007. The District Court ordered Microsoft to strip the
feature from their Word products and gave them 90 days to remove any versions
containing the feature from store shelves. This was in addition to the monetary
Microsoft is seeking to have the judgment overturned based
on their claim that they had a patent on the same functionality as i4i and that
the Patent Office made a mistake in granting i4i the patent. Although I fail to
see how a court can be expected to pass judgment on something as technical as a
patent, Microsoft will be asking the Supreme Court to consider that as a factor
when deciding their appeal.
I'm not certain how litigious i4i is. I don't believe they
are involved in any other law suits of any description at this time. Microsoft,
on the other hand, is on more familiar ground. They have been very active in
the area of law suits over patent infringements, both as plaintiffs and
defendants. Among others they are involved with, or have been involved with,
are: Salesforce.com, VirnetX, Apple (through their partner, HTC), TomTom (the
automotive GPS maker), Linux (through TomTom), Belkin, and Primax. This
certainly doesn't make them particularly litigious when you compare them with
the likes of Apple, but certainly does keep an army of patent lawyers busy.
We can blame the legal system for this situation, or we can
blame the Patent Office, but how about the major players in the high tech
sector taking a little responsibility? I'm not suggesting that no-one should
avail themselves of legal help if they suffer business losses from patent
infringement, but surely there is a simpler, less expensive way to resolve the
situation. i4i initiated the law suit but I don't know what preceded that
action. Reaching out to Microsoft to give them the opportunity to propose a
resolution would be one step. I would think that an opportunity to partner with
Microsoft in some way could be advantageous to i4i. From Microsoft's point of
view, I'm sure they would not want to feel that they were being blackmailed
into offering i4i a huge cash settlement but could they have made i4i an offer
that would have made both companies happy and provided Microsoft with access to
technology that could increase sales? For a company that prides itself on
innovation, I would think that crafting a solution shouldn't be beyond their
Much has been made of using law suits as a warning to other
companies, sending the message: "back off or we'll use the courts to crush
you with huge settlements". Corporations who are tempted to go that route
should pause to look at the long term consequences. The advent of the
"patent troll" is one consequence. Patent trolls buy patents from
small companies, or bankrupt companies not with the intent of manufacturing
them but of using them to launch law suits. A classic example of this was the
settlement of $612.5M paid by RIM to patent troll NTP. The success of law suits
to gain awards for patent infringement has spawned an industry whose sole
purpose is to launch patent law suits.
Courts have a role to play here as well. The possibility
that i4i actually suffered $290M in damages as a result of Microsoft infringing
on their patent is extremely remote. Even worse was the judgement of $612.5 paid
by RIM to NTP. While this was not a court awarded settlement, it was
precipitated when a judge ruled that it would not wait for a Patent Office
investigation before it ruled on a settlement. The judge denied all of RIM's
requests and what was at stake was RIM's primary product, the Blackberry. RIM
felt that settling for $612.5M was a safer course of action than to chance a
court decision that would have taken the Blackberry off the market. Courts in
the U.S. have recently taken the actual damages suffered by a plaintiff into
consideration, with the result that patent trolls have seen their awards
reduced. The courts can take this a step further by letting the Patent Office
settle these disputes when the plaintiff is not actually generating revenue
with its invention.
The legal system has generated an atmosphere in which
litigants who are willing to gamble a relatively tiny amount on legal fees and
court costs can win huge settlements if a jury likes their case. That doesn't
mean that corporations must contribute to the feeding frenzy. It's time for
corporations who feel that they own a patent that has been violated to let
their R&D and marketing organizations work out a solution with their
opponent. It's time for corporations who are informed of a possible
infringement of a competitor's patent to make an honest effort to resolve the
issue with the competitor before calling in the lawyers. Mediation is used to
resolve many other disputes. Why not try it here? There is a sound business
case to be made for this approach. Corporations who are on the winning side of
a huge settlement today may find themselves on the losing side tomorrow, take
Microsoft as a case in point.
It's up to the courts and Patent Office to resolve the
problem of the patent trolls. One way to stop these people dead in their tracks
is to have the Patent Office review and approve, or disapprove, the transfer of
a patent much the same way that car registrations are transferred. The
difference being that the Patent Office could deny the transfer of a patent
unless the new owner could prove the ability to manufacture the invention.
Another solution would be to grant a patent holder a period of time to develop
the invention. If they have not developed it within that window, the patent
would be denied. The Patent Office can also help the courts here by expediting
reviews of patents that are the base for infringement law suits. One of the
reasons that the courts denied RIM's request to wait for such a review was the
Patent Office's estimate that it would take 10 years to complete! The
similarity between 2 patents is what is at stake in most of these cases.
Whether the similarity constitutes an infringement should be decided by the
patent experts. The courts can also help by limiting the amounts awarded to
successful patent trolls. $612.5M for a company that produces absolutely no
product, other than patents? You're smoking your socks!
I wrote an article in this web site's blog on Remembrance
Day encouraging organizations to consider hiring our returning veterans because
of the unique skills they have to offer. At the time of that writing I was not
aware that the federal government had a hiring policy in place to give
preference to injured or wounded veterans when hiring a resource to fill a
government post. This policy has been in existence since 2005 and I was made
aware of it by a news story appearing in the Toronto Star newspaper reporting
on the potential impact of government spending and hiring cutbacks on the
The government policy is only applicable to veterans
released from the military due to medical reasons and it appears to be driven
by the government's sense of responsibility for supporting these folks when
they can no longer serve in the military. Although I stand by my original
article's premise that all veterans who have served in a combat zone have
acquired a unique set of skills and abilities that make them attractive to an
employer, I certainly would not argue with the government's approach. MPs and
Senators who feel that our country owes these veterans employment opportunities
should be supported in that view. The policy should be implemented by the civil
service and I would hope that every veteran who has left the military for
health reasons will be given an employment opportunity that is attractive to
them. I also hope that those veterans are not asked to carry the burden of
Let's talk a little about the policy as I understand it. The policy
requires a hiring (federal civil service) manager to give consideration to the
veteran when the veteran satisfies all other hiring criteria. The policy would
give preference to the veteran over a civilian applying for the same job,
provided the veteran met all the hiring criteria. That's good as far as it
goes, but as a veteran pointed out on another blog, asking that the wounded
veteran have a University degree will pretty well eliminate any non-officer
ranks from applying. I would say that the policy could be improved by stating
that unless the criteria is directly applicable to the job (e.g. an accounting
certification when the job calls for financial audits), it should not trump the
veteran's priority. Of course this stuff should be common sense for any hiring
manager. The objective is to hire the candidate that will give the employer the
best result; the criteria should be intelligently set to achieve that goal.
The policy, as I understand it, only deals with veterans
released from the military for medical reasons. Since I'm sure that most of the
work government employees do does not require manual labour, these vets would
be eligible for most government jobs, providing they meet other reasonable
criteria. I would like to see the policy extended to include veterans who
manage to complete their service without being physically or mentally harmed. I
certainly feel an obligation to veterans who have risked their lives serving
their country, as I'm sure most Canadians do. I'm also sure that veterans are
not looking for a hand-out or charity, nor should they be made to feel they are
receiving any. The policy should be viewed as the repayment of a debt.
People who are motivated to hire a veteran out of a sense of
duty, or debt, to veterans should be supported in that view. I would add that
hiring that vet will yield the employer additional benefits. The combat veteran
will bring an ability to deal with stress and risk that no civilian would be
able offer. As I point out in the earlier article, the stress they face when
under fire would make them ideal candidates for facing any stress a civilian
job might throw at them. I am also certain that the ability to work together as
part of a team is well developed in the military and that ability is also a
desirable quality in candidates for many jobs. I think that the policy could
benefit from the realization that combat veterans are able to offer some skills
and abilities that are uniquely theirs due to their roles in combat. The government
may be paying off a debt to these veterans, but we are getting something of
value in return so veterans should feel that they are being selected because of
their abilities, not their disabilities.
So an "attaboy" to the government for implementing
the "hire a vet" policy. Keep up the good work and don't let the
austerity programme negatively impact it. Why not look at expanding it to
include combat veterans who have left the military after completing their
service without physical or mental damage? Our debt is not just to those
veterans who have sacrificed their health, but also to those who have taken a
tremendous risk on our behalf. I'd also like to see the government advertise
the policy, not just the repayment of a debt, but the benefits that veterans
are uniquely able to bring to the job, so that employers in the private sector
can be influenced to adopt the policy.
I recently published a blog article describing some CSR
(Corporate Social Responsibility) "don'ts". The news is not all bad
on the CSR front and this time out, I'll talk about some good examples of CSR
practices. The focus shifts from the steel making industry to the forestry
industry and from Hamilton Ontario, Canada to British Columbia, Canada. The forestry
industry has operated under close scrutiny from a number of organizations
representing a number of community based stakeholders.
The forestry industry was blissfully ignorant of the
negative impact that angry stakeholders could have on their business until the late
'90s when organizations such as the Sierra Club and Green Peace began to make
their impression on public opinion. The
forestry industry had been battling native bands in the area for the rights to
log for decades. This added an extra degree of complexity to the situation for
forestry companies because logging is a provincial responsibility and Indian
affairs is a federal responsibility. Indian bands attempted to deny forestry
companies access to forests based on their claims to the land and their claims
that even when they had no claim, they claimed responsibility for preserving
the forests devolved to them. Forestry companies generally reacted by
continuing the logging practices they had used for years, including "clear
cutting" forests. Clear cutting harvests almost all the trees for the
Protests by groups such as the Sierra Club caused the
industry to dig in their heels initially. The Sierra Club is very skilled at
drawing public attention to activities it wishes to discourage. It has years of
practice with successful campaigns such as the one that succeeded in halting
plans for 2 dams that would have flooded portions of the Grand Canyon. The BC
chapter of the club brought the same organizational expertise to bear on the
forestry industry. The Club, along with Greenpeace and other organizations
organized international boycotts of the forestry industry. Those boycotts and
other actions succeeded in getting the industry's attention.
Things began to turn around, beginning with an agreement
reached in April 2001 between 4 environmental groups (including the Sierra Club
and Greenpeace), 8 first nations bands, 6 forestry companies, and the
provincial government which protects millions acres of forest in the coastal
region of BC. The exact extent of the area under protection seems to vary
depending on the source, which goes to show that even when a solution
acceptable to all stakeholders has been identified, agreements seldom last
long. The agreement reached amongst these stakeholders was held up as an
example of what can be accomplished when companies work with stakeholders to
find a solution to a problem which satisfies the community and corporations
doing business in that community. The agreement was made even more difficult by
virtue of the number of companies which had to be included in the agreement.
Two of the first nations bands involved in the agreement received the Land
Award for their part in reaching the agreement.
So why did CSR succeed in the BC forests but not in the
Hamilton steel mills? This answer has to do with the stakeholders each was
dealing with and their approach to those stakeholders. The forestry companies
were dealing with stakeholders which could bring international attention to their
cause. Not only can organizations such as the Sierra Club and Greenpeace
attract attention, they are also capable of harming profits with boycotts of
the company's products. This "perfect storm" of stakeholder interest
provided the companies involved with a great incentive for reaching an
agreement which preserved CSR goals and objectives while allowing the companies
to engage in their business and make a profit. What follows is my take on the
CSR "Do's" that succeeded in this situation.
"Do" look for the "win
win" solution to sticky CSR problems. The forestry industry companies,
first nation bands, provincial governments, and environmental groups all
demonstrated a willingness to give something up in order to gain the agreement.
"Do" look for ways of
bringing all the stakeholders together so that the process of agreeing is
simplified. What made the Great Bear Forest agreement possible was the active participation
of all the stakeholder groups in thrashing out a solution. This required to
everyone communicated to everyone else. No matter how willing, a company
attempting to pursue a CSR policy by dealing separately with 2 different
stakeholder groups will be frustrated by differences between the groups.
"Do" look for common ground.
This "do" is aimed at community stakeholders rather than
corporations. Groups representing differing community interests must be
prepared to reach an accommodation with the groups they compete with.
Intransigence when dealing with a rival group makes reaching any agreement
impossible. Corporations will frequently take the course of least resistance
when faced with this kind of situation. I can't please everyone so I might as
well please myself.
"Do" be prepared to take the
strategic view. Implementing a CSR policy which is acceptable to the community
stakeholders you are dealing with may require you to make short term sacrifices
in return for long term gains. The Hershey company is a great example of a
company who took the long term view. Adopting a CSR policy (even though the
term had not been coined yet) in Pennsylvania rewarded the company with
thousands of good will ambassadors, to the extent that they named a town after
the company founder. The name also happens to be the company name.
I don't like to pick on BP, but when a disaster as large as
the Gulf Oil Spill happens we should learn all we can from it. The latest news
in this saga comes from a report released late Tuesday, November 16, 2010 that
questions the risk management efforts put forth by BP and their
sub-contractors. BP and their sub-contractors were not the only organization to
be criticized. The report also criticized the U.S. Minerals Management Service
and other regulatory agencies. The report was released by National Academy of
Engineering and National Research Council and in it the independent panel cites
a failure to learn from several near misses as evidence of a lack of risk
management. It should be noted that this is only an interim report and a full
report will be released by the council when they have concluded their
The report is critical of BP and its sub-contractors for
making bad decisions which could have been better informed if the probability
of certain risk events had been properly estimated. They were critical of the
oversight agencies for not questioning the decisions. One example was the
decision to continue abandonment operations despite
several tests that indicated the cement used to plug the well, put in place after the installation of a
long-string production casing, was not an effective barrier to prevent gases
from entering the well. The test results were accepted by the folks on sight as
satisfactory but subsequent examination of the results by experts working on
the investigation show that the results were not satisfactory and did not support
the decision to proceed. There were also more general criticisms of the players
such as the lack of a systems approach to integrate the multiple factors
impacting well safety, to monitor the overall margins of safety, and to assess
various decisions from a well integrity and safety perspective. The council
called several other decisions about the cementing process into question,
including attempting to cement across multiple hydrocarbon and brine zones in
the deepest part of the well in a single operational step. The council felt
that this approach made a hydraulic fracture in a low-pressure zone more
BP lost drilling materials deep in
the hole about a month prior to the disaster but did not use this as an
opportunity to recalibrate their risk information, or identify new mitigation
strategies. The risk event that should have been avoided was the failure of the
blowout preventer which was designed to prevent leakage from the capped well,
as the name would suggest. There could be any number of root causes for the
blowout, including the type of cement chosen for the plug and the amount of
time allowed for the cement to cure. The loss of the oil rig, blowout
preventer, witnesses (11 of the crew died in the accident), and much
documentation deny the investigation information that would help them identify
causes so it is unlikely that the root cause will be found with any degree of
accuracy. Failing that, the investigation seems to be focusing on failures in
BP's risk management.
It will be impossible to determine
whether the desire to maximize profits played any role in BP's decisions, and
how much they influenced them, if they did. Rather than make assumptions, let's
look at the lessons it can teach risk managers. The first lesson I'd like to
point out is that risk management is a cyclical activity. You can't just
identify and analyze risks at the outset of the project, or project phase, and
then put your risk register away. Risk management activities have to be
performed repeatedly throughout the lifecycle of the project if your goal is to
avoid derailment of the project due to a missed or unmitigated risk event.
There are some obvious points that call for a review of the risk register, such
as at the end or beginning of each phase. There are less obvious ones such as
when a change is introduced to the project plans, even a minor change. Your
risk management and change management processes should be tightly integrated
such that no change is introduced to the project which has not been thoroughly
analyzed for new risks, or impact on existing ones.
Another less obvious point is when a
corrective or preventive action is necessary. These actions should be treated
as changes to the project plan, after all they are just that, even if they are
introduced by the project manager. Analyze your action for the introduction of
new risks or an impact on existing ones. Only when you are satisfied that risks
have been properly dealt with should you take the proposed action. The
occurrence of a risk event is another point for review. Was the risk event
identified? If it was identified and mitigated, what went wrong with the
mitigation strategy? Does the failure of this particular strategy indicate that
there are other strategies which may fail? In BP's case there were a number of
strategies that failed without causing a review of their risk management plan.
The simple passage of time is another
cause for review. As time passes, work is completed and as work is completed,
more is learned about that work and similar work. The information accumulated
could bring about improved mitigation strategies for work to be done in the
future. Even without the additional information, the passage of time affects
risk. Think of a risk event that would prevent you from taking a flight you
have booked. 3 months before the flight, the impact of this risk event is
slight. Canceling the flight will usually not incur any penalties. If that
exact same risk event were to occur the night before the flight, the damages
could be significant, up to the forfeit of the price of your ticket. That's why
they sell flight insurance. Check the risks in your register for the impact of
the proximity of the milestone they apply to and adjust your mitigation
strategy if the proximity elevates the impact to an unacceptable level.
Lastly, analyze your most significant
risks for quantitative impact. This analysis usually quantifies the risk event
in terms of money. If the risk event were to happen, the cost would be $X. The
value of this exercise is its effectiveness at putting the risk into
perspective against the goals and objectives of the project. I guarantee that
if BP had done this analysis on the risks around that well, they would have
taken a different approach to managing the risks.
Effective risk management is all
about residual risk. Residual risk is the amount of risk remaining after a
mitigation strategy has been implemented. All the risks in the project should
be managed so that risk is below the organization's risk appetite. Acceptable
risks should score less than that threshold with mitigation. Mitigated risks
should be re-evaluated after the mitigation strategy has been implemented. The
new score should be less than the threshold.
In a story in Tuesday's Toronto Star newspaper, CP staff
writer Julian Beltrame wrote about U.S. Steel's response to a judgement in
Federal court that rejected U.S. Steel's attempt to declare a law suit launched
by the Federal government unconstitutional. U.S. Steel is the American company
which acquired Stelco, the Hamilton Ontario steel maker in 2007. Let me provide
some background to this story, then I'll get to current events and how this
story ties to CSR.
Stelco began encountering financial problems at the turn of
the century. The reasons for Stelco's problems needn't concern us here but the
upshot was that they were forced to seek bankruptcy protection under the CCAA
(Companies' Creditors Arrangement Act). Under the act they drafted a Plan of
Arrangement which was approved by the Monitor appointed by the Court. This plan
was a proposal which set out how Stelco would satisfy its creditors and under
the Act creditors were prevented from using any legal recourse which would
otherwise be available to them. This gave Stelco time to organize its business
and, due to the re-organization and an improvement in the steel market in general,
Stelco was able to exit protection in March of 2006. U.S. Steel then acquired
Stelco in 2007 for $1.9 B, $1.1 B in cash and the assumption of $800M of
Stelco's debts. U.S. Steel acquired all of Stelco's component companies and
facilities, including the main steel making facility in Hamilton Ontario and
the Lake Erie works in Nanticoke Ontario.
Foreign companies who wish to acquire a Canadian company
must apply to the Federal government and satisfy regulations administered by
the Investment Canada Act. In Stelco's case, approval was given for the
purchase based on a number of commitments undertaken by Stelco which had to do with
keeping jobs in Canada and maintaining productivity levels at its Canadian
U.S. Steel laid off 700 employees from the Hamilton facility
in late 2008 when it closed a blast furnace. In March of 2009 U.S. Steel
announced that it would temporarily shut down its Hamilton its Hamilton plant
and most of the Nanticoke facility putting 2,000 employees out of work. In
October of this year U.S. Steel announced the permanent closing of the Hamilton
facility. They have since restored about 100 jobs due to a steel order received
from Germany. Industry Minister Tony Clement felt that these acts constituted a
violation of the agreement with U.S. Steel and launched a lawsuit in the Canadian
courts to force U.S. Steel to pay a penalty for breaching the agreement. The
Act provides for penalties of up to $10K (CAD) per day.
This brings us up to the events described in Tuesday's Star
by Julian Beltrame. U.S. Steel is attempting to have the suit dismissed based
on the fact that allowing the union which represents U.S. Steels Canadian
workers, and a potential bidder for U.S. Steel's Nanticoke facility, Lakeside
Steel, intervenor status fundamentally alters the nature of the proceedings. Justice David Near reserved judgment after hearing arguments from both
sides. This follows an attempt by U.S. Steel to have their agreement with the
government voided because they claimed the Act was unconstitutional. This
appeal was dismissed by the Federal Court. The government suit has been stalled
to date while these various appeals have been adjudicated.
Now to connect all of the above with CSR (Corporate Social
Responsibility). Although U.S. Steel does not appear to have a CSR policy as
such but does have a "Code of Ethical Business Conduct" which governs
every employee of U.S. Steel from the Board of Directors on down. The Code is
divided into 7 principles that cover safety, the environment, and business
ethics. Principle number 7 states "Conduct business with utmost integrity
and only for the benefit of U.S. Steel. With the exception of principle 3
"Protect the Environment", the other principles are all focused
inwardly. The fact that U.S. Steel has no formally recognized CSR policy
visible to the public (I have taken this information from the U.S. Steel web
site) would be the first CSR "don't". Don't think that existing codes
of ethics can be substituted for a CSR policy.
Corporate Social Responsibility requires that organizations
take a broader view of their responsibilities. In the past corporations viewed
responsibility as flowing upwards from employees to managers, to officers, to
directors, and ultimately to the shareholders. CSR requires corporations to
broaden the scope of their responsibility to include the society they do
business in. Any policy which does not include the communities the corporation
does business in cannot qualify as a CSR policy. Policies which specifically
direct employees to conduct business "only for the benefit" of the
corporation run counter to the concept that the corporation has stakeholders
outside of the company who must be considered. Policies directing employees to
abide by the laws in the municipalities, states, provinces, and countries where
they do business are no substitute for considering the welfare of those places.
It seems to me such policies are redundant. Breaking the law is a criminal
issue which goes beyond the scope of corporate ethics.
The second "don't" here is: don't enter into an
agreement with a community or government which you know, or should know, you
may not be able to honour. In U.S. Steel's case the agreement was around
employment levels in the Canadian facilities and U.S. Steel argues that market
fluctuations have prevented them from fulfilling that commitment. They have a
valid point: steel prices are volatile. In the less than 2 year period, 2009 -
2010, prices for hot rolled steel coil have gone from a low of $474 USD per ton
to a high of $754 USD per ton, a fluctuation of 59% The problem is that in the
2 year period 2002 - 2004 prices fluctuated from a low of $76.8 USD to a high
of $134.6 USD which is a fluctuation of 75%! My point here is that steel prices
have fluctuated since U.S. Steel came into existence in 1901 so they should
have known that prices could tank after their acquisition making living up to
their commitment uncomfortable for the shareholders.
There is another factor at play in this issue and that is
the Buy America provisions that mean that products, including steel made in America are given preference when
governments are selecting vendors. The CSR "don't" here is: don't
play one stakeholder off against another when determining, or abiding by, CSR
policy. U.S. Steel did not exactly play one stakeholder (the U.S. Government)
off against another (the Canadian government) in this case. The Buy America
policy was introduced after U.S. Steel acquired Stelco. The problem is that
they do not appear to have attempted a reconciliation of their commitment to
the Canadian government with their adherence to the Buy America policy.
Corporations implementing CSR policies will encounter conflicting stakeholder
interests. Don't play one stakeholder off against the other or support one
stakeholder's interests at the expense of another's, attempt a solution which
will be acceptable to both and which still allows you to make a buck. If a
solution which suits all parties is not possible, choose one which does the
least harm and try to get both parties to live with it. Making the attempt will
at least get the issue into the open where public pressure may help bring the
parties to an agreement. U.S. Steel is a large enough corporation to command
attention from the 2 governments. They could have approached both U.S. and
Canadian officials to attempt a solution acceptable to both governments. I
suspect that didn't happen in this case because U.S. Steel believed their
interests lay in satisfying the Buy America policy and did not see this as
conflicting with their ethics policy.
I've noticed lately that a number of organizations in the IT industry, searching for a project manager, are making experience in working with specific software a requirement. First let me say that I have nothing against organizations hiring project managers looking for specific skill sets. "The customer is always right" in the area of resource acquisition as well as in the retail trade. If experience in use of a certain software product is really important to you then by all means make it one of the selection criteria. My point is that it should not be assigned the same priority as some of the other selection criteria.
To successfully manage a software project, the project manager must have a solid grounding in general project management practices. These practices are fairly thoroughly covered in the PMBOK® (Project Management Body of Knowledge) and any project manager who has demonstrated their grasp of these practices by passing the PMP® certification exam can be relied upon to use them to manage your project. The fact that a project manager has been certified as a PMP® should not be used as the only hiring criteria and it should not be taken as a form of performance guarantee. It is merely an indication that the certified project manager has studied project management best practices and is able to demonstrate an ability to use them in project situations. Those looking to engage a project manager should not choose a project manager simply because they have the PMP® certification unless they are able to demonstrate an ability to manage their project to a successful conclusion.
I'm suggesting a top down (or bottom up, depending on your stance) approach to identifying the skills and experience that will identify the ideal project manager to you, with the top level representing the higher priority criteria. The demonstrated ability to use general project management practices should be your highest priority. Certification of a project manager means that they have a command of these best practices and can identify them with simulated project problems in an exam setting. You should look at the project manager's experience as a means of demonstrating the candidate has used the best practices to successfully manage projects. If you are working with selection criteria grouped in "must have", "important", and "nice to have" categories, general project management skills would be a "must have".
The next most important criteria will be the ability to manage the project's human resources to successfully deliver the projects they have managed. Again, this ability should be demonstrated by the candidates experience in managing similar resources on similar projects. I would argue that it really is not necessary to have managed a specific type of resource (e.g. database architect, C++ programmer/analyst, etc.) in order to demonstrate the ability you need. Look, instead, for the candidate to demonstrate their ability to create and maintain a high performance team, then look for a demonstration that team was able to deliver performance above and beyond the sum of its parts. A project manager with zero experience in managing a C++ programmer, but who has had years of experience in developing high performing software development teams is much more likely to deliver the results you need than one with experience in the management of that specific resource but without experience in developing high performance teams.
A project manager's experience in managing projects of a similar, or greater, size and complexity than the one you are undertaking is the next most important criteria on your list. Look for project complexity indicators such as the size of the project teams, the number of sub-projects, the number of applications and databases, the volume of data, the number of stakeholders, the budget, the number of customers or clients, and the number of vendors as indicators of the size and complexity of the projects the candidate has managed. The type of project and the type of software tools used in its execution matter less than the candidate's experience with large and complex projects. The project manager with a depth of experience in managing projects larger and more complex than yours will be able to take the added complexity factor of the technology (if indeed there is one) in their stride.
Your project manager will be the face of the project. This frequently means that they will be called upon to communicate with executives on a Steering Committee, or other stakeholder body. The project manager you select should be able to demonstrate the ability to identify the information needs of these stakeholders and the ability to meet those needs. They also need to demonstrate an ability to communicate with executives one on one, by means of presentations, or by e-mail. Smaller projects with lower profiles may not call for a PM with this experience. The demonstrated ability to communicate with executives and meet their information expectations is actually addressed in the scope management and communications management areas of general project management skills, but candidates should be able to demonstrate experience in dealing with this type of stakeholder where required.
Your project manager should also be able to demonstrate an ability to spot potential problems and issues before they impact the project. This is typically demonstrated by their experience with risk management. This is actually a general project management competency, but you may want to segregate it from other general PM competencies if your project is large and complex. Their experience should cover all risk management processes from risk identification to retirement of risks. I have also noticed some companies asking for PMs who have experience in "escalating issues". This usually means the ability of the project manager to spot a problem which the PM is not able to resolve on their own and reflects the desire of the sponsor to be informed of the issue in time for them to take action and avoid a negative impact on the project. This is actually covered in the Communications Management area of project management best practices, but you should ask the candidate to demonstrate their experience with managing this area of project communications.
The last item on your list, and the one with the lowest priority, should be the candidate's experience with the technology chosen for the project. I would actually recommend deferring a decision on technology until the PM has been chosen, if at all possible. Too many projects are hampered by a decision to use a technology that has been sold to the executive sponsor or IT sponsor, without consideration for what will best meet the project's needs. Choosing a technology that the project team is comfortable with is also a consideration. For projects that must utilize technologies already in place, by all means choose a PM who can manage a project using that technology. Making this criteria the lowest priority means that only when you have two candidates who have met all the other criteria equally well would this be a deciding factor. Hiring organizations who have the luxury of choosing from among two or more candidates capable of demonstrating competencies in all the other areas I've mentioned should consider themselves extremely fortunate. Providing you've done your due diligence in the interview to ensure the candidate actually has the experience they claim, you can't make a bad choice!
Hiring organizations should be prepared to do some leg-work when they engage a project manager. The amount of leg-work will be commensurate with the importance of the project to you. Selection of the project manager who will take responsibility for a project that is critical to your organization's strategic plans should not be the result of an automated search for a key word or phrase in a resume such as C++, Agile, or Oracle Version 10.1. The temptation to use these key words and phrases to limit the number of resumes you have to read through is strong, but try to resist it. The reward for this extra effort will be the rich field of candidates you have to select from. Using the same care and discipline you would use when selecting a vendor for a million dollar contract will pay off by identifying the best candidate and increase the probability of a successful delivery of your project.
November 11th is designated as Remembrance Day in the
countries of the British Commonwealth, including Canada. Its purpose is to
remind us of the men and women who have made the supreme sacrifice for us in
one of our foreign wars: WWI, WWII, the Korean War, and Afghanistan. We mark
the occasion with 1 minute of silence at 11:00 am every November 11th. The line
"Lest we forget" is frequently used in association with the event as
a sort of tag line to remind us of the sacrifices made on our behalf and to
keep the memory alive in the future.
Thinking of those who died in those wars and of how one
could thank them for their sacrifice launched this blog. The answer to the
question is, of course, that you can't thank the dead for their sacrifice. If
we feel gratitude towards those have made sacrifices on our behalf, we will
have to focus our attempts on the living. With that in mind let me list some of
the reasons for being grateful and thankful to those who go overseas to fight
on our behalf.
Lest we forget: It's not only those who die in battle (or through
accident when in uniform overseas) who make sacrifices on our behalf. Some of
the folks making sacrifices are coming back to us with serious wounds. These
wounds include the loss of limbs and the loss of the use of limbs.
Lest we forget: Not all the wounds suffered by combat troops
are visible. Some of these young men and women come back to us suffering from
forms of mental illness caused by the stress of battle. Despite the fact these
wounds are invisible, they can be just as debilitating as the physical sort.
Lest we forget: Every single man or woman that put themselves
in harm's way on our account are making a sacrifice. The lucky ones, and thank
goodness they far outnumber the injured, still sacrifice years out of their
lives and usually when they are in the prime of their lives and would otherwise
be carving out careers for themselves.
Lest we forget: It is not humanly possible to be continually
exposed to the violence and stress of battle without those conditions having a
profound effect on you. Even soldiers who are not diagnosed with physical or
mental problems will be profoundly changed by their experiences.
Lest we forget: These folks have made, and are making, these
sacrifices on our behalf. When our country asks for soldiers, sailors, and
airmen to serve, the people who volunteer to serve (or are already in the armed
forces because they volunteered before the war) are serving on our behalf. This
is true whether we agree with the reasons for the war or not.
Lest we forget: It takes great courage to volunteer for a
service which is physically dangerous. There is no more dangerous job in the
world than a front-line service man or woman. They go over to whichever country
we happen to send them knowing they could come back amputees, horribly
disfigured, or not at all.
The project management community can show its gratitude to
these brave men and women when they come back to us by hiring them when they
come out of the forces. Remember that the army will currently only retain those
veterans who are battle field ready. Readiness is tested by a physical exam
which excludes most of those who have lost limbs or have their mobility
compromised. Project managers and their teams may feel they are in a battle
sometimes, but there are no physical demands an IT, pharmaceutical, financial,
insurance, etc., etc. project makes on them. The fact that a veteran is
disabled should not bar them from a job they are otherwise fit to perform.
The very fact that these folks sacrificed their time will
handicap them when they compete with others who have been adding to their
education and skill sets during that same time. To compensate for that
disparity the veteran can offer you their courage and their ability to handle
the stress of battle. How can that help your project? How many times have you
seen otherwise capable performers behave irrationally when a deadline looms and
they are behind on their work? How many times have you seen evasive behaviour
when the pressure is on? Now think of the effect their experiences in battle
have had on a veteran's ability to handle pressure situations. Most of us, when
we interview a candidate for a position on a project, will look for a candidate's
ability to demonstrate the skill or experience they say they have. There is no
better demonstration of someone's ability to handle pressure situations than
the experience of a veteran who has gone through the stress of battle, not once
The other attribute these veterans have is the ability to
work as a member of a team. There are no projects I can think of where team
play is not important. Soldiers are forced to rely on one another in the
battlefield. They put their lives in the hands of their team mates and the
ability to work together as a team not only leads to success, it can save their
lives. Think of the number of times you have read of a soldier's bravery in
battle as demonstrated by the risks they took to save a comrade. Now think how
many times that must happen without comment in the media. If you are looking for a demonstration of the
ability to work as a member of a team, look no further than the vet's
The next time you have the opportunity to hire one of our
veterans, make sure that you weigh their experience on the battlefield with all
the other attributes you value for the job. Veterans are not looking for hand-outs,
they are looking for a level playing field. Hiring the vet for a job they are
qualified for will benefit your team with courage, the ability to function in
stressful situations, and the ability to function as part of a team. And that
vet might just teach you a thing or two about handling stress!
Tony Hayward, the ex-CEO of BP, was interviewed by the BBC
about his role in the Gulf oil-spill and his subsequent replacement as CEO by
American Bob Dudley. The interview hasn't aired as yet but the BBC has posted
some excerpts on their web site. These excerpts are "teasers",
designed to entice the viewer into tuning in to the full interview and not
necessarily representative of the entire content. The parts of the excerpt that
I found intriguing were the bitterness that Hayward felt towards the media, and
BP's lack of a contingency plan to deal with the leak.
Let's deal with the media issue first. Hayward is perhaps
justified in criticizing the media for the way they focus on the story of the
day and feature the most lurid aspects of the story in prime time news.
Certainly, the amount of attention focused on the Chilean miners who were
recently rescued from a mine collapse illustrates the media approach. The story
was featured on TV news in both North America and England for days on end.
Every day the lead story seemed to be about the latest development: someone's girlfriend showed up at the site and
their wife stayed away, what they were eating, and on and on. The attention
focused on the story seemed out of proportion to its impact on world news, yet
stories with a seemingly greater impact on the world were elbowed off the stage
in favour of the Chilean miners' story. Even after the rescue was effected and
the miners safely above ground, the TV stories kept coming.
Tony should remember two things about the media: number 1,
the media will report on events they think will capture the public interest
because their ability to sell advertising is directly dependent on the number
of viewers that tune in to their news casts and number 2, the most anyone can
expect from the media is that what they report, they report truthfully. The
media feeding frenzy that Tony Hayward refers to is bound to happen when one
network identifies a story they believe will draw viewers and other networks
are made aware of it. If the first network to pick the story up is a reputable
large network, other networks have a choice to make: assume the first network
is correct in their assessment of the story and give it the same amount of
attention, or assume they are wrong and don't report it, or give it much less
prominence. The worst that can happen in the first case, if they are wrong
about public interest, is that they will suffer the same loss of viewers as the
first network. The worst that can happen in the second case is that the first
network reporting on the event, and any other that gives the story the same
prominence, will draw viewers away from your news report. Given the pace that
news events hit the evening news, decision windows are brief and the stakes high.
Even if a mistake is corrected the next day, the loss of viewers may be
Of course, none of this is news. Newspapers were taking a
similar approach to reporting news events of the day long before the advent of
BBC or CNN. Big papers were battling one another in the last century. Their
competitive approach to reporting and the way they sensationalized stories was
dubbed "yellow journalism". Granted, yellow journalism also distorted
the news they reported but one of the ways in which distortion was accomplished
was the exaggeration of comparatively minor stories to turn them into front
page news. Sometimes there seems to be an element of this in the way TV
networks handle news stories.
None of this is news to major corporations such as BP who
have entire organizations devoted to manipulating the way the media report on events
involving them. These folks attempt to have stories that paint their
corporations in a positive light featured as prominently and as favourably as
possible while suppressing negative stories or putting a positive
"spin" on them. If Tony wasn't aware of the way this story was going
to be treated by the press, he had only to consult with his PR organization to
In fact Tony indicated during the interview that he
understood the reaction of the media. "I don't feel like I've been made a
scapegoat, I recognised the realities of the world we live in." " In some senses it comes with the patch
and you simply have to take the rough with the smooth." Tony appears to be
facing up to the fact that he was aware of the attention he could expect from
the media and failed to deal with it properly. The attention that he objects to
is his vilification. The vilification occurred when he took time off to go
sailing in the midst of attempts to stop the leak and his statement that he
wanted his life back. These weren't the only gaffs he made, he was also quoted
as referring to the local victims of the disaster as "little people",
a remark that did not play well with the American public.
The fact is that when you are responsible for a major
project such as the Deepwater Horizon oil well, you have to be prepared for the
full glare of the media if something goes wrong. As Tony Hayward says, "...it
comes with the patch..." It is also true that Tony Hayward did not cause
the spill himself and even BP is not solely responsible. They sourced some of
the work to vendors who are also responsible. None of this gets Tony off the
hook. He was the face of BP and acted as its spokesperson from the outset. That
he was willing to take the heat and face the media frenzy reflects well on him.
How he handled that attention and the negative impact it had on BP, does not.
(www.threeo.ca) deals with project management issues so I'll put this story in
the context of project management. Remember that when you undertake to manage a
project, you can expect the accolades if the project goes well. Expect the
brickbats if it doesn't. You may not be personally responsible for the mishap,
you may not even have been informed of it until your ability to respond
effectively was severely restricted. Doesn't matter. As the project manager you
are responsible for project results including any negative outcomes. Take your
lumps and learn from the experience. You should always use the opportunity to
conduct a "Lessons Learned" even if you have to conduct it alone.
What went wrong? Why did it go wrong? What could I have done that would have
avoided the negative outcome next time? How could I have improved on the way I
handled the disaster when it did happen? Answering these questions will aid the
maturation process and better prepare you for your next project. Remember the
George S. Patton quote "I don't measure a man's success by how high he
climbs, but how high he bounces when he hits bottom." Same applies to
women. Don't sulk, or feel sorry for yourself. Learn from the experience and
improve on your performance next time out.
The next part of the Tony Hayward interview I found
interesting was his reference to BP's contingency plan. Tony felt that contingency
plans were inadequate; "BP's contingency plans were inadequate. We were
making it up day to day." Some comments on the internet refer to a crying
need for ERM in BP's operations. While BP does not boast an ERM policy it does
have a Health Safety, Security, and the Environment (HSSE) policy which sets
standards for managing risks in these areas. The BP policy statement available
on their web site makes no mention of any responsibilities that the Board of
Directors or company officers might have in this area. As is the case with all
policies, standards, and processes, if it ain't in writing you don't have it.
It is difficult to say whether ERM would have been of any assistance in this
case. It would definitely have elevated the importance of risk mitigation in
the area of safety and the environment, if it did nothing else. It would not
have identified the right strategies to prevent the accident, or the right
contingency plan to deal with the disaster if it an accident did happen.
It is difficult for me to believe that no one at BP, or
their vendors (e.g. Transocean who leased the drilling rig to BP), could have
foreseen the consequences of a blowout. That's the whole point of the blowout
preventer the rig is outfitted with. Add to this the fact that a 2002 safety
inspection identified the blowout preventer as being non-compliant with BOE
regulations. This is not to say that the rig was non-compliant when it was in
use by BP, but it should have informed them that a problem with the preventer
was a possibility. The fact that there was no effective contingency plan
shouldn't necessarily shock us, but it sounds as though there was no
contingency plan in place. The fact that there was a blowout and the preventer
did not work as advertised illustrates that their mitigation strategies were
not effective and that a contingency plan would have been a great help.
The blowout on the Deepwater Horizons oil rig was an extreme
example of a risk event with a very high impact. 11 lives were lost, wild life
in the gulf and gulf shore suffered greatly, and businesses dependent on the
gulf were devastated. The $20Bn price tag of the disaster should put the impact
into perspective, though that doesn't begin to define the impact of the 11
deaths. This disaster has taught me one lesson which should be applicable to
any project. We are typically focused on a qualitative analysis of a risk
event, answering the question "Which of these risk events has the
potential for the greatest impact and should therefore have the highest
priority?" If we take the time to examine the risk event scenario and
estimate the costs of the various outcomes, we can derive an estimate of the
cost of the event in dollars (a quantitative analysis). Do we want to do this
for each of the risks identified for our project? Of course not. Should we do
it for the events that we determine will have the greatest impact? I'd say it
would be worth our while. We don't necessarily have to blow the budget on
effort and expense to come up with an exact estimate, make the investment
proportional to the impact and project.
Look at identifying a practicable contingency plan to
mitigate the impact of a risk event that you are unsuccessful at preventing,
especially when the impact of that risk event would be catastrophic. Rollback
strategies that return the previous version of a software system is an example
of what I'm talking about. No project manager worth their salt would dream of
cutting over a new version of a mission critical software system without having
a rollback plan. That project manager will go even further; they will test the
rollback plan to ensure it will work in the production environment. Mitigation
strategies that tend to reduce the possibility of a failure of the new system
version will include system testing, stress testing, load testing, and
performance testing. This two pronged approach should be considered for any
high priority risk.
Risk management is all about business cases. Does the amount
of the risk reduction exceed the cost of the mitigation strategy? (($risk
impact x %reduction) > $ cost of risk mitigation) In the case of contingency
plans, does the cost reduction the plan provides exceed the cost of the
contingency plan? (($risk impact x %reduction) > $cost of contingency plan).
The lessons the BP gulf disaster should teach a project manager is to carefully
allocate the risk management budget to derive the maximum benefit. Don't
hesitate to propose an increase in the budget to your sponsor if, in your
estimation, you have a valid business case. You don't set the budget for your
project so have to accept the sponsor's decision on whether your strategy is
worth implementing or not, but you must make sure your sponsor has all the
facts to make an informed decision, including any estimates of the actual cost
of a risk event. If your sponsor declines to spend the money for your strategy,
don't just assign responsibility to your sponsor and describe the mitigation
strategy as "accept" in your risk register. Look for alternatives
that might be a little less effective in dealing with the risk but will be less
costly. Your project should have a Risk Management Plan which both you and your
sponsor can live with. No one should be surprised at the outcome if the worst
case scenario happens and your stakeholders should be prepared for the negative
outcomes. I would say that certainly did not happen in the case of the BP gulf
e-Health Update, November 3, 2010
Greg Reed is making progress as the new leader of e-Health
Ontario according to an article appearing in Wednesday's Toronto Star. The
article, written by the Star's Queen's Park Bureau reporter Tanya Talaga,
reports that nearly 5,000,000 patients across the province have had their files
converted to electronic form and that 5,500 doctors can now manage their
patients' health files electronically. These numbers represent a jump of more
than 80 per cent over the previous year.
Health Minister Deb Matthews was reported to be happy with
this result. She told the Star that e-Health has "turned the ship around
and progress is being made". The story also reported the dismal background
for the story, quoting the exorbitant charges by consultants and consultants
expensing $1.65 cups of tea. The Progressive Conservative spokesperson,
Christine Elliott, was not so flattering in her comments. She criticized the
progress as being "light years" behind the rest of the country. The
NDP were slightly less critical, but only slightly. Their spokesperson, France
Gelinas, described the news as a step in the right direction, but only a small
Some other details, reported in the same story: doctors have
been given $28K (all figures are in Canadian dollars) over 3 years to upgrade
their office systems. They must use this money to purchase software from one of
12 different vendors. Once the systems and software has been implemented, the
doctors are able to communicate patient records electronically. One of the
immediate benefits of this connectivity is the ability to check drug
interactions on-line. Doctors no longer have to rely on their own records or
their patients' memories to determine if they can safely prescribe a drug
without having the patient suffer a bad reaction because of 2 incompatible
drugs. Given the increase in our consumption of drugs over the last 50 years,
this is no small benefit.
First a word about the e-Health programme. I've described
the programme as a giant data warehousing effort in previous articles and still
hold that view. The scope of the programme can be gauged by the number of
patients it must support. It has absorbed 5,000,000 patients to date and will
probably have to absorb another 5,000,000. Given that each patient will
probably own multiple medical records, the system will likely have to store
billions of records. Assuming that the figure of 5,500 doctors represents half
the population (5,000,000 patients represents a little under half the
population of Ontario), there will be another 5,500 doctors offices to convert.
I think it's time to congratulate Greg and his team(s) on
their progress to date, not forgetting that the work done previous to Greg's
arrival is of value as well. The reaction of the opposition parties is to be
expected. After all, their job is to criticize the party in power. The
programme's sponsor is still the government in power, specifically, Deb
Matthews the current Health Minister, and a programme or project manager should
manage work so that that person's expectations are met. Then it is up to the
sponsor to champion the programme with the other stakeholders. Deb seems to be
stepping up to the plate very nicely as the programme champion. I can only hope
that Deb and Greg are making an effort to communicate this good news to the rest
of the e-Health team who must be somewhat demoralized at this point.
This is the first time I have seen specifics of the
programme's requirements, I'm referring to the fact that doctors are being
given a choice of 12 software packages that are compatible with the e-Health
system. I can only imagine the complexity that the requirement that 12 software
packages must be supported places on this programme. Getting approximately
11,000 doctors to standardize data (shared data must be standardized before it
can be store in a central location) will be difficult enough. Having to support
12 different applications which will have different ways of communicating the
data at different times will mean that the central warehouse must determine
which application it is communicating with and then modify its data transfer
The cost of upgrading the doctors' systems alone will amount
to over $300M! This does not take into account the cost of the networks and
software necessary to support all 12 applications. The story makes no mention
of the affect the differing applications has on the work on the government end.
The data warehouse requires an application programming interface (API) to
communicate with the doctors' office systems and the API must be able to manage
communications with each of the 12 different applications, or the programme
must develop 12 different APIs! I don't have access to the initial requirements
defined for the programme so I can't say whether this is scope creep or not,
but I suspect it is a much more expensive approach than choosing a single
The leadership at e-Health seems to be doing many of the
right things, starting with a "strategy statement" (Ontario's eHealth
Strategy 2009-2012). The strategy statement does an excellent job of defining
the goals and objectives of the programme. The strategy statement goes further
than most project charters or vision statements and includes key milestones, critical
resources, and key risks to the programme.
The goals and objectives mentioned in this document are
divided into 2 groups: clinical priorities and functional priorities. The
functional priorities are the IT systems, including data warehouse, data
standardization, and data marts that comprise any data warehousing project. The
clinical priorities include medication management, diabetes management, and
wait times. I can see that medication management and the e-Health system
components are directly connected. Putting the system components in place and
capturing drug prescription information in electronic form will deliver this objective.
Diabetes management and wait times are more of a stretch. The diabetes
management objective requires the programme to establish a baseline dataset.
Burdening the programme with a project to capture this data seems to me to be a
huge undertaking in itself. Wait times will probably be the most contentious of
Wait times will likely be the most contentious of the
clinical priorities. The objectives identified in the strategy speak to
establishing the IT tools to direct patients to the care facility best able to
see them in the shortest time, to measure wait times, and report on wait times.
The system will not necessarily reduce wait times without service providers
making a commitment to provide accurate and up-to-date information to the
system and then using the reports to improve performance. Come time to assess
the programme's performance you can bet most folks will measure success by wait
time reductions. If wait times are reduced, the perception will be that the
programme succeeded, otherwise it will have failed.
One of the challenges for any programme manager responsible
for a programme this large is the translation of the grand plan into individual
project plans and the breakdown of those plans into tasks, deliverables, and
milestones that the project team can manage. This programme has a great head
start in that the strategy document seems to do an excellent job of breaking
the programme down into individual projects and setting goals and objectives
for the projects. Now it's up to the individual project managers to translate
these goals and objectives into deliverables and break the work down into tasks
The other challenge that e-Health leaders have is the
communication of the programme's goals and objectives and the programmes progress
in meeting them. The media are in the business of selling advertising, or
newspapers, or both and sensational stories tend to sell newspapers. Expecting
the media to issue programme progress reports is unrealistic. Expecting them to
report on the stories they cover accurately is reasonable. The leaders of this
programme need to get the facts to the media. The latest story in the Star does
this - 5,000,000 patients and 5,500 doctors are currently using the new system.
The story even captures a measure of progress - an 80% increase in 1 year, but
it doesn't tell us if the programme is on schedule or not. Getting the paper to
report this simple fact would go a long way to lending credibility to the
programme. It would be nice to read, listen to, or watch, a news article which
tells me whether the conversion of doctors is on schedule or not, or whether it
was delivered on budget or not.
The programme faces other challenges as evidenced by the
requirement to support applications from 12 different vendors. There is a rule
of thumb in software development projects: complexity increases effort
exponentially and effort affects both cost and schedule. Burdening the
programme with goals and objectives not directly connected with the conversion
of medical records will also add time and cost to the programme. In previous
pieces about Ontario's e-Health programme I have mentioned that changes to the
programme will be inevitable because of changes in technology, changes in
government, or changes to medicine to name but a few. Add to this list of
external influences changes in the economy. The downturn in the economy may
mean that the scope of the project will have to be reduced so that the core
goals and objectives are delivered but some of the goals and objectives which
are further removed from the core mission are sacrificed for a reduction in
cost. It seems a shame that this option wasn't considered when contemplating
the dozen software vendors the central system would have to support.
There are lessons here for the managers of less grandiose
programmes and projects. The first is with regard to project scope. We all have
the tendency to set high expectations for high profile IT projects. We struggle
to get our projects noticed and when we succeed, have to struggle to avoid
extraneous requirements that spring from stakeholders high expectations. The
requirements come from business problems or opportunities that our stakeholders
expect the project to address. Programme and project managers must act as a
brake on these expectations. Even when the sponsoring organization is willing
to provide the budget to meet all these expectations, lumping them all together
into one project will cause the scope to become unmanageable. Disconnect any
requirements that do not have a proximity to the project's key goals and
objectives. They can either stand on their own, if they have an adequate
business case to support them, or should not be part of any project. Those that
enjoy some proximity can be tracked for a future project. Capturing them in a
requirements register, log, or issue tracking tool will satisfy the stakeholder
that their requirements are not being ignored. They can be the base of the next
project, if the sponsoring organization still has the appetite to fund it.
Projects that deliver a physically tangible benefit such as
a bridge, a tunnel, or a building, can be difficult enough to manage when they
are large and take years to complete. Changing economic conditions, technology,
and labour conditions can throw these projects enough curves to present a
challenge to their managers. IT projects have the additional challenge of not
being physically tangible so expectations can vary as greatly as stakeholder
imaginations. Keeping everyone's feet on the ground is more difficult.
Technology tends to be more volatile here than in construction so limiting the
project window is more important. Fortunately, IT projects are much more easily
broken down into smaller components. Instead of undertaking a huge project that
will take 3 years to complete, break it down into 6 smaller ones which take 6
months each to complete. The difference will be that the projects at the end of
the cycle will benefit from the experience gained doing the earlier ones.
Requirements that have become obsolete will be easier to discard, especially if
they are part of a future project, and new requirements will be easier to
Once you have defined a manageable set of requirements for
your project, keep your stakeholders focused on the key goals, objectives,
deliverables, and milestones. Progress reporting to stakeholders must focus on
these as well. It is OK to report on individual tasks and activities to the
team but reporting on these details to a Steering Committee will only obscure
your success, or lack of it, at achieving those goals and objectives the
stakeholders expect. Expect changes to your requirements. It is seldom that a
project comes along that won't involve some changes to scope. Stakeholders will
learn more about their requirements on the road to defining and building them
so it is unreasonable to expect that requirements won't change as a result.
Once the scope, budget, or schedule for the project has changed for any reason,
it is important that stakeholders understand how the changes will affect their
goals, objectives, and milestones. Once that learning has occurred and
baselines have been updated, you need to report on your progress towards the new
goals and objectives.
Informing your stakeholders will take on the form of a
marketing campaign. Repetition may be necessary to accomplish your education
process, especially where stakeholders are not familiar with the best practices
in project management. In addition to focusing your stakeholder reports on key
goals, objectives, and milestones, try appending them to your e-mails. Capture
them on the home page of your web site, if your project or programme is
fortunate to have one. Standardize the way you communicate changes to the
project's baselines and be consistent in reporting them. Draw the connection
between the change and the baseline it changed. Don't let baseline changes come
as a surprise to the steering committee in the first meeting after a change has
been approved, communicate the change a summary of its benefits and the changed
milestone, goal, or objective.