In this post we’ll discuss some of the issues our team identified during the technical assessment phase of our project with DDR&E. As we’ve touched on in previous posts, our technical team (made up of developers, system architects and technical PMs) began by conducting an inventory of over one hundred systems (applications and sites) currently being utilized by the Intelligence and Defense Research and Engineering Communities. These were systems that our client felt aided in collaboration, information sharing and information dissemination in some capacity within the enterprise. From those one hundred systems, we identified 16 whose functionality directly related to the business priorities of creating sustainable processes, generating improved data and developing more sophisticated tools to increase collaboration. These 16 systems became the focus of our technical assessment work.
For each system, we conducted interviews with technical SMEs, including system owners, project managers and developers. Each system underwent a thorough analysis of functionality and, when possible, system documentation was examined and unclassified versions of tools were audited. Working with agencies within the national security apparatus presents a unique challenge in that much of the information and many of the tools themselves are classified. Even when tools aren’t classified, the stewards of those systems provide information only on a need to know basis. In order to conduct the most thorough assessments possible it was imperative that we gained the trust of internal personnel in order to extract the necessary information.
Getting that information took time, some interpersonal relationship ingenuity and literally hundreds of hours of phone calls, but in the end we had a clear view of the current state of online collaboration and information sharing within the communities. What we found, in terms of current initiatives, development methodologies and accepted practices was of great value for our client. For the purposes of this post, however, we’d like to discuss some more general findings that also apply to other organizations and enterprises.
Not surprisingly, we found existing technical solutions that aided in collaboration and information sharing at the department level (i.e. within an agency), but that were not designed to scale to meet the needs of the enterprise (i.e. the larger DOD and U.S. Intelligence Community). These sorts of narrowly defined solutions are also common within Fortune 500 companies. There are myriad cultural and technical drivers that lead to incomplete solutions, but a key one is the fact that much strategy, planning and development occurs in a vacuum. By this we mean that solutions are conceptualized and developed to serve a specific department-level business need (“I need an online SME Rolodex in 3 months!”) without a clear understanding of the bigger picture. In large organizations this leads to duplication of effort and replication of functionality, resulting in near-identical solutions. Both of which cost time, money and intellectual capital.
The resulting solution might meet the immediate department-level need, but rarely will it serve the long-term, enterprise-wide strategy. That’s because the solution was not engineered, from a code standpoint, to scale to the enterprises’ needs. As we’ve seen, these enterprise needs are often clearly articulated from a business standpoint, but that does not translate into technical requirements. Anyone who has spent time in large organizations knows that much is lost in translation between business requirements and technical specifications. To alleviate that, technical standards and development practices must be clearly articulated and continually managed.
A related cultural driver that leads to incomplete enterprise solutions is the issue of ownership. Turf wars within and between departments can lead to the politicization of IT decisions. The issues of who owns what, which solution should be promoted to scale and how that work gets funded internally all require objective decision-making processes. The Department of Defense is seeking to answer those questions by creating oversight bodies to review and promote IT initiatives in which the enterprise view is central. These people “get” the big picture and are tasked with making recommendations for IT expenditures based solely on those larger enterprise needs.
In times of shrinking budgets and downward trending revenues the focus on enterprise-wide solutions becomes critical. In more economically rosy times it’s just good planning. Scalable solutions not only decrease long-term development and maintenance costs, they also benefit the user community. These benefits include simplifying user experience, lowering the cost of user buy-in and increasing shared enterprise knowledge of specific tool-sets. While we don’t advocate a one-size-fits-all approach to all problems, when a shared solution serves the business objective that’s often just what is needed. And that’s what the DOD is trending toward in terms of enterprise solutions. If the larger mission of the enterprise is being served then that will naturally line up with department-level objectives. If not, then those objectives are clearly out of whack.
Collaboration Is Key, Even If You’re The DOD: Share That Information! Protect That Information!
January 20, 2010
In the second post we discussed the importance of a clearly defined vision to a project’s eventual success. An actionable vision is crucial because it gives rise to strategies and corresponding tactics to achieve target state goals. What happens though when that vision runs counter to current-state realities? In this post, we’ll discuss that conflict between the ideal and the actual within the context of our work with the Department of Defense Research and Engineering (DDR&E) Plans and Programs office.
For DDR&E the vision was to be able to collaborate, share information and disseminate that information in real-time to answer any question regarding scientific research and technological development. For a large, complex and, subsequently, bureaucratic organization like the DOD that means tearing down existing cultural and technological barriers that stymie collaboration and information sharing. It also means confronting the real and perceived security concerns that give rise to those barriers in the first place.
The continuous protection of sensitive information is of the utmost concern for the DOD, especially as more of that information travels electronically. It can be assumed that the centrality of information sharing in the new collaboration paradigm will only increase that flow of information. Many people within and outside the national security apparatus see this increased sharing as having the potential to compromise our cyber-security. These concerns are amplified by the increasing sophistication of attacks on networks in both the public and private sector.
So are those two mandates (sharing information and protecting information) in direct opposition? Does the fulfillment of one necessitate compromising the other? The answer to both is, quite simply, no. From our experience, the call to protect information and, subsequently, to limit the dissemination of that information is often not based on valid security concerns, but instead on cultural perceptions and the fear of loss of control. People who fear the loss of their prestige within an organization are inclined to resort to tactics to avoid that outcome. In a culture where information sharing becomes a priority, the ‘natural’ response for these individuals is to hoard information and knowledge and to use the perceived security concern as political cover. They fear their status as the ‘go-to guy’ will be diminished, thereby decreasing the organizational demand for their expertise.
That isn’t to say that valid technical concerns regarding securing and protecting sensitive information don’t exist, but those are technical issues to be overcome and they should not be politicized. From our experience with the DOD, they have the technical know-how and resources to confront those challenges and provide a way forward in securely sharing information.
The larger issue, then, is confronting cultural perceptions around sharing versus hoarding and providing the right incentives to ensure the success of sharing. In many ways, the very act of collaboration is what drives the shift to a culture of sharing. This may seem obvious, but until individuals within an organization see the benefits of sharing information they will not fully engage in the paradigm shift. The positive outcomes of collaboration (such as the inclusion of differing perspectives and viewpoints, which is especially important in scientific research) create a feedback loop that drive the continued and ever-increasing desire to share and disseminate information.
Level Five and DDR&E recognized these issues at play within the DOD and we focused on cultural incentives, coupled with technical tools, to drive information sharing and diminish the potential for ‘share fear’ (not the catchiest term, but you get the idea). These cultural challenges are not easy fixes and sustainable collaboration must be incubated within targeted areas of the enterprise and allowed to replicate when successes occur. The alternative (that is, the failure of the effective sharing of scientific information and technical intelligence) will be disastrous to the long-term success of collaboration within the DOD and, more importantly, the security of the nation.
One of our primary goals at Level Five is to build long-term relationships with our clients. We seek out these relationships because they are fundamental to our ability to think strategically and work effectively. Developing long-term relationships also enables us to see the big picture, that is identify opportunities, issues and strategic objectives for our clients that might otherwise have gone unnoticed.
The key to developing long-term relationships is to know our client’s culture inside and out. This goes beyond knowing what drives their economic engine, although that understanding is obviously essential. It involves understanding individuals’ professional objectives, identifying and articulating team work methods and seamlessly integrating ourselves into the language and social norms of the enterprise. In short, we strive to make ourselves indispensable to our clients by understanding and becoming an integral part to their culture.
The Strategic Foresight and Agility Initiative (SFA-I) conducted with the Department of Defense Research and Engineering (DDR&E) Plans and Programs office presented a unique opportunity to learn a new culture and test the efficacy of our approach. The Department of Defense has one of the most well-defined cultures of any organization in the world. There are norms, taboos and a language that, while not immediately apparent to the outside observer, are widely understood and accepted within the DOD. Our first objective was to quickly learn those norms and ingrain ourselves within the culture.
We began by reading hundreds of pages of strategic plans, policy directives, summations of objectives, development plans and technical system assessments. All of these related directly to past and on-going initiatives to stimulate sustainable collaboration and information sharing within the Intelligence and Defense Research and Engineering Communities. We were fortunate to be working directly with a team of individuals in the Plans and Programs office who could guide our “education” and ensure we developed a formidable knowledge base. The outcome of this reading was an understanding of what the community thought about, the methodologies they employed and why they came to the strategic conclusions they did.
Once we were satisfied with our foundational understanding we began conducting a series of in-person interviews with a cross-section of representatives from the Intelligence and Defense Research and Engineering Communities. We interviewed analysts, researchers, system developers, program managers, agency liaisons, deputy directors, program directors and Chief Technology Officers. In all, we conducted over 60 interviews during a two month period.
The purpose of these stakeholder interviews was to develop a baseline understanding of the communities in order to determine current work methods, roles and responsibilities within the community and the current state of collaboration. This process also allowed us to identify systems with the greatest potential to scale across the enterprise and whose functionality most closely aligned with SFA-I objectives. In addition, we utilized interview sessions to ask community members for input on the ideal target state relating to collaboration, information sharing and information dissemination.
The official deliverable that came out of these sessions was business and functional requirements for future phases of SFA-I. Of equal importance, however, was the cultural understanding and personal relationships we developed. By going directly to “the source” (i.e. the people that have an intimate knowledge of and history with the community) we gained a great deal of knowledge about the DOD’s culture and began the process of building long-term relationships. It also afforded us the opportunity to visit the Pentagon and CIA Headquarters, which was pretty heady stuff.
Without a clear understanding of the DOD’s culture and how individuals interact with that culture we would not have been able to make effective business process or technology recommendations. We are a technology company that recognizes the centrality of users (itself a problematic term) in any technological implementation. We recognized early on that the development of systems does not occur in a vacuum. A sophisticated understanding of a client’s culture is key to successful development initiatives. As we’ll discuss in the next post, our understanding of the DOD’s culture provided the foundation for successfully assessing the DOD’s current software portfolio and drove our subsequent target state technology recommendations.
Collaboration Is Key, Even If You’re The DOD: Define The Vision
January 12, 2010
In our first post about Level Five’s project with the Department of Defense, specifically the Research and Engineering (DDR&E) Plans and Programs office, we touched on what our client hoped to achieve during the project’s first phase. In this installment we’ll touch on specific objectives and discuss how a clearly defined vision is the only way to ensure a project’s long-term success.
We’ve all been involved in projects, both personally and professionally, that failed because they lacked a clearly defined vision. Without a vision there is no desired end state and no specific strategies and tactics to achieve that end state. Without a vision all you have is a poor-conceptualized dream. And don’t get us wrong, dreams are the best, but they’re only useful in the “real world” if they can be realized.
The DOD doesn’t do dreams. They function on directives, mandates, strategic planning and actionable intelligence. This isn’t to say they don’t have loads of visionary thinkers at their disposal, but those thinkers visionary thoughts become clearly defined strategies with supporting tactics. The visionary thought that drove the Strategic Foresight and Agility Initiative (SFA-I) was “Hey, wouldn’t it be cool if we could collaborate, share information and disseminate that information in real-time to answer any question regarding scientific research and technological development?” Yes, it would.
Toward that end, DDR&E began by defining their goals for SFA-I. In short, those goals where:
- Contribute to strategic momentum and communication around the centrality of collaboration in the national security community
- Design and establish mechanisms to address knowledge gaps
- Increase collaboration and feedback within and between the Intelligence and Defense Research and Engineering Communities
- Collect, integrate, prioritize and regularly update information requests for technical intelligence
- Formalize linkages between efforts and strategies in order to reduce portfolio risk
In addition, DDR&E hoped to integrate the Intelligence Community into the planning process in order to more quickly identify and respond to foreign science and technology programs that have the potential to diminish U.S. capabilities.
What we see here are very specific and actionable goals around which tactics can be developed. The first tactic was to break out the SFA-I project team into smaller working groups. The working group that we engaged with became known as the Collaboration and Infrastructure Issue Team or CIIT (everything has an acronym in the federal government), which was made up of a cross-section of members of the Intelligence and Defense Research and Engineering Communities, including analysts, researchers, program managers, program directors and agency liaisons.
The CIIT had its own mandate within the larger initiative. That mandate was to increase DOD and Intelligence Community collaboration around science and technology through the creation of sustainable processes, improved data and more sophisticated tools. Again, we have a clearly defined mandate around which recommendations can be formulated and acted upon.
This sort of planning may be old hat to the DOD, but it was a breath of fresh air to our team. We came into the project knowing, with absolute clarity, what our client hoped to achieve and why. The strategies were open for debate, but the vision was not. This allowed us to focus on the task at hand and bring our expertise to bear on a clearly defined problem set. As we’ll discuss in the next post, the first step towards solving those problems was to deeply immerse ourselves in our client’s culture and become a sounding board on which they could voice their recommendations, concerns and past lessons learned.
The Level Five Approach: Systems Thinking
July 16, 2009
As part of the current project we are working on with the Department of Defense, I had the opportunity to meet with Dr. Ruth David last week. Dr. David was the former CIA Deputy Director for Science and Technology from 1995 to 1998. She is now the president and chief executive officer of ANSER, an independent, not-for-profit, public service research institution that provides research and analytic support on national and trans-national issues.
Towards the end of the meeting, we started talking about tools and systems that are used to break down overwhelmingly complex problems. Causal loop diagrams and systemigrams were a couple of examples of the possible approaches when trying to understand the relationships between objects within a process.
What I found interesting was the fact that these approaches were very technical in nature and ultimately were a systems approach to thinking about process and communication issues. This type of systems thinking is something that the ANSER promotes through their ASysT Institute. This approach also resonates with Level Five because it is the same way we approach problems.
At our core, Level Five is a of group problem-solvers. We joke that we almost like problems more than we like clients. Creating an elegant solution to a problem is extremely rewarding for us, and we solve these problems through the use of technology. Level Five was founded in the software development field. Specifically, we develop software that has extremely high levels of rigor and quality to its functionality.
Since we focus so much on technology and a systems approach to development, it’s only natural that we apply that same approach to other types of problems — like communication or business processes.
Every one of our clients has communication and process problems. Often they attempt to solve these problems by implementing tools that promise to fix the issues, but they fail to understand the underlying problem. If you are experiencing pain and frustration trying to resolve communication and business process problems, it’s because you are not looking at the bigger picture.
At the end of the day, it’s most often a people problem. It is rarely a technology or tool problem. Understanding the end-to-end scope is absolutely necessary to fix the issue. What we have found at Level Five is that the level of detail, scope and understanding that is inherent in a systems approach to problem-solving provides a more effective path to success.
Components of Web Governance
July 2, 2009
One of the recurring themes we see across all our clients is the issue of managing the creation, distribution and implementation of assets throughout the entire web lifecycle.
The majority of the time, the “web group” is the one that carries the banner for being successful since the website has the most visibility to everyone in the organization. If the product mini-site didn’t launch on time, it’s glaringly obvious to everyone. And unfortunately, it’s easiest to point fingers at the web group for dropping the ball.
However, what we commonly find is that the problem lies much farther up stream. There a number of groups involved in any website implementation (i.e., product management, marketing, brand, legal, etc.) It’s just that the web group is in charge of putting it all together at the end and launching it at the last minute crossing their fingers that everything is correct and approved and on time.
In essence, all these groups tend to perform their role independent of each other and only collaborate when necessary to move to the next stage. In order to promote collaboration and transparency throughout all the various groups, we have developed a governance model that creates a framework for successfully managing the entire web lifecycle.
The goal is to gain visibility to all activity no matter the current status in an effort to proactively prepare ahead of time to eliminate the last minute scramble that so many web groups deal with on a daily basis.
There are three primary components to Level Five’s web governance model: people, process, and standards. These components are dependent on each other, and a successful model fully integrates all of them.
People:
Organizational structure of resources that have defined roles and responsibilities
It is the responsibility of the organization to make decisions regarding all levels of process and standards within the web governance model. A successful web governance model depends on roles and responsibilities being defined in order to ensure accountability.
Process:
Organizational methods and tactics for the creation, communication, and development of new web properties
The web governance process is the workflow of how web deliverables move through the organization from concept to implementation. The scope of the process must include all stages of the web lifecycle and must represent all parts of the organization.
Standards:
Creative and development guidelines for executing web deliverables
Brand guidelines, design style guides, and code standards are all part of web governance standards. Standards also help define the technology methods that are necessary to effectively execute the web governance process.
Learn more about Level Five’s web governance model
Phil
kurtlane
Greg Stickley
