A Four-Part Series

By Aaron J. Shenhar

PART 4: THE NEW ADAPTIVE PROJECT MANAGEMENT FRAMEWORK

Based on our research we suggest changing the paradigm of project management and accepting things as they are. The new framework is success-focused, flexible, and adaptive, and we can simply call it the “Adaptive Project Management Model;” it differs from the traditional approach in several ways, as shown in Table 1

According to this model projects are not just a collection of activities that need to be completed on time. Projects are business-related processes that must deliver business results. They are not predictable or certain. Rather, they involve a great deal of uncertainty and complexity, and they must be managed in a flexible and adaptive way. Planning is not rigid, fixed, or done once and for all; instead, it is adjustable and changing, and as the project moves forward, re-planning is often appropriate or even unavoidable. Project management styles must adapt to the specific project and its requirements, and one size does not fit all. While this approach represents a shift in thinking, it is inevitable to meet today’s organizational challenges. While no framework could provide all the answers, we believe that every organization can significantly improve its business results and achieve more homeruns from its projects if it will consciously apply the adaptive project management frameworks.

One final word: We do not suggest, however, eliminating the traditional approach. Rather, we are building on it. Many elements of traditional project management continue to be useful; yet, the overall approach will be augmented. As established by the conventional approach, each project must have a work breakdown structure, a schedule, a budget, an organization and a process. All those are necessary building blocks for well-organized successful projects. These building blocks will only form the baseline to leading the project in a flexible way. Not only do projects have to monitor and review their progress, they must periodically examine the need for the product and the customer’s position. Are the initial assumptions still valid? And if not, what adjustment does the project have to make in order to guarantee better success. Furthermore, in many projects it is impossible to build a clear and detailed plan. The uncertainty involved is simply too high to enable creating a clear project plan with all its bells and whistles. Instead, companies must initiate pilot programs, namely, small-scale efforts that will help remove some of the unknowns before the company can commit to the major large effort. In other situations, managers must create product prototypes that will be tested by customers before the final product requirements are set and determined.

In sum modern projects involve a great deal of uncertainty and complexity, as well as other constraints such as time, political pressures, economical risks, and many others. Each project is unique and it has to be managed it its own way that best fits it unique characteristics, risk and complexity. Only after companies learn how to manage projects in an adaptive and flexible way, will projects become the powerful competitive assets that they can be.

PART 1: THE PROJECT MANAGEMENT OPPORTUNITY

PART 2: WHY MANAGING A PROJECT BY THE BOOK IS NOT ENOUGH

PART 3: WHAT IS MISSING IN TRADITIONAL PROJECT MANAGEMENT

A Four-Part Series

By Aaron J. Shenhar

PART 3: WHAT IS MISSING IN TRADITIONAL PROJECT MANAGEMENT

As mentioned in the previous article, the current, standard, and formal approach to project management is based on a predictable, fixed, relatively simple, and certain model. It is also generally decoupled from the changes in the environment or the business needs; once you created the project plan, this plan sets out the objectives for the project, and the project manager must execute the plan, using a “management-as-planned” philosophy. After the project is launched, progress and performance are assessed against the plan and changes to the plan should be rare, and if possible avoided. Consider the following two major drivers of project management today:

The triple constraint: Project managers see their job as successful when they are able to complete the project on time, within budget, and achieve performance (or requirements) goals. This has famously been named “the triple constraint” (or “iron triangle”) of project management and deviations from it are seen as a negative sign, which must be prevented or corrected.

One size fits all: Many executives and managers assume that all projects are the same, thus suffering from the “project is a project is a project” syndrome. They expect to succeed by simply following a standard set of activities as outlined in the conventional project management books, which currently do not include guidelines for distinction among projects and for selecting the right approach for the right project.

In their struggle to keep projects on track, both executives and teams get frustrated when they are trying to fulfill unrealistic expectations of stability. Worse, in their effort to focus the project on the triple constraint, project teams often lose sight of the business rationale behind their projects, that they must satisfy a customer and achieve business results, and not just meet project requirements. And when they try to follow a standard set of rules for all projects, they often employ the wrong approach to their specific project.

The classical drivers of project management are no longer enough for today’s business environment. The traditional model fits only a small group of today’s projects. Most modern projects are uncertain, complex, and changing; and they are highly impacted by the dynamics in the environment. Virtually every project we studied underwent changes that were unpredictable upfront, and none of the projects was completed exactly as planned. Furthermore, as we found, projects differ in many ways, and “one size does not fit all.” In order to succeed, projects must be adjusted to the environment, task, and goal, rather than stick to one set of rules.

PART 1: THE PROJECT MANAGEMENT OPPORTUNITY

PART 2: WHY MANAGING A PROJECT BY THE BOOK IS NOT ENOUGH

PART 4: THE NEW ADAPTIVE PROJECT MANAGEMENT FRAMEWORK

A Four-Part Series

By Aaron J. Shenhar

PART 2: WHY MANAGING A PROJECT BY THE BOOK IS NOT ENOUGH

The current techniques as used in the discipline of project management form the necessary basis for learning and understanding what project management is all about, but they are insufficient to guarantee a project’s success or to address the needs of today’s dynamic and uncertain projects.

We have seen projects that were managed exactly as required “by the book”–and still failed. They followed a structured process of planning and execution, which is common in the profession, and even when completed on time, they ended up in disappointment to management and clients. And we have observed other projects that did not follow any acceptable structure or process, or did not have a full plan with all its elements, and yet they turned out to be outstanding successes, bringing-in value and fame to their performing organizations and great satisfaction to their customers.

The discipline of project management is based on an outdated model that assumes that projects are successful if they meet their time and budget goals. Once the project is launched, it must continue to its end to meet time, budget and requirements goals. Rarely do projects focus on business results or on changing at mid-course to better adjust to customer needs.

Most of today’s project problems are not technical, but managerial. When technical errors cause projects to fail, it is usually management that failed to put the right system in place so that these errors will be detected in time. We also realized that the current practices of project management are insufficient to predict project problems or to solve them. And we found that even if you do everything according to the conventional well-established practices of project management, you may still fail.

Ironically, these traditional practices remain typically unchallenged by top management. As a result, many project teams are left on their own. They often struggle to keep their projects on track while trying to fulfill unrealistic expectations of stability; often highly detached from dynamic business needs and changes in the environment.

Our conclusion is simple. There is more to project success than following a standard set of rules. It is not the tools or applications, nor is it the lack of process. The problem lies in the mindset and the assumptions that are driving the traditional approach to project management, rather than in process or practice. The critical questions are: can we help project teams make the right assessment before presenting their project proposals to top management? Can we show executives how to ask the right questions and foresee danger before they make a commitment to a project and before it is too late? And can we guide project teams on how to adapt their project management style to the right circumstances, environment, and task? It seems that managers at all levels need a new framework and a new language to communicate with each other about projects.

PART 1: THE PROJECT MANAGEMENT OPPORTUNITY

PART 3: WHAT IS MISSING IN TRADITIONAL PROJECT MANAGEMENT

PART 4: THE NEW ADAPTIVE PROJECT MANAGEMENT FRAMEWORK

A Four-Part Series

By Aaron J. Shenhar

Executive Summary
Projects are the engines that drive innovation and change. Yet top management ignored them for a long time. Thus many projects today do not meet their objectives. In order to unleash the hidden potential that exists in projects companies must learn how to manage project in a highly adaptive, flexible, and strategic way. This change can make projects one of the most powerful competitive assets of modern corporations. In this series of articles we outline the potential that exists today in project management and what organizations can do to take advantage of this power.

PART 1: THE PROJECT MANAGEMENT OPPORTUNITY

Although projects have been around for thousands of years and project management as a discipline about fifty years, there are two reasons why projects and project management are becoming more and more important today to almost all organizations and businesses. First, the share of on-going operations in most organizations is on the decline, while the share of projects is rising. This trend began already in the early 1900s during the industrial revolution, and it is accelerating in almost every organization or industry: Not only do product lifecycles become shorter; today’s customers require greater variety and more choices, forcing companies to offer more products. In addition, market globalization is forcing businesses to respond to local markets and to low-cost competition around the world.

The second reason why organizations need to look closely at their project management is that across the board you may find that most projects today do not meet their time and budget goals and many do not meet their business objectives. Study after study shows that only one out of three projects is really considered successful. Thus, if two thirds of the efforts going into projects do not create the expected value, there is clearly a reason for concern.Ironically, during the last few decades many organizations focused on improving their operations, but not their projects. This trend goes back to the turn of the Century when Frederick Taylor developed the scientific management principles, which greatly influenced the evolution of mass production systems, and it continued to this date with more recent concepts such as Just In Time, Lean Manufacturing, Reengineering, Supply Chain Management, and of course, the latest one, Six Sigma.

Although operational efficiency is important, it has its limitations. With time, at least conceptually, all companies may reach a similar level of efficiency. Additional investment in efficiency may not bring the advantages that it has created in the past. At best it may help you stay in the game and not fall behind. For comparison you may look at quality, which during the last decade has become a must, rather than a source of competitiveness as in the past.

However, no business enterprise today can survive if it is only focused on improving its operations. Projects are the engines that drive innovations from idea to commercialization. But projects are also the drivers that make organizations better, stronger, and more efficient. And since most organizations today accelerate toward a project-based world, shouldn’t companies ask themselves are they doing a better job than their competitors?

This situation presents a tremendous opportunity. The time has come to unleash the untapped potential that exists in projects. We believe that if managers and organizations will pay a greater attention to their project management practices, the rewards will be significant. If top executives will spend as much time on project management as they did on Six Sigma, they will make their organizations much stronger and more competitive.

PART 2: WHY MANAGING A PROJECT BY THE BOOK IS NOT ENOUGH

PART 3: WHAT IS MISSING IN TRADITIONAL PROJECT MANAGEMENT

PART 4: THE NEW ADAPTIVE PROJECT MANAGEMENT FRAMEWORK

Conversation with Mr. Arun Gupta, Group CIO K Raheja and Shoppers Stop

Arun is the Group CIO at the K Raheja Corporation which has business across infrastructure, realty and retail among others. He has a rich experience in the industry as an IT business leader and is recognized as a “Business friendly” and “Strategic CIO”, a leader in aligning IT and business. He has been featured by Economic Times as “The CIO who never spoke Technology”.  Arun is also an active blogger and pens down his observations @ http://cio-inverted.blogspot.com

What is the process your organizations uses to translate strategic initiatives into front-line action and results? How do you assess/manage the demand pipeline and prioritise accordingly?

The management team comprising of the CXOs together define the strategic direction of the organization.  Based on this direction discussions on initiatives required to achieve the strategic objectives are formulated. These initiatives are then broken down into buckets based on time priority of long, medium, and short term.  Strategic initiatives may be long term in nature as they potentially deal with capability development.

The initiatives are then translated into the Balanced Score Card of the organization which are then further broken down into KRA/KPI for the business and functions of the organization.  Project proposals along with budgetary approvals for the initiatives are reviewed in the management meetings. Management and leadership team decides on these initiatives based on consensus and on many occasions projects are prioritized for implementation based on available bandwidth in the organization. For the approved initiatives which are funded the tracking and monitoring is done by the functions and presented to the management team.

This process doesn’t necessarily work all the time for all the initiatives; this may be due to multiple reasons including but not limited to priority focus changes, time estimates mismatches and inability to foresee all the risks and uncertainty.  Also the tactical review discipline is an area for improvement as review is critical to success from an executive perspective.

What are your top 3 or 5 problems with programme/project delivery? How are you currently addressing these 3/5 problems? What support do you get from other CXO’s in addressing these issues?

Business understanding in the partner eco-system is an area of concern and many assumptions are made by the business and the partners when conceptualizing the project.  Patience to go into the details and critical skills of appreciative inquiry and deep interrogation is missing at times. We realized this after specific issues faced on few of our projects as rework on them was going out of control.  Going forward we have now incorporated multiple validation steps which ensure details are discussed and captured as we progress in the lifecycle.  Although on the surface the validation processes seems to consume time it improves delivery as rework post go-live is reduced

For the organization the measure of success of the initiatives is more than just being on time and budget.  Focus on post implementation benefits realization vis-a-vis the baseline was an issue.  Although projects have a business case when it’s proposed and approved, the challenge was to measure the actual realized value.  We have now initiated the process of capturing benefit realized post implementation.  This is important to get the buy-in from other functional heads and by setting an example.  Also delivery teams now have benefit targets to achieve and demonstrate as part of their initiatives.

The third and largest issues remains in the “People” domain as the discipline to execute and follow a structure or processes not just in projects but in general are required for making efficiency gains.  Like most organization, we don’t claim to have an answer for this but in our experience so far, mentoring and coaching people is the way to work on this issue.  There are many things being done here and most of them at an individual leadership level.

Does your organization have a PMO? At what level is it? What are its role and responsibility and how is it being measured? Is the practice of PM actively promoted in your organization? Can you share some of the details?

Our organization does not have a formal PMO in place and at this juncture we don’t seem to be in need of one.   Each of the business and functional leader has a view of its portfolio of initiatives and the same is presented to the committees.  The recognition of PM as critical business skill is not present in function other than IT and infrastructure team.  Apart from nominating people to project management training program there is currently no organization initiative focusing on this.  However, few years ago PM capability development was initiative but due to the slowdown the initiative lost momentum and focus.  Apart from this there is a strong need to align business and functions to the PM discipline.  Apart from interventions in individual organization one needs to include PM as a core subject in formal education. This will assist in building the recognition of this discipline.  And I agree industry needs to start demanding these skills in graduates and management professionals along with pushing the institutions to deliver this.

As a CIO of an owner organization, do you see a difference in the project management practice used by the service providers and by owner organization? What are some of the key differences?

From an industry perspective the key difference is the structured approach that service provider use in defining and managing projects.  Although there are improvements required in estimation, planning and scheduling but compared to owner organization they are more structured.  However, most IT service providers and their consultants lack the ability to decipher the (client) organization context and align the project and/or delivery to it. Understanding the business context and the stakeholders is a major area for service provider to focus on as the key to success lies in alignment of these. We have seen inordinate issues in implementation due to lack of stakeholder alignment and business understanding.

Rigour of review, alignment to business/organization context, balance opportunity with capacity/bandwidth when moving initiative to implementation, mentoring and coaching of managers to adopt a disciplined approach, building PM discipline in academic curriculum

Is Project Management a commodity or a craft?

Some days back I visited the Regional Transport Office of Bangalore North district, more commonly called RTO office. For those unfamiliar about my part of the world, RTO issues driving license if you pass their written test and driving test.

Bangalore, and I guess many of the cities in India, is teeming with driving schools. As the name would suggest, these folks teach you how to drive. In Bangalore and again, probably in other Indian cities, driving schools have, in a way, exceeded their brief. They also help you get the driving license. It is not uncommon to see a driving school agent chaperoning young would-be drivers around the RTO offices, filling up forms on their behalf, making them rehearse the driving rules and in general making them feel at-ease. With the passage of time, this has been stretched to such an extent that many would-be drivers go to a driving school, not to learn driving but to get a driving license!

Does this sound familiar? Rather very familiar? Isn’t this very similar to what is happening of PM education? You don’t see much of PM education happening around except maybe people getting coached to pass an exam. Traditional colleges and institutes do not offer PM as a course except maybe as an elective. The ones that do offer are not necessarily aligned to the practice.  Add to it the growth in number of PMI^® registered education providers who at the best provide only PMP^® exam prep programs.

As per PMI^®’s website an R.E.P. program has been designed to enhance the ongoing professional development of PMI^®’s members, those credentialed through PMI^® and others in the project management profession. But as time passed, a good number of them are now merely PMP^® exam coaching centers, with more following the suit. Some of them guarantee you passing the examination. A savvier few would even return your money back if you do not pass. Being a project management mentor, I have got requests for help in filling up in the PMP^® application from aspirants. (I feel like screaming at such requests!)

The conflict between credential being a commodity versus it being recognition of a craft (A craft is a skill, especially involving practical arts – Wikipedia) is a much debated and discussed topic in multiple forums. The jury is still out on this decision. But in the meanwhile, someone has to take serious look at PM education.

Coming back to my story, I had gone to the RTO for my daughter’s driving license. Even if she gets it, I would be really wary of handing her my car keys. I hope the powers-that-be in the industry do not share such apprehensions about a PMP^® certified project manager!

Eager to know if you would agree or disagree with me. Please do write.

Knowing your customer’s business.

I drive around in a Mahindra Scorpio shown here. It gives me unfair advantage on the roads in Bangalore where the right of way is based on the size of the vehicle! Lest you think so, this blog is not about the comforts of Scorpio or the horror called Bangalore traffic.

It so happened, some days back I rode in this SUV with my friend who is a mechanical engineer. As he got down, he looked back at the vehicle for a moment and said “Tell you what, my team designed the gear box for this SUV. Mahindra chose the design from a couple of prototypes we had made. Today, all the Scorpios in the country run on my gear box design.” Otherwise very restrained, my friend had to struggle to hide his sense of pride when he said that.

As you would have guessed, my friend does not work for Mahindra but his organization provides services to them, typically as projects.

This conversation set me into thinking. How many of us in our projects appreciate why the customer has entrusted us with the project? Or how many of us know where the project fits into the proverbial larger picture?

If you ask me, my answer would be “Not many”. Some if not most of, projects run on the classical iron triangle of scope, schedule and cost. The team gets the project with the requirements. It is executed hopefully in schedule and within costs and delivered back to the customer. Then you return to your home team and get reallocated to the next project in line. Taking further liberty, I would like to say that the PM is worried about on-time delivery and the team about sale-ability of the skills acquired through the project. And the twain sometime does not meet.

The basic question is should the project manager and the team know the customer’s business? Is this a nice to know or badly needed piece of information? Probably, the later.

Let me paint a few scenarios.

Is your project a part of mature well proven product? If yes, you can expect clear requirements but the customer would expect quick turn-around time.

Or, may be your project is a part of a brand new product/platform. You can expect uncertainty in requirements. (I am sure my friend in the above story would have faced a lot of this.) Don’t fret over frequent requirement changes.

Or is the customer meeting some legal compliance through your project. Expect very clear requirements but don’t get frustrated by thorough verification with a magnifying glass, almost nitpicking.

So, knowing the larger picture does help you in managing your project better.

If you become invisible and get into some of the project meetings, you will get to hear a lot “we and they” talk (or should I say “us versus them”, anyway). Like “They always change requirements”, “They do not know what they want”, “We are already overworked” etc. If you know the customer’s business, you will have less reason for the “we and they” talk.

I want to end this blog on a philosophical note. Inherent in the human heart is the desire to be of some use to somebody and to leave a legacy behind. Knowing the customer’s business fulfills this desire. Like “thousands of vehicles ply on the bridge that I worked on” or “every time you talk on this phone, my compression software kicks in”.  How do these statements compare with “we completed the project within 10% schedule variance but got beaten on cost escalation of 50%”?

Need I say more.  As usual, eager to hear your views and experiences. You could also vote at http://polls.linkedin.com/poll-results/95180/gamah.

Observations on the practice of estimation

I had heard this story long time back. There was this gentleman visiting a historical fort situated in a small village. He was walking his way to the fort but unaware of how far the place was. On the way, he saw an old man sitting on the steps of his house soaking the morning sun and asked him “Baba (loose translation: the revered), how long will it take to reach the fort?” The old man remained silent. Assuming the old man to be hard of hearing, the visitor continued his walk. In about two minutes, the old man called him back and told that it might take him forty minutes. Looking at the nonplussed and almost angry expression on the visitor’s face, the old man added “Son, unless I know your pace, how would I be sure of the time you would take?”

I wish the many of us in the project management community had the same patience and wisdom which the old man had in this story, when it comes to estimating and scheduling.

Through this blog I wanted to bring out some prevalent mistakes in estimation and scheduling.

Inherent inaccuracy: All the project managers (and their supervisors and customers) know that by its very definition every project is unique. The very first slide in any project management training course would say this. But probably this realization is only at the intellectual level. None probably wants to accept the fact that along with uniqueness comes uncertainty which in turn leads to inaccuracy in estimation. Moreover, this inaccuracy cannot be wished away till you are actually done with all the activities.

Single value certain estimates: Given the inaccuracy, shouldn’t the estimates have a range. Say 20 staff days plus minus 5. Or 10 staff days at 10% accuracy. But usually there is no range specified. You get to see only single and certain values.

Two, all the work elements get the same treatment. There is no distinction made on the uncertainty of the work element and thereby higher or lower tolerances in the estimates.

Same productivity for all resources: When resources are allocated to work elements it is assumed that all the resources have the same productivity. This simplifies duration estimation to division of work estimation by the number of resources. But unless the resource is a machine, you cannot assume same productivity. In fact, human beings are notorious for having different productivity at different times in the project. Needless to add, there are differences in productivity across humans too.

Progressive elaboration not considered: As project progresses, accuracy of the estimates is expected to improve. During the concept phase there would be a wide spread say -50% to +75%. During the design phase the spread would narrow further to say -35% to +50%. This implies that the project schedule gets re-baselined at the start of every phase if not more frequently. But this rarely happens. Once a schedule is base lined at concept stage, it is cast in stone. No re-estimation, no base lining.

Single project finish date: For all the reasons mentioned till now, should not schedule show the project finish date as a date with a range. Say 14-Aug-2010 plus minus 5 days.

But this is rarely the case.

Variations not anticipated: All schedules depict interconnected activities. Variation in one activity has a cascading impact on the schedule. Variation in a dependency outside the scope of your project may also impact your schedule. This is again a well known fact, which largely gets ignored. There is an entire new approach to scheduling called Critical Chain Project Management (Goldratt) which takes care of statistical variations and interdependencies. Even without buying the add-ons for CCPM to their existing scheduling software, project managers can use the concepts of feed buffer and project buffer put under the control of the project manager. But this is rarely done.

No Plan B: Most of the projects have foreseen risks. There is an elaborate risk register containing risk description, mitigation plan, owner etc. But when it comes to plan B, project managers behave like the proverbial ostrich with its head buried in sand. Foreseen risks with high exposure should prompt the project manager to be ready with plan B which would control the damage done by the risk. But one rarely gets to see plan B. Most of the contingency plans talk of communication and escalation like “inform the management” or “inform the customer” in place of a plan B.

So much said and done in the practice of estimations, I will be eager to know your view and experience regarding this topic.

An effective IT PMO can deliver breakthrough results in most PM areas including increased throughput, speed & reliability, significant reduction in resource burn-out, higher productivity, leading to high benefit/ cost ratios for IT investments.

Long before Hrithik Roshan[1] became their brand ambassador and set hearts “Dhak, Dhak, Go”, Hero Honda used to run an advertising campaign – “Fill it, shut it, forget it”. They were referring to the fuel economy of their bike which was claimed as 80 kilometres per litre. That’s why the line “Fill it …”

This popular ad-line popped up in my mind from nowhere, when a close colleague remarked that his project just goes on and on and on.  I began to wonder if the Hero Honda tag line “Fill it …” applied to project management too. I see more people looking at project management as a template filling game. The biggest and most talked about template we fill up is the risk management template. Fill it, save and close it and forget it seems to the practice of risk management.

My observation has been that using standard checklist people do prepare a list of risk or a risk register as described in PMBOK.  But the question is, do we move beyond risk identification and manage risks at all?  So in-spite of all the great intent with which register and plans are prepared, projects continue to fail.  In my view this is perhaps due to two problems

One, the risk register is not integrated with the rest of the project plan.

Two, the risk register remains a well intentioned document but there is hardly any follow up or in the PMBOK parlance, monitoring and control, of risks.

Problem one, is largely an issue of integrated planning. Revisiting the plan taking the risk as inputs is an area that needs improvement. It’s a good practice to show significant risk mitigation steps in the schedule as activities. This ensures that the mitigation plans have an owner and a date.

For example, if the lack of expertise in technology is identified as a risk condition, the corresponding mitigation response would be training the team. One or multiple activities related to training should be there in the project schedule. Taking the same example further, if this training involves hiring a vendor’s services, one should allocate a cost to this which in all probability may consume the reserves or contingency fund.

It is also possible that training once conducted, may not reduce the risk exposure and one will now need a contingency plan or plan B to reduce the impact of this risk to the objectives. For example, hiring expert services on short term contract could be your plan B.

Problem two is the ongoing monitoring and controlling of risk register. It is not sufficient that risks be documented during planning alone. The on-going effort and not just intent to monitor and control, is critical and not doing this is as good no risk management at all.  Remember a risk never closes completely, it just retires. At the same time, a new risk could be just lurking around the corner.

Apart from this, it is possible that the risk exposure of active risks changes that in turn may impact the overall project objective.

Identifying risk triggers is not only useful for monitoring but also assists the manager in defining the appropriate mitigation steps. Risk trigger plays an important role in alerting the manager if a risk is likely to occur. If you are not watching out for the trigger and looking at the actual risk event instead, you may not be left with much leeway to act.

Like they say, chance only favors a prepared mind, just filling up the risk register template and shutting it is not good enough or else we forget about project success.