Manufacturers are facing big problems when it comes to recruiting enough top-tier factory workers, but there’s a fix few employers think about -- #workflex. Those employers who implement more flexibility on their factory floors are finding workflex is helping them attract and retain top talent. This topic will be front and center during an upcoming session at SHRM’s annual conference next month in Las Vegas entitled Attracting and Retaining Talent in Manufacturing. Why should you attend? With the aging of the manufacturing workforce, employers are looking to the next generation of employees to...

By Aaron VolkmannSenior Research Engineer CERT Cyber Security Solutions Directorate This post is the latest installment in a series aimed at helping organizations adopt DevOps. When building and delivering software, DevOps practices, such as automated testing, continuous integration, and continuous delivery, allow organizations to move more quickly by speeding the delivery of quality software features, that increase business value. Infrastructure automation tools, such as Chef, Puppet, and Ansible, allow the application of these practices to compute nodes through server provisioning using software scripts. These scripts are first-class software artifacts that benefit from source code version control, automated testing, continuous integration, and continuous delivery. When using software to define networking, the same DevOps practices that help provision and configure compute nodes can be extended to cover provisioning and configuring the network. As Brent Salisbury points out in his blog post titled The Network Iceberg, compute nodes in today’s data centers have evolved with the help of operating system (OS) virtualization, as bare metal servers were condensed into many virtual machines running on a single physical host. Virtual network endpoints now outnumber physical network ports. The next phase of this evolution is virtualizing the application with the help of containers. A single OS instance running a container platform such as Docker can host many application containers. Each container is a separate endpoint on the software defined network (SDN), increasing the network density. In the quest for independently testable and deployable program units, applications will be architected into a series of micro services. Application function calls that previously occurred within the same process in the OS will be called amongst separate services on separate containers, requiring network connectivity to support these interactions. More than a decade ago at a medium-sized enterprise I consulted for, the network admins were using Excel spreadsheets to keep track of their network configuration. Today many organizations are still doing the same thing. With the ongoing explosion of network density and complexity within the virtual world, we can no longer rely on Excel spreadsheets or manual testing to manage network changes. It is important to point out that there is not yet any single canonical technology to configure both the physical and virtual network. SocketPlane, Flannel, and Pipework are early pioneers in managing container virtual networks. SDNs will enable the network space to gain the efficiencies that the compute space gained through source control, automated testing, continuous integration, and continuous delivery. Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below. Additional Resources To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js. To read all the installments in our DevOps series, please click here or on the individual posts below. An Introduction to DevOps A Generalized Model for Automated DevOps A New Weekly Blog Series to Help Organizations Adopt & Implement DevOps DevOps Enhances Software Quality DevOps and Agile What is DevOps? Security in Continuous Integration DevOps Technologies: Vagrant DevOps and Your Organization: Where to Begin DevOps and Docker Continuous Integration in DevOps ChatOps in the DevOps Team DevOps Case Study: Amazon AWS

Kevin Cunnington, Director General, Business Transformation Happy 1st Birthday, Digital Academy! It’s been a year since we opened the doors of the first Digital Academy in Fulham Jobcentre. Back then, we ran an 8-week course, turning out the first cohort of 12 graduates who then went on to work in key roles in digital projects. I created the Digital Academy to grow our own capability within DWP. The Digital Academy provides learning and experience that enables graduates to work in agile digital development projects, building services to meet our users’ needs. It isn’t all about digital though - the learning includes an overview of user research and user-centred design; the agile lifecycle; the role of the Product Manager and Delivery Manager; how to build prototype products and master agile rituals such as show and tells and stand-ups. Students have a 1-week placement in another government department to experience agile development environments elsewhere - we’ve had students at GDS, HMRC, MOJ and DVLA. We opened a Digital Academy in Leeds in September 2014 which increased the number of graduates. So far, 140 people have graduated from the Digital Academy. This includes people from other departments when we held our first cross-government Digital Academy in January this year. Our 1-day ‘Discover Digital’ sessions have allowed people to get a quick overview - over 1000 people have benefited from this. Our 100th graduate, Suzanne Butler, has talked about what she learned at the Academy and how DWP is transforming by starting with the user. Kevin Cunnington, Annette Sweeney, Lara Stevenson I was delighted to be at a Digital Academy community day a week ago, when we brought the graduates together to prioritise their user needs and generate a backlog of ideas for future academies. It’s clear to me that Digital Academy graduates don’t just get the benefit of extra learning and experience - they’re inspired by working in a way that puts the user at the heart of designing services. Kate Bruckshaw’s blog about the benefit repayments service is a great example of where we’re designing around user needs. Graduates are a network of like-minded people who can support each other and share knowledge and learning across digital projects. They are innovative, collaborative, curious and like to learn and share - a truly transformative bunch of people. I’m really looking forward to seeing it grow and really transform how government delivers services that meet users’ needs. Happy Birthday, Digital Academy - 1 year on and going strong.

It’s important for HR professionals to know and understand the ramifications of workplace violence to reference not only on the human level, but also concerning employer’s workers compensation and liability coverage for such acts. Other legal issues loom large, too, As an example, let’s say an employee, Jane, has a boyfriend, John, who the employer discovers has violent tendencies. Jane and John break up, and that ensues in domestic drama via a volley of phone calls during work hours. Jane’s co-worker, Karen, overhears a phone call whereby John threatens to come to...

By Kevin Fall Chief Technology Officer The Department of Defense (DoD) and other government agencies increasingly rely on software and networked software systems. As one of over 40 federally funded research and development centers sponsored by the United States government, Carnegie Mellon University’s Software Engineering Institute (SEI) is working to help the government acquire, design, produce, and evolve software-reliant systems in an affordable and secure manner. The quality, safety, reliability, and security of software and the cyberspace it creates are major concerns for both embedded systems and enterprise systems employed for information processing tasks in health care, homeland security, intelligence, logistics, etc. Cybersecurity risks, a primary focus area of the SEI’s CERT Division, regularly appear in news media and have resulted in policy action at the highest levels of the US government (See Report to the President: Immediate Opportunities for Strengthening the Nation’s Cybersecurity ). This blog posting is the first in a series describing the SEI’s five-year technical strategic plan, which aims to equip the government with the best combination of thinking, technology, and methods to address its software and cybersecurity challenges. Software in Government and the SEI’s Value Proposition Software provides the DoD and other federal agencies significant flexibility in delivering advanced capabilities comparatively quickly by leveraging the enormous existing investments in the IT industry. The demand for these software-reliant advanced capabilities is growing rapidly.  For example, in 2006 the F-35 Lighting II had 6,800 KLOC (thousands of line of code). According to a recent Crosstalk article that figure increased to 24,000 KLOC, much of it related to sensing, communications, and data processing.  Trends such as big data, the emergence of cloud computing, cyber-physical systems, the Internet of Things, information sharing in social networks, and autonomous robots have caused the role and importance of software and its security to expand significantly for the DoD and entire government.  While incredible efficiencies can result from government adoption of commercial IT technologies, the associated risks and operational requirements are often sufficiently different to require the modification and enhancement of commercial off-the-shelf (COTS) technologies for government purposes. The SEI works with members of government, academia, and industry to customize, develop, analyze and adapt software technologies and related methods for the measurable benefit of users. To act effectively in its role at the nexus of government, academia, and industry, the SEI maintains expertise in the following areas: software engineering systems engineering for software systems cybersecurity and software assurance computer science applied mathematics measurement of software systems lifecycle management of software systems Starting in 2014 and building on earlier work, the SEI is pursuing two primary technical focus areas: lifecycle assurance of software-reliant systems high performance software components for the distributed collection, processing, analysis, and dissemination of data and information, even in challenging settings where computing and communications may be limited The remainder of this post presents an overview of the technical focus areas of the SEI. Future posts in these series will take a deeper dive into each of these focus areas, highlighting research initiatives and accomplishments in each. Lifecycle Assurance of Software-Reliant Systems Software behaves differently than "physics-based" systems, such as engines, airframes, and ship hulls. Understanding its complexity and risks is hard, especially for large-scale systems-of-systems composed of many components of differing origins and pedigree. Our work in this area therefore focuses on enabling the government to obtain software-based "capabilities with confidence." Confidence is multi-faceted, encompassing cost and schedule, functionality, security, monitorability and other desirable properties including the -ilities (i.e., non-functional architectural features such as extensibility, flexibility, availability, and efficiency.) Confidence also encompasses the level of assurance that individuals with conventional levels of education and training are able to effectively and safely operate software-reliant systems. To further the technical vision of capabilities with confidence, the SEI focuses on the assurance of two primary lifecycles: the acquisition lifecycle, which includes aspects of requirements engineering, acquisition strategy selection, project management, and success measures the software design, development, testing, and operational lifecycle, which is part of the acquisition lifecycle Both lifecycles have evolved to favor incremental and iterative "agile" approaches. Less well developed are the procedures and tools to provide standardized evidence for assurance throughout these lifecycles, especially at the scale of mission-critical DoD systems. A primary technical strategy element for the SEI involves providing this type of assurance throughout system lifecycles by combining expertise in areas as diverse as cost estimation and malware analysis. To accomplish this, the SEI focuses on the following activities to support the DoD and other government sponsors: acquisition and management, including quantitative methods for cost and schedule estimation, requirements based on system and software architectural properties including security, earned value assessment of functionality and assurance in conjunction with iterative/incremental development, architectural recovery of legacy systems, sustainment and remediation, and acquisition workforce education software development, including software/system/network/protocol architecture, model-based engineering, code analysis (binary, source, and malicious), formal analysis and proofs, building assurance cases, performance analysis, software techniques for heterogeneous/novel hardware architectures, cross-domain security designs, and usable security operations, including operational risk assessment, performance monitoring, and anomaly detection, insider threats, forensic analysis, performance analysis/scalability, simulations and exercises, continuity of operations (COOP)/event response, best uses of human-computer analyses policy, including gap analysis, security and safety policies, technology transfer and assessment, compliance and validation, privacy considerations in data processing, leadership briefings and consultation High Performance Software Components for the Distributed Collection, Processing, Analysis, and Dissemination of Data and Information High performance software components refer to implemented collections of software functions that are known to perform efficiently, safely, and in a wide range of environments that are delivered with evidence indicating freedom from cybersecurity vulnerabilities. The DoD and other government agencies depend on many types of data that are amassed through a process known as TCPED—the tasking, collection, processing, exploitation and dissemination of (intelligence) data. Modern intelligence has grown far beyond the realm of closed government programs, however, and now includes commercial business intelligence, advertising, etc. Indeed, the current interest in big data, statistics and machine learning are modern instantiations of TCPED. It is well-established that software is the main driver for implementing modern analytics, advertising, scalable computing, and networks. While commercial big data has received much attention, the DoD and other national security and emergency response organizations may need to use such capabilities in constrained environments that may lack power, communications, or other computing and communication resources. These challenges appear in the tactical setting (e.g., forward deployed operations or disaster scenarios).  Many conventional commercial applications and computational frameworks perform poorly when applied in so-called disconnected, intermittent, and limited (DIL) communication environments. Bringing together assured, portable software components in support of modern TCPED in such environments is another major aspect of this SEI technical strategy element. SEI researchers focus on the following activities to support the DoD and other government sponsors: frameworks including programming and computation frameworks for big data and analysis (e.g., map/reduce; Spark), application programming interface (API) security and ease of use, data storage architectures and security, performance monitoring tools networking protocols and architectures enabling the transport and access to data in tactical environments, protocol fuzzing, formal methods edge components, including applications and libraries focusing on analytic processing of mobile and tactical environments, disconnected operations, human factors (avoiding operator overload when in stressing circumstances) algorithms, including efficient portable graph algorithms, heterogenous high-performance computing, pattern matching, applied cryptography Evaluation and Governance SEI leadership works to ensure that its projects produce artifacts that are (or will ultimately be) useful to the government and do not require unknown leaps of faith.  An emphasis on transitionability for research projects is accomplished by providing guidance and feedback to principal investigators (PIs) regarding stated government problems, industry trends, and potential collaborators.  When PIs propose projects each year, SEI leaders ask them to indicate how their projects align to the SEI’s technical focus areas and to show consistency with the expressed R&D needs of the government. For example, the DoD has initiated an effort to communicate its R&D needs and activities in a set of ‘hard problems’ which are being addressed by 17 technical "Communities of Interest" (COI), comprising the collective effort known as Reliance 21. In addition, PIs are asked to discuss the scientifically valid methods they intend to use in demonstrating results and the degree to which they will collaborate with others. In addition to its internal research review processes, the SEI has external governance from both its DoD sponsors and CMU’s leadership.  Annually, the SEI presents its strategic technical direction and project plans to the SEI’s DoD-managed Technical Advisory Group (TAG) and Joint Advisory Committee Executive Group (JAC-EG) that report to our DoD government sponsors at the Assistant Secretary of Defense for Research and Engineering (ASD(R&E)).  Likewise, SEI leaders regularly present the SEI’s status, including its R&D activities, to the SEI’s Board of Visitors, which reports to the vice-president of research at CMU. Wrapping Up and Looking Ahead The SEI’s technical efforts produce artifacts including component software technologies, methods, analyses, tools and prototype systems. In addition, the SEI helps to adapt and mature the technical work of others (e.g., government basic research organizations, such as the National Science Foundation and DARPA) for broader application. Our goal is to produce measurable improvements in the security and performance of software-reliant systems through improved practices in software engineering and cybersecurity. The SEI brings the best combination of thinking, technology and methods to the most deserving government software-related problem sets, free from conflict-of-interest.  As part of CMU, the SEI has access to facilities and research talent including professors, students, and staff members. Our FFRDC status and DoD affiliation grants our technologists access to government data and knowledge of national challenges unusual for most university R&D labs. Future posts in this series will highlight current and forthcoming initiatives in each of our technical areas that are helping to support the DoD and other federal agencies. We welcome your feedback on the technical strategic plan and vision for the SEI. Please leave feedback in the comments section below. Additional Resources Download the latest technical notes, papers, publications, and presentations from SEI researchers at our digital library http://resources.sei.cmu.edu/library/.

Naomi Stanford - Organisational Design Forty-seven years ago (1968) the Fulton Committee published its report on Civil Service reform. I would never have known this except that a colleague reading a blog I published, ‘Horseholding or Leapfrogging’,  sent me the link. The report discussed six things the Civil Service needed to reform - the balance of generalists v experts, the grading structure, its management/leadership capability, the lack of involvement with other stakeholders, the inadequate personnel policies, and authority vested at the wrong levels. The CEO of the Civil Service, John Manzoni, gave a talk on 2 February 2015 at the Institute for Government. New to the role, he made some observations. "Government does really hard things, and we ask very bright generalists to do them, and the blunt truth is that doesn’t always work very well." "The system is designed in many ways to slow things down and be less accountable- the system becomes the people and vice versa" "We need to create professions and real careers for those who wish to learn about delivery". "We need big leaders to take accountability for big things." "The Government is remarkably un-joined up - the future will demand a great degree of collaboration". "The Civil Service has not taken the development of its people as seriously as the corporate world. I cannot emphasise enough the importance of taking this seriously." I was struck by the similarity between the observations from 1968 and 2015. Manzoni acknowledges the fantastic progress that has been made over the last four years towards Civil Service reform, but he says this progress is "necessary but not sufficient" and that many before him have tried transforming the Civil Service without huge success (as the echo of 1968 in 2015 shows). I’ve seen evidence of this myself. I’ve got a great flyer from 2007 about the ‘transformation’ that ‘lean’ techniques promise.  It was a massive piece of work, although it wasn’t used to its full potential. But I could re-use the flyer just substituting the word ‘agile’ for ‘lean’. Similarly, I have a lovely 2010 brochure on ‘Managing Change’ that could be re-issued as is. So what will it take to build the momentum for the Civil Service to meet the challenges of thefuture? Clearly it’s time for a different approach. Here’s something we in DWP are going to try. On March 16, we are running a hack aimed at finding, and planning to try out, the radical steps that will transform the Department in terms of how we operate. We’ll be sharing innovative ideas about how we can really change the way we work, act, behave, and think, and more importantly we’ll be bringing together a community of people who will come up with an action plan for how we trial, test, and model these transformative ideas. The Fulton Committee Report was then. This is now. Our hack plans to deliver a different future so we’re not looking back in 2062 and saying more or less the same thing that we said in 1968 and saw in 2015.

By Aaron VolkmannSenior Research EngineerCERT Cyber Security Solutions Directorate This post is the latest installment in a series aimed at helping organizations adopt DevOps. The DevOps movement is clearly taking the IT world by storm. Technical feats, such as continuous integration (CI), comprehensive automated testing, and continuous delivery (CD) that at one time could only be mastered by hip, trendy startups incapable of failure, are now being successfully performed by traditional enterprises who have a long history of IT operations and are still relying on legacy technologies (the former type of enterprises are known in the DevOps community as "unicorns," the latter as "horses"). In this post, I explore the experience of a fictional horse, Derrick and Anderson (D&A) Lumber, Inc., a company that hit some bumps in the road on its way to DevOps. As D&A finds out, a DevOps transformation is not a product that can be purchased from the outside, but rather a competency that must be grown from within. D&A is a retail company with 250 stores making a net profit of $210 million annually. D&A’s IT operations have grown organically since their humble beginnings in the early 1980s, relying on a proprietary hardware and software vendor for their point-of-sale (POS) and inventory systems. Due to the long history of incremental upgrades from the vendor and hundreds of custom modifications and bolt-on programs developed by in-house development staff, D&A’s systems were becoming increasingly hard to maintain. Deployment of software updates proved especially challenging due to a complex nightly batch schedule that synchronized data between the remote store locations and the central office. As numerous organizations did in the early 2000s, D&A hired a fresh crop of engineers to develop and maintain the company’s web presence. The website grew to become integrated with the proprietary legacy POS and inventory system. Many features that were added to the web site were jointly developed by the web and legacy backend development teams. The website would call custom programs running on the legacy system to exchange data between the two platforms. Over the course of the next several years, adding new features to the website became painful due to the need to update programs running on the legacy system. Moreover, the website was becoming slower and slower as performance was constrained by calls to the legacy system. The marketing department was continually requesting new features, such as complex online ordering and a mobile offering. The web team found that it could only perform updates to the web site every six months. Deployment at D&A typically took from the close of business Friday until Sunday afternoon because the team needed to allow the nightly batch processes to complete for Friday, back up the system, deploy the updates, and manually verify that the changes were successful. Any misstep caused a cascading effect in the batch processes, where missed days of data had to be manually loaded by IT support staff the following Monday. It was common for lingering issues from the upgrade to not be completely resolved until halfway through the next business week. D&A needed to do something differently. The CIO caught on to the buzz in the industry about the DevOps movement and knew this was the change that D&A needed. The company hired a DevOps consulting firm to work with its web team to analyze the company’s web application and implement a plan to improve its deployment. The consulting firm recommended purchasing and implementing a software package from a partner company to do CI and CD, which would improve D&A’s software quality and help speed up deployment of its website. The consulting company helped D&A’s operations team stand up the DevOps package and configured it to build the web application upon every check-in to the source code repository. Several benefits occurred from these changes. For example, productivity was improved because the development team received feedback within minutes of committing bad code that broke the build. The DevOps firm also developed a process for automating deployment of the web application that allowed IT operations staff to deploy the built code to production with the press of a button. Throughout the engagement with the DevOps consulting firm, the legacy team was too busy with a major software and hardware upgrade to participate in the project. This lack of involvement was brought to the attention of the CIO by the web team’s technical manager, but it was mandated that the legacy team must not be distracted from completing the upgrade on schedule. Besides, the consultants only had expertise in Linux and Windows systems and no knowledge of D&A’s proprietary legacy system. Two months passed as the web and legacy teams developed and tested the next set of new website features that allowed customers to request a special coating on their lumber products. The new capability was already being talked about in trade magazines and touted by D&A’s marketing department to the press. The time came to release the website updates along with the corresponding updates to the legacy system at retail store locations. The automated website deployment completed quickly and successfully as expected. Deployment of the legacy system update, however, did not go as smoothly. About half of the remote locations’ servers did not come back online after the update due to an operating system hotfix that was not applied consistently across all store locations. The systems that received the hotfix worked, but others hadn’t hung because of a new system call introduced with the custom software update to support the website enhancement. These servers required manual intervention that took close to an entire day to remediate. These store locations were missed during the next day’s batch schedule, and the usual Monday morning fire drill was on as VPs complained that their data warehouse reports looked wrong due to missing data for several locations. The CIO ordered a detailed analysis of the incident. The company expected its investment in DevOps to speed up deployment of the website. The website was deployed quickly and smoothly, but the complex legacy backend systems remained a bottleneck to the whole process. D&A missed the opportunity to properly remediate its deployment problems when engaging the DevOps consulting firm. This inability resulted in hundreds of staff hours wasted in cleaning up the most recent upgrade fiasco that would have been better spent improving operations on the legacy side. Over the next few months, the legacy and web teams got together and explored re-architecting the integrations between the legacy systems and the web front end. Both teams found that they could de-normalize their data by ascertaining on-hand quantities of products at the remote locations. They accomplished this by subtracting their sales from their orders and storing them in a relational database at the central office instead of taxing the legacy system at the stores. This new process was separate from day-to-day retail operations and could be updated at any time without risking the legacy system’s availability. They also began to use a new Java-based service layer being offered by the legacy system vendor. This layer alleviated the need for the legacy team to deploy custom code every time a small change was needed to the required web interfaces. The legacy team automated the process of deploying software updates to all their test and production systems to assure they had identical software on them. This automation assured that what’s been tested in the test environment would work in production. Automation also helped them avoid large deployments that could take an entire weekend to complete It by allowing them to stagger the updates of legacy systems throughout the week without affecting production operations. D&A learned that each technology area within the enterprise is unique in its constraints and capabilities. The website, which could be deployed quickly and easily through automation, was constrained by its dependence on the legacy backend system that was much slower to change. By hiring an outside consultant who focused on the lowest hanging fruit, their initial DevOps venture missed the mark. The key lesson from this case study is that broad transformation of enterprise technology must come from within the organization, using the expertise and knowledge of internal subject matter experts who can navigate the maze of systems integrations often in place. These transformations can be time intensive, hard, and initially painful, so these initiatives can only succeed with senior leadership’s full support and investment. The best kind of DevOps is not bought, but learned. Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below. Additional Resources To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js. To read all the installments in our DevOps series, please click here or on the individual posts below. An Introduction to DevOps A Generalized Model for Automated DevOps A New Weekly Blog Series to Help Organizations Adopt & Implement DevOps DevOps Enhances Software Quality DevOps and Agile What is DevOps? Security in Continuous Integration DevOps Technologies: Vagrant DevOps and Your Organization: Where to Begin DevOps and Docker Continuous Integration in DevOps ChatOps in the DevOps Team DevOps Case Study: Amazon AWS DevOps Networking Solutions  

  The date was March 5, 1987.  My mom was in Northbrook, Illinois beginning her training as an Allstate agent for what seemed like a never-ending three weeks. I was eleven years old and staying with my grandmother.  I loved my grandmother.  She was the best grandmother ever.  This is mostly because she made me guava-paste-and-cream-cheese crackers every night much to my mother’s chagrin. Her greatness was cemented as she fell asleep while I sugared up. She didn’t even bat an eye when I stayed up past 1AM watching late night television.  In one fell swoop I was mystified by...

Michelle Dyson, Director, Business Transformation Group I’m Michelle Dyson, Director in the Business Transformation Group. I’m responsible for wide-ranging aspects of our transformation, including designing what the future DWP is going to look like and how we get there. Why do we have to transform? Because the expectations of our customers are increasing all the time. They (and we - we are all likely to be DWP customers during our lifetimes) expect to be able to interact with public services as they interact with all other services. And because we expect continued pressure to cut costs. If we get it right, transformation should help us to both improve customer service and to cut costs. We have a vision for what a transformed DWP should look like. We also now have a high-level roadmap showing us the milestones that will take us to our vision. Like a Rubik’s cube, our roadmap has different cuts of our transformation. One cut shows the milestones of our key transformation programmes. Another cut, for example, measures our progress in delivering on the enablers for our transformation, or pillars on which our transformation is built, eg intelligent use of data. This week, we’re holding a SPRINT DWP event to share the vision for the future DWP, and bring together some of the people who will play a part in transforming the department. We’ll turn the spotlight on our roadmap, and on the flagship and lesser-known services that contribute to it, and demonstrate that we are on the journey to achieving our vision. Still a long way to go, but very real and tangible progress. We can’t do transformation on our own. We need ambassadors across DWP to make it happen. Ambassadors to talk about transformation, to bring it to life in their teams, to spot opportunities for further transformation, to spot opportunities for join up including across government, and to be creative in removing barriers. SPRINT DWP. A great opportunity to demonstrate what we have achieved, inspire confidence in the next stages of our transformation and engage people in delivering it.

Today I presented our 2020 vision at the last of the Spring 2015 Sprint DWP events in Leeds Civic Hall. In the presentation I covered the "perfect storm" of pressures and opportunities for the department, and the need for a joined-up and evolving Business Design for the future, if we are to make the most of the opportunity. I explained the idea of High-Touch and Low-Touch services, to deliver the policy intent in a modern and efficient way. I finished by explaining the design process and the critical enablers in the business design, and the way we are bringing these into reality.  My requests for the attendees were that they should feel able to challenge work that doesn't join up, pass on this story, and recognise the vision is evolving. Several people have asked us to share the full presentation, so alongside our internal communications, here is what I presented in full.  (10 minute read)   Our transformation journey My presentation at today's Sprint DWP event in Leeds Civic Hall has three main aims: give some more detail about our vision for the future of the department; share some of the ideas that are behind that vision; and give some highlights of what we’re doing now to make it into a reality. Our transformation is now well underway and it’s gathering momentum.  We are past the point of asking ourselves if this is something we should be doing, and starting to get into the nuts and bolts of what is it really going to look like and how DWP is going to get there. We are in a "perfect storm" of external pressures on the department, including citizens’ expectations of us and the financial pressure we’ll face during the next parliament.  But we also have a huge opportunity through the change programmes that we are running, and our technology that needs rebuilding. If we are to get this right and make the most of this opportunity, we need to have a clear vision for where we’re trying to get to.  And we will need the help of everyone at Sprint DWP to direct all of our change efforts towards making it a reality.  For that to work, we need a joined-up Business Design to work towards, and it has to be both ambitious and achievable. The starting point Just after I joined DWP we held a Digital Transformation Group conference in Sheffield, back in April last year.  In the panel session I got asked "what does a great year look like?" for our business transformation.  That’s always a great question to ask (and we should keep asking one another). My answer was that it would be a great year if we could get to agreeing a much clearer view of what DWP would look like in the future, and start to align our change programmes so that they know which pieces of that vision they are building. So the good news is that we do have a much clearer view of our future, and we’ve produced a first version of a joined-up roadmap across the department that starts to show how the moving parts fit together. As you’d expect with a challenge of this scale, it hasn’t all been plain sailing! If everyone loves your idea, then you should worry it’s not forward-thinking enough. The picture Last summer we created a picture and a video to explain our transformation journey.  The photo shows us having a conversation about it in the business transformation slot at the Digital Academy.  We ended up showing it to about 1,000 people, and got lots of feedback that it was really helpful, and also lots of great suggestions for how to improve it. Great conversations about our future and the transformation journey at #DWPdigitalacademy today @DigitalDWP pic.twitter.com/lrZ9Ek2j2N — Andrew Besford (@abesford) July 22, 2014 We have come a long way since then, and we have worked out so much more detail.  So we wanted to create a new version that we could share even more widely around DWP to help bring our transformation story to life. And I’m delighted that we’ve unveiled the new version of the video today.  It was still "cheap & cheerful", but I am really proud of where we have got to - the team have done a great job of bringing people together from all over DWP to create a positive and exciting vision of the future. We’re also really excited that the video has a ‘superstar’ voiceover for the first time - featuring members of our Executive Team. Kevin Cunnington and Andrew Besford with our vision for DWP in 2020 A key message in the 2020 vision is that there are some things we do at the moment to deliver our services, which we don’t have to do that way in the future.  We have the opportunity to deliver a better service for our customers, and do it in a more modern and efficient way for our taxpayers. The customer experience layer describes DWP’s customer proposition in the future, such as "Better use of existing data", "More automation where it’s safe".  Those are the words which have been introduced across DWP in the last two rounds of our internal DWP Story events, so they should be increasingly familiar to our people. One of the aims of the picture is to explain how we organise ourselves in future to deliver that customer experience, across our people, technology and ways of working.  We want to be clear that it’s not just about building websites, but about our ambition for the way the whole of the business operates. High-Touch Low-Touch thinking A key part of the underlying thinking is about us making explicit choices between using "High-Touch" and "Low-Touch" ways of delivering our services. We’re saying "High-Touch" to refer to the parts of our services where we need to use manual interventions to operate the business.  That could be face-to-face, on the phone, or carrying out a back-office process.  When we do things in a High-Touch way, we are investing the efforts of our people, and that comes at a cost, especially when we factor in overheads like the buildings those people are in. We might choose to use High-Touch because of a person’s health condition, or we might do it because our data shows it will reduce the potential for fraud.  Either way, complicated cases become easier if our front-line people are presented with the right information, to help them give the best advice. The opposite of that is "Low-Touch", which refers to the parts of our services we deliver without human intervention.  Low-Touch means a simplified, automated way to achieve the same outcome, which is quicker or cheaper, maybe both.  DWP already has many Low-Touch activities today, like automated processing of payments. But at the moment we sometimes have to ask customers for information which they have already provided to us. Why would we do that if we were able to make smart use of information we already have, so that we can carry out the process automatically?  That’s better for our customers, and it’s better for DWP. We need to recognise the differences between High-Touch and Low-Touch, and we need to knowingly choose which is right at any stage to deliver services to customers. In our vision we want to systematically use Low-Touch whenever we can. One of the ways that we’re taking this to action now is that we’re looking at areas where we can build a proof-of-concept for High-Touch Low-Touch so that we can demonstrate it working for us. Is this realistic?  Technologies and ways of working that are now commonly used in all sorts of organisations give us the opportunity to continuously build up data and use it throughout a customer’s journey with us, in a way which hadn’t been envisaged back when most of DWP’s current IT was created.  So the focus is on making safe decisions in individual customer experiences, and also building up a big picture from the data, to make sure we’re making the right decisions in general, and to help us continuously improve. That’s why we’ve put our intelligent use of data story right through the middle of the 2020 picture, because it's now becoming central to the way we deliver our services.  And having the right technology and data science skills will be crucial. Continuously evolving the operating model Another important feature of this vision is that it’s a user-centric organisation that is constantly exploring and searching for what works, and making those ideas part of the way we operate the service for everyone.  In that sense I describe the Business Design as an "Evolving" Operating Model, rather than a static Target Operating Model. So this is not a set-in-concrete, linear description of exactly how the organisation will work in 2020.  We’re laying out the key moving parts of DWP in the future, and for some of these we’ll only build up the detail through many years of adapting and improving, working closely with our change programmes which inform, and are informed by, the overall design. Analytics and User Research in our 2020 Vision This is why it’s critical that we have our User Researchers understanding what our customers need from us.  We’ll know more about our users than we’ve ever known before, and this can help us make life easier for them, and for ourselves.  So User Research will remain a central feature of DWP in 2020, and already today we have BTG’s User Researchers working as part of the programmes. Thinking about the future costs to operate the business, how do we know that this is a credible story that will make sense from a financial perspective?  Our analysts have built confidence through their work, by looking at the opportunities to improve our current customer journeys with High-Touch Low-Touch thinking.  And of course our Analytics team will also play an important role in DWP in 2020, which is why they’re also shown here. The Business Design process I’ve covered why we need a Business Design, and some of the important features of it, but I also wanted to say a few words about the design process we’ve been going through to get to this point. This is "The Squiggle of the Design Process" by a designer called Damien Newman, which he uses to explain how things are uncertain in the beginning of a design process but become increasingly clear. The Squiggle of the Design Process, by Damien Newman  (CC BY-ND 3.0 US) At the start there was lots of uncertainty and it was very difficult to make a plan for how we were going to get there.  But we knew we needed to get to a reasonable idea of how the size and shape of the business will change over time.  For example we know all this is going to need people with different skills and a different grade mix, working in different ways. To get this right we have to describe how our people, processes and technology all work together to deliver our services .  The process of doing this is as much an art as it is a science, but we’re moving along the squiggle now, and we have made sense of the different moving parts. One of the things that’s become clear in our work is that at DWP we’ve used technology for years to support admin tasks, but we can now use it to deliver services in a radically different way.  So it’s becoming clear that we are now at a turning point where technology and data become central to the way that DWP operates. We’re starting to see the detail of the business design becoming a lot more granular than the general Civil Service Capabilities Plan (in areas like Cyber Security).  This work is helping us collaborate with HR colleagues to build out that plan to get the right skills in the right places in the organisation.  Even just introducing a common vocabulary we can all share is a big help. We’re now starting to get to the clarity we need on this, and we are at the point where the concept is clear and the focus shifts to delivery. Our Enablers Our Enablers are the six critical areas where we’ve identified we need to drive a step change, to "do more".  These aren’t the only things we need to do, but they’re the ones that we have to get right.  And importantly the Enablers are Business Capabilities so we mean "the things DWP is able to do" - the combination of the technology, the people and the processes, to deliver the business outcomes. Our Enablers: six critical areas which combine technology, people/locations and processes to deliver business outcomes We’ve drawn these as being under construction in the picture to reflect that they’re building our future, and they’re already underway. For example, Universal Credit is already building important parts of our "Decision Making Based on Trust & Risk".  We’re working together to drive out the details of how this becomes the way we operate across DWP, for example in Pensions. And we’ve mobilised a piece of work that will bring together all of the different aspects of "Data", which is central to the vision, so that we have a joined-up plan for what we need to create. It’s important that we all start to understand Government as a Platform.  DWP will be part of Government as a Platform, where government will increasingly be delivering services by sharing capabilities across departments.  We already have some shared capabilities, GOV.UK is a shared publishing platform, and Verify is a shared identity assurance platform.  There’s also the Performance Platform, and the Digital Marketplace.  The Government Digital Service are actively looking at what next, and their thoughts are around areas like payments, status tracking, and address details. "Tunnelling from both ends" How are we making this all real?  Nic Harrison and I have been using the analogy for a while of "tunnelling from both ends". When we say "tunnelling from both ends" we mean that Nic has been working with all of the in-flight digital programmes to maximise reuse.  That started with areas like storage and tools, which were the immediate areas where we needed to have shared ways of delivering our services.  This work has now matured to the point where Nic’s team is building the Digital Service Centre platform for Universal Credit. So Nic has been "tunnelling forward" from the present. Meanwhile, the Business Design has been "tunnelling back" from 2020, getting that clear link through from the future customer proposition and the way we want to connect the business together to deliver those services.  And in that work we’re now at the level of detail where we can see features, like the Digital Service Centres, and start to build our plans towards those. The tunnel is nowhere near finished but we now finally have that breakthrough where we can see the work meeting in the middle, and that’s building our confidence that we have been digging in the right direction. The ask My big asks to leave everyone with are: Be clear on how your change work joins up with the big picture (and challenge anything that doesn’t) Pass on this story about what the DWP of the future can be like Recognise the vision is evolving: We’ve said "we need to do more", and we will all need to work together to help evolve and grow it.  We can't do this on our own. Keep in touch by following Andrew @abesford on Twitter.