We talked in Part II of this blog series about elements of agile transformation with a focus on two main initiatives: process and technical agility. We laid out some ideas and details to consider and to understand approaches to scaling. But one question is still not answered – in what order of priority do you tackle these initiatives? Does it even matter?
There are a lot of changes in the “trenches”, at the engineering level with adoption of technical practices, changing how we build, test and deploy the code. And at the time these changes are happening, the organization can be changing to support release trains, engineers are moved around, and new teams are formed. By doing so, release trains may start breaking up existing organizational entities managed by directors and executives.
Let’s look into some scenarios, link them to organizational culture types and discuss outcomes that we may expect, at least based on our humble experiences.
Process Changes as Higher Priority
In this scenario, priority is given to process transformation over technical transformation to align engineers around scrum teams and form release trains. This obviously requires lot of preparation at the leadership and executive level as existing organizational entities and silos are broken. All this is done while teams and leadership still have a commitment to the business and customers. For example, we can’t stop on these promises while reorganizing in an effort of creating a better delivery model. This can be challenging and creates a lot of stress and potential burnout. Developers are under the gun to deliver, fix issues, deal with escalations, and yet the world around them is changing.
At the leadership level, this can start creating “antibodies” and “non-believers”. Reasons for this could range from just not understanding how breaking established organizational models will create better value, to extreme situations where it may even be political. To understand the latter, we need to reference our Part I blog where we discussed Westrum’s organizational culture model where the first two models mentioned are power-oriented (pathological) and rule-oriented (bureaucratic).
Both models are basically based on a siloed mentality with often unhealthy relationships where either information is withheld, collaboration is low, or scapegoating is present. With a rule-oriented organization, each organization protects its own “turf”, where they have their own rules and any attempt for cooperation means others need to adopt those rules which may create friction.
Leaders in these types of cultural environments often push back on changes since their “turf” is changing, and the rules and processes they created are not valid anymore. In some cases, some leaders may see breaking up existing teams as a loss of power and control. With this, they become demotivated or even they challenge process changes as they don’t see evidence of immediate positive impact on product quality or time-to-market.
So executing big organizational changes first, changes which may not provide immediate tangible and measurable results, have some risks and may result with “antibodies” within leadership and teams themselves that may slow or sabotage the transformation. Thus, it becomes important to have the right strategy defined to turn these into forerunners of change.
In our experience we also see the HiPPO  effect emerging in these organizational cultures with top engineering leaders with authorities giving up on transformation efforts and falling back to old practices for doing business, which in return puts the company behind against the competition and the market pace.
Technical Agility as Higher Priority
In this scenario priority is given to technical transformation over big processes and organizational transformation forming release trains and values teams. Just to make it clear – we are not stating that process transformation is not done, but just that effort and energy is first put into work on “low hanging fruit” – fixing code quality and improving delivery capabilities. In this approach, the organization recognizes the existing technical challenges, long release cycle, or inadequate testing and agree on prioritizing these challenges first before doing bigger organizational changes. In this approach agile and technical coaches and DevOps engineers are typically hired to drive most of technical transformation:
Agile coaches will start helping teams embrace Scrum, help them understand how to break problems into smaller increments and how to deal with flow and apply lean principles. They will help limit work in progress (WiP) to allow a percentage of the capacity to address technical debt such as manual testing, complex branching, or slow, infrequent builds, to name some.
Technical coaches will pair with developers and help them start refactoring code and teach them how to embrace proper unit testing and advanced methods such as TDD and BDD frameworks for example. They will examine their branching strategies and teach how to move from long lived isolated branches to a more trunk-based model with CI and daily merges.
DevOps engineers will start helping with a tools ecosystem, help automate build and release processes, and help with environments setup automation to enable continuous code integrations and deployments.
Above are typical examples of technical transformations which, when combined and well executed, will start demonstrating evidence of continuous deployment capabilities improvement.
In order to see the evidence of progress, monitor the changes and make sure to address any negative trends of teams falling back to old practices, a set of engineering metrics unified across teams must be established. These metrics mainly provide answers to two key questions:
What does my code quality look like? The expectation is to see positive trends with regards to defect reduction, security issue reduction, increased unit test code coverage, and increase overall test automation.
How well are my teams transforming? This means teams embrace fast CI/CD with a reduction in build-cycle-time and increased number of builds, a positive trend with regards to pass/failed builds, story-cycle-time shows positive trends and so on.
It becomes almost obvious that with proper adoption of technical practices along with coaching and servant leadership support to ensure teams have what they need, then positive results of the transformation become very measurable quickly. Ideally, key metrics are automated and updated on a daily basis (ideally by each integration build run) and displayed and visible within team spaces.
We looked into two prioritization cases, one where priority is given to organizational changes over adopting technical practices and fixing teams first. There is a risk with this approach, if an organization’s culture is power or rule oriented. While organizational changes are important to set the organization for success long term, they are quite disruptive for leaders and engineers and there is no immediate return on investment – by changing the organization we don’t improve code quality or time-to-market immediately. In this scenario, it is easy to see that people in doubt will become vocal and undermine the efforts and in extreme cases, division can be so deep that transformation efforts may fail.
However, when we put priority on technical transformation first, and staggering organizational changes until we start seeing benefits of technical practices and DevOps we put in place, we are minimizing risks of disagreement and friction. Those potential non-believers or antibodies will not have arguments if we start seeing better code quality, more automation, less security issues, reduction in delivery cycle time and happy teams. Once we start seeing an indication of these key benefits (metrics are so important here), we can start executing organizational changes to set scrum teams around common goals, create release trains and focus on delivering value faster to customers. We focused these recommendations for organizations that may have experienced symptoms of those two Westrum’s cultural models, i.e., power or rule oriented. However, if an organization is supporting a generative culture with good information flow, high collaboration, and with servant leaders focused on eliminating impediments for teams, then transformation can be much easier to execute. These organizations see transformation as a business change and not just an engineering experiment.
Transformation Strategy Elements and Their Priorities
In the previous blog (Part I) we discussed organizational transformation and organizational culture as a factor that is often overlooked, yet is a factor that can greatly impact the outcome and success of the agile transformation. But before we analyze that impact, lets briefly discuss key elements of a successful agile transformation.
Elements of Agile Transformation
There are articles and books written on this topic discussing process, business agility, change management, and technical agility. But for this blog, lets focus on a few that really matter.
Organizing teams for continuous delivery and self-efficiency. The most popular framework to achieve this is Scrum. In Scrum teams are organized around the ability to deliver features quickly and desired level of quality. Adoption starts with reorganizing teams into smaller groups (versus a big monolithic development organization) with right skillset mix to achieve the above mentioned objectives – speed and quality. Changing and reorganizing teams is a disruptive process (“Change is good…you go first”), and there will be developers that may not embrace it at first. While talking to a bigger group of engineers about organizing into small teams, and the notion of shared responsibilities and collaboration, we experienced more than once, push back from at the back of the room with comments such as “coders like to work alone…”as they express their disinterest. But these instances are really outliers and for most part, engineers do tend to see benefits of scrum and with proper coaching, they start embracing it.
For small companies with a simple organizational structure, the transition to Scrum can be fairly straight forward. People know each other, often they are all collocated and they are used to dealing with frequent changes, comfortable with direct communication and may already have a “just do it” attitude.
On the other hand, for larger companies with a complex structure and equally complex processes, these changes are much more challenging and may take time to fully transform across all departments and geographical locations. But even in this case, engineers can often see the “good” in the change. They embrace it, over time they improve it and ultimately become better at it.
Beside teams of developers organizing in scrum teams using Bezos’ two pizza size rule, next process related change that is important to highlight here, is the ability to scale Agile in big organizations. This means organizing multiple scrum teams together to continuously deliver meaningful value to customers. Hence, the concept of a Release Train may be introduced to align scrum teams and other functions (development, DevOps, test, product and program management, service, etc.) in logical grouping with shared business and technology objectives. Release train may have up to 150 developers in large organization, with multiple release trains running concurrently. Members of a cross-functional release train should seamlessly work together without traditional organizational boundaries or impediments (or “silos”) to complete all activities necessary to deliver value continuously, fast and with quality and security built-in. Further, the set of release trains’ activities can be organized around value streams where value is a content the train is delivering. The value stream is also a reflection on how business is aligning a key product or portfolio strategic themes delivered to customers over period of time. By definition, a value stream may include activities across multiple release trains.
It is obvious that scaling Agile with release trains, value streams and associated changes, may require modifications of the existing organizational models especially if they aligned around technology, architectural components or existing product components. These organizations may have developers, test engineers and other functions working on these components that alone may not be releasable customer values. This is important to remember as we will later discuss organization culture models relationship with organizational changes introduced by implementing release trains. This may require reorganizing teams around the value they would deliver to customers.
 According to Bezos, ideal size of the team is the one that can be fed with two large pizzas
Technical Transformation or Technical Agility
Beside organizing teams and aligning organization around value streams where value is delivered by release trains, another element of successful transformation is technical transformation or adoption of advanced engineering practices.
As we said earlier, the ultimate goal is to deliver valuable product increments to customers continuously (in frequent deployments), with quality and security built in. To do this, teams need to change the way they produce code. In waterfall-like models, developers will write code, pass it to test teams who will open defects for any bug they found during testing. These defects will go back to developers to fix them. When code is ready, software executables are built and provided to operation teams to deploy to a sandbox environment to do more integration testing . This process keeps going until predefined release readiness goals are reached and software is finally ready for customer deployments by operation teams. All this takes time, promotes silos and isolates developers from software delivery process, and ultimately from accountability for product quality. Because it takes time and deadlines are tight, this often causes burnouts and stress conditions for people involved.
Hence it is important that along with agile transformation, teams embrace engineering practices that sustain agile and ensures quality issues are fixed fast, when they actually happen. . This reduces turnaround time for delivering value to customers and makes developers accountable for a code quality. Some of most important technical practices teams need to learn are:
Automated Unit Testing – Teams should adopt xUnit test framework within which developers create unit tests pretty much for each line of code they write. One of the most popular models for embracing unit testing with full code coverage is adoption of Test-Driven Development (TDD). In this model, unit tests are written prior the code that is tested. Another good extension to TDD is Behavior Driven Development (BDD) which allows automation of acceptance tests that can be considered a contract between developers, product owner and business stakeholders. Adoption of these test frameworks, requires often mindset change, but with proper technical coaching engineers quickly see the benefits and adopt.
Continuous Integration (CI) – Teams need to have the ability to run fast CI builds that are triggered each time they commit their code which, if done properly, means running CI builds many times a day. Developers are encouraged to run their unit tests during these builds along with performing other analyses to discover code anomalies and security vulnerabilities. The feedback CI provides is critical. It is important developers act and fix these issues immediately, not wait for downstream testers to discover and pass information about code issues in the form of a documented bug or defect.
Automated Continuous Deployment (CD) – – While each developer is running CI builds on their code and cleaning it up as they get unit test feedback, it is important that code is continuously built and tested for integration between key components of the system they are building. To do that, a means of automating environment setup and code deployment are required. These days this is often automated by adopting infrastructure as a code paired with use of cloud platform and its related services.
Proper branching strategy –e.g. Trunk based development. Developers tend to keep their code isolated from main or release branch in private or feature branches for a long time. These practices prevent code integration and timely discovery of integration issues. Hence in trunk-based development developers are encouraged to integrate their code branches into the main daily (and after passing their unit tests)
Security analysis – There are many tools available today that help with threat modeling and finding timely security vulnerabilities in a developer code or open source they use. But, remember these tools must be properly integrated into CI/CD pipeline and developers are must look for their feedback and be accountable to fix issues.
To make this technical transformation happen, two main things need to be provided: coaching and a proper engineering tools ecosystem that supports developers by seamlessly automating most of the process overhead.
There are other elements of successful transformation and other technical practices, but what is described in this blog is a good starting point helping us understand transformation priorities and risks discussed in Part III blog.
Many of us with passion for software organizational transformation, and a passion for helping teams transition from traditional waterfall or other “ancient” development models to contemporary agile and lean processes, have been reading books, blogs, white papers about these transformations. We often go to various online forums and follow threads on this topic. And by doing so, we find a lot of references about successful moves to Agile, Scrum, SAFe, embracing Lean or other initiatives and reading posts by passionate engineers talking about all the awesome positive outputs they got by adopting these methodologies. We embrace learning and trying to find best practices or develop a model that may apply to our own situation, will work for our next client or our own business. In this research journey we learn a lot about success stories or how startups are doing it and how quickly they come up with a model, a solution and adoption of new processes, tools or technical practices that put them on a path to success : delivering value to customers fast with consistent quality and built-in security.
But how many stories have we read about hidden problems that organizations are facing beyond just adopting new processes, tools and technical practices that enable them to automate everything? Startups and small agile companies are one thing, but what about big companies, enterprises who have been in the software business for decades? Yes, we have learned quite a bit about Kodak and Nokia moments, and books were written about how they failed by not innovating fast enough and keeping up with emerging industry leaders and embracing new technologies fast enough.
Change is Good…You go First!
But what about companies that may have good products, a solid product strategy, great existing market share but need to keep ahead of competition, and therefore transform and learn how to move product out of the door faster, improve time to market and still keep quality under control. Typically these transformation stories begin with methodologies like Agile, Scrum, organizing teams around delivering value continuously, then DevOps, automated CI/CD , test driven development to improve product quality, shift-left security and testing, and so on. All great stuff.
And that’s just the beginning of the list though.
So how do we approach this? In what order do we implement these things? This is where the fun begins. You may have heard about the book from Mac Anderson and Tom Feltenstein “Change is Good…You go First.” Changes are good, but they are hard, they can be disruptive; especially when asking engineers who have grown accustomed to doing things a certain way to adopt a new way of doing things, new practices and learn unfamiliar methodology. These things often put them out of their comfort zone and they question whether it’s worth the discomfort. But eventually, engineers can be convinced once they learn it will make their life easier and empower them to reduce waste in their workflows they complained for years but nobody listened.
While those in the “trenches” who are actively utilizing the tools and methodologies may eventually embrace the change, other people in the organization need to buy into the strategy and change and be supportive in order for the organization to succeed. To discover challenges associated with this, we are moving upwards from engineers to management and executive leadership levels.
Organizational Culture Can Generate “Transformational Friction”
And to talk about challenges, we , undoubtably need to discuss organizational culture. One of the first things most of us would do to learn about company cultures is to search for companies who demonstrated great corporate culture or were proven to be successful in the past. Here are some statements from leaders and CEOs who have a great understanding of the value of embracing change:
“An organization’s ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage” Jack Welch former CEO of GE
“Good leadership requires you to surround yourself with people of diverse perspectives who can disagree with you without fear of retaliation” Doris Kearns GoodwinAmerican biographer and historian
“We can change culture if we change behavior.” Aubrey Daniels Founder of ADI
All valuable and true insights.
But as most of us know or may have experienced, when we integrate ourselves with an organization, we discover certain behaviors that characterize how work is done and how an organization performs from a software delivery performance perspective. These behaviors and performances are directly correlated to the core of the organization’s culture. American sociologist Ron Westrum researched the topic of organizational culture in the 80s and developed an organizational culture model which is very applicable to organizations of today:
Pathological or power-oriented organization. As the model indicates these organizations are all about top-down, silo mentality, messengers shot, information withheld to keep an org or individual look better, new ideas are crushed.
Bureaucratic or process-oriented organizations. These are organizations that have teams who follow the processes, but each organization may have their own set of rules and practices based on which they deliver and expect everybody else who works with them to adopt just their way. Any novelty is seen as a potential problem that should be avoided
Generative or Performance-oriented organizations.This organizational model demonstrates highly collaborative environment with shared risks, novelty being embraced, and failure is seen as an opportunity to improve and pivot to avoid in the future
Turning Non-believers” to Forerunners
These models are important to understand, and as we look at our organizations through the lens of these models, we may see evidence of these associated behaviors.
So how culture impacts transformation and what are potential risks when dealing with organization who examined some behaviors and what we do about them?
What to do if we discover we are dealing with power-oriented or process-oriented organization and the transformation efforts start suffering from “non-believers”. How to overcome this and how to turn these “antibodies” into forerunners?
So let’s get into the details and in Part II we will discuss elements of a good transformation strategy, possible approaches, risks, and recommendations that should be considered to mitigate risks of failure and overcome challenges due to these existing cultural models.
As market dynamics increase, the selection of projects, which are important to align enterprise operations and strategy, face challenges from cost-benefit related conception, to criteria for project completion. Nearly all organizations have more project work to do than people and money to do the work. Trying to do too much causes all projects to suffer from delays, cost overruns, or poor quality.
Focus On Portfolio Performance
Common business pressures that serve as a catalyst to evolve a focus on portfolio performance can include:
Smaller or greater demand from your customers
Lack of available skilled resources needed for projects
Increasing risk exposure across project portfolios
In any of these cases, you may have to adjust your priorities for the next few months. Or, you may have to adjust your spend, where to spend more, where to spend less. Also, you may have to rethink your business strategy for the long term.That means adjusting your project portfolios. Some projects must be stopped, some paused, some adapted, some accelerated and some newly created. These are difficult decisions, which must be made with little certainty about the future, and, hence, potentially with more risk. The decision-making process can generate positive results while leading a company, or make a significant damage to an organization.
Project portfolio managers need a well-facilitated and structured approach to assess, reprioritize and effectively deliver the project portfolio that is needed in a tumultuous world. A process of analysis and judgment must occur in business on a day-to-day basis, and is an important component of managerial work on various hierarchical levels in the corporate environment.
Planning Under Pressure
Being compelled to select the “right project(s) next” is a most important opportunity, especially during crisis circumstances, that can:
Reduce the number of low-value projects, which will reduce the overhead of keeping track of them all and, even more importantly, increase the availability of resources for other high-value projects.
Better align project investments with your organization’s business strategies, e.g., growing overall revenue, and with your organization’s cultural values. Facilitated discussion among executives about better alignment will entail broader agreement on overall business objectives and strategies.
Improve balance and diversification of projects along key dimensions, which will entail broader agreement on such dimensions (such as, perhaps, revenue growth, product innovation, maintenance and compliance)
Follow A Two-Pronged Approach
In our experience at Group Atlantic, our clients enjoy best success by taking a two-pronged approach that emphasizes:
Top-down development of mindset, governance, and process—but not (software) tools—alongside education of relevant stakeholders, so that gradually a common enterprise-wide process for project approval, diversification and tracking is practiced. Purposeful organization development emphasized several important aspects:
Shared vision and mindset: (e.g., breaking down silos, alignment with strategies and business goals) rooted in our Business Value Pointsmatrix approach.
Governance: where to house portfolio management responsibility and accountability in the organization, who can (not) make decisions about what, and related issues.
Process: working with top leadership (e.g., to formulate the “burning platform”, develop sponsorship and communications, develop policies and model desired behaviors) and working with other executives and managers (e.g., to communicate the change(s), cascade the change down the management hierarchy, identify and manage champions and resisters, develop training, and change incentives and performance appraisals).
Quarterly exposure of executives to strategic projects, their dependencies, and their value and impact on overall strategy and results, so that executives start to appreciate interdependencies, strategic (non-) alignment and (non-) effects on overall results. This second prong follows, at least informally, a rolling 12-month plan (perhaps with a multi-year look ahead), updated every three to six months, to better exercise strategic agility.
Achieve Lasting Value
It’s certainly not trivial to reprioritize a wide ranging project portfolio, with many projects already in process and multiple influential stakeholders seemingly inseparably connected to project. The pressures of time and resource constraints, along with uncertainty about the future, can add to executive stress. Reacting chaotically could lead to a disorganized response and an inefficient use of finite resources.
A systematic project portfolio management approach, expertly facilitated, is about getting the best outcomes despite planning under extraordinary pressure. Decision-making meetings are more collaborative, effective and efficient. Better ideas come with facilitated attention to proven portfolio principles, process and reliable techniques.
With a structured and well-facilitated approach, one can move quickly and carefully to build/rebuild and manage the project portfolio your company requires to face challenges today—while also laying the critical next steps for prosperity tomorrow.
Who’s the best project manager you ever worked with? This question, posed in a Q&A discussion after one of my recent corporate workshops, stimulated some fond reminiscing about all of the project managers I’ve respected through the years and what made them so good. It also probed into some comparison about what they all had in common. If you take nothing else from this post, do that … take some quiet time perhaps while sipping that second cup of morning rocket fuel, and develop a list of the project managers you’ve respected through the years. Then think about what traits they all had in common.
I’ve had the good fortune for decades to work with project managers in successful Fortune 50 companies and rapid-growth startups, ranging across many industries, including aerospace, telecommunications, finance, insurance, retail, information services, and manufacturing. From these experiences, the best project managers I’ve worked with seem to have the following traits:
They think for themselves. They have the self-confidence to make their own decisions. This isn’t to say they don’t coordinate with others when needed, or disregard other people and don’t heed advice … quite the contrary. They will make their own decision, factoring in their skills, their team’s skills and their assessment of the situation. For example, during a project problem-solving gathering where there may be some questionable risk factors, they’ll listen, engage, and attempt to facilitate to get a full range of ideas. And in the end, while factoring in what the group is doing, they’ll make their own decision.
They understand what the business domains value about the projects they manage. This knowledge helps them make good decisions, and when unusual things happen, they have an extra bit of insight that helps them out of a jam, whether it’s a difficult project launch, an unusual stakeholder demand, or a perceived mid-project crisis. Somehow their projects seem to deliver value more reliably, and fellow project managers around the “neighborhood” will peek over to see what/how they’re planning and tracking.
They take quality risks. Project success demands risk management. It’s about good decision making, a hallmark of good project management. The best project managers I’ve worked with have surprised me on both ends of the risk spectrum, sometimes with a very conservative decision, and other times with a decision that seemed to involve more risk than I would have accepted. An in-depth conversation with them usually revealed a deeper level of analysis than I had undertaken, and I usually walked away with a few more strategies to put in my risk management toolbox.
They welcome questions about their decision-making process. Of course, this can be influenced by how you question their decision. If you approach them in an accusatory or judgmental way, you may not find them receptive. However, if your intent is to understand the analysis and all they were thinking about, you’re likely to find an enjoyable and enlightening discussion; one in which they probe you back for your assessment of the situation, and what you would have done and why.
They are brutally honest about evaluating performance and maintain a focus on improvement. When you work with them, you’ll hear them acknowledge missteps or errors. In project post-mortems or sprint retrospectives, they don’t seem to brag much; they seem most interested in analyzing their mistakes and seeking knowledge or techniques that might help them. They didn’t become one of the best project managers you know by glossing over their weaknesses.
They enjoy gaining knowledge about project management. It’s been said, “Do what you love and you’ll never work a day in your life.” The best project managers I’ve worked with delighted in quenching their thirst for project management knowledge. Maybe it stems from their love of getting valued things done, so it’s not work for them to read up on the latest developments, or spend an evening after a long, difficult day in the office by attending a presentation by a thought leader at a professional gathering. They routinely stay abreast of project risk taxonomies that accurately mirror the concerns of real-world project managers.
They’re calm under pressure. Perhaps it’s a culmination of all of the above, but the best project managers almost seem to have been waiting for the critical moments. They don’t panic; they aren’t shocked. They seem to go into a zone where they just matter-of-factly take care of business.
Are you on your own list of best project managers? Are you on anyone else’s list? What is needed for you to master the skills and thought patterns to get there? Embark on the rewarding path to becoming one of the best project managers you’ve ever worked with.
Complex engineering systems are prone to schedule slips, budget over runs, and a variety of challenges that compromise delivered value. These challenges are a sign of failure on the part of both management and technical roles, but can be overcome through a Risk Aware Framework that integrates the roles into a cohesive systemic and systematic approach to delivering high-value business outcomes.
This article shows how your organization can become more effective, more efficient, more responsive, and enjoy better business outcomes by bridging the gap between Systems Engineering and Program Management via a Risk Aware Framework. Beginning with an overview of key concepts, this article details the challenges faced by System Engineering and Program Management practitioners every day. The practical framework that follows describes how a principled process can be integrated successfully to streamline project workflow. A case study details how a real-world company successfully implemented a risk framework to improve cost and schedule performance, while improving the likelihood of success of your organization’s own strategy.
This article describes a proven framework to:
Overcome challenges and improve cost, schedule, and business performance
Assess current capabilities and build to the level your organization needs
Manage risk throughout all stages of a Project Life Cycle
Deploy best practices for teams and systems
How’s this for a system engineering truism? “The best system engineers possess the superior judgment to avoid situations requiring their superior skills to survive.” While arguably more true than a whole wealth of truisms, it doesn’t provide much guidance in our quest to become one of those wiser and more-capable system engineers, especially when we find ourselves in a position of leadership. Which raises an obvious question: How does one develop such profound judgment?
Regardless of our degree of skill and experience, the trick to safely nudging the envelope comes in knowing as much about what we don’t know as what we think we do know and weighing those factors wisely before we venture forth. The process of evaluating those elements before taking action is a process known as “risk management.”
This is an era in which risk-taking is rewarded, leaving companies that run away from risk as plunder to be divided up by the others. Risk is inherent in all activities. It is a normal condition of existence. Every day, companies are exposed to various types of risk. They can be connected to property, liability of third parties, staff or decisions; risk is the usual companion in every business and with direct influence on result. But what is a useful way to think about risks and risk-taking in today’s environment?
Risk is the potential of loss resulting from a given action, activity and/or inaction. Usually we have a choice having an influence on the outcome. Exact definition of risk is given within the ISO/IEEE Standard 16085:2006 on software and systems engineering risk management.
Risk is not a problem. It is an understanding of the level of threat due to potential problems. A problem is a consequence that has already occurred. Risk is defined by two characteristics of a possible negative future event: probability of occurrence (whether something will happen) and consequences of occurrence (how catastrophic if it happens). If the probability of occurrence is not known, then one has uncertainty and the risk is undefined.
The computerization of the workplace and the levels of IT dependency that now exist means the risks associated with the failure of IT systems are one of the most potent sources of operational risk within any organization. Systems engineering management related risks could be related to the system products or to the process of developing the system. Risk management in quickly changing environment is a requirement, for it contributes to reaching strategic advantages of a company. Inadequate attention to risk, especially at the early stages of a systems engineering project, is often the reason behind cost overruns, schedule delays, and poor technical performance.
Consider the Future of Your Present Decision
The purpose of risk management is to make decisions, not to admire the risks. No behavior goes more to the core or soul of a company than how it makes decisions.
Making the right decision means performing risk analysis. Risk analysis is systematic use of available information to determine how often specified events may occur and the magnitude of their consequences. The goal of any of these methods is to help the decision-maker choose a course of action, given a better understanding of the possible outcomes that could occur. By exploring the full space of possible outcomes for a given situation, a good risk analysis can both identify pitfalls and uncover new opportunities. Risk analysis can be performed qualitatively or quantitatively. Qualitative risk analysis generally involves assessing a situation by instinct or feeling and is characterized by descriptive statements. Quantitative risk analysis attempts to assign numeric values to risks, either by using empirical data or by quantifying qualitative assessments.
Three Essential Elements for Success
Bringing risk management to an organization is a change in language and attitude towards risk and its link to decision making. Behavior changes at all organization levels and requires at least three elements:
A repeatable process with defined steps and artifacts supported by applicable methods and tools.
Widespread access to adequate knowledge sources to fuel the process.
Functional behavior including human interactions, motivators, perceptions, communication, decision making processes and risk tolerance.
These are not independent elements; there are strong interactions that must be accounted for in implementing and sustaining risk aware management. Process and knowledge sources, while necessary, cannot by themselves change behavior. The last element is the key and yet it has received little attention. Although change management is a discipline in its own right, there are special considerations for risk management.
To introduce effective risk management practice in an organization requires the role of all three — process, knowledge and behavior — must be understood. However, it is the issues involving functional behavior that will determine whether a risk management practice can be successfully sustained.
Case Study: Rockwell Collins
One company that has thrived with risk is Rockwell Collins (now Collins Aerospace). An independent audit revealed that due to risk management practice, Collins achieved double digit improvement in Cost Performance Index and Schedule Performance Index. Enterprise Risk Management (ERM) at Rockwell Collins comprises two dominant threads that wind around a central decision process, as well as each other, forming a strong organizational risk culture. The central decision process at Collins is a phase gate model that covers the entire lifecycle of a business opportunity. The decision process directs a compelling set of business questions at key points in the lifecycle of each endeavor. It ensures productive interrogation and structuring of the company’s discretionary investments. As an organization, Rockwell Collins minimizes surprises, provides relevant, objective and timely information to decision-makers, and focuses on asking the right questions. Seven key questions that are regularly and rigorously answered are:
What are today’s risks – are they higher or lower than before?
Are the risks likely to get higher or lower in the future?
What is being done to reduce risks, to monitor risks and to prevent risks in the future?
Who is responsible for the aversion measures – who can I call if things are not correct?
How will I know the aversion measures are being put into place?
What is the timetable for the aversion measures?
How and what should I communicate concerning risk internally, to suppliers, and to the customer?
Focused through the phase-gate decision process, the complementary decision processes of management of risk and risk management allow Collins to address risk in a systemic, multidisciplinary manner that weaves business strategy, finance, program and project management, etc., into a comprehensive and unified whole.
Communication of risks is one the most challenging tasks in risk management. The people in the position to best recognize many of the risks are typically system engineers working on the project. For a variety of reasons these people may not be willing to communicate the risk. Collins’ success is in part to creating an environment that generates information pull. System engineers and their managers must learn that merely identifying a risk, placing it into a risk register, doesn’t mean it will occur (and ignoring it doesn’t mean it won’t).
At Collins, one means of creating information pull is to condition people at all levels to ask questions that elicit risk causes and characteristics. For example, my long-time associate at Rockwell, the late Art Gemmer describedhow his organization coached managers to consider certain questions in response to cues, some of which are listed in the table (From “Risk Management: Moving Beyond Process” by Art Gemmer in IEEE Computer, May 1997) below.
Four Types of Risk
Successfully answering key risk aware management question demands a widespread access to adequate knowledge sources to fuel the risk aware process. It involves four types of risks:
Programmatic, Organizational, Economic and Technical. Classification of risks is helpful in order to group those with similar risk characteristics, and is fundamental to any engineering system in order to evaluate them.
Product risks include both end product risks that relate to the basic performance and cost of the system and to enabling products that relate to the products that produce, maintain, support, test, train and dispose of the system. Risks relating to the management of the development effort can be technical management risk or risk caused by external influences. Risks dealing with the internal technical management include those associated with schedules, resources, work flow, on time deliverables, availability of appropriate personnel, potential bottlenecks, critical path operations and the like. Risks dealing with external influences include resource availability, higher authority delegation, level of program visibility, regulatory requirements and the like.
Programmatic Risk: This is the risk that a major change initiative could fail or the benefits expected of it might not materialize. With an increasing use of projects and programs to drive through change within organizations, this type of risk is often closely associated with strategic risk, as failure can have significant impacts on the organization. Moreover, with the increasing complexity of organizations, managing this type of risk is fast becoming an essential skill.
Risk drivers include: project purpose and need is poorly defined, project scope definition is poor or incomplete, project scope, schedule, objectives, cost and deliverables are not clearly defined or understood, no control over staff priorities, too many projects, consultant or contractor delays, estimating and / or scheduling errors, unplanned work that must be accommodated, communication breakdown with project team, pressure to deliver project on an accelerated schedule, lack of coordination / communication, lack of upper management support, change in key staffing throughout the project, inexperienced workforce / inadequate staff / resource availability, local agency issues, public awareness/support, agreements.
Organizational Risk: Risk drivers include: inexperienced staff assigned, losing critical staff at crucial point of the project, insufficient time to plan, unanticipated project manager workload, internal “red tape” causes delay getting approvals, decisions, functional units not available, overloaded, lack of understanding of complex internal funding procedures, not enough time to plan, priorities change on existing program, new priority project inserted into program, inconsistent cost, time, scope and quality objectives.
Economic Risk: This covers those risks that can affect the business in terms of its general financial viability. It includes risks associated with the market in which the organization operates (market risk), as well as the ability to finance growth through loans (credit risk). These risks are generally well understood, with a large number of financial instruments and techniques available to the risk manager.
Technical Risk: This is different from operational risk in that it is associated with bringing new technology products to market and introducing new technology into the organizational setting, both of which are high risk ventures. Risk drivers include: design incomplete, environmental analysis incomplete or in error, unexpected geotechnical issues, change requests because of errors, inaccurate assumptions on technical issues in planning stage, surveys late and / or surveys in error, materials / geotechnical / foundation in error, structural designs incomplete or in error, hazardous waste site analysis incomplete or in error, need for design exceptions, consultant design not up to department standards, context sensitive solutions, fact sheet requirements (exceptions to standards).
A Repeatable Process With Defined Steps
A widely recognized risk management framework (see below) depicts the different activities involved in the risk aware management associated with system engineering. The framework is represents a dynamic, continuous and highly-iterative process, while the arrows show the logical flow of information between the activities. From this framework, a project may structure a risk management practice best fitting into its system engineering project management structure.
Dis-functional Behavior: Risk Arrogance
Francis Bacon is quoted as saying, “Man prefers to believe what he prefers to be true.”
Organizations may think that effective risk management will follow merely from a repeatable process and widespread access to adequate information about risk management. However, as my associate the late Art Gemmed said, “Following a repeatable process may mean we are just systematically managing risk poorly. Likewise, having adequate sources of knowledge doesn’t necessarily motivate people to use them correctly.”
Companies that seem to understand the necessity of risk-taking are sometimes prone to the following strange behavior: They try to emphasize positive thinking by ignoring the possible unfortunate consequences of the risk they’re taking. This is an extreme variant of the can-do attitude. After all, risk awareness involves at least a bit of can’t do thinking, they reason, so it can’t be good. In order to stay positive, they steadfastly refuse to consider much of the downside. If there are things that could go wrong, that would make your project a total fiasco, for example, they would just have you not think about those things at all.
Denial is a major reason risk management is not usually done as part of project management: as my associate Dr. Robert N Charette said, “software project success is based upon minimizing the thought of possible failure.” Typical organizations are focused on the success of a project. Owning up to risks is all too often considered defeatism. The problems created by a “can-do” attitude, paradoxically, increase with the exposure and difficulty of a risk.
It’s not only managers who are subject to such hubris. If you’re a younger and less experienced system engineer, not only might you be unaware of the risks confronting you, but you may truly believe that any such risks that might emerge can be overcome, because you’re real smart and you’re willing to work real hard.
Many organizations in fact foster such attitudes as part of the can-do ethic. Risk averse and arrogant attitudes lead to system engineering dominated by crisis management and heroics. The organizational incentives are often structured to reward heroics and “can-do” employees. This positive reinforcement further ingrains these destructive attitudes.
Among aviators there is a saying, “There are old pilots and there are bold pilots, but there are no old bold pilots.” Few experienced system engineers are so foolish as to ignore all risk. When people ignore risk, they do it selectively. The way it typically works is, they take elaborate care to list and analyze and monitor all the minor risks (the ones they can hope to counteract through managerial action) and only ignore the really ugly ones.
Create A New Functional Behavior
Here’s a credo that describes the risk-related functional behaviors for which we should strive.
Manage risk as an asset. We choose the types of risks we face to match our business needs. We understand and anticipate our customers’ and competition’s opportunities and risks as well as their problems. We manage this knowledge as a strategic competitive advantage.
Treat decision making as a skill. Decision-making is a critical skill that we teach, practice, and constantly strive to improve.
Create a pull for risk information. We ask the right questions to obtain risk formation. We actively seek it. We conduct meaningful discussions of our risks and act on the results.
Seek diversity in perspectives and information sources. We seek information from the political, cultural, economic, environmental, and technical realms. We involve multiple disciplines. We listen for and learn from divergent viewpoints.
Minimize uncertainty in time, control, and information. We systematically search for uncertainty wherever it may be. This search is the heart of a learning organization.
Recognize and minimize bias in perceiving risk. We make decisions based on sound information that is derived from an adequate analysis of the situation.
Plan for multiple futures. We plan for the best case, worst case, and several most likely scenarios.
Be proactive. We act before things go wrong. We attack root causes. We look for and address systemic risks.
Make timely, well-informed decisions and commitments. The purpose of risk management is to make decisions, not just identify risks. We understand when decisions must be made. We manage the risks and understand the chances of success before we make commitments.
Reward those who identify and manage risks early, even if the risks become problems. Even prudent risk takers will realize some problems. Our heroes are not justthose people who solve problems, but also those who intelligently avoid them.
Be Prepared to Slay a Sacred Cow
A huge obstacle to risk aware management is organizational memory. The memory of “how we’ve always done things around here” is an ad hoc truth that substitutes for “doing things the right way around here.” The root is fear. People don’t want to make mistakes, and the best way to avoid making a mistake is to continue doing things exactly as they’ve always been done.
Organizations get trapped in a kind of circular logic: “We do what we do because it’s the best thing to do. And it’s the best thing to do because it’s what we’ve always done.” Unfortunately, this is a comforting fantasy for too many. What you end up with are sacred cows — things that you take for granted; pro forma (“tick in the box”) risk management processes that you have come to believe will help you get things done. In reality, all they do is get in the way of getting things done. You must be prepared to slay a sacred cow. The greatest challenge may be finding the courage to candidly answer the question, “Are we ready to hear the ruthless truth about the risks of our system engineering decisions?”
The truth is that significant, lasting performance improvement in risk aware management may require a courageous change in your organizational culture even before driving ongoing, institution-wide initiatives to optimize performance. Progress will occur in your organization when (and only when) a positive vision for the future multiplied by dissatisfaction with the status quo is greater than the natural human resistance to change (and resistance to the truth). Be prepared to challenge yourself to commit to evidence-based risk aware management as a way of organizational life.
Risk aware management is a vital part of successful systems engineering and project management. Although most system engineering managers know what to do, sometimes they just don’t do it. Some of the factors that contribute to this behavior include deficient system engineering processes, failure to adopt a risk aware management process, risk-averse or reckless attitudes, and failure to consider organizational context.
While there are many possible steps to improve risk management in an organization, some of those that appear to have the most potential for success include training managers to elicit risk information through checklists and improved communication methods, aligning rewards and incentives with risk management activities, examining risks in the context of the organization, and managing risks across an organization. These techniques are not typically part of risk management processes. And therein lies perhaps the most important lesson: Risk Aware Management is more than a process; it requires the right information and the right behavior to bridge the gap between Systems Engineering and Project Management.
Sustaining employee engagement while they are working from home (WFH) goes well beyond merely providing laptops, video conferencing and collaboration tools. Are your WFH Policies helping or hurting? How do you know? Employees need to feel, believe, and experience being a valued team member. One of the most effective ways to show workers their value is to solicit their participation in improving their WFH experience by using their views and opinions. Of course, you must be willing to take action based on the information provided. The following describes how a VP of Development and his boss the SVP-CIO used a WFH Effectiveness Index to identify and validate the root cause issues endangering their WFH program, and provide action options for improvements.
It had been four weeks since ABC Company implemented a Working From Home (WFH) Program for the Information Technology organization. For VP of Development Tom and his boss SVP-CIO Justin, it had quickly turned into a world of the unknown laced with frustration, apprehension, lack of control, stress and fear. And, it had been getting worse by the day.
When the CIO Justin had asked how the WFH Program was going – Tom didn’t really know. Most all of the usual beacons he had used to judge effectiveness of his areas of responsibility had disappeared. No face-to-face staff meetings or follow-up meetings. No walking around observing his department employees and teams in action. No social contact to judge morale. No impromptu one-on-one conversations around the water cooler and most of all, no body language to observe. He was in the dark.
Coordination, ensuring trust, validation of information for decision making, establishing a common ground needed for team problem solving, and supporting people to overcome their reluctance to say what was on their mind had always been a challenge. Now it had become impossible. It was a new world, a new environment – and Tom had needed to quickly come up with a way to measure it and control it.
Tom came up with an Index to measure the effectiveness of the WFH Program – an Index that would not only measure effectiveness but would help prioritize and drive improvement actions. This technique would also create a secure foundation for supporting WFH control over his areas of responsibility, which included 70 people organized into three development groups and eight work teams with three teams embracing Agile and the others using Waterfall (WF) development methodologies.
With his Index approach, Tom was able to give SVP-CIO Justin a status of the WFH program. It had an Effectiveness Index of 53 (out of 100). It wasn’t going well at all. The Index was a roll-up of critical things that were essential to an effective WFH Program. Going down the roll-up provided the intelligence needed to improve the index by enabling Tom to identify and validate problems, determine solutions, establish solution focus, and determine priorities.
Tom felt the quality of this intelligence about the WFH Program was rock solid. It was based on what the stakeholders involved were actually experiencing and what they said they needed, with the bark off. This was their ground truth, given anonymously, without fear of retribution. Participants were not identified individually and from the results, it seemed that they had no reluctance in calling out real problems and slaughtering “sacred cows” that had become barriers to them in doing their jobs under the WFH Program. This is how he did it.
Tom broke down the idea of an Effectiveness Index into component parts or Critical Success Factors (CSFs). These would be the critical areas that had to go right for his department to achieve their commitments. These CSFs would be the operational enablers supporting his employees in doing their jobs. Tom chose ten:
Communications – accurate, timely, and truthful exchanges of information within teams, across teams, and up/down the organization.
Action Bias – avoidance of procrastination in decision making.
Change – involvement of stakeholders in developing and implementing new and/or modified procedures and processes.
Empowerment – allowing people to make decisions without constant approvals.
Employee Value – recognition of employee contributions.
Leadership – providing guidance to remote employees by clarifying direction and expectations
Management – involvement and subsequent support of management.
Productivity – the changes in productivity as new processes are implemented
Work Environment – establishing and maintaining working conditions that allow individuals to concentrate on their tasks and develop new skills without inappropriate distractions.
Critical Challenges – identification of the most critical challenges to the WFH program.
Tom would use web-enabled anonymous electronic interviews to have his employees evaluate each of the CSFs. An issue for each CSF would be defined in the form of a question or statement for evaluation. The participant would be able to score the status of each issue and would be given a place below the question where they could provide detailed clarifications and suggestions for improvements. The text comments would provide a basis for employee participation in developing appropriate action plans for improving the WFH Program. This text data could also be used to improve questions/issues for additional rounds of electronic interviews, just like results obtained in staff meetings helped him focus the next staff meeting agenda.
In thinking about the relevance of the questions he had developed, Tom decided to add a second evaluation for each question. He wanted to know how important each issue was to the respondents in doing their jobs. That way, not only could he validate his intelligence gathering questions, but solutions could be focused for areas where they were most important and really needed.
The importance consideration gave rise to another idea. If something was evaluated as mediocre to a respondent, but not important to them in doing their job, then it could be considered sufficient for that respondent. So, Tom decided to use the difference between satisfaction and importance as another index, sufficiency. Tom now had three parts to his Effectiveness Index: Importance, Satisfaction, and Sufficiency.
These scores would provide an Effectiveness Index measure for each CSF and could be rolled up for an overall Index.
Tom created a question or issue statement for each of the ten CSFs. Not only did he want everyone to evaluate each issue in terms of satisfaction and importance, but he wanted them to expand on their thoughts about the WFH Program these issues stimulated. The good, the bad, and the ugly could be described in a comments box with no fear of retribution.
A rather subliminal positive feature of Tom’s approach was that it involved the employees in defining the problems as well as the potential solutions. Tom’s experiences had been that the most effective change management had occurred when employees had participated in defining the change and in essence had become “partners” with, instead of victims of, the change agents.
Tom also included a couple of demographic questions for respondents to select their department, their team, and their level of responsibility. He made sure each demographic group would have enough members to preserve respondent anonymity. His plan was to learn the specifics of problems experienced by groups working together in order to apply focused and meaningful solutions and didn’t need to identify individuals.
The Electronic Interview
Tom’s intelligence gathering involved his 8 development teams and the associated management chain under his responsibility, a total of 70 people. They all responded to the anonymous electronic interview. There was a reason for 100% participation.
Tom’s electronic interview system provided each respondent with a confidential ID code – a random generated 6-digit number. Even though the interview was short, a participant could exit the interview and return later to finish. They would input their code and be returned to their specific interview. Once submitted, the respondent could download a pdf copy of their responses that included a coded receipt for their participation. When Tom invited his employees to participate, his email stressed how critical it was for them to join in by evaluating and clarifying the problems and concerns they had with the working from home (WFH) Program. Consequently, and in order to protect anonymity of respondents, if everyone didn’t participate their managers might be asking for them to produce their receipt. After all, an all hands meeting meant just that! Mandatory attendance!
Tom sent an email to each employee giving them the link to the electronic interview. He committed to all the participants that they would be getting feedback from the responses and would be kept apprised of actions being planned (based on their responses) to improve the WFH Program. The interview was open from Monday through the following Saturday. Data was to be downloaded for analysis on Sunday. Tom planned to let his managers know the response numbers each day. By Thursday, all had responded.
Tom’s system structured the data for easy analysis and included a variety of graphs and drill downs by demographic areas and by CSFs. Tom was ready to meet with CIO Justin after one day of analysis.
The CIO Justin was shocked when Tom told him the WFH Effectiveness The CIO Justin was shocked when Tom told him the WFH Effectiveness Index from the electronic interviews came out to be 53 out of 100. Justin’s expectation was for the high 80’s! Tom was expecting mid 80’s! Tom’s four Directors had not been quite so optimistic suggesting Tom’s thoughts were a “little high” although they seemed unwilling to venture an estimate. Their reticence reminded Tom how important anonymity was if you want people to give you their true thoughts on a controversial matter.
Tom started with the “bottom line”:
Tom explained that 70 people responded (count) and he had three measures (color coded on all his charts and graphs):
The Importance (IMP) – average value from all respondents (Count) on a scale from “not important at all” (1) to “extremely important” (100).
The Satisfaction(SAT) – average value from all respondents (Count) on a scale from “completely unsatisfactory” (1) to “extremely satisfactory” (100).
The Sufficiency (SUF) – Average value from all respondents (Count) on a scale from “totally insufficient” (1) to “completely sufficient” (100)
Tom noted that in the case of Sufficiency, it could go over 100 (overly sufficient) which would indicate that the satisfaction with a situation exceeded the perceived level of importance.
Tom’s thoughts were that the satisfaction level should closely match the importance level for maximum effectiveness of the WFH Program (Sufficiency of 100 or more). So what was going badly to drive the low satisfaction and sufficiency numbers?
Justin’s first question to Tom was, “What is causing the low numbers?”
To answer that question, Tom showed his boss Justin a radar chart (Exhibit 1). It showed the levels of Satisfaction (in red) and Importance (in green) for each of the 9 CSFs. The space between these two lines was a visualization of the Sufficiency – the larger the space, the less the sufficiency.
Sorted in order of least satisfaction, Justin could see that Productivity, in the opinion of the 70 respondents, was the biggest problem, with a level of Importance at 95, a level of Satisfaction at 25, and with a level of Sufficiency at 26. The CSFs in order of least sufficiency were :
Productivity (95, 25, 26) – the changes in productivity as new processes are implemented
Work Environment (95, 40, 42) – establishing and maintain working conditions that allow individuals to concentrate on their tasks and develop new skills without inappropriate distractions.
Empowerment (93, 48, 52) – allowing people to make decisions without constant approvals.
Action Bias (92, 48, 52) – avoidance of procrastination in decision making.
Leadership Guidance (88, 57, 65) – providing guidance to remote employees by clarifying direction and expectations
Change (88, 60, 68) – involvement of stakeholders in developing and implementing new and/or modified procedures and processes.
Management Support (88, 61, 69) – involvement and subsequent support of management.
Communications (91, 64, 70) – accurate, timely, and truthful exchanges of information withing teams, across teams, and up/down the organization.
Employee Value (91, 75, 82) – recognition of employee contributions.
Critical Challenges – a list where all 70 respondents selected the most critical challenges to the WFH, then ranked from highest concern to lowest concern (not shown on the radar chart, see Exhibit 5).
The levels of importance indicated the respondents felt the CSFs were very important to the program, as did Tom. The satisfaction experienced by the stakeholders was a different story.
Justin asked Tom, “Are these perceptions consistent among all the organizational groups, or is there a particular area or development team driving these low scores?”
Tom brought up the next chart. It showed the Indexes (sorted by sufficiency) for the entire Systems Development department with a breakdown for each organizational unit. Tom also included the Index for the teams using water fall and the teams using agile. The agile teams were the most affected by the WFH Program.
Before the WFH Program, the agile teams, especially Team 01 (Sam) were the most productive of all the teams in Systems Development. Their users were making the majority of the positive comments about the support from IT since the introduction of agile. Sam’s team also had the most critical project for the company.
Justin was stunned. His most important project had the lowest sufficiency with the WFH Program! He asked Tom, “Do you have some detail on the team responses?”
Tom then said, “Let me show you how the waterfall and agile teams responded.” He brought up the next two charts showing the index numbers for each of the CSFs.
The teams (34 team members) utilizing waterfall (WF) methods had an index (89, 65, 73):
1. Productivity (94, 33, 35)
2. Work Environment (93, 48, 52)
3. Action Bias (90, 62, 69)
4. Empowerment (88, 64, 73)
5. Management Support (86, 71, 83)
6. Change Management (86, 71, 83)
7. Leadership Guidance (85, 76, 89)
8. Communication (90, 76, 84)
9. Employee Value (90, 82, 91)
Tom said, “Four serious problem areas requiring immediate analysis: Productivity, Work Environment, Action Bias, and Empowerment.” Justin agreed. Tom pointed out that the agile teams really needed to be addressed in all areas.”
The teams (23 team members) utilizing Agile methods had an Index (91, 38, 42):
1. Productivity (98, 14, 14)
2. Empowerment (100, 22, 22)
3. Work Environment (98, 25, 26)
4. Action Bias (91, 27, 30)
5. Leadership Guidance (86, 39, 45)
6. Management Support (85, 46, 54)
7. Communications (90, 53, 59)
8. Change Management (86, 53, 62)
9. Employee Value (89, 64, 72)
Tom said, “The Four most serious problem areas are: Productivity, Work Environment, Action Bias, and Empowerment.” Justin agreed and added his concern over the low indexes for Leadership Guidance, Management Support, Communications, and Change Management!
The Agile Teams appear to be devastated by the WFH Program as it is currently operating. Justin asked Tom, “What were the specific responses from the agile teams to the Productivity question and did they have any interesting comments?” Tom had the answer – he showed Justin the following detailed responses distribution chart with key comments listed.
Productivity – thequestion on the electronic interview was:
How are current practices (work-at-home) affecting productivity?
For the agile team members:
Key Confidential Comments Agile Teams – Productivity
23 I am spending a lot of time wondering how to respond to some of the confusing directives I get from my manager in web meetings. Impossible to interact with everyone else on the call. When questions are asked, made to feel stupid or foolish for asking. Not getting anywhere near the work done as before working from home. Very depressing.
18 This work from home is a nightmare. I am lost. My usual confidants are not available except by appointment. I am very unsure of what to do most of the time.
30 Management control needs to lighten up and let people do their jobs. Work from home has made management paranoid and increased their control activities. No trust in what employees are doing.
84 A lot is not working so well. Web meetings not well organized and go too long. Ramble. People appear bored and not involved (video). Lots of distractions – such as people leaving their mics on with background noise screwing things up. Backgrounds in some individuals video is distracting.
96 Communications needs to get straightened out. Too many delays in getting critical information.
120 Current practices of outside daily interference are destroying the effects of agile practices. Status reporting is getting more frequent and in more detail – killing productivity. Also, micro management is interfering.
Justin certainly didn’t like the responses of the agile teams on productivity. But he sure liked the data! Talk about “ground truth” – here were the unadulterated convictions of those directly producing the productivity of his department. These were the people that generated the results he was accountable for.
The consistency of responses among the 23 team members across 3 different teams was also striking. His first reactive thought of ‘who said it’ evaporated. Anyone who wanted to point a finger would need a big finger. It also told him it wasn’t just a one team anomaly. It was rampant throughout the agile teams.
Then there were the comments. Justin thought about what the comments would be if he asked individuals what the problems were. His managers had already told him nothing, because they didn’t really know and were more likely guessing. Logically identifying problems and defining problem causes was typical when people weren’t sure and didn’t have adequate information. But getting visibility directly from those on the front line was strong and convincing. Furthermore, the detail and suggestions indicated that they knew things could be done differently and were asking for approvals and help – they wanted to participate in making things better and were more than ready to change.
Justin asked Tom, “What about responses from the WF Teams? What was the distribution of their responses to productivity?”
Tom showed Justin the following charts for the teams using the water fall development approach.
Productivity – results for the WF Teams:
Key Confidential Comments WF Teams – Productivity
41 Some inconveniences but generally working out.
52 Many distractions have been eliminated by working from home.
61 More positive than negative. Lot of inane interruptions have been eliminated. Collaboration has taken a hit. Could use more consistent guidelines on communications amongst others regarding technical issues resolutions.
72 Things have slowed down. Harder to be sure it is safe to move ahead on projects. When collocated, it was easier to touch base and verify directions.
108 We have had to modify the department directives to be more effective for us. No conference calls without video, no one-on-one calls without video, consistent agenda for conference calls, etc.
291 Lot of inconveniences
Justin could see it was also bad but not like with the agile teams. The comments didn’t seem as desperate either. Still, however, WFH was taking a toll. Justin asked Tom, “What do you think is different for the WF teams than the agile teams?”
Tom said, “Agile, by definition, requires close collaboration and team interactions. WF approaches tend to have more independent contributors not requiring constant team member interactions. Things tend to happen more spontaneously with agile than WF. It appears that the WFH Program has destroyed the heart of the agile approach, collaboration and interaction. But still, the WF folks have the same problems, just maybe not so directly detrimental to their productivity as the agile team members. I have another view of the data that is online that shows the demographics of specific responses.”
Tom said, “Agile, by definition, requires close collaboration and team interactions. WF approaches tend to have more independent contributors not requiring constant team member interactions. Things tend to happen more spontaneously with agile than WF. It appears that the WFH Program has destroyed the heart of the agile approach, collaboration and interaction. But still, the WF folks have the same problems, just maybe not so directly detrimental to their productivity as the agile team members. I have another view of the data that is online that shows the demographics of specific responses.”
“By clicking on that line highlighted in yellow, I can view the demographics of those 20 people (Exhibit 8).
As you can see, they are spread across all three development groups and the 5 WF teams. The project that Team 04 is working on has the least team interaction requirement. Some of Team 05 (Jackie’s team) members have already been working at home. So, they are telling us that their previous working from home has been adversely affected by the WFH Program just introduced. They might be a good source to help us identify the problems WFH has introduced that they didn’t have before.
Justin made a note to make this one of the priority actions going forward.
Justin asked, “What are the columns on Exhibit 7 – Imp Agr, Sat Agr, and Suf Agr?”
Tom said, “Those are agreement indexes for importance, satisfaction and sufficiency. If the specific responses were all the same, agreement index would be 100. Those indexes show high level of agreement on importance with larger dispersion on satisfaction and sufficiency.”
Justin was surprised by the low indexes and especially by the Productivity detail. It was hard to take. He had done so much to ensure control was maintained over the development teams in moving to the WFH Program. It seemed as though it wasn’t working, and things had gotten much worse. But he began to see Tom had come up with an intelligence gathering technique to fuel a very effective recovery.
Tom said, “Let me show you one other picture. Our 10th CSF asked the team members to identify the challenges they were experiencing due to the WFH Program. Their responses are very informative as to the potential causes for the productivity drops.”
It was easy to see how the challenges the teams were experiencing would lead to productivity problems. It didn’t take much to connect the dots. Before the WFH Program, things were progressing nicely. Justin was beginning to see how his additional attempts to maintain control over working from home might be causing problems.
Justin started thinking about some of the things he had initiated to ensure the WFH Program didn’t result in paid vacations for team members.
Daily morning reports on tasks planned for the day.
Daily evening reports on accomplishments for the day.
Group conference calls for more than 5 participants had to be submitted to his admin assistance who would set them up and send out invitations
Report required summarizing every conference call (must include action items)
Tom had argued these types of directives would destroy the empowerment necessary for the agile framework. It would also destroy morale and show a lack of trust on management’s part. But Justin was accustomed to Tom’s “people orientation” and felt it usually interfered with the necessary task orientation. Overriding Tom had become a frequent event for Justin on this issue.
Justin was new to the company, just completing his first year. President Brandon had brought him in as CIO to improve the effectiveness of IT. He had inherited a technically strong but not very responsive IT organization. Justin’s predecessor had promoted Tom to VP of Development two years ago and although the quality of systems was unquestioned, continuous schedule slippages had been the demise of his predecessor.
Justin had come to realize that Tom was one the most knowledgeable employees about all the systems as well as the technology on which they were based resulting in high quality but late delivery. Justin had been putting heavy pressure on Tom to improve systems development timeliness and when Tom requested the go-ahead to embrace Agile approaches, Justin had succumbed quickly to Tom’s logic by given his approval. Justin knew very little about the agile concepts, but Tom seemed very knowledgeable. Almost immediately, things had started to improve – best measured by the users of I/S beginning to give a little praise for a change. Progress could be seen. Even President Brandon had complimented Justin on the positive progress. Then came the required WFH Program.
Justin was not intimidated by serious problems or difficulties. He was inspired by them. At the moment, he was somewhat shaken as he began to realize his initial WFH Program actions had not been based on the necessary foundation of information and feedback to ensure his path was the right one. He had detected that Tom and his management team seemed less than excited about many of Justin’s directives, but challenges from them were minimal. Justin was a strong, Driver/Type A, personality and once his mind was made up, he didn’t listen very well, or so he had been told. When the WFH Program came about, he was determined to maintain control over IT and continue the positive developments, so he had become more personally involved than ever.
It was one thing to hear bad news from a direct report or some of the managers, but it was really different when the news came directly from those involved first hand – and all of them besides! And the consistency of agreement among the team members was unnerving to say the least. Justin could see the true meaning of the term “ground truth!” He said to Tom, “Let’s start defining what actions we need to take to get things moving again.”
Tom, on the other hand, was more inclined to think about identifying and validating what the electronic interview participants had indicated instead of taking immediate actions based on this preliminary view of responses.
Tom suggested: “Let’s define the problem areas we see so far and then continue going through the rest of the CSFs and see what other issues come up. We can also start verifying what we have discovered so far and see how the problems interact among the CSFs. Then, let’s get some other key managers together and show them what we have and get their reactions. The goal would be to define, validate, and prioritize the actions we might take – like a straw man – then have our group beat on them. Then I suggest we pass these ideas by the team members, along with a summary of the electronic interview results to get them onboard as participants with our plan.”
Justin’s first thought was, this is typical Tom – delay taking action and keep enjoying the analysis of data! However, in this case it seemed to make sense. Besides, since Justin was very surprised at what this first data analysis had uncovered, his curiosity of what else might come out was pretty strong. He agreed with Tom.
Tom said, “It seems like so far, the most serious problems to productivity might be identified best by the development team responses to the challenges question (Exhibit 9a). If we look at those challenges, combined for all 70 people in the department (Exhibit 9b), we get a good list of problem areas or themes that give us a structure for putting together our action plans.”
Tom continued, “As we go through the rest of the response data, we can see how the CSFs contribute to these themes. We might come up with different themes as well. We can also find out more detail about what it is the people view as causing problems and what they might recommend be done. This would help us make sure we have the right problems defined and the right priorities as well.”
Justin immediately saw the value of this approach. In looking at the first challenge of collaboration that 90% of the 70 people had selected, he could already envision CSF interactions that would influence or contribute to that concern. Justin agreed.