The Money Files

Last time risk expert Wilhelm Kross and I talked about the soft factors influencing managing risk. Here is the second part of that interview, which looks at integrated risk management. Wilhelm is presenting next week at Project Zone Congress in Frankfurt, on the topic of Risk Management and he will also deliver a masterclass on the challenges of mega-projects.

Wilhelm, how do risk management and change management fit together to provide an integrated process?

Almost all so-called risk management processes which have been published in the last couple of decades have in common that they reflect what is commonly referred to as the controlling perspective, while neglecting considerable and important elements of the management perspective. Making trade-offs, designing short-term compromises, implementing short-term work-arounds and the like, are typical management challenges that seem to be ignored.

Admittedly these processes reflect the advantage that they are easily rendered compatible with the abovementioned advantages of static risk frameworks. In contrast, however, the implementation of such processes in dynamic risk frameworks poses the danger that the true complexities are severely underestimated, and inherently setup for failure. Change can and will happen as things evolve and in most real-life actions and initiatives it would be rather dangerous to assume that the base conditions at start-up will remain carved in stone.

Of course, the environment doesn’t stay the same while we are managing risk, so naturally things evolve. Although often our processes don’t reflect that. Are there any common weaknesses?

A common weakness in change management frameworks, including project management standards, is that risk considerations reflect the abovementioned weakness of predominantly focusing on the controlling perspective. The framework which was incorporated in PMI’s otherwise extremely useful Project Management Body of Knowledge is a good example. Any real-life organization which intends to focus on the interplay of risk controlling and risk management within its frameworks of change management would need to add a few steps between planning risk management action, and controlling and monitoring the effectiveness.

There are several additional considerations though which are often under-emphasized. First, common frameworks of change may assume that risk is simply one of the knowledge areas which need to be incorporated within change initiatives, while on the other hand risk intervention measures may become the main driver in the adoption to new circumstances as they evolve. The need to reduce risk factors to lower, acceptable levels may cause a significant deviation from what was originally planned.

Second, those standardized change frameworks which use projects as the predominant organizational structure usually tend to underemphasize that the scope of both change management and risk management usually commences long before a project is conceived, and can stretch far beyond the official close of a project, particularly when cultural change and multiple external stakeholders are involved.

Third, risk management efforts in real-life organizations are often setup and implemented somewhat half-heartedly until the true need arises to practice risk management more professionally. Once the establishment of professional risk management involves the triggering of turnaround and crisis intervention measures, of course, numerous additional factors need to be reflected including in particular the recognition of the fact that there is insufficient time available to design and plan all related activities thoroughly.

Hence it is likely best to, within a preconceived framework of change, reflect risk in both a static and a dynamic setting, and allow for the gradual professionalization and optimization of risk management from rather informal activities to more mature decisions and action that are increasingly based on tangible quantitative data.

OK, so the best approach is to blend static and dynamic risk frameworks so you cover all bases. Integrated risk management seems a bit more than that though. How would you define it?

The expression “integrated risk management” commonly refers to static and dynamic risk frameworks in which risk management, often in multiple dimensions (i.e., cost, time, reputation, societal damage, environmental damage, toxicity, etc.), is fully incorporated into line function or change management activities and related decision making.

Thanks. What are the benefits?

Depending on what is truly done and how well, and what is at stake, the conceivable benefits usually include enhanced levels of transparency, a focus on what truly is important, a reduction of undesired negative impacts and side-effects, a protection of the organizational value at risk, time savings in the implementation of management action, and in some cases enhanced value creation as part of what is commonly referred to as systematic opportunity management. Given that numerous frameworks of change, and risk frameworks, authorize the implementation of risk management using predominantly qualitative approaches, in spite of the fact that any unquantified risk is by definition quantified with zero, the quantitative proof of the benefits of integrated risk management inherently remains underestimated.

Are there any limitations to implementing this risk approach in practice?

In my view many real-life organizational frameworks for risk management reflect some inherent limitations that can and should be considered avoidable. To name two typical misconceptions, real-life risk management improvement frameworks are often focused on reaching elevated levels of maturity, and ultimately thriving toward the royal discipline of enterprise-wide risk management. Both may be overly shortsighted. As Harold Kerzner pointed out, maturity can be a point from which onward everything goes downhill, at least when one builds on the analogy of the introduction of products into markets. Kerzner submits that organizational leaders should bank on the preparedness of knowledge workers to accept and adopt change on their path toward maturity; however, rather than maintaining the glass ceiling that often protects these leaders from criticism and emotional attachment, they should consider mapping out the path beyond maturity, which may consist of organizational excellence and ultimately the development of true competitive advantages.

The second aspect of enterprise-risk management as it is portrayed in risk textbooks poses the danger of underemphasizing rather significant factor in today’s real-life. Many organizations have heavily engaged in outsourcing activities and in some cases have even outsourced parts of their core business. Similarly to what is the case in the application of cost reduction activities in which the simultaneous increase in risk levels was simply ignored, the true implications are largely unmanaged. In today’s business environment larger scale investors may be able to purchase and redesign entire industry sectors. A supplier, who was believed to be a secure outsourcing partner, may no longer be available, even at short notice. The typical interface between the organization and its suppliers, the procurement function, may be wrongly focused and may lack the relevant skills to assess the likelihood of stability in the supplier relationship, in which case the evolving hazards for the core business of the organization may remain undetected until it is almost too late. And by the way, these considerations are of significance too in change frameworks, including standards for project management.

Thanks, Wilhelm.

Find out more about Project Zone Congress here: http://www.projectzonecongress.org.

About my interviewee: Dr. Wilhelm K. Kross, Dipl.-Ing., MBA, Eur. Ing., PMI-RMP is an internationally recognised expert in the fields of risk and project management and a partner of Plejades and the Amontis Consulting network. His main focuses are the fields of applied risk management and related in-depth risk analytics and valuation techniques, (mega-)project structuring and financing, as well as operational crisis and turnaround management, particularly in complex larger scale crisis programs and projects.

About the author: Elizabeth Harrin is Director of The Otobos Group, a project management communications consultancy. Find her on Google+ and Facebook.

In this instalment of my occasional Ask the Experts feature, I speak to risk expert Wilhelm Kross, who is presenting this month at Project Zone Congress in Frankfurt.
Wilhelm will talk about Risk Management and
also deliver a masterclass on the challenges of mega-projects.

Wilhelm, thanks for talking to me. Let’s start by clarifying something you talk about in your work. What is the difference between a static and a dynamic risk framework?

A dynamic risk framework recognizes the fact that the world has not come to a stand-still while certain action takes place. It enables the reflection of what is commonly referred to as “the management perspective”. It reaches beyond the scope of reducing the current level of risk to the acceptable level of risk with a combination of risk transfer, operational risk, and strategic risk reduction measures, whichever proves to be effective and efficient. It is typically implemented with feedback loops and iterative approaches in order to help focusing on what truly is important, and why. Necessarily, a dynamic risk framework is future-oriented, and allows for the systematic capturing of new and evolving risk factors as and when they become conceivably relevant. It needs to cope with soft factors, and imprecise and uncertain information, which implies that a probabilistic approach is a “must”.

In contrast, a static framework is useful when the predominant focus of risk analytics and related documentation is the one of consistency in performance evaluation, or higher level portfolio aggregation in risk reporting.

OK, so which is better?

Both static and dynamic risk frameworks can be useful. They need to be designed for specific purposes though.

Thanks. One of the big things in risk management at the moment (in my opinion) is the understanding of how human interpretation affects risk. How much of a role do soft factors play in risk management?

Under certain circumstances it may be appropriate to ignore the relevance of soft factors in risk management, particularly when the main focus is comparative historical performance and consistency in risk analytics within a portfolio of activities. As and when the predominant focus is the one of designing and implementing risk reduction measures, preparing decisions, making trade-offs, or reaching beyond risk reduction into opportunity management, soft factors are what truly count.

Why is that?

The reasons are quite simple in that usually the response to a new risk factor or the design of a new risk management system commences in an environment in which certain data and information are lacking, or reflect an uncertain level of accuracy and partial transparency with regard to underlying assumptions.

“Hard data” risk analytics and number crunching as well as risk modeling and portfolio-level risk aggregation may follow. However, as and when it comes to decision making under uncertainty, decision making with numerous conflicting objectives, coping with a variety of stakeholder opinions and desires, or the implementation of risk reduction measures, usually “soft” cultural and human factors become dominant again. Besides the naturally limited human perception, time constraints and a variety of biases, usually, risk management in real life usually reflects a compromise which is designed and implemented by humans, to handle what is conceived feasible and sensible.

OK, so we can’t ignore the soft factors related to risk management. What's your top tip for project managers who want to be better at managing risk and reducing the financial implications of risk on their projects?

Unfortunately the financial dimension is not the only relevant one in integrated risk management. Neglecting other relevant factors invariably leads to sub-optimum decisions and action and avoidable mistakes.

Fair enough! You must have a couple of tips to share with us though.

There are two considerations which I believe to be of utmost importance, and which I typically observe to be underemphasized if not entirely neglected in real-life organizations. First, irrespective of the standard frameworks which have been established for the organization and its financial reporting, do consider the management perspective. This may involve setting up additional activities and tracking additional key performance indicators over and above the minimum requirements of the organizations at large.

Second, do focus risk reporting on the true needs of the target audiences, and adopt the explanatory wording accordingly. A member of the board of directors usually has entirely different needs than for example a quality manager, or an external stakeholder who may be the recipient of undesirable side-effects of the core processes. Moreover, in order to trigger decisions, the underlying chain of arguments may need to stress entirely different factors. And last but not least it should be noted that any form of risk documentation offers opportunities in that the minimum level documentation can be combined with a specification of the true mandate that the risk reporter would like to be offered, with all its must’s, nice-to-have’s, and exclusions.

That’s great, thanks Wilhelm.

The second half of this interview will be published next time, when Wilhelm and I chat about integrated risk management.

About my interviewee: Dr. Wilhelm K. Kross, Dipl.-Ing., MBA, Eur. Ing., PMI-RMP is an internationally recognised expert in the fields of risk and project management and a partner of Plejades and the Amontis Consulting network. His main focuses are the fields of applied risk management and related in-depth risk analytics and valuation techniques, (mega-)project structuring and financing, as well as operational crisis and turnaround management, particularly in complex larger scale crisis programs and projects.

Find out more about Project Zone Congress here: http://www.projectzonecongress.org.

About the author: Elizabeth Harrin is Director of The Otobos Group, a project management communications consultancy. Find her on Google+ and Facebook.

In my article last month I looked at four common budgeting mistakes: not forecasting holidays, scheduling team members at 100% availability, confusing tolerance and contingency and forgetting tax. Here are three more common budgeting mistakes for you to look out for this year.

1. Not sharing the figures with the team

If you don’t share the budget figures with the project team, what is stopping you? There are some elements of project budgets like salaries, that you can’t (and shouldn’t) share, but there should be very little reason why you can’t share timesheet data and capital costs with the project team members.

That doesn’t mean that you have to give weekly updates on project spending. After all, talking about money isn’t the most exciting of subjects and it can be difficult to relate to. But it is worth project team members knowing what the overall budget is, and at various points in the project how well you are doing about achieving those targets.

It’s also useful to let the team know when the project budget is challenged. In other words, when they should start considering how they can all work together (with you) to come up with some creative ways to do more for less.

2. Not revising based on actuals

Your budget is a work of fiction until you start spending against it.  Then you’ll start to know exactly what your run rate is for certain services. This is particularly the case if you are budgeting for cross-charges from other departments or contractor time. You may not know exactly what these are going to be until you start working on the project.

When you have a couple of months of data, you can go back to your budget and revise it based on what your actual spending has been. This will give you a far more accurate picture of the future spending you are likely to incur.

3. Not planning for benefits tracking

Why do we do projects if not to get the benefits at the end? Too often, project teams forget to plan how they are going to manage benefits. You may be lucky enough to have someone in the Project Management Office who can act as Benefits Manager (or they may have another title, like Change Manager, but benefits management is part of their job role). Even if you do have someone available to act in this role, it is very likely that they will need some input from you in order to be able to do their own job and plan the benefits accordingly.

Tracking benefits can be done in a number of ways. For example, if you are expecting financial benefits, you can create a spreadsheet to model the expected benefits after the project (or during it, if you are delivering in phases and expect to see some returns before the whole project finishes). You can then track the actual financial returns against your predictions, and use that to manage the benefits.

Tracking intangible benefits is a lot harder – how do you accurately manage productivity or staff morale? One way is to make sure that you have a benchmark to compare to. If you don’t have a starting point for comparative purposes, you can’t prove that you have made any difference at all – either positive or negative – with your project.

Put some activities in the project plan for early on to record these tasks: you’ll want to work out how to take your benchmarks and then at what point later you will repeat the measuring activity to see if you have delivered any changes.

Have you made any of these mistakes? I hope not, but if you have, let us know your stories in the comments.

About the author: Elizabeth Harrin is Director of The Otobos Group, a project management communications consultancy. Find her on Google+ and Facebook.

In this edition of my occasional Ask the Experts feature, I talk to Eric Winquist, CEO of Jama Software, about how to avoid duplicating work and how reusing requirements can save companies time and money.

Eric, you did a survey recently in which 58% of respondents said their company frequently duplicates work when it isn’t necessary. What are the pitfalls of doing this?

Lack of efficiency is the main drawback to duplicating work—it takes 2-3 times longer to build a new product when yourecreate the wheel. When you consider multiple products in one overall line, you’ll note lots of overlap in functionality. Some new products only require small modifications, yet in many organizations, there’s no way to know that.

Recreating existing requirements over and over again increases risk. Multiple versions increase the chance that things get missed, which diminishes the quality of your product. The end result is a costly fix and potentially late delivery. Organizations that centrally manage requirements respond to change faster and catch errors earlier because they are leveraging requirements that have already been developed and tested.

A lot of knowledge thus goes to waste. By creating an environment of reuse, you can harness all that intellectual property, connect the dots and build enterprise libraries of strategic assets, which continually improve over time.

What do you mean by reusing requirements? Is it the documentation, or the code components that gets reused in order for companies to be more effective?

When we talk about reuse, we are not talking just cut and paste from one document to another. We are talking about everything that describes scope – text or visual requirements, mockups, use cases, epics, story cards, plus all associated context around it. So the test cases, the changes or updates, the documentation, traceability, or relationships, decisions around the requirement – at every stage in product delivery from elicitation to launch, a requirement goes through numerous phases. Requirements available for reuse are battle-tested and proven.

Would this work with projects that are not software projects?

Yes. Enterprise reuse works for any product deliverable, whether a software implementation, a web-based project, or an actual piece of hardware. For example, one of our customers manufactures hospital beds and wheelchairs; different hospitals have specific customization as to the specs, but the bed or chair has the same basic requirements. Reuse is an incredible asset for manufacturers as it simplifies and speeds pulling together new products from core components.

How can companies best archive/store/catalogue their requirements so that they can be reused again when required?

Companies can operationalize requirements – by that we mean they can create central repositories of items, including components, requirements and processes for use across the enterprise. For example, a product manager could use Enterprise Reuse in Jama Contour 3.6 to store core requirements, define the scope and vision for the entire product line.

Different project managers can then replicate the project hierarchy and copy related test cases and requirements for each individual product in the line. They have the advantage of having all the core requirements integrated into their projects and having them auto-sync, so their project is always up-to-date with changes and updates across every project that uses the same core requirements.

They would be able to automatically sync their requirements into their specific products, bringing along all the items’ tags, attachments, links and continuing to use all the relationships to any set of items.

How important is reuse to being able to deliver on time? What are the other benefits of reuse?

New projects that can pull core requirements are already partially completed, in the sense that so much of product success relies on solid requirements. We have one customer who, prior to reuse, spent six months with three people to stabilize a specification. With reuse, it now takes one person one month. We’ve seen companies reduce their time to market by two-thirds and increase efficiency by as much as 85%.

Click to see this image larger, and in .pdf format.

Wow, that’s impressive. Do you have any other examples?

SpaceX is a great example of requirements reuse. SpaceX designs, manufactures and launches the world’s most advanced rockets and spacecraft. In 2012, SpaceX made history when its Dragon spacecraft became the first commercial vehicle to successfully attach to the International Space Station — a feat previously achieved by only four governments. Like many other large organizations tackling complex projects, SpaceX was challenged to meet aggressive launch schedules and turned to Jama Contour’s Enterprise Reuse capabilities to create common assets once to support parallel development efforts.

Reuse allows SpaceX to maintain all the common requirements—managed by a core engineering team ensuring?that they are current and accurate—in one central place. Engineers working on specific projects can access requirements quickly and easily. Additionally, if any of the common requirements change, the engineers are notified and can determine the appropriate action. This enables them to spend their valuable time on the requirements unique to each project. Using Contour, SpaceX has eliminated cumbersome spreadsheets to track requirements and other important details of projects. This allows the company to focus on design and development and missions to space.

Thanks, Eric!

About the expert: Eric Winquist is CEO of Jama Software. In July 2007, Eric founded Jama Software with the vision of providing customers a more collaborative way to develop new products and eliminate the common frustrations with traditional approaches to requirements management. Eric is an accomplished entrepreneur and project manager with over 15 years’ experience working with a wide range of enterprise organizations, teams and technologies.

About the author: Elizabeth Harrin is Director of The Otobos Group, a project management communications consultancy. Find her on Google+ and Facebook.