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.

Agility outside of Software Development: A case study from a Theatrical Play

In the ever-growing need for agility in today’s business context, the principles espoused by agile Manifesto have emphasized enhanced productivity, increased customer satisfaction, and improved profitability. As noted in the previous blog entries, these principles are so entrenched from the software development practices that one of the foundational agile manifesto principles values working software over comprehensive documentation. Does this mean then that IT projects establish the glass ceiling for the agile principles?

As a member of the Chicago Tamil Sangam’s recent venture to stage a historical play, “Ponniyin Selvan” (n.d.) that was staged on May 4, 2013, we staged a historical play in the Tamil language. Centered on a course of events that took place several centuries earlier, the play presented several unique challenges that were overcome by applying some basic agile principles breaking the glass ceiling demystifying how these principles can extend outside of IT projects.  

The limelight of the play was its backdrop set in 11^th century Chola Dynasty in ancient India that weaved several challenge threads, such as the following, that needed to be collaborated to allow the finished fabric shine.

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
3. Designing several high-end artifacts that were transportable with easy assembly, such as preparing backdrops suitable for the play, two boats that moved, 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

Do any of these resonate with agile thinking that many reserve for software development projects? Let us revisit the Agile Manifesto (n.d.) and evaluate against this stage play.

Evaluation of the First Agile Manifesto Principle

The first Agile manifesto principle recommends “individuals and interactions over processes and tools.”  While following the audition, the characters were formed, several self-organized teams evolved that took on preparing specific artifacts. While marketing team operated separately from the teams that designed the costumes, prepared the ship, palanquin, backdrop, pillars, and boats, every team led communicated updates through the distribution group, on specific phone conferences, and provided incremental updates. So much was the focus on the individuals and interactions that when one member felt challenged by a work schedule, business trip, or a family emergency, there were so many willing and helpful members that came to assistance. Every team meeting ended up with a summary of the next action items following the same basic principles of what progress has happened, what progress is expected before the next meeting, and what the challenges were trying to create a win-win situation for all.

Evaluation of the Second Agile Manifesto Principle

“Working software over comprehensive documentation, “says the second Agile manifesto principle. While it is true that iterative delivery of working software makes the user experiment with the software mitigating the risk of failure, enhancing speed to market, and satisfying end user experience, can we rethink what software is? 

How many of us will travel on a bridge that is functional for the first 200 yards, but the remaining 100 yards are not yet constructed? How many of us are willing to buy a book that has the first three chapters written but the next 3 chapters are in script review? As you can see, in some cases, the end result has to be a fully functional system or product and not a partially working product. This play required that all the 50 scenes are seamlessly orchestrated and not just partially done. However, the challenges of the working individuals that made up the cast or the stage preparation crew that had overlapping members with cast, required we divide and conquer using iterative releases.

Dividing scenes of the main events in the play, the cast was informed to memorize the lines, rehearse their dialogue, and practice their songs with every weekly iteration and monthly releases over approximately 6 months rehearsing specific scenes in the sequence, making progress in preparing artifacts, checking the costumes, perfecting dance, singing, and fighting sequences of the play. There were even members invited only to provide constructive criticism using index cards presenting the user stories. For instance, one of the index cards read, “As a minister to the King, you should not use too many hand gestures to show your surprise so that the audience knows that you are always composed and thinking of the next scheme.”  Even the venue selection for the 40 individual practice days was so distributed to address geographical challenges to collocate the team to benefit from osmotic communication in that everyone could manage to attend understanding stage movement clues, voice projections under different audio systems, as well as including phone rehearsals to perfect dialogue delivery to combat.

Agile does not say “no documentation” but only “comprehensive documentation.” But the extent of required documentation is left to the individuals in the team. While there was no specific documentation created on how to assemble the palanquin or the shipwreck scenario, there was a substantial documentation created with more than 150 light clues on what area of the stage had spotlight, when there was colored light, when the light flashed to add special effects, etc.  Similarly, there was documentation on the backstage collaboration as stage, scene, and individual props moved seamlessly through worksheets identifying who moved and removed properties to the stage, where they moved, how they moved, and communication protocols to the custodian that gave the cues to the light crew sitting far from the stage.

Evaluation of the Third Agile Manifesto Principle

Agile manifesto values customer collaboration over contract negotiation. Again, real life scenarios such as these stage plays challenge the common thinking of who the customer is.  In business parlance, the customer is the one that pays for the product or service and is the reason why the company is in business. Extending the same terminology would mean the audience that came to see the show or the sponsors that supported the show were the customers. But this stage play extended the notion of customer far higher, such as the following instead of going back to “what you are supposed to have done” contracts based on the rehearsal.

1. A character is a customer when talking/interfacing with another character. So, even when the lines and body language were rehearsed, the team didn’t wait for the cue words that went missing but filled and moved on.
2. The light crew was a customer to the character on stage and when the character in the spur of the moment was on the right marked spot to deliver, the light crew attempted to refocus the light.
3. The cast themselves were customers to the stage crew that required the individual properties to be returned to them for reuse in other scenes. However, when one member missed it on stage or left it on different section of the stage, the backstage crew or the experienced cast members accommodated to keep the show moving without backlog.
4. The self-organized team was so focused on the goals that lines of who was the director/facilitator (product owner) or who was the process checker (scrum master/coach) never needed to surface. So tightly integrated the team was that they even altered their international and other business trips to attend rehearsals, participated in phone rehearsals from taxis, cabs, and hotels during their business trips. The “How may I help?” message and motivation support was so evident among the cast, crew, organizers, and volunteers.

Evaluation of the Fourth Agile Manifesto Principle

Finally, Agile recommends responding to change over following a plan. Although Agile may promote this value statement, this value proposition is emanating from common misconception of traditional project managers that think, “Plan the work and work the plan.” Fundamentally, such purist project managers are those that came to the profession accidentally thinking that working the Microsoft Project plan and being a task master is all that this Project Management means. Contrary to this belief, experienced project managers whether they follow Agile or Waterfall, know that no project goes by the tasks laid out in the work breakdown structure (WBS) of the project plan exactly. If they do, why is fast tracking and crashing approaches exist? 

1. In the stage play, several “gotcha” moments existed. A few examples include the following that emphasize how the stage and crew adopted to change instead of reacting to we should stick to the plan. People that failed to project their voice or speak closer to the microphone got directions from the crew or other supporting cast on stage using body language to direct them to speak louder.
2. Microphones that did not pick the voice adequately from where the throne was located requiring the cast to adjust their movements requiring them to “be in the act” walking closer to the microphones.
3. Using incorrect clues from the stage coordinator to the light crew that started the scene prior to the backdrop swap was completed requiring to readjust the plan as the volunteers got stuck behind and could not be readily available for the next stage transition.
4. Realigning the position of the location of the palanquin and using a different spotlight from the originally approved light sequence when the microphone needs challenged the available moving space for the cast.
5. Altering the movement of the boat movement sequence requires using the entire stage area differently.

Summary

In a nutshell, this stage play is one of the several testimonials that Agility should be in one’s mind first. Agile Manifesto might have started as guiding principles of software development, but its application is not limited to the software development projects.  It is important to understand that everything Agile is subjective and not definitive. This is sine qua non of Agile Project Management. The goal of the iterations or releases are incrementally building progress towards the end goal and the role of the product owner or scrum master is to be authentic in their leadership so that the group buys into the goal becoming a self-organized team. Then, the teams don’t just break a leg! They make history.

References

Manifesto for Agile software development (n.d.). Retrieved May 11, 2013, from http://agilemanifesto.org/

Ponniyin Selvan (n.d.) Retrieved May 13, 2013, from Wikipedia http://en.wikipedia.org/wiki/Ponniyin_Selvan