Starting the Problem Half solved: Strategic about Successful requirements gathering

In one of the recent round table discussions that I spoke on the differences between traditional and agile approaches, it became apparent to me that there was some disconnect in the notion of what constitutes a requirement. The software development approaches leveraging traditional plan driven approaches to project management focuses on scope planning activities that centers on requirement definition because it is fairly well known that a successful definition of the problem in hand means we are half the problem solved.

In light of the developments in agile approaches to project management where change is welcome even at later stages in the development, the gathering of up-front requirements is often frowned upon. Although the requirements definition may be a daunting task when there is ambiguity around it, value delivery happens only when an attempt is made to eliminate such ambiguity. When client facing members fail to ask powerful probing questions and engage the expertise to eliminate some level of ambiguity, the business goals are often compromised.

For instance, a requirement should at a minimum should address what the software must to do satisfy what the users need so that the value is maximized and benefit is realized. On the contrary, if the requirements are conflicting and attempts made to eliminate ambiguity are thwarted, then neither the traditional nor the agile approaches to software development will benefit. As the movie, Apollo 13 calls its mission at the end, such requirement gathering from the beginning can only lead to "Successful failure."

Readers are directed to check out an interesting video at this point to gather some insights into the incomplete requirement gathering This video is on youtube at https://www.youtube.com/watch?v=BKorP55Aqvg. What went wrong here? A few thoughts are as follows. Share your thoughts.

• Is starting immediately with a “No” a good approach?
• When trying to ask what the end result will look like, is attempting to over-please rather than understand the business goal appropriate?
• Are both the client facing person and the project manager on the same team as the expert?
• Were any attempts made to negotiate for a acceptable best alternatives?
• Is this project setup to succeed?
• Is this a productive meeting?

What powerful questions can you add to ensure that redefine the requirements correctly? Stepping outside of this video into our own projects or products, what additional questions can we ask to understand the client’s requirement and the reasons behind the requirements better to position ourselves for success?

Negotiation: Tactical Conflict Resolution to Strategic Transcendent Eloquence

Managers and leaders can always recognize that they may not always get what they want when working with stakeholders. Whether it is working with external vendors and clients or internal business units and employees, negotiating for the right resources, contractual agreements, time, cost, scope and even risk is omnipresent in today’s business environments. The fundamental reason for negotiation is to agree on a term that allows both parties in the negotiation to perform better or produce something in relatively better terms than in the absence of the negotiation agreement.

Those that have worked on negotiation may very well know the common techniques like issue resolution, democratic dispute resolution, bargaining, and litigation. But, some may relate to the term phrase best alternative to a negotiating agreement (Fisher and Ury, 1981). Depending upon the root cause that led to a disagreement or conflict, the negotiation may have to morph from simple dispute resolution to a transcendent eloquence. For instance, the discussions such as negotiating for an extension to a project or salary negotiations for a new job may involve evaluating the BATNA from the following areas:

• Opportunity cost of the existing status quo relative to the alternative arrangement
• Impact of the alternative arrangement on the immediate needs that caused the dispute
• Timely feasibility of executing the alternate arrangement
• Risk of the alternative arrangement not providing the promises relative to the status quo
• Evaluating the risk profile and thresholds of the appropriate stakeholders who can be enablers of the best alternative 

However, when the disagreement is no longer simple and arises due to differences of opinions that are both equally valid and respectable, then the resolution to such disputes may involve strategic negotiation techniques like the transcendent eloquence. This is a technique to foster constructive dialogue evaluating the strategic fit of these incompatible yet morally valid disagreements. Such beyond-the-normal discourses need to philosophical, comparative, dialogic, critical, and transformative, says Pearce and Littlejohn (1997, p.157). While it is generally recommended to apply this technique in extreme scenarios like military negotiations and high corporate decision making involving spin-off, merger, etc., this technique can also be beneficial for middle management to exercise their strategic skills.

The philosophical nature of this approach looks beyond the root cause analysis to evaluating the fundamental belief system that gives raise the conflict. Such a journey can encourage both parties to educate themselves on the paradigm shifts in the industry to think outside the box to raise the bars on performance measures. Similarly, the comparative nature of this approach attempts to resolve differences of opinions arising from incorrect frames of references, such as those in differing geographical cultures or vendor relations where each party may have different operating rhythm in software development. As a result, both the parties may establish common patterns of language that serve as the framework of reference on the roles and responsibilities moving further beyond eliminating conflict to addressing productivity.

The dialogic nature of the transcendent eloquence engages active listening steering towards breaking a new ground by using powerful questions towards exploring the root causes. Both parties are now engaged in not only establishing common ground but collaborate towards alternative generation that neither party could have arrived at working alone. On the contrary, the critical nature of this technique applies the concepts of power and influence each party can exercise in implementing the solution by evaluating the strengths and weaknesses of the espoused solutions to ensure that the best alternative is not only a strategic fit but also is rooted on operational efficiency promoting changes that also need to be provided to the appropriate managers and leaders in successfully implementing the solution. 

Finally, the transformative nature looks beyond the conflict into applying the alternative agreement and seeing if the costs of winning justifies being in the game. In other words, should we even be engaged in resolving this situation? For instance, if continuous investment for a product losing its market share may be justified to some extent but if the massive adoption of a new technology is acknowledged in the macro-environment, should alternatives to sustain the product be even considered?

Have you applied any of these approaches in addressing your challenge? How do you think you can apply these negotation techniques in addressing your challenge?

References

Fisher, R. and Ury, W. (1981) William Ury. Getting to Yes: Negotiating agreement without giving in. 3rd ed. New York: Penguin Books.

Pearce, W.B. and Littlejohn, S.W. (1997). Moral conflict: When social words collide. Thousand Oaks, California: Sage Publications 

Project is a verb in Project Management

Project Management is one profession that has grown from practice. While education and some experience was the only prerequisites for one to be considered a project manager, the surge of accidental project managers have made really led to the loss of the fundamental skills and competencies of a project manager. The project management role is a conduit to projecting a voice backed with action managing and leading change using projects as a vehicle in managing all areas of project management.

Therefore, I view “Project” as a verb and not as a noun. This is one way to make project managers move much beyond cookie cutter project management. Each character of Project therefore is defining the competencies expected in a project manager.

• P - Passion about people. Project management is all about people management. This is where the transformational leadership elements of a project manager is displayed.
• R – Resourceful around Risk management. Seeing proactively the risks and managing them by maximizing opportunities and minimizing threats  
• O - Organized around self to manage all aspects of the project. As the saying goes, if you can’t manage yourself, you can’t manage the people that do not work you in the project.
• J - Justified in constant review of resource utilization including both the human and non-human resources keeping in mind the total cost of ownership on the project managing scope and quality
• E - Effective in leading change seeing it as a vehicle to improve scalability and as a liaison to other business units within the performing and client organization
• C - Collaborative in bringing ideas together letting the individuals become groups and then evolve as teams to support each other
• T  - Trust worthy to transform people’s career. This completes the cycle of project where one’s passion for people makes them a servant leader.

Abuser Stories:What shouldn't the software do?

The general tendency of the requirements document has predominantly focused on what the software should do. In project charters and scope control documents,  sometimes we also write what features will be out of scope. The UML diagrams and use cases discuss how the classes should interface and modules should interoperate, for instance. The agile paradigm discusses persona approaches drilling down DEEP property for describing backlog features and INVEST principle elaborating on the  characteristics of a user story. Even test cases that focuses on negative testing uses a requirement traceability matrix to the requirements limitedly testing the functionality of what a system shouldn't do.

But, when a system is hacked or inappropriately accessed, the loopholes rests on the inefficiencies in how the system was designed to allow such loopholes to exist. So, how do you avoid these vulnerabilities so that the hacker doesn't exploit these "working as designed" gaps?

While volunteering at the Agile 2015 conference, I chose to attend a section on Abuser stories by Judy Neher from Celebrity Technical Services. It was a great session introducing the concept that a persona of a hacker or disgruntled employee who could potentially have a malicious intent to deliberately break the system. The speaker suggested describing user stories that specifically could break the system or expose the system for mal-intent. The participants in an activity gave examples for a simple user authentication such as the stringent password recycle policy, the use of a double password and picture identification, the use of external devices such as phone, email, or mobile texting to use tokens for validation within a short timeframe before the account is locked, the creation alerts for maintenance for incorrect and frequent access to multiple accounts, the enforcement of HR exit policies on employment dates before the role based access can be authenticated, the validation of human versus robot logging by tracking the spee of password entry, etc. Imagine having such stories to bullet proof the system against malicious attacks on standard user stories and have automation capabilities to constantly check for these loopholes.

I am sure one would say that this would add more time to the scheduled release or limit the stories written per iteration/sprint. Of course, similar to non-functional stories that add some time, the abuser stories also will add time. The need to develop hinches on the type of regulations in the industry, the type of technical platforms used, the time to market considerations, etc. However,  the question shouldn't be whether to do them or not but when to do them. If we fail to do them we are increasing the technical debt. A couple of  alternatives are to dedicate a sprint or a portion of every sprint to address these abuser stories.

I really think this is an important component of combined technical and product ownership to ensure we see the persona of other types of users and see the system from that view. As good project mangers turn assumptions into risks and control quality, the technical and product owners should be accountable for products that preclude vulnerabilities by design. Abuser stories are a great start. Don't you think so? Share your thoughts.

Attention or Time Management

Flying over India returning from Mumbai to Chennai, I was browsing the Jet Airways magazine. Often filled with travel recommendations and shopping suggestions, these in-flight magazines have only created a browsing pleasure. But, this magazine had a topic on achieving more with less perking my interest to explore.

It was an interesting read as the article began discussing how the time management pretty much shouldn't be the focus of smart managers. Instead, the article focused on attention management. Based on the time of the day, people can manage difficult tasks that require deep thinking,  strategy, etc when their attention to detail is at the peak. Then, as the energy winds down, their attention takes a deep dive. This time should be used for tasks that require less critical thinking.  Between these extremes is the reactive attention seeking timezone that should be used for other tasks that require a balance of the two.

I agree that it is a good idea and that tasks require different levels of thinking. For instance, planning for the project, evaluating strategies to grow account, or  grooming the product backlog with new features based on the market and reactions from customers and users require thinking different from task or resource management.

However,  the article said the urgency of the tasks shouldn't be a criteria for attention management.  This begs some thinking as depending upon the role of an individual manager,  the urgency of the task, such as a grieving customer on the phone, an infrastructure deficiency leading to business continuity management,  or a delayed or poor quality work impacting deployment readiness of a project is not something that can be ignored.

The earlier approach on using Scrumban to think a couple of steps ahead and plan can be combined with attention management to better compartmentalize take at hand and energy/attention requirements to better manage productivity.

Thoughts?

Client Management: The Influence of Powerful Questions

I had a wonderful opportunity to be with one of my mentors in three different client settings. I am sure people in project, account, product, and sales setting have gone through the stakeholder management aspects. Whether it was a formal status meeting, casual hallway conversation, informal dinner meeting, or an internal project evaluation meeting, I found it very inspiring to see how my mentor was skillfully weaving these questions to eliminate ambiguity and establish a solid business relationship. While I added a few of my own color from account and project management, I felt such a strong reinforcement of these questions that I felt compelled to package these questions for the community at large. So, here goes the list. Feel free to add - focus however on strategic account & project management and not bury with technical aspects of platform and feasibility here!

1. What are your goals and objectives? Are you interested in market expansion, market penetration, or both? What's your timeline? 
2. What are your challenges to meeting this goals and objectives? How would addressing these challenges benefit you and your organization financially?
3. What are the profiles of stakeholders that you are looking at to satisfy with your campaign?
4. What types of population are you planning to target? Why are these targets important to you?
5. What types of channels are you planning to use? What data points do you have to support these channels to effectively reach your population? 
6. How much of your budget are you willing to spend on these channels? What's your exit strategy?
7. How would meeting these goals and overcoming challenges enhance the competitiveness of the product?
8. If you were to meet your goal, what would this mean to you? 
9. If these challenges are not met or goals accomplished, what does this mean to you?
10. What's an example of a successful campaign or meeting? What data points are you looking at evaluate the effectiveness of the campaign or efficiency of the meeting? 
11. What's your communication style? 
12. What's your risk profile? Are you adventurous and creative to try new things? 

Future of Project Management in the Next few years

In the Professional Development Day (PD Day) conducted by Project Management Institute Mass Bay chapter on June 19, 2015, there was a great introductory session with more than 100+ participants representing many industries that broke into numerous tables. One of the questions that all the attendees worked on was the top challenges that are facing the field of project managers in the next 10 years.

Synthesizing the various thoughts from these discussions, the following set of challenges evolved where project managers should equip themselves with more knowledge.

1. Become more business oriented learning strategic thinking
2. Having to work with remote multinational teams learning the cultural nuances
3. Become more involved with futuristic technologies learning mobile, service orientation, and security areas
4. Learning to work with multiple tools for both process and analytics
5. Understanding agile framework as much as traditional project management framework learning to know when to apply each or a hybrid form
6. Learning to manage external and internal stakeholders in the business learning to negotiate better
7. Getting better at managing risks in multifaceted areas (PESTLE) besides just SWOT
8. Being more accountable for quality to compete with the agile thinking
9. Promoting project management in organizations much beyond PMP certification
10. Understanding the impact of growing regulatory environments on projects

These thoughts present insightful forecasting of what is to come both in the project managers that face the clients and the account managers (Ryals, 2012) that should exhibit project management thinking. So, the landscapes around the evaluation of project management competency are rising. For instance, the Project Management Institute is looking at PMI Talent Triangle (Know the details, n.d.) incorporating technical project management as integral component to continuing credit requirements. 

Similarly, Computerworld in an independent study (Pratt, 2014) forecasts the growth of project managers as part of IT skills emphasizing project managers to exhibit both business and technical acumen to oversee large enterprise projects, growth of security and compliance skills, demand for skills in the mobile application and device management, and increase in the knowledge of big data analysis. 

So, competition is rising! How equipped are we in rising to this challenge stepping out of our comfort zone? One or two years from now if we come to read the same blog, what new skills by training and experience would we have gained?

References

Know the details (n.d.) Project Management Institute. Retrieved Jun 17, 2015, from http://www.pmi.org/certification/ccr-updates/know-the-details.aspx

Pratt, M.K. (2014, Nov 18). 10 hottest IT skills.  Retrieved June 22, 2015, from http://www.computerworld.com/article/2844020/it-careers/10-hottest-it-skills-for-2015.html

Ryals, L. (2012, July 13). How to succeed at key account management. Harvard Business Review. Retrieved May 18, 2014 from https://hbr.org/2012/07/how-to-succeed-at-key-account/#sthash.0YH3ELKn.dpuf 

Extreme Productivity: Basic principles to doing more with less

Having been in a managerial capacity as a functional manager and having led several complex programs and projects as a project manager in many industries, I have seen challenges from people on work life imbalance and from organizations for maintaining business productivity by doing more with less. However, in my experience, the percentage of the population that seek continuous growth pursuing the professional certifications or attending the networking events or conferences is slim.  

Having taught more than 150 classes through various academic institutions for adult learners, I observe learners missing classes because the academic institutional policy allows missing 20% of classes or accepting a “C” in their courses as that guarantees employer compensation. So, why should organizations invest in people that won’t invest in themselves by integrating their professional and personal life by managing time to acquire knowledge? By the same token, how could organizations allow mediocrity with a "C" and expect stellar performance? Aren't the organizations then enabling a behavior that allows individuals to be satisfied with the knowledge in their chosen fields that doesn't scale with the growth?

Remember that the growing organizations in the future will no longer be characterized by 8 to 5 jobs but will require one to be digitally connected.  So, waking up to the reality to know the demands of your profession is critical for career success. In this blog, I present three simple and powerful principles that I have found useful. I would like to call them “Extreme Productivity” unleashing people’s energy towards what the organizations are going to be looking for in the future in the midst of growing business challenges so that the value the individuals add become indispensable.

Principle #1: Look for a role and not for a job

You interview for a job and so getting a job offer is just the beginning. But, if you continuously do what you in your job, you continuously get what you get.  Will the same compensation and career challenge keep you satisfied? Even if you say, “yes,” because of personal challenges, comfort zone, or unwillingness to change, will that be good for the organizational growth that provides for you?  The organization is constantly changing to meet the market conditions and so the conditions under which one got a job can no longer be the same. When the economy shifts and the organization sees the need for sustaining growth with competitive high performers, they look for those that have already proven their multifaceted skills in the organization. It is not time for them to skim the individuals resume for past experiences because current performance paints an accurate picture. They look for those that exceeded their job responsibility and went the extra mile. These members succeed because they look around, prepare themselves early, and take on a role to make themselves useful. This is not a role given by the organization but assumed by the individuals,

Principle #2: Business Impact is measured by results and not the efforts

Sometimes, the business may demand someone to put more hours. But, from a business perspective, long hours doesn’t always mean more productivity. It may also mean that you are not doing your job efficiently or expanding the work to fill the time. If ambiguities in task, missing analysis in backlog grooming, lack of adherence to process control, or deficiency in the required knowledge domains surface to the organization, then, one is not only wasting their own productivity but also that of others. Depending on your role, the earlier principle will be extended so that you are becoming efficient by analyzing the market for latest trends and being ready, investing in a tool that the businesses use, learning about the trends being used in your practice to make you more success-friendly, or setting effective time management practices for yourself to manage personal and professional balance.  

Principle #3: Pack value in your day for the team

Everyone must have heard the saying about seeing things from others point of view. Those that really look at productivity will focus first to ensure that other’s time is not wasted. For instance, should the people copied on the email be copied, are those meetings necessary, will that person receiving the task know what to do? When the other person is actually more productive and you are not, you have just created a producer-consumer imbalance. One can avoid this imbalance and other’s dependency on them by first planning the day on those deliverables others will need. This will add time to our schedule. By putting timebox around activities on what takes less than 10 min, 15 to 30 min, more than 60 min, etc., one can start addressing these tasks efficiently. Readers are advised to an earlier post on Scrumban approach (http://agilesriram.blogspot.com/2014/10/adapting-scrumban-to-personal.html) on personal productivity.

In the end, any professional has to be productive to some extent. Everyone believes that they are definitely worth more in money and career status. If this is true, then everyone should understand that their value to the business should always exceed the economic value the business can derive. When that happens, the business will always find new ways to benefit from your talent. The only way to satisfy this equation is when one can be “extremely productive.” In today’s digitally expanding, virtually global, and multicultural distributed workforce, one’s value is constantly challenged every day that can only be addressed by a continuous improvement mentality. Are we ready to take on this challenge? 

What is a successful meeting?

Meetings are everywhere.  External meetings, internal meetings, individual meetings, group meetings,  team meetings, daily sprints, sprint reviews, retrospectives, etc.

Often, people claim a meeting is successful. There are meeting notes distributed too. But, what determines a successful meeting? I am not focusing in conducting an effective meeting on meeting etiquette but evaluating the success of a meeting.

I recall a great book on How I raised successfully from failure to success in selling that gave the tip. A successful meeting is one that has the next meeting identified.  But, wait a minute, is that it? So, if recurring meetings are set, then isn't all meetings successful?

There lies the myth. The successful meeting is the one need having clear action items identified with action owners and due dates so that the next meeting serves as a follow up. The follow through happens in between these two meetings ensuring incremental and iterative progress closing the sale, improving processes, updating progress, identifying risks, lessons learned, and removing obstacles.

If follow up meetings are proving to be action owners not providing updates or providing vague updates, then it is time to evaluate if the right owner was identified or if the owner is capable and having bandwidth. Identify escalation paths if necessary. Of course, this is true when that action item is still applicable.  If a solution is identified or closure is recommended,  then it is also important to ensure collaborative commitment and if any additional follow up would be required now or later.

Would you look at your meetings and evaluate if your meetings are successful?  What other criteria would you add outside of meeting etiquette to evaluate the outcome of a meeting?

Value of Microsoft Project Schedule in Agile Environment

One of the biggest wars in today’s software development community is the choice to use Microsoft Project Plan. In a traditional plan driven approach, the value of Microsoft project plan to know the higher level milestones, traceability of hammock, resource leveling, earned value, project and resource calendar, unit of work, impact of delay, critical chain versus critical path, network analysis, early/late start/finish, lead/lag discussions, and multi-project/program dependency are all very well understood. 

But, when you turn the attention to agile, the story shifts! Agile focuses fundamentally on self organized teams that manage their own tasks who are empowered to try different approaches. This is one of the reasons why the Scrum methodology doesn’t even mention a project manager role but only the scrum master role and product owner roles. But, in a true agile environment, or a matured scrum practice, the team is almost on an auto-pilot! The only two needs for the team are to get the clear direction and business need on what features to develop (product owner) and the support to keep deviations minimum to work on the delivery (scrum master).

But, how often are the teams so self-reliant that they think of the feature outside of their business unit as a whole on the delivery? When the team is depending on the other leaders to drive this priority, interface with the product development to provide the clear direction (business need and business impact) among other things, the project manager role emerges again.  If this need exists, then, what’s the question behind the MS Project in agile methodology?

Let us think from agility. The goal of Agility is focus on burn rate and velocity. These are good key performance indicators (KPI) in agile world in a product development setting. For instance, if we have 500 story point worth of user stories with each sprint taking up ~50 stories over 2 weeks, then, at the end of 10 iterations (discounting the hardening iteration), we expect all features to be completed. Now, say at the end of third sprint (6 weeks have gone), you are at 120 story points. We use the velocity to look for patterns in what types of commitment can be delivered by this agile team or the burn rate to project when the project can be delivered. The project managers that understand the earned value management (EVM) principles can utilize planned value, earned value, and actual cost to analyze patterns. Properly utilized, these values can come directly out of the Microsoft Project Plan even in the absence of a Project Management Information System (PMIS).

If the individual iterations are a major milestone with additional hammock activities focusing on specific user stories, then, the Microsoft Project can still be a value added tool for the project manager to use in an agile setting. In such cases, if required, the Project Manager can still limit the focus only to the user story level tracking and should the user story become a show stopper (DONE criteria not going to be met), then, it is possible to move this story to subsequent release. Using MS Project, still commitment planning can be forecasted better. Using project reports and earned value techniques, one can do similar analysis as velocity tracking and burn rate!

The tool is only a means to accomplishing the work. If simple Excel or white board can be used for Agile tracking, then, to discard such a power-loaded tool as a non-agile tool is a premature exclusion of the tool without considering its benefits.

Thoughts?

Choosing between agile versus plan driven approach

Increasingly, I keep hearing to references like the challenges and benefits to waterfall approach versus agile approach to software development. Whether these are software developers, testers, technical operations, project management, or sales & marketing professionals, the underlying theme is that software development life cycle (SDLC) has become synonymous with waterfall development but agile is not. Focusing on the core principles of agile, primarily ‘working software versus comprehensive documentation’, isn’t agile approach also developing a software? Aren’t the concepts of planning at various layers, such as daily, iteration or sprint, and release, to iteratively develop incremental software enhancements part of a life cycle for software development? So, where is the huge disconnect?

The challenge is not in the approaches but in people’s incorrect assumptions in thinking what the original SDLC proposition was and equating it to waterfall. In fact, in a recent meeting that I attended in PMI Mass chapter, many participants didn’t relate to the original author of SDLC, Winston Royce’s seminal proposition in 1970 who himself related to the challenges promoting incremental and iterative approach and the increasing involvement from project management in software development. Practitioners therefore created a non-existent and non-functional theory of waterfall embedded with the assumptions below that are challenged by an article located at http://airccse.org/journal/ijsea/papers/5614ijsea07.pdf

1.       Linear approach to software development with no feedback
2.       Big upfront requirements gathering
3.       Gathering requirements upfront saves cost
4.       Analysis follows requirements followed by design
5.       Project Management is not part of software development
6.       High degree of documentation needed before starting work
7.       Customer sees work after all the work is developed and tested
8.       Testers need not be involved early

Therefore, I will deviate from using the word, “waterfall” or “traditional” approach and recommend using the “plan driven development” using the rapid application development and fundamental project management principles. Basically, the requirements for the choice of agile or plan driven approach to software development lies in the problem being solved. 

If the challenge is to build a mission critical application controlling the amount of x-ray radiation that will be discharged by a software application, then, a plan driven approach may be a better fit because of the certainty in requirements that can be reasonably predicted and the amount risk involved in doing it incorrectly without impacting the profit margin. On the other hand, if the requirements are not certain and the complexity is not high where the functionality is possible to release in an iterative fashion such as a new mobile application or responsive website for student enrollment in a college, then, agile may be a better candidate. 

So, instead of choosing the methodology and solve the problem using the methodology, the methodology has to be chosen based on the problem solved!

Thoughts? 

Risk Managemeent: Key to Advancing into Program Management

The Project Management Institute (PMI) introduced the principles behind program management with a critical focus on maximizing benefits.  Often project management focuses on controlling scope and schedule using available work flow tools that they miss an important component of not understanding the value of the project on a larger scale.

The question to ask here is what role did the project do in increasing the value to the performing organization, customer,  and the society?  When we think about this and focus on the benefits,  we step into the next stage of ensuring the project risk is constantly monitored.  There are various tools to managing the risk but constantly keeping focus and most importantly the risk register.

Understanding these risks is a critical element to the next stage called program management.  Why? This is because the program management focuses on what an individual project can't deliver. The impact on value maximization is high in program management a if the risk is not more actively monitored.  There will be too many interproject dependencies that may impact this projects higher. So, when advancing to program management,  active risk management is critical and is a sine qua non for project management excellence.