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?

Evolution and Revolution of Change Management

As I was in the last training session with my current project management professional training batch, I was discussing how change sticks within an organization. As I differentiate governance processes for managing changes within the context of a project or program related to introducing large scale change management, questions emerged on what is change management. Some members who had attended a 2-day Scrum Master class mentioned about ADKAR and another management learner discussed about Kotter's change management. 

And both these change management frameworks are good and relevant. While both ADKAR and Kotter's change management frameworks are powerful and relevant in today's organizational environment, the knowledge of the change management evolution can help understand how change is perceived, planned for, and implemented. One can then appreciate the richness of history in connections with both the influence and impact of change management framework. 

Dr. Sriram Rajagopalan's Synthesis of Change Management Framework Timeline

Year	Model Name	Brief Explanation
~1947	Kurt Lewin 3-Stage	Kurt Lewin (1947) used the sociology and social science  concepts to introduce a 3-stage process. These 3-stages are "unfreeze, change, and refreeze." Before change can take place, a period must be allowed where no changes are allowed, and change is internalized.  Then change takes place as employees show involvement. This leads to knowledge sharing, leadership involvement to support the experiments, and then plans are put in place to implement the change.  As change slowly sticks, more change may be required where time must be allowed for the new changes to be internalized before the cycle repeats. Lewin used the analogy of a block of ice to be unfrozen to become water and then the water put in desired containers to be frozen again into ice.
~1969	Kuber-Ross Change Curve	Elisabeth Kuber-Ross (1969) ap6roached change from how people on the dying bed teach about change.  This change theory comes from the medical field particularly in hospice and hospital care.  Ross introduced the Change curve to demonstrate how people process change through their emotional lens of nearing end of life or seeing their loved ones or patients approach end of life.  People process the emotions of shock, denial, and disbelief of death. This frustration may turn into fear or anger. Then, they accept the immutable reality and slowly commit to adapting to the required change. During the first two stages of shock or frustration, no amount of motivation or feedback will be processed (because they are not actively listening - emotions have taken over). Slow and steady support and constructive feedback will help in the next stages rather than rushing through change.  While the stages of the Change Curve are very distinct from this field, these concepts really are analogous to how changes to have been unfrozen (not introduced too quickly) in the first two stages and slowly introduced in the change (accept) and freeze (commit) stages.
~1980	McKinsey 7S Model	Starting around mid-1970's, Waterman, Peters, and Phillips (1980) from McKinsey (a consulting organization) introduced the first organizational change management framework.  The seven stages were (no order) are strategy, structure, systems, skills, style, staff and shared values.  Strategy related to firm's alignment of their resources and capabilities to create competitive advantage. Structure focused on the way the firm is organized to deliver value using hierarchical relationships and roles and responsibilities. Systems tied the business and technical infrastructure to realize the goals and objectives. Shared values emphasized the display of behaviors supporting the firm's mission and vision. Style highlighted how the company's leaders demonstrated an inclusive culture for leadership to thrive. Staff comprised of the capabilities, skills, and competencies as well as the firm's ability to manage capacity, transition, and sustenance. Skills showed the firm's ability to deliver work and evaluate performance improvements.
~1991	Bridges Transition Model	Bridges (1991) Transition model differentiates change from transition. It states that changes [anyway] happen to people. Transition, [however], is internal - it's what happens in people's mind when facing and experiencing change.  This model draws parallel with the Kuber Ross' Change Curve Model in terms of emotions felt as change is processed. The three stages in this model include Ending, Neutral Zone, and New Beginning.  In the ending phase, people feel frustrated, show anger, demonstrate low morale and productivity, and are worried about the future. They find it hard to lose and let go. But this ending phase must end before they can arrive at the neutral zone. They are not ready for change yet as they feel adrift and lost. More listening ears are required like the other models in this stage. As they begin to leave the neutral zone, they feel they are facing a new beginning. The promise of the future brings new energy and a willingness to learn. With support and feedback, the change begins to stick with their renewed commitment.
~1996	Kotter 8-Step Model	Kotter (1996) underpinned action-oriented steps for change to stick within an organization. It improves on 7S framework in that the steps are actionable.  The steps are cyclical and iterate progressively on small increments of change. (Perhaps why more Agile practitioners like this approach) The 8 steps in the same sequence include the following. They are self-explanatory.  Creating a Sense of Urgency Forming a Guiding Coalition Developing Vision and Strategies Communicating the Change Remove Barriers to Action Accomplish Short-Term Wins Build on the Change Make Change Stick
~2006	Hiatt's ADKAR Model	More frequently called Prosci's Model due to its adoption in Prosci, this model is relatively recent. The model is build in five stages. These include in the same sequence. Awareness - Creates conscious need for change (Similar to creating sense of urgency) Desire - Shows intent to participate and support change (Similar to forming a guiding coalition) Knowledge - Demonstrates the skills and competencies on planning for change (Connects with developing vision & strategies and communicating the change) Ability - Highlights the desired skills and behaviors to implement change (Connects with removing barriers, accomplishing short-term wins, and building on change) Reinforcement - Shows steps needed to sustain change (Connects with building on change and making changes stick).

Have I missed out on any model or misinterpreted any connections to models? Share your thoughts.

References

Bridges, W. & Bridges, S. (1991). Managing Transitions. Boston, MA: Da Capo Lifelong Books.

Hiatt, J.M. (2006). ADKAR: A model for change in business, government, and our community. Loveland, CO: Prosci, Inc.

Kotter, J.P. (1996). Leading Change. Boston, MA: Harvard Business School Press

Kubler-Ross, E. (1969). On Death and Dying: What the dying have to teach doctors, nurses, clergy & their own families. New York: Scribner, An imprint of Simon & Schuster, Inc.

Lewin, K. (1947). Field theory in social science. New York, NY: Harper & Row

ADKAR Model (n.d.)  Prosci. https://www.prosci.com/methodology/adkar

Waterman, R., Peters, T. and Phillips, J. (1980). Structure is not organization. Business Horizons, 23 (3), 14–26

5A Principle - A mindset about managing change

As organizations strive to increase productivity and reduce total cost of ownership, the reasons to jump on the “agile” train expecting it to solve all challenges seem to raise. Social media has scores of posts questioning agile practices. In my mind, agility is simply a “mindset about managing change”. At the end of the day, if one is truly nimble about embracing the right change at the right time the right way, then, agility should result in a) increasing value to the customer, b) increasing quality to the product, c) reducing speed to market, and d) reducing cost to operations. To achieve these goals, I propose a 5A principle to truly being ‘agile’ These 5A’s are “Awake, Arise, Adopt, Adapt, and Adept”. These stages are cyclical in nature. Let me illustrate these in the sections below. While reading this, think of the “change management framework” in mind rather than treat this as a methodology to implement agile.

Awake

Change is the only constant today. All the five competitive forces suggested by Michael Porter are a reality today.  The potential entry of new players, competitive pressures of the consumer, global market refinement and product differentiation of existing players, innovative distribution channels, and intense rivalry among competitors are making the famous economist, Schumpeter's notions of "Creative Destruction" a reality. In addition, disruptive innovation suggested by Clayton Christensen is taking industries over with ideas opening new avenues of doing business. Unless we wake up to smell reality, we will eliminate ourselves.

Arise

John F. Kennedy once asked people to think of what they can do to the country instead of what the country can do to them. Most of today's workforce is still expecting their employers to train them and tell them what to do. People fail to take their future in their hands and wait for the right opportunity. An anonymous quote reads, “If opportunity does not knock, build a door.”  Successful people are those that are not only awake but arise by training themselves with the required knowledge and volunteering to gain the required experience for the right opportunity to knock.

Adopt

Many fear that if they will make the right decision and stumble to move forward. If we walk back on our memory lane in the past, are we all certain that we always made the right decision? If we did, we wouldn’t have the expression, “In hindsight, vision is 20-20.” No one can predict what the future can bring. If fear had ruled, would anyone of us now know the depths of the ocean or the height of space? What we are today is the result of overcoming fear and not yielding to it. So, don’t worry about making the right decision but proactively work towards making the decision right. We can do that by adopting individual strategies that meet our goals.”

Adapt

A wise man once said, "Show me a person that has not failed, and I will show you a failure." Life is not about what happens to us but how we react to it. If one has learned from failure and applied the lesson learned from such failure, then, one has turned failure into success. Did you know that Walt Disney was fired from his job for lack of imagination? It was only thousands of failed attempts that got Edison to get us the light bulb. Failure is not when you fall but when you don’t get up again. So, adapt to the trends, refine your approach, and create your voice.

Adept

No matter how much you know there is room for growth. The wise also shares the responsibility to train the next generation. The value of knowledge lies when it is shared. Many people claim luck is the special ingredient available only to the privileged. I always used to say, LUCK is also "Labor Under Correct Knowledge." So, find a mentor to enrich your knowledge, spread your knowledge by training and coaching others, and better yet become adept at being a student of knowledge. The more you know the more you understand how little you know. That awareness awakes you to a new reality where learning continues.

I have used this 5A principle during my training and teaching and have found my proprietary 5A principle is a good reference framework for people to improve themselves personally and professionally.

Share your comments and let me know if you would like to hear more!

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. 

Essential Leadership behaviors for Agile Transformation

In the recent Scrum Coaches Retreat that I attended, I saw a pattern where the majority of the topics presented for discussion centered on organizational transformation and implementing agile correctly. The topics ranged from change management traits for individuals and organizations, executive leadership behaviors, coaching approaches for executive leadership, coaching for non-technology groups to implement agile, facilitation techniques for team trust, and scaling agile for coaching within an organization. Having established, led, and managed a program management office (PMO) in a healthcare IT and professional services industry and with a strong desire on leadership behaviors through project management and product development, I joined the team on this theme seeing an increasing focus around executive leadership behaviors for leading organizations to embrace agile successfully (“Build an Agile Organization Executive Coaching”, 2013).

Following the agile principles of user story development, our group with backgrounds from multiple industries began identifying the major categories of persona in today’s leadership that lacked understanding or came with a traditional mindset in transformation. These observations were later shared across the various participants from numerous countries during our daily retrospectives to further refine our persona categories. The major themes of persona classification of executives evolved are listed as follows that I have reordered in a continuous spectrum of the knowledge of agile in their implementation challenges.

Resistant: The executives that fall into this category are those that have a generational gap leading to a resistance in change. The relevance to current ways of managing projects or understanding product development is not in the radar screen for taking the organization to the next level. These leaders are more task-oriented managers than leaders who feel challenged that agile may not add value. “It has been working for me and so I see no need for agile” is the theme behind such leadership.

Never heard of agile: The executives that fall into this category are open to ideas but are unfamiliar with the agile framework.  This group’s lack of understanding may arise due to many reasons such as their own personality towards new learning, lack of initiative, and firm’s industry representation to understand new trends. These members often rely on the experience of others bringing in consultant experience or another senior member to implement the transformation. If the consultant or the senior members fail to apprise of the executives of the implementation challenges in product development, skills reorientation, and the structure required for agile development to thrive, then, these executives lose faith in Agile.

  

Big Vision: These groups of executives understand that their current structure is not in line with their big vision for growth. They recognize that they need to develop products differently for competitive position of themselves in the marketplace or excelling in doing things efficiently. They have heard of the agile framework through their own due diligence to implement their growth ideas and look forward to their delegates for support.

Misinformed: Similar to object oriented programming where the subclass inherit characteristics of super class, this group of executives have had bad experience from the earlier bad implementation in their organization or in a different organization. Their “bad taste” of agile implementation shouldn’t be attributed to agile framework’s failure but the failure of those leaders or consultants that didn’t implement a stable and scalable solution.

Metric Oriented: Some executives have an instinct to not just focus on the profit motive but also establish key performance indicators. But lack of having correct types of metrics and threshold to begin with may impede successful implementation.

Insufficient Experience: This final group leans on those consultants or senior members that are brought into the organization just because they have implemented agile in their previous job. As Boyatzis and McKee (2005) noted, these high-profile members need to understand the emotional makeup of the new organization and not just their own personal success in their previous job. The reliance on a structure or set of tools that they had found useful previously but failure to understand the new organizational structure, impediments, and product makeup among others add up to the challenge of insufficient experience that these roles bring to implement agile transformation successfully.

In the end, the successful implementation relies on proper coaching of the organizational executive for leadership behaviors that they need to inculcate to succeed leading to forming a team that can coach and train the organization. If the leadership has not bought into the fundamental twelve agile principles for successful agile transformation and middle management members like functional team leads and project management not trained on product ownership, project team leadership, process governance, and client management, then, the fragile leadership should be held accountable for agile framework’s failure.

Do you think there may be other persona besides these persona classifications?

References

Build an Agile organization executive coaching (2013). Scrum Coaches Retreat. Retrieved December 17, 2013, from http://www.youtube.com/watch?v=4z_6rEkTP8k&feature=youtu.be

Boyatzis, R.E. & McKee, A. (2005). Resonant leadership: Renewing yourself and Connecting with Others Through Mindfulness, Hope, and Compassion. Boston, MA: Harvard Business School Publishing.

Execution as a Strategy in Acquisition – Relevance to Agile Transformation

In one of the networking events on effective agile transformation that I facilitated, one of the learners asked a question about how agile did not measure well in an organization that the learner’s organization acquired. The learner reasoned that the acquired company was a smaller organization that claimed financial profit in a niche market but has been bleeding after acquisition when adopting agile. While the specifics of the details have to be left out in this blog, the discussion made me realize some of the pitfalls in agile adoption in mergers & acquisition prior to shifting responsibility of failure on agile practices.

This quest for executing mergers & acquisitions (M&A) successfully led me to pursue several articles and books which made me feel that “Execution” itself should be “strategically” thought through by leaders within an organization and particularly with M&A.  Paul Burmeister, who has executed in the capacity of COO and CFO in many industries, quotes multiple ideas to ensure that the M&A activity becomes successful, emphasizing critical importance of the leaders’ synergy from both the organizations to establish success factors to measure the efficiency of integration.

Among these stands out an important point on whether the M&A focuses on products, processes, and intellectual capital (Dahl, 2012). While M&A accelerates the acquiring organization’s competitive advantage by leveraging the new product line or the intellectual capital that leads to quicker access to additional markets horizontally or vertically, the reference to processes differentiated how clash of various processes (waterfall versus agile) may have to carefully weighed.

I think here is where organizational leaders may be failing to adopt asking “what would have to be true for the” execution to continue to be a fantastic choice? (Lafley & Martin, 2013, p. 204) If leaders failed to understand the twelve principles behind agile and scale them appropriately, then, they have created an organizational impediment for agile to fail their organizational success. Rationalizing on how the acquired company has always functioned differently and seeing no need to change fails to take advantage of the additional capabilities that come with the acquisition, reasons Jeff Sutherland, one of the contributors to the Agile Manifesto, who attributed the organization’s failure to remove impediments for Agile to fail (Larman & Vodde, 2011).

Once we come to terms that we have to review the processes in place, there are a couple of additional areas to look at for successful integration of agile in M&A. These include identification of proper product owners and tools for interaction. Unleashing properly spaced-out adoption of skilled people to work as product owners that understand the agile principles of establishing a good risk adjusted product and sprint backlog, prioritizing the backlog to build trust and maintaining a cadence balancing team’s commitment in distributed and virtual teams that have to be embraced, and recalibrating on the tools of communication is vital. Charlie Rudd, CEO of SolutionsIQ, underscores how organizations fail to implement agile without building the product owner capability (2013, para 5). Firms should give importance to training in such a way that time is made for people to get trained, says Larman & Vodde (2011, para 4).            

Given these observations, what other execution specific strategies should one consider for agile to succeed with M&A activities? Should there be a standardized M&A integration checklist put together for agile success and if so, what are some pointers to definitely consider? Please share your thoughts.

References

Dahl, D. (2012). 7 steps to a successful company merger or acquisition. Retrieved Oct 10, 2013, from, https://www.openforum.com/articles/7-steps-to-a-successful-ma-a-small-business-guide/

Larman, C. & Vodde, B. (2011, February 9). Top ten organizational impediments. Retrieved Oct 11, 2013, from http://scrumedge.blogspot.com/2011/02/top-ten-organizational-impediments.html

Leading Change: Remote Teams can collocate on the right ALM tools

When I began working at Physicians Interactive, there were many tools. One business entity used Jira for tracking tasks. Another business entity used OnTime. Both business teams used Mercury for tracking test cases and compiled defects on a project through email for tracking. In addition, the development team used manual tracking sheets, such as the ones seen for interdepartmental communication to track who is doing what and when things are required. The project management team used Microsoft Project to update their updates to predict when the project will launch. Some teams across these two business entities were spread geographically requiring duplication of these manual tracking sheets for development purposes!

When I started consulting for the company, I was not very happy. I felt that most of the time was spent updating manual tracking sheets, duplicating work through emails, and updating the project plans that was not used by anyone! When I talked to the infrastructure team that managed all the applications, I found that they had purchased the SpiraTeam ALM tool which no one used. When I probed for the reason for not using the ALM tool or their preference to be using their existing manual processes, the answer was something like “This is how it is done here!”

I didn’t want to take this answer and wanted to turn this process around. Using delay as a pseudo resource in the project schedule, I documented the amount of time spent on project that didn’t generate any value but cost money to the company (my hourly rate * the number of hours spent waiting!). Simultaneously, I tested SpiraTeam myself mapping the developmental and operational processes for the critical teams to the workflow capabilities within Spira. Then, I compiled the cost of licenses for the various tools. When I compiled all these findings for the senior leadership, the writing was clear! Why would we want to resist adopting the tool while wasting money paying consultants and the tool vendors, wasting time (note that time is money) duplicating efforts for remote teams and other teams that didn’t have the access to the tools due to licenses, while not generating the value for the company?

The leadership team and the managers of the business units were willing to adapt the ALM tool. We mapped the users, created the queue managers, created the workflow, adapted the phases, etc. Due to the cost of licensing and the overarching artefact support, requirements for business, technical, and compliance requirements, test case authoring and tracking of the test cases and defect management to requirements, defect triage process support, and tracking the definition of done through task management, SpiraTeam emerged as the winner. The continuous 'listening ears' of the Inflectra person for how the release management should work, the traceability to tasks, and potential to include risks sealed the deal on SpiraTeam because none of the other products had anyone willing to spend time. 

While we managed the risk register outside this system, the convergence of tools improved the "total cost of ownership" (TCO) and enhanced the "single source of truth" (SST). While the finance and business were happy with the former, the compliance and audit team were happy with the latter. As the head of PMO now, using Spira improved the transparency of work avoiding waiting time and improving value flow. Even the remote teams spread across the countries were able to collocate themselves on the ALM tool tracking their conversations through comments. Manual processes such as tracking sheets, compiling defects in Excel for email communication, and having standup meetings to discuss updates for other remote teams were avoided. As the saying goes, "We stopped starting and started finishing!"

It is not that people are unwilling to change. It is just that nobody cared enough to lead the change lobbying people through the change giving a platform for people to reason with change. Any change like this is not a one-person show! Multiple department heads weighed in on their concerns in the process but were willing to collaborate on a solution. Yes, there were some comfort zones with tools for certain members, but they were willing to see the opportunities ahead and recognize the shortcomings of the current tools. It took a village to see such an electronic tracking of requirements, test cases, tasks, and defects augmented by structured naming conventions to documents and file folders.

After one year of having this entire PMO running on SpiraTeam with hundreds of project launches, I am happy to see that we have improved transparency to our workflow to do more with less!

References

SpiraTeam (n.d.). Inflectra. Retrieved from https://www.inflectra.com/Products/SpiraTeam/