We have developed Automated Project Office (APO) to allow each and every one of a customer’s projects to have consistent, world-class quality assurance reviews. Through collecting operational project data from your existing systems and incorporating feedback from all project stakeholders to form a holistic view of each project and continuously filtering this data through a built-in library of expert knowledge, APO can provide improved visibility and management of project risk.

As a software-as-a-service (SaaS) solution, it’s easy to get started with APO. There is no hardware or software to install and maintain, so APO can be up and running within one month.

Take a look around for yourself. Let us know what you think about our work and services. By all means, contact us if you think your organization could benefit from a tool like APO.

In light of the focus of this blog, we’ve reviewed the listing of upcoming live webinars. We believe you would enjoy the following webinars that explore risk:

• Data Collection for Risk Identification
• The Organizational Politics of Risk Management
• Sizing, Cost, Schedule and Risk for Software: A 10 Step Process

And when you can’t attend, we record the webinars and provide them for free viewing for the first week after the webinar has aired. After that time, you can purchase access to the webinar for a nominal fee.

These webinar recordings are stored in our webinar archives. There is a search feature that allows you to search either by category or by speaker. When you search by the category of Risk Management, you get a list of almost 15 webinars to choose from. Some of the more interesting webinars include:

• Early Warning Signs of IT Failure: The Four Horsemen of Doom
• Managing the Black Hole: The Executive’s Guide to Software Project Risk
• Speaking the Language of Risk
• The Race to the South Pole: Lessons in Risk Management for Leaders
• The Software Baby Boomer Risk
• Welcome to the Land (and Brand!) of Risk

Look over the full list of webinars and maybe purchase some. Then let’s talk about what you’ve learned, the topics you’d like to see us offer, and suggestions for improvement.

In his article, “Eight Key Issues in Managing Operational Risk,” Stanley Epstein defines operational risk as “the risk of loss resulting from inadequate internal processes, people, and systems or from external events.” He then looks at the four key elements of that definition—people, processes, systems, and external events—and expounds on each of them. Read More>>

He then lists the eight key issues for management of operational risk with brief explanations:

• Internal Environment
• Setting Objectives
• Event Identification
• Risk Assessment
• Risk response
• Control Activities
• Information and communication
• Monitoring

What do you think of Stanley’s definition of operational risk and his issues related to operational risk? Is he spot on the money, or does he miss some key component? Share your thoughts with us.

In the article, “Project Risk or Issue?”, the unknown author explores both risks and issues and tries to offer operational definitions for each.

A risk is an unknown event that people are worried about that may or may not happen. It affects only the project’s cost, schedule, scope, or quality, and if it happens after the project over, it is not a project risk.

An issue is an immediate problem that we must resolve immediately by adding tasks to the plan, extending the schedule, or increasing the budget. Issues get tracked and resolutions are attempted all the way through until the issue no longer affects the project.

At the end, the author states, “That is the difference between risks and issues.  Handling each appropriately will communicate more effectively and make management much easier.” Read more>>

We think, if we are going to manage risk and projects appropriately, we must know the differences between risks and issues and handle them appropriately. If you have different definitions, or you think the difference doesn’t matter, feel free to post on our blog. We’d love to engage in dialogue about this issue.

In the article, “Failure Leads To Success,” the author suggests a paradigm shift. All too often failure in our society is equated with guilt, shame, and inadequacy, to the point that it is synonymous with incompetency. The author argues that failure is the only road to success; through appropriate risk taking and mitigation, new information is learned and success is achieved.

The author suggests viewing failure as a learning process. In the words of the article:

Failure vastly improves your odds of success, particularly in the long run, because it tells you what to do—and what not to do—next. When you diagnose your failures and figure out where you went wrong, you’re teaching yourself, literally by trial and error, how to go right. Read More>>

To turn victory into defeat, with each failure, you must analyze yourself by asking the following questions:

What have I learned from this experience?

What value can I find in it?

What will I do differently next time? Read More>>

In the article, the only time you truly fail is when you fail to learn from your mistakes. So, what have you learned from your mistakes? Did you use a process similar to what is in the article, or did you use another process? Leave your comments on our blog.

Steve divides his risks of mistakes into four categories: people, process, product, and technology. In sum total, he lists 36 risks of mistakes that can be made. The following table lists each mistake by category:

Note: The material in this table is copyrighted 1996 to Steve McConnell. He reserves all rights to it. Read More>>

Throughout the article, he discusses the details behind each risk or mistake, including some of the more cryptically titled ones. He is even conducting a research study to collect new risks and validate the old list. We invite you to share your experiences with these risky mistakes on our blog, along with any mitigation techniques you successfully used to overcome them.

In her article, “Ten Ways to Guarantee Project Failure,” Naomi humorously lists ten mistakes that project leaders can make, in a sort of flip side look at managing risk on the project. I think if she were to share a few of her tips for managing project risk in a more serious light, they would include frequently measuring the team against agreed upon milestones, providing frequent communication with the customer, ensuring the right people are in the right positions, and ensuring the schedule doesn’t result in a long death march of overtime and weekend work. She closes with the comment:

“As a rule of thumb, remember that if you pay attention to the needs of the project, the team, and your customers, you run the risk of succeeding.” Read More>>

Looking over her tips for project failure is fun, and yet there is truth in humor. We invite your comments on other project success (or failure) factors.

An article in today’s Scientific American (here) discusses some recent research on how willing people are to take risks when they feel secure.  The article is largely about external factors that give us a sense of security, but I find it interesting because in every test case where the researchers made participants feel more secure (and take more risks, usually around finannces) they never made participants feel secure by providing them with more information – instead they appealed to the same kind of basic securities that you can find at the bottom of Maslow’s Hierarchy of Needs.

By itself, I think the most surprising thing about this study is that they were able to see these results with financial risks – an area where I would normally say risk-taking and risk management behaviors are most mature.  When taken in the context of risk management more broadly, I think it’s even more interesting, as it seems to me to be exactly how we tend to deal with risk management in the larger scheme of things: projects we “feel good about” are often the projects we tend to ignore.  But the criteria upon which we “feel good” are no better than the shoulder-patting confidence the study participants got – we tend to allow ourselves to feel very comfortable and confident in a project without any true evidence that the project is going well (for example, estimates vs. actuals, or requirements stability measurements, etc.).  This is exactly why project failure rates are so high for IT.  We have to be proactive in identifying and measuring risk, rather than feeling good and eventually being reactive in trying to address catastrophies.

Computer scientists at Queen’s University have developed a new form of chess in which players (including computers) can’t identify a chess piece until they move it. They call it Quantum Chess, and it’s amazing because taking the knowledge of the piece out of the equation actually makes the combination of potential moves incalculable – without being able to project movements based on piece locations, a computer can’t rule out any possible moves, thereby making the total possibilities nearly infinite. You can check out the whole story here.

The story caught my eye because I think it’s so similar to risk management strategies of today. How often do organizations actually know enough about their risks to predict the potential outcomes? Queen’s University worked very hard to take measurement out of the chess equation. We often don’t work hard at all to bring measurement to the project risk equation – as a result, both of our outcomes are pretty much the same: unpredictable.

Fortunately for us, we don’t actually have to work as hard as the CS folks at Queen’s to bring measurement to IT projects. For us, a little bit of measurement can go a long way. Even without a firm plan, collecting data will yield a positive result – although you’re better off with a plan if you want to get better ROI on that data. But the fact of the matter is, even some very simple project performance baselining will help you start to predict how similar projects may perform in the future – which is exactly how the early chess playing computer designs started.