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 1^st as originally planned, but on July 1^st, 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 1^st.

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 expressway).

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

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

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:

1. 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 have chosen.
2. 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.
3. Make certain that each of your employees feels that they are a valued member of the team.
4. 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.

The 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 award.

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

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

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 austerity measures.

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

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.

Monitoring Risk

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

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

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

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 but repeatedly.

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 battlefield experience.

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

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 find out.

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.

This site (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 disaster.

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

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 process accordingly.

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

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 these objectives.

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 and activities.

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

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.