With AI here to stay, what kind of humans will autonomous systems and mechanical robots demand?

I was traveling in India where I had discussions with family and friends around the revolutionary AI landscape. I could sense a feeling of paranoia and confusion. So, I asked myself, "Imagine a future meeting where scheduling is automated, risks are predicted in real time, stakeholder sentiment is analyzed instantly, and portfolio trade-offs are simulated before anyone speaks. The dashboards are perfect." In such a utopian world, what happens when the contextual decisions are problematic and the forecasts are probabilistic. Would the robots turn to the human in the room and say, “Optimization complete. Strategic ambiguity unresolved. Ethical trade-off undefined. Human intervention required.” In my mind, that is not science fiction. That is trajectory.

AI is extraordinarily good at optimization. It can reduce noise in medical images, prevent aircraft drift through autopilot, activate ABS braking systems in milliseconds, and execute trades at speeds no human can match. It detects patterns, flags anomalies, and recommends mitigation paths. But optimization is not direction. Prediction is not purpose. Progress is not value. Algorithms can simulate ten efficient options; they cannot define which future is worth pursuing. They cannot decide what the organization should value when speed conflicts with sustainability, or profit conflicts with reputation.

In such a world, project management does not disappear—it mutates and reemerges. The coordinator of tasks becomes the architect of decisions. The status reporter becomes the framer of ambiguity. The future competency is not mastering more tools; it is mastering judgment. It is rethinking the current process and workflow rather than fall victim to an old tool. It is the ability to think and address risks much before it materializes. It is the ability to define value under uncertainty, to reconcile competing incentives, to make trade-offs that algorithms surface but cannot morally resolve. AI will compress execution layers. What remains, and expands, is decision architecture.

If Agile were written in an AI-native era, it might read differently. Not “responding to change over following a plan,” but conscious human judgment over blind automation. Not velocity metrics over everything else, but strategic intent over algorithmic efficiency. Agile was always about adaptability in complex environments. AI increases complexity. It accelerates data. It amplifies consequence. It does not eliminate the need for leadership—it sharpens it.

The uncomfortable truth is this: AI will not replace project leaders. It will expose those who never moved beyond tools. In a room full of autonomous systems, the only human invited to stay will be the one who can answer: Why are we doing this? Who benefits? What risks are we willing to accept? What future are we choosing? Leadership begins where optimization ends. And in that moment—when the machines pause and wait—the human who can think will matter more than ever.

What are your thoughts?

Has AI killed Agile and Project Management?

Is Agile dead? Do we even need project managers in an AI-driven world? 

These questions surfaced every time technology discussions around AI came up in the last 3-4 months. But before we declare the end of a profession, we must pause and examine a deeper truth: First, AI isn’t new. I was exposed to Expert Systems in 1991-92 when I designed rules based first responder system  using Prolog. If I have exposure to it almost 3 decades back, then, I am sure many others have used it in numerous ways. 

In my experience subsequently, I have found that we have trusted it for years. It already flies planes through auto-pilot systems, prevents skidding through ABS braking, and executes trades in milliseconds through algorithmic platforms. In healthcare, it enhances diagnostic images and flags clinical risks long before the human eye can detect them. Yet in every one of these domains, humans remain accountable. Why? Because context, risk, and ethics cannot be automated. Judgment cannot be outsourced.

The question to ask here is did AI eliminate pilots, drivers, traders, or physicians? No. It elevated them. It removed repetitive execution and exposed the higher-order responsibility of decision-making. The same shift is happening in project management. AI can optimize schedules, analyze risks, summarize meetings, and generate reports. But it cannot align conflicting stakeholders, resolve strategic trade-offs, or lead teams through ambiguity and resistance. It cannot sit in a room where political tension exists, apply context, and choose courage over convenience. It cannot balance short-term delivery pressures with long-term enterprise value. Project management was never about tasks; it was always about decisions.

So, Agile is not dead and neither is project management. What is dying is cargo-cult Agile and checklist-driven project management. Frameworks were never meant to replace thinking but promote it. When we confuse process compliance with leadership, we diminish the profession. The uncomfortable reality is this: AI will not replace project managers, but it will expose those who never learned to think strategically. It will surface who understands value and who only understands velocity. It will reveal who can translate uncertainty into direction and who relies solely on templates.

In Leadership Unleashed, I argue that leadership begins when we move beyond tools and into conscious choice. This moment in history is not a threat to project management; it is a clarifying force. AI optimizes execution. Humans create meaning. AI accelerates data. Leaders shape direction. In a world of increasing complexity, the need is not for fewer project leaders—it is for stronger ones. The future does not belong to those who manage tasks. It belongs to those who can think, decide, and lead when certainty is absent.

Music Performance: Reflections towards Change Management

I was very excited to attend my niece's solo music performance as part of her Music program graduation requirements. There were postures of the "Soul Quest" posted in many places outside the auditorium announcing her solo performance with QR codes for registering for the event. As I sat in front row in the theater, I reviewed the program schedule before the program began! Now, I didn't relate to the list of songs selected, the genre of emotions it invoked, and the time of the composers or the story behind those compositions. But I very much related to the multitude of things that happened as the program started with my niece performing on flute and singing in Western and Eastern styles. 

A music performance such as this program needs to be viewed from multiple angles. There must have been several discussions between the student and the teachers in selecting the songs to ensure that the songs were challenging, bringing the maximum out of the student. There must have been multiple rehearsals from the student personally and specifically staged performances before the teachers to confirm "go live" readiness. Throughout these processes are instances of change management initiatives demonstrating how people pivoted themselves. Not a single song was instantly selected, the iterative practice avoided, and approval granted. This is exactly how strategic initiatives are identified, evaluated, executed, and approved at various stages for both proactive and reactive change. 

Did this program only conclude with the song selection and practice? No! There were creative postures designed, a program title carefully selected, and the entire design and development process executed in parallel. Production of such colorful displays was further compounded by logistical complexities around where these postures can be displayed around the campus. Furthermore, there were digital media approaches to QR code generation, website for program announcements, and scheduling the campus theater for the graduation requirements. Every one of these needs had to go through many rounds of changes. I only saw the result, just like a project manager stages the outcome or the product owner approves the product increment! There were many other team members that staged this performance!

Then, the post-production processes like the post-deployment considerations or the operational excellence initiatives.  Were they left out in this music program? No! I saw people who were streaming the performance for online audience, people collecting the photographs others took for photo albums, and others, such as the teachers confirming the satisfaction and providing feedback.  There were also website updates about the program's success. 

So, the concepts of risk-based thinking towards delivering a quality performance satisfying stakeholders with the agreed upon scope within the confirmed schedule and cost considerations involving appropriate timely management of resources and procuring work to other subject matter experts were all evident! Little do people relate to the concepts of integrated change management in delivering projects such as this music performance! 

This is the reason why I keep mentioning project management principles are integral to everyone pursuing any degree so that they can excel in what they prepare themselves for! I was able to implement what I call Projecting Leaders of Tomorrow (PLOT) sowing the seeds of project excellence and also wrote the book, "Organized Common Sense". 

I believe we will see when we are ready. What do you think?

Influence of Linguistics on Project Leadership

There is a common saying that 80% of the project manager's job is communication. Frequently, many think that this communication is about working with a team and writing status reports. On the contrary, most of this communication is working with both project management stakeholders and project team members. I always say that people's non-verbal communication carries more meaning. With various remote ways of working, it is important how the verbal and non-verbal communication play together in the leading people as the concept of communication is centered on five critical elements - clarity, correctness, completeness, cohesiveness, and conciseness. 

Fortunately, I had my son who was studying linguistics in his college and sharing his thoughts on what he was learning. He mentioned to me that linguistics in a nutshell has five major elements which include phonology, morphology, syntax, semantics, and pragmatics. It was shocking to me how much language plays a pivotal role in leadership level communication and here are my connections on the influence of linguistics on project leadership. 

Phonology: This area focuses on the study of sounds implemented within a language. It differs from phonetics where abstract sounds that may or may not have any meaning associated. For instance, the letter "s" takes the sound of "z" while saying "cars". Particularly in verbal communication, this is very critical for people to understand each other as it lays the foundation for clarity. Especially when team members are from different culture or a technical communication channel is used with remote team members, clarity may be compromised, and it is important for one to actively listen to avoid the risk of assumptions of what one thought they heard. In project meetings, I often ask people to summarize what their actions items are before meeting again, and this helps me ensure that they heard me right.  

I normally say, "writing is for the eyes and speaking is for the ears." However, even with written reports, if project managers do not think through how the report will sound to others, then, they may risk misinterpretation. Therefore, taking the time to read out the reports aloud eliminates how the report may sound to someone. 

Morphology: This area focuses on the study of words within a sentence. The history of culture itself may influence how words are formed differentiating agglutinative, fusional, and polysynthetic structure. Now, just like morphology builds on phonology, I see correctness in project communication builds on clarity. When relying on bad news such as schedules delays, cost overruns, or resource challenges, the appropriate placement of words in the sentence may assuage fears. In other words, I feel that morphology addresses the "What's in it for me?" types of questions in both ,verbal and non-verbal communication.   

Syntax: This area focuses on the study of sentence formation with words and punctuation. Using an example of a syntax tree, the different parts of the sentence are constructed. I recalled how lexical analysis was integral in computer science in assemblers, interpreters, and finally compiler design in computer science. To me, this syntax builds on morphology for larger level decision-making. For instance, the connections of various elements in project charter, the strategic connections between project charter and the business case, and the connections between business requirements document and functional specifications document are all examples of syntax analysis required for "completeness" in communication through the multiple artifacts. 

Semantics: This area focuses on the study of meaning. Since meaning is interpreted by people, culture comes into play. This culture may not necessarily be limited to geographical cultures (e.g.: Hofstede Dimensions) but also role specific communication. For instance, the type of meaning people associated with words among various people. A business analyst sees "value" to be with customer whereas the same "value" relates to technical stability by a systems engineer. We can see how project delivery members mix up words such as "iteration" from Agile and "sprint" from Scrum. The semantics elements therefore play a critical role in push, pull, and interactive communications because of their use either for dissemination of information (broadcasting) or for alternative generation (brainstorming) for problem solving or decision-making, the concept of semantics brings "cohesiveness" in communication. So, semantics must be considered excessively by project managers to lead others.

Pragmatics: This area is the study of the social aspects of language semantics. All the essential above elements are codified in informal or formal language registers and take on additional focus especially with many areas such as the dialect, age groups, respect, etc. For instance, generational considerations may have to be incorporated in both verbal and non-verbal communication differentiated in informal and formal communication. When conflict resolutions come up, groupthink behaviors may have to be addressed in favor of smoothing and collaboration approaches. During all these interactions, pragmatics avoids unnecessary confusions by focusing on "conciseness."

Interesting to see how much the discipline of leadership is critical for project leadership! What do you see? 

Global Leadership and Project Management

I am currently in Paris, France. As I was strolling through as part of my regular walks, I was particularly struck by the number of construction initiatives and establishments with several technology companies, hotels, fast food chains, fashion accessory companies, etc. I could not help starting to think of all the types of projects and leadership involved in such projects establishing these companies across the globe. I saw the same establishments in Vietnam, India, and the US.

While still upholding global branding, these companies and establishments need to cater to local markets leveraging funding options specifically relevant, yield to local laws and regulations, and show demonstrated leadership in each of these projects. It was at this time that I also saw announcements about tariffs from the US on steel and aluminum. These external influences emphasize the need to understand PESTLEED approaches to analyzing SWOT further.

As project and program managers start working on global initiatives introducing change, it is pivotal to understand that global leadership is beyond just understanding cultural diversity. Global leadership must extend to working in a volatile, uncertain, complex and ambiguous (VUCA) world where project and program managers need to understand all the ten knowledge areas of project management but also go deeper in understanding the program management domain in strategic alignment and the benefit delivery lifecycle.

This generation of focus on value maximization is the foundation of glolocalization, i.e. global leadership with a localization that much beyond just culture and diversity.  In other words, “think global, act local” philosophy integrating leadership and management needs to be woven into grooming upcoming talent as well as existing talent.  Several strategies have failed when people didn’t think globally factoring cultural conditioning.  Let us learn from these lessons and avoid repeating the same failures. As I always say, “Fail forward!” 

Executives need to understand Program & Project Management

As a firm believer in continuous improvement, I have always been monitoring the external environment to find new trends and equip myself with this knowledge. One of these interests was understanding more about Program and Portfolio Management. Although I had executed successfully a few program initiatives and been part of the strategic portfolio management, my interest to pursue Program Management certification became strong with an announcement of Project Management Institute on Program Management Improvement and Accountability Act (President Barack Obama Signs the Program Management Improvement and Accountability Act, 2016). It was then I made a commitment to pursue PgMP certification which I passed successfully this month.

During the pursuit of this journey, I felt the inexorable gap in people in strategic leadership positions not truly understand the value of Project Management - let alone the program management. Many viewed program management that focuses on benefits delivery and benefits sustenance the same as project management that focuses on unique product or result. Mark Langley, the CEO of Project Management Institute, claimed how the lack of understanding project management culture among chief executives such CFO leads to money being wasted on projects failing to meet their strategic objectives or not having the appropriate structure for strong project management culture is a recipe for organizational failure (Langley, 2015).

If the culture of project management that touches on scope, schedule, cost, quality, risk, stakeholder, procurement, human resources, communication, and integration can't address servicing customers, delivering good quality products, and retaining talent, what other professional discipline can be part of the operational excellence that touches on all areas of middle management to address customers, products, and people? It is no wonder Ireland (2006) claimed almost ten years back why executive management needs more project management skills than technical skills or delegation skills to effectively lead the organization. Several years later, Gale (2012) reports on a few organizations as a case study to support the case for increasing role of project management.

As I went through the program management framework that lays the foundation for strategic benefits, coordinated planning, complex interdependencies, deliverable integration and optimized pacing, the role of program management in benefit delivery was conspicuous. The focus of programs not only dealt with incremental benefits delivered through component projects but also on the consolidated benefits through structured governance to resolve quin constraints aligning the program efforts to organizational direction, identifying and responding proactively to risks across the projects and into operations, and leading, coordinating and collaborating multiple work streams. When such a program level leadership role is not identified to go through a program delivery framework, lots of productivity loss becomes transparent to the organizations.

Organizations today are changing dramatically. The need to respond to changes rapidly is an essential fabric to maintaining market share amidst the political, economic, societal, technical, legal, environmental, ethnic, and demographic changes and competitive edge. So, the need for executives to understand the project, program, and portfolio management is not a luxury but a necessity.


References

Gale, S.F. (2012). The case for project management. PMI Executive Guide. Retrieved August 31, 2017, from https://www.pmi.org/-/media/pmi/documents/public/pdf/publications/pmi-executive-guide.pdf

Irelend, L. (2006). Executive Management's role in project management. International Project Management Association. Retrieved August 31, 2017, from http://www.ipma-usa.org/articles/ExecRoles.pdf

Langley, M.A. (2015, August 6). 3 Things CFOs Should Know about Project Management. CFO.com. Retrieved August 31, 2017, from http://ww2.cfo.com/business-planning/2015/08/3-things-cfos-know-project-management/

President Barack Obama Signs the Program Management Improvement and Accountability Act (2016, December). Project Management Institute. Retrieved August 31, 2017, from https://www.pmi.org/about/press-media/press-releases/president-barack-obama-signs-the-program-management-improvement-and-accountability-act 

RACI Errors: Impact on Project Integration Management

In developing a good project integration management, it is critical to understand the role of responsibility assignment matrix. The goal of project management primarily is to deliver results through other people. This involves a clear role and responsibility for every work package or function that will play a critical role in project delivery. One such responsibility assignment matrix is the RACI.

I have often seen RACI filled incorrectly and have blogged (Rajagopalan, 2014). However, I would like to discuss the following two issues further as they have a relationship on other aspects of project management knowledge areas.

1.  Mixed roles with "A" and "R": When a person or function is marked with both these roles, then this may introduce the risk of project schedule slip. If the individual responsible for doing the function fails to perform, then typically the accountable person will monitor the slip and ensure that the work is getting done. Alternatively, if the work is not completed satisfactorily, the accountable person shares the onus to check on the quality and the cost of poor delivery. However, if the "R" person also is the "A" person, then the latter will not put any pressure on the former because they are both the same. This impacts risk, time, cost, and quality. Similar challenges can be seen with "R" and "C" or "I" overlap.

2. Too may "A"s: If two people are accountable, then there are two types of problems. The first is the blindness game each "A" role plays thinking that the other role will keep an eye in ensuring the task is completed. When this task fails to be done, the blindness game becomes the blame game reasoning with the "I thought you would have done it." This introduces project delays that may impact time and introduces challenges with procurement. The second issue is the team gets conflicting directions from each "A" person leaving the team to get caught between power plays. The resulting team dynamics may lead to HR and stakeholder challenges.  Furthermore, these issues may impact other areas of project management.

There are several symptoms that a proper RACI may resolve for the project manager to proactively address. But unless a project manager has a good understanding of RACI, the symptoms deteriorate leading to major problems requiring surgical intervention from executive management.  The project manager can avoid these strategically by planning to succeed with end in mind. 

References

Rajagopalan, S. (2014). RACI: Errors and Implications in building the right one. https://agilesriram.blogspot.com/2014/07/raci-errors-and-implications-in.html

Product Management versus Project Management

As I was concluding a capstone class on project management, there was a question from a few students on whether there is any scope of career growth for project management as a profession with the increased focus on agile principles. Questioning further, the root cause of this concern was the fact that agile approaches, such as Scrum, do not call for a project manager role and the focus is only on product management. In a brief attempt to address these ongoing confusions thinking product and project management are mutually exclusive disciplines with product management slaying the project management field, I explain here the ongoing need for the symbiotic relationship between these two disciplines.

The experts in the field agree that a project is a temporary endeavor to create a unique product, service, or result. Inherent in this definition lies an inexorable relationship between these two disciplines. The project management is a set of processes, tools, and techniques that is indispensable to bring a product into the market. Therefore, a product cannot be delivered without the strategic focus on execution that only the discipline of the project management can provide through the phases of initiation, planning, execution, control and closure.

Does that mean product management is a subset of project management? Definitely not! I say this with so much certainty because project management is temporary in nature unlike product management that has a longer time horizon. Consider bringing to market a new hybrid car that runs purely on water! The product management may focus on generating the ideas, evaluating the alternatives, assessing the feasibility, and creating a business case at the beginning. Hence, the product management will have to think of a strategic road map of scouting the external and internal environments by applying the Porter's 5-force model. This 5-force model involves the availability of substitute products, bargaining power of the buyers (price consciousness of buyers), bargaining power of suppliers, those that supply goods), rivalry among the established firms, and the threat of new entrants.

Finally, after all the commercial, technical, and operational considerations have been addressed, the business case from product management becomes the starting point for project management to intervene initiating the project charter putting together the scope statement followed by the work breakdown structure and the sequence of activities that need to happen for bringing the hybrid car to the market. Now, if project managers only become tactical, then, they lose the ability to question the inherent assumptions to avoid a strategic failure. This fundamental need is why the businesses label the areas they need to work on as "capital project selection." The "capital" adjective here is a strategic decision making to ensure that the investment of funds, time, and resources are used to maximize the organizational value.

It is therefore evident that the product management defines what and where we should be doing while the project management tells us when and how we could be getting there. But the project management is like the Phoenix bird that ceases to exist as soon as that need of product management through the project management has been served. However, as the product management continues its journey through its lifecycle of development, growth, maturity, and retirement, there will be additional needs that will come up and the Phoenix bird revives itself again. Therefore, the good product managers will know that they need strategic project managers as brainstorming partners and similarly the good project managers will have more strategic thinking beyond the organizational context to support the product managers. Each profession, as a result, has a symbiotic relationship.

What do you think? Please respond with your comments.

Project Management is a life skill

In one of the blog entries earlier, we had discussed the need for mindset change for project management. If we truly understand the principles of project management, we can appreciate how relevant this skillset is in managing one’s own life. This discipline is perhaps the only pervasive profession that has tight coupling as a life skill.

For instance, let us evaluate how the ten core knowledge areas espoused by the Project Management Institute are integrated with the circle of life using an example of planning a vacation. These areas involve managing time, cost, scope, integration, procurement, human resources, communication, risk, quality, and stakeholder. When we are planning to go on a vacation with our family, we plan how many days we can go on a vacation based on the number of days available from our work. Depending upon whether spouse and children are joining, we engage with additional stakeholders at School and integrate our activities around time. Every activity that we plan during the vacation is scoped out by the amount we can spend on the vacation and the risk tolerance to adventures we can engage in. 

We also engage with multiple types of vendors to book our travel and hotel arrangements. We continue to engage several people in evaluating the vacation spots and activities that we can do to ensure that the value of the time and money spent is of acceptable quality. Finally, we manage several other activities such as taking care of bill payments, watering the plants, taking care of pets, preparing transition plans at work by communicating with the involved stakeholders. Now, is everyone traveling on vacation a project manager? However, as you can clearly see, these skills are still essential outside of the project management profession. Is there any reason why we shouldn't call these project management skills critical life skills? 

The significance of project management principles outside of the project management profession is not new. On May 4, 2013, the Chicago Tamil Sangam staged a historical play, “Ponniyin Selvan” in the regional Tamil language. Centered on a course of events that took place around the 11^th century Chola Dynasty in ancient India, staging the play presented several unique challenges that were overcome by applying some basic project management principles. Each of the following activities were considered interdependent projects that was coordinated as a large program with several milestones, conference calls, demos, rehearsals, and marketing demystifying how these life skills were executed by many non-project professionals. 

As a result, the principles of agility can apply much beyond software development (Rajagopalan, 2013). In fact, the Agile Manifesto shouldn't have even said "Working Software over Comprehensive Documentation" limiting agility to software development. It shows the lack of diversity in the Agile Manifesto contributors from the application of agility beyond their background domain knowledge. For instance, imagine if we had said "Working Products over Comprehensive Documentation". The product can be replaced by any benefit that could be translated into value!

1.    Preparing rich costumes, jewelry, and artifacts to differentiate the Emperor, the Kings, Queens, Ministers, and workers that required coordinated efforts to identify the needs among the actors, procure items necessary from India, and get them shipped from India.

2.    Identifying the needs of the auditorium based on the play requirements, distance, transportability and audience needs including law and order maintenance.

3.    Designing several high-end artifacts that were transportable with easy assembly, such as preparing backdrops suitable for the play, two boats that moved on the state, a ship with effects to display shipwreck, a palanquin as an entry point for the character, and pillars establishing the authenticity of the 11^th century.

4.    Rehearsing the play spread over five volumes perfecting dialogue delivery, enunciation of words, clarity of voice projection, light cues for various spots on the stage differentiating progress of characters and events through various backgrounds, preparation and coordination of musical clues, singing and dance choreograph appropriate to the characters, body language clues collaboration such as when to pass the message card or the crown, how various characters should see during critical scenes, 3 full length exams including a daylong marathon practice sessions.

5.    Advertisement and marketing efforts on social media, press, and soliciting appreciation from prominent external representatives, such as the President of India, increasing the reach.

6.    Subsequent preparation for the main event date with food and supply for the crew, makeup needs, and transportation of goods, stage preparation, and coordination of light clues with the auditorium crew that didn’t speak the regional language, backstage line up of cast during the play informing what scene is in progress.

7.    Addressing challenges for audience lineup, food distribution, parking lot and law & order challenges on the day of the event.

As an extension to the change in mindset on what the misconceptions around project management, let us arise to learn the tools and techniques recommended by this discipline so that we can enhance our own quality of life as well as the voluntary community efforts several of us support. In the next session, we will discuss further on a unique framework from my post-doctoral pursuit of how we can focus on what we need to learn. 

What are your thoughts? Please share and spread the knowledge.

References: 

Rajagopalan, S. (2013). Agility outside of software development: A case study from a theatrical play. https://agilesriram.blogspot.com/2013/05/agility-outside-of-software-development.html

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 well known that a successful definition of the problem means we have the problem half solved.

Considering 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 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?
• Is both the client facing person and the project manager on the same team as the expert?
• Were any attempts made to negotiate for an acceptable best alternative?
• 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?

Project is a verb in Project Management

Project Management is one profession that has grown from practice. While education and some experiences were the only prerequisites for one to be considered a project manager, the surge of accidental project managers has 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 defines the competencies expected in a project manager.

• P - Passion for 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 - Trustworthy to transform people’s career. This completes the cycle of project where one’s passion for people makes them servant leaders.

Choosing between agile versus plan driven approach

Increasingly, I keep hearing 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 my scholarly publication (Rajagopalan, 2014). 

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 solving the problem using the methodology, the methodology must be chosen based on the problem solved!

Thoughts? 

References

Rajagopalan, S. (2014). Review of the myths on original software development model. International Journal of Software Engineering & Applications, 5(16), 103-111. Retrieved from http://airccse.org/journal/ijsea/papers/5614ijsea07.pdf

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 workflow 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 play 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 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. If the risk is not more actively monitored, there will be too many interproject dependencies that may impact these projects more. So, when advancing to program management, active risk management is critical and is a sine qua non for project management excellence.

Furthermore, risk management is at the epicenter of value management. While project management focuses on delivering products, services, or results, program management focuses on benefits delivery. Since the extent to which businesses and customers derive the benefits describes value, in delivering products or benefits, lean principles advocate flow by avoiding delays. As the day passes, value should be incrementally built. Even when the project may not have been launched and the anticipated benefits realized, we monitor the progression of work so that projects don’t slip, tasks don’t wait, or decisions are not delayed. From the discipline of earned value management, this is why we even look at the 'value' earned in a snapshot in time!

One thing that I was very proud of in my current workplace is that there was an all-hands meeting from all account managers, project managers, development representatives, script writers, creative artists, testing team, and operational team members. The project management team was responsible for holding this meeting on a weekly basis at a predetermined time on Tuesday with remote representatives and traveling account managers on the telephone bridge. This meeting served as the 'synchronization' meeting where everyone synched on raising their part of the risks and issues as well as the impact to the project, client, and the revenue to be recognized by the company! Everyone was willing to pivot accordingly because there is only limited capacity of time/resources available! 

Now, will synchronization alone contribute to seamless value flow? Let us see. While each team had their independent meetings to discuss what was in their backlog. The creative team had a weekly meeting to discuss department specific projects and client specific projects. The development team had its daily standup with the onshore and offsite engineers. The account management team had their own retreats (that's the name they used) to discuss client and deal with specific issues. So, each team had its own cadence on when to meet, what to discuss, etc. 

Therefore, although both cadence and synchronization were present, some of the challenges that we repeatedly discussed in the synchronization meeting emphasized that there were other forces at play impeding value flow. The most common things that came up are the following:

• Lack of Visibility: There was no combined backlog or a visible backlog of what happened inside every team. If a team discussed a new project that is slowing work for other initiatives, that was a surprise!
• Multitasking: Some teams had a single person working on multiple things. For example, a creative artist was assigned to more than project extending the amount of time taken for both projects. This diffused the need for more resources required to meet the increasing demand. Delays in projects slowed value delivery and revenue recognition. 
• Size of the Work Commitments: Some work commitments made were large. There was not enough questioning of the estimates to the commitments made. Sometimes, there was only one single person available to do such work introducing the key candidate risk. 
• Complicated Workflow: Some review and approval steps in the process were unnecessary, increasing the amount of time taken for people to wait on those steps. The time zone and the manual processes fueled this fire further. 

I believe value is proportional to the waste reduced (value = f (waste reduced)). Some of these value blocking forces causing waste are common in many companies. We tried to address it by having cross-functional representatives in other cadence meetings, consolidating tools on a single ALM tool, introducing role-plays with team members rotating with others, and reviewing steps in the workflow to minimally required to ensure compliance. What other techniques could have worked? Please share.

Cost of Quality: The increasing value of acceptance testing besides automated testing

There are two prevalent themes in software development in the corporate world: “Zero Quality Errors” and “Doing more with less”. The dominance of both these concepts has critical importance in their implementation.

1. Eliminating the number of testers increases the level of effort on the remaining testers to check every test case as thoroughly as possible introducing errors. The testers that have the accountability to ensure that they don’t release features without signing off are under pressure compromising the quality.
2. Keeping more testing resources also does not guarantee zero quality when the testers don’t keep up with the current trends. The number of communication lines increase with the QA manager, test lead, offshore test coordinators, and testers. This functional hierarchy removes the testers from the developers defeating the self-organized team requirements. Consequently, the requirements dilute and morph leading to management problems as the customer complaints increase, time to market slips, and product reviews decline.

The logical solution is “Automated testing” making the system do testing detecting more defects at earlier points in the development life cycle as well as continuously testing deployed code for production bugs. The solution is logical and practical as it accomplishes doing more work with fewer resources consistently, continuously, and almost effortlessly compared to the needs to have a human present to manually test. 

Does that mean automated testing is a perfect solution where we can enable computer assisted software tools (CAST) to as many testers as possible? The agile engineering practices recommend automated testing but also emphasize acceptance testing where the business owners also are involved in testing. But how far are our people in client-facing roles like product managers, project managers, program managers, and account managers increasing their knowledge of the business domain and related technical tools to test the releases?  How much is the management attuned to this fact?

1. The client facing roles mentioned earlier may question why they should do this testing that the testing department is accountable for? It is a valid question but when buying a car why do you want a test run? Why do we do our own walk-through inspection of the home instead of leaving the work completely to the home inspector? We do this because we are equally responsible for the outcome. As these roles face the client who can claim escaped defects or the features for enhancement, how could these responsibilities have downplayed?
2. Let us face another argument of being busy doing this acceptance testing! When automation is introduced, the developers and testers must write additional lines of code and test scripts to ensure that the automation works according to the 3A principle (Arrange what needs to be tested, Act by developing code to test, and assert by evaluating the outcome against the expected).  This needs more time commitment and learning additional tools where the developers and testers need to immerse themselves to evolve to the expectations of today’s workforce. So, if one group that is busy can increase their competencies, why should not these client facing roles elevate their skill-competency gap instead of claiming the busy life?
3. Another important angle to consider is new functional non-customer value add requirement but a business value-add requirement, such as the heartbeat monitors, exception log checks, and time taken to test checks as part of the automation efforts. None of these requirements are part of the actual product feature a customer sees but are additional scope of work that the business mandates on the execution wings to design, develop, and test. When these are baked into the level of effort or timeline and when customer asks to reduce the time to market, the client facing roles cripple the quality by not standing up for best practices.

If quality were a coin, automation testing and acceptance testing are its two sides. Efforts spent only on one side won’t have the completely desired economic impact.  Automation is a shift in the way the code is developed, tested, deployed, and monitored requiring refined skills. It is an important element in reducing the cost of quality but so is the acceptance testing that requires additional skills. If we fail to recognize and implement both these effectively, then, the efforts spent in automation may be offset by escaped defects due to lack of acceptance testing.  A new breed of client facing roles is therefore on the rise and the management needs to focus on both the automation testing along with acceptance testing. 

Differences between Kanban and Scrum

Recently when attending the 5-day Agile 2014 conference in Orlando, Florida, I had an opportunity to discuss various agile implementations. Some of the discussions centered on selecting the right type of agile methodology to consider for software implementations from extremely regulated medical devices industry and government projects where Scrum was considered prevalent. Then, when I found in my network of work and friends, there were questions that revolved around using Kanban because Scrum wasn’t working.

Having used Kanban and Scrum, I wondered why there is still confusion among the early adopters of Agile and why Kanban would be considered as a substitute for Scrum. Unclear understanding of agile concepts may lead to failure just like how people created a non-existent theory of waterfall based on inaccurate practices (Rajagopalan, 2014). So, I focus below on a comparative study of the basic premises between Kanban and Scrum. I hope this article captures the essence of these approaches demystifying the confusion and helping in the selection of the right approach for the challenge at hand.

One of the primary differences is that Kanban is a method that can be used independently or along with other approaches like Scrum. This is why we even have derivative approaches like the Scrumban.

Concept	Kanban	Scrum
Management focus	Maximize resource usage avoiding delay and enhancing accountability to support flow.	Consistent delivery in the cadence of execution, as the features in the product backlog is delivered.
Operating rhythm	No time-boxed iterative development exists.	Time-boxed iterative development – usually two to four weeks.
Granularity of work	Focus is at the task level for which the scope of work is generally known.	Focus is at the user story level for which the scope may not always be known, requiring it to be estimated before tasks can be identified and taken up by the team.
Agile Estimation & Planning	Estimation is generally not done. There is little to no ambiguity on the task that any member of that team should be able to take on the next available task and execute it.	User stories are estimated. Then, they are prioritized, and risk adjusted so that these are included in the release and iteration planning.
Value Delivery	Every task completion may not necessarily add minimally marketable value to the customer. Task identification and dependency require careful coordination.	The cadence of release and iteration planning focuses on adding minimally marketable feature through the scrum cycle. The self-organized team determines the task identification and dependency.
Progress Tracking	Flow of items throughout the lifecycle limiting delay. This is why the focus is on limiting “Work in progress (WIP)” is promoted through “Don’t Repeat Yourself (DRY)” focuses on maximizing work not done	Focus is on tracking the velocity measuring the user stories done and delivered to customer in an iteration
Utility value	Better for managing workload and resource management. E.g.: How many projects of different combinations can be taken up by a project?	Better for managing products, programs, and projects.
Thoughts to consider in software development	Use of Kanban for software development may impede flow if all the units don’t consume the work produced at the same speed. Therefore, additional processes must be in place to support Kanban. E.g.: QA not having capacity to test code developed by engineering team. If QA’s capacity comes from the fact that more defects are found in the build, then, more granularity in tasks to ensure proper code review, unit testing, and documentation are processes that the organizations must have in place.	Implementing Scrum doesn’t mean the ability to write user stories and avoiding documentation completely! This requires a management shift to ensure critical thinking on the product, program, and projects. If iterative delivery is not understood by the management and client, then, Scrum is not an option to consider.

In summary, Kanban and Scrum are both light-weight approaches, but the operating philosophy is different. Scrum focuses on the work being delivered to customers through multiple iterative deliveries of minimally marketable value by assembling a cross-functional, skilled, and self-organizing team or team of teams. Kanban, on the other hand, is a pull-based system and focuses on the visualized workflow where flow is maximized by limiting what gets worked on by the team. Although both approaches require prioritization in the items represented in the backlog, Scrum team can’t pull an item outside of the Sprint backlog when they have capacity. Kanban team can pull the next priority item from the backlog. So, depending on what product, service, or result the team is delivering, or the benefit being sustained in operations, Scrum, Kanban or Scrumban may work. Select the right tool for the right job!

Thoughts?

Enhancing Productivity

Today’s corporate world is characterized by increasing pressure to deliver more but of uncompromising quality at a better rate. Increasing efficiency of production using just in time production is not new followed by build-on-demand concepts where value add to a customer takes on the focus in agile software development.  Regardless of the industry and product built, how can today’s projects still deliver increasing value maintaining the strict adherence to quality?

The fundamentals of iron-triangle of quality by managing the levers of scope, schedule and cost is still present but timelines are requested sometimes without clear scope, schedule then is accelerated to meet customer’s demands, and still cost is allowed not to increase both in operational and capital expenses. Keeping the focus on operational expenses, the question often evolves: How to measure and enhance productivity?

I believe the basics of productivity are in clarity, duration, and customer management. For projects that have somewhat known scope, such as extending a product installation in a different client site that can leverage past lessons learned, the clarity is not an issue. But, for new initiatives, the product scope may be evolving, and this is where delivering to what is known using agile concepts may be beneficial.

But the basics of duration management are differentiating the type of hours that go into the project. Productivity losses come from two types of hours that derail the project because productive time is taken out of the duration because the “right” people are not on the “right” job at the “right” time.  These types of hours are as follows.

1. Non-Project Hours – Delivering no value to project but time for internal process enhances, functional department meetings, training, company meetings
2. Non-Productive Hours – Time lost due to ambiguous work, lost work requests, unnecessary meetings, doing other’s work, assumption about roles, lack of accountability, etc.

The basics of project management differentiate duration from estimate in addressing the first component which is often misunderstood. Agile concepts address these by using ideal time to ensure that the story points are properly incorporating enough time to develop value. But the second part is the difficult one that the management needs to spend additional time in ensuring that properly motivated and trained people are present, tools are sufficient, and collaboration is cohesive.

In terms of the customer management (remember client is both internal and external), the productivity goal should be to maximize hours charged to a project, establish a baseline for products of similar nature and use appropriate time entry/approval methods to evaluate against the baseline, forecast and promote predictability of workload and hold everyone accountable. The principles of stakeholder management are no wonder a newly added separate dimension in the Project Management Book of Knowledge (2013).

In summary, productivity measure is rooted in people, process, and tools that allow the job to be defined in adequate detail, breakdown accountability by increasing collocation, introduce distribution tools for effective collaboration, lead instead of managing the clients more effectively, and use process as a key vehicle to integrate the whole in a virtual distributed environment.

Thoughts? 

References

Project Management Institute (2013). Project Management Book of Knowledge. Fifth Edition. New Town Square, PA: Project Management Institute.

Need for Statistics for Project Managers

“I am not good at statistics. So, I am not cut out to be a project manager,” said a potential PMP aspirant after attending a PMP boot camp. My heart slipped a few beats to regain my stand and found out from this potential PMP candidate managing dates in the timeline, evaluating project slips, looking at contracts for vendor management, and monitoring metrics demand high mathematical skills for a project manager to be successful.

Let us look at the core knowledge areas in Project Management Book of Knowledge that includes management of scope, time, cost, risk, quality, communication, procurement, integration, human resources, and stake holders. Most of the process groups within each one of these domain knowledge areas involve qualitative thinking, leadership, organization, negotiation, and people management skills. For instance, the project manager that asks for what percentage of a task is completed draws attention in today’s context because even if 80% of the task is completed, the remaining 20% of the task can take more time to complete. Understanding people’s commitments and winning consensus towards project goals is central to task completion, and therefore eventually project success.

Even when we focus on metrics, such as cost or schedule variance, schedule or cost performance index, or other earned value metrics like planned value and actual value, estimate at completion, etc., the mathematical formulas involve simple subtraction and proportions. Do these mean they are statistics? How much difficulty exists in comparing the milestone slips from baseline to actual? Simple office automation tools like Microsoft Excel can accomplish these computations effectively and if the proper use of Microsoft Project is used, then these metrics can be easily computed.

Now, let us turn our attention to Agile. Technically, project plans are not preferred in this setting as the teams are dedicated and self-managed. The project manager is not managing the tasks. Focus shifts more towards product features, benefits to business, etc. Neither the estimate gathering process like planning poker or metric computation like velocity planning is quantitative. Besides, good application lifecycle management (ALM) tools like SpiraTeam, Version One, or Rally allow such metric gathering more effectively. So, where are statistics coming in to play as a core skill of a project manager?

Let us not leave capital project selection where the management using steering or governing committee must make a conscious selection of products to invest or consume resources to work on. These ranking of projects use basic mathematical concepts like payback period, net present value, or internal rate of return. None of these methods call for detailed analysis of variance, kurtosis, skewness, or involve factor analysis.

Besides, if simple observations of ratio and proportion or central tendency analysis using mean, mode, or median indicate statistical expertise, then, how much time are a Project Manager spending on such analysis compared to communicating and managing stakeholder expectations to ensure project success? It is true that interpreting such data for preventive and corrective actions as well as escalating risks and issues require some understanding of these thoughts. So, is statistics a core skill for PMP aspirants? Readers, what do you think?

Agile Success Seed: Product Owner’s role to manage risk

One of the common themes that often percolate as organizations transition to agile approaches has been the identification of who owns the product vision. In a traditional project, often as recommended by Project Management Institute, effective project managers control the risk related processes as they own the project's scope. With agile thinking, this burden of responsibility shifts to the product owner because maintaining the product roadmap (starting with the vision) and grooming the product backlog is the product owner’s responsibility.

But one of the common pitfalls that I believe is a root cause for agile project's implementation failure is the inadequate orientation of the product owner to be available to do this role. Product backlog grooming is no longer entry of information in a tool or grid but is a systematic approach to handling prioritization of events that could positively or negatively impact the features in a product backlog with an unforgiving focus on business value. When products are designed and developed in vacuum without thinking through how it will be rolled out, this intense focus on business value is no longer on the radar. Depending upon who plays the product owner role (Business Analyst, Project Manager, Project Manager, Functional Manager, etc.), the nature of identifying risks morphs so much that agile projects stumble during its build (any of the releases/sprint) or as they hit the road for clients to consume. So, what are the key steps for a product owner to monitor as they maintain/groom the product backlog?

The first step to monitor the horizon for events can derail the project. The team can give some input, but the onus lies with the product owner to do the SWOT analysis and assess if the risks (Hilson, 2001) impact any of the features. This assessment could reveal new features to the backlog even on completed features. Care must be taken not to become too granular in not getting carried away for risks that impact user stories or tasks to be completed. For instance, instead of focusing on resource availability in a shared environment that may impact sprint velocity, focus should be towards eliminating risks that address training for the team to embrace agile, tools and processes to streamline communication, etc. The hardening iteration (Iteration 0) is a good place to begin this risk assessment.

When avoidance or withdrawing is not an option, the second step is to transfer the risk. Often, people skip this step and move on to mitigation right away. Sometimes, mitigation may not be the best strategy because of the detailed subject matter expertise involved, or the time commitments to deliver earlier. For example, consider the translation of voice and email notifications in foreign languages or consolidating data centers distributed globally that require specialized skills. In such cases, the third step is transferring the risk to another more informed party (e.g.: outsourcing, consultant, application service provider). 

Sometimes, transfer may not be the option leaving us to the third step of mitigation. Furthermore, even when transfer to a 3rd party is in place, steps need to be taken to mitigate the possibilities of something going wrong.  This mitigation step involves, for instance, enforcing best practice guidelines, using service level agreements, having standard operating procedures, contract review guidelines, or leveraging feedback loops to optimize the business processes, incorporate preventive actions, or take corrective actions. The sprint retrospectives are a good area for product owner that has assumed the role but not having formal product ideation training within the specific industry. This need necessitates that the product owner becomes available for the team to gather this information first-hand through osmotic communication. The more the product owner becomes unreachable, the more this risk assessment loses accountability leading to failure.

Many best practices from the mitigation strategy will still apply here, but the focus shifts more on the other responsible party, like transferring risk to an insurance carrier. For a product owner to get familiar with these trends, a more conscientious awareness of domain knowledge skills and business knowledge skills become necessary so that the product owner can make a case for the return on investment of continuing to build the product.

When none of the strategies work, the final and fourth strategy is the acceptance strategy. It is in this stage the team absorbs the risk. Yet, the product owner and the team negotiate on how much velocity can be consumed in that iteration if the probability of risk to materialize is higher. Perhaps that iteration should have more “Should do” and “Could do” features from product backlog and not do any “Must do” features. Like business continuity planning or disaster recovery planning, the product can proactively select the right mix of user stories for the team to implement to show progress but protect the team by managing risks.

All these discussions are still focusing on the fact that risk represents a threat. It is possible that risks also represent opportunities. If it is a positive risk, then, the opposite strategies apply. Instead of avoid, one exploits the possibility. Teams enhance the probabilities of opportunities rather than mitigate the likelihood of a threat materializing. Organizations prefer to share ideas to collaboratively benefit rather than transfer responsibility. 

In summary, the risk management principles are no longer just a project manager’s toolkit and are the seeds of success for successful agile implementation. They equally extend to a product owner because in an agile world, quality is non-negotiable as the product is operationalized and introduced to the customers. In fact, this is the reason why the product backlog is called risk adjusted prioritized product backlog. To embrace change, risk should also be equally invited and managed proactively. Having a product owner available to ramp up to speed with the domain knowledge of the operating business and understand the project risk management principles is inevitable for maintaining the product backlog, without which the product cannot be sustained. 

References

Hillson, D. (2001). Effective strategies for exploiting opportunities. Paper presented at Project Management Institute Annual Seminars & Symposium, Nashville, TN. Newtown Square, PA: Project Management Institute.