Blog

The CWL View

By Elliot Smart August 11, 2020
The future of IT Ops is collaboration and balanced judgement
By Elliot Smart July 15, 2020
Ever wonder why so many organisations struggle to become agile? I have watched, time after time, as Executives announced that their IT department was going to do things differently, that everyone needed to get on board to help them, and that the fortunes of the company rested on being able to increase collaboration with customers, change faster, and innovate more. Then the CIO/CDO/CDIO (or whoever) is tasked with kicking off a transformation programme, and maybe some money is allocated to make it look like they mean it. Then they go back to their day job of running the company. The 'Programme' looks at the delivery process and who is engaged with it, does some training and maybe hires or outsources an Agile Coach function, selects a couple of projects to get started with and then gets on with it (in the best traditions of the Agile approach!). The problem is that failure to transform is rarely based on the development method, or the 'project management' of it. Becoming Agile means that everyone is Agile, not just IT. To understand what it means to become 'Agile' you must first recognise why, of all words, this was the one chosen to describe it. In the Collins Dictionary it is as follows: (ˈædʒaɪl ) - adjective 1. quick in movement; nimble 2. mentally quick or acute 3. denoting a project-management system based on teams of workers who are empowered to adapt the development process in response to regular feedback Let's examine the difference between the first two simple definitions and the third, much more complex one. The first two are non-specific and can apply to any activity where some form of action needs to be taken quickly and/or safely. With the latter definition there is no sense of a lithe, nimble execution, but instead a depiction of a system involving many moving parts and activity phases. In the Theory of Constraints, a machine is only as fast as its slowest part (this is also known as the Buffalo Theory). With it's emphasis on engagement with the users, measurement and feedback, controlled investment through value prioritisation and autonomous delivery teams, Agile is a complex machine involving numerous actors, all engaged with a varying degree of cohesion. The Collins description is therefore wrong. It is focused only on Project Management, which is also the mistake many businesses make. Since Agile is inherently described as a system, a ll active participants in an Agile environment should be examined before we can use feedback to improve it effectively. This includes users, governance and control, finance, executives and even end customers where their engagement of feedback is critical to continuous improvement being undertaken at pace. My favourite definition of Agile is a simple one: Agile: q uick and well coordinated in movement For Agile to deliver its promise it must be quick - to be quick it must not over-promise in the first instance - to be quick it must be well coordinated and controlled - to stay quick coordination must continue beyond the kick-off and throughout ongoing delivery - to stay quick, controls should not unnecessarily slow things down. Looking at why businesses fail to become Agile, we can see that these are usually linked to the circumstances necessary for Agile to succeed: Whilst development teams and some members of the user community become trained in Agile methods, Design Thinking, and some of the tools like Mood Boards and Kanban Boards, critical 'other' stakeholders are not trained and therefore, at best, add little value or, at worst, create friction and hurdles. Limited experience in Agile delivery, combined with a false belief that planning slows Agile projects down leads to poor coordination between the delivery team and other stakeholder groups, and a lack of understanding of what interaction between them is designed to achieve. Product Owners are not given the financial or operational empowerment necessary to continuously develop and improve the product, but are instead onerously reviewed and challenged by Portfolio Managers and Financial Controllers who lack understanding of the value of the product and its various features or component parts. Definitions of 'Done' are too rigid in the first instance and seek too high a value return at the first development review by Executives or Portfolio Managers who do not understand the continuous improvement lifecycle and its investment profile. Critical: Poor early results (and a sense that money is being wasted) lead to the re-introduction of Project Managers and a return to some Waterfall behaviours and methods, which deliver a hybrid methodology that often takes the worst aspects of both and undermines the iterative 'learning' nature of Agile. Becoming Agile is the result of practice with learning As experience grows, so the expectations, coordination, interaction and controls are improved. This is the result of Agile's focus on the feedback loop and when combined with short, rapid development phases, quickly trains teams to deliver (particularly true of Scrum, DSDM and Extreme Programming delivery methods). However, it can take several iterations for projects to deliver these improvements to the point where project outcomes are improved. If you introduce project managers, project controls and apply Waterfall mentality to an Agile activity you increase the chances of switching off (or otherwise mangling) the delivery, and reverting to old ways. Just like learning any new skill, reaching a level where you are adept, capable and comfortable is hard work and takes investment. When those that review your progress are not a part of the transformation, early attempts will be unfavourably measured against the capabilities and outcomes of previous methods and the risk of failure rises significantly. Start by understanding who and what needs to be coordinated. In the next blog on this subject we will investigate how the moving parts of this system can be established, nurtured and measured to ensure that Agile is designed for your company so that how you finance, plan and execute your projects is aligned with how your business is designed to operate.
By Elliot Smart July 10, 2020
At a time when a digital revolution is disrupting the business landscape and forever altering how IT is deployed, serviced, and used, a global giant's scale increased the challenge of achieving the transformation required to remain a dominant force. A programme of creating new innovative products and services was underway but struggling. Asked to become involved by our associates in Mooody Cow Ltd, CWL engaged with the EMEA CTO to investigate how to unlock the concept of an innovation-led customer operating model, taking into account the company's strong governance culture and long-established sales and delivery methods. A critical factor was the existing portfolio of services which, though facing a rapid decline in sales, continued to deliver the vast majority of existing sales and revenues. The account management and sales teams were comfortable promoting the traditional products, despite the recent trajectory, and not attuned to the challenges of collaborative innovation with their customers. Further complications included a challenging post-merger business structure, in-flight workforce restructuring, and the complex procedural hurdles typical of global corporations. From the start, we focused on identifying where we were beginning the journey from so that we could quickly re-validate the current plan of action and ongoing activities. Within 3 months, we established a revised strategic vision, target operating model and accompanying transformation strategy. These were designed to achieve cultural, technical, and organisational changes necessary to pivot the wider business towards emerging buying practices without damaging current service revenues and contracts. The new operating model included changes to sales processes, new forms of customer engagement, solutions delivery and partner management. These were designed around Agile methods, Design Thinking and Complex Adaptive Systems modelling to rapidly meet highly demanding customer expectations of technology. They were also designed to promote up-sales of traditional services and solutions, re-using these to simplify and narrow the scope of innovation activities. Critical to success was the establishment of multi-talent teams at the commercial and investment level. Each team serviced a specific industry and included an account manager, sales lead, consulting lead, CTO and Digital technology lead. Teams focused on the identification of common customer needs and the investment profile that would take them into the marketplace with workable solutions and subsequently acted as a 'Product Board' to support allocated Product Owners for each emerging initiative. CWL established a value management team which provided leadership and coaching to these teams, ensuring that the teams concentrated on the most valuable solutions and that new ways of working were understood and assimilated into existing skills and inter-department processes. In this way investment could be unlocked for non-budgeted developments, and oversight elevated to the Executive level. When CWL was first engaged, close to the end of the financial year in 2019, only $8m of a $25m sales target for innovation-led sales had been met. By the end of the 2019 Financial year $38m sales had been achieved and an additional $58m was achieved in 2020. At the start of the current financial year the new operating model has created a sales pipeline of over $400m and is expected to deliver over $100m revenues. At the same time, 2 new industry products have matured beyond prototype level and several more are in the delivery pipeline.
By Elliot Smart July 7, 2020
We've all been there. The company is unshackling itself from endless planning, re-planning and progress monitoring of projects that are always over-budget and rarely deliver to the original specification. You are going 'Agile' There's lots of new terminology, new roles, new ways of doing things, and it's exciting. What's more, it's now OK to get it wrong, as long as you quit quickly. Projects are now 'Experiments' that are 'Safe to Fail'. We can get to a prototype quickly and work out the next steps from there. It's a brave new world. Only, nobody told the Finance department, or the Executives who are tasked according to annual budgets set months ago, or a project portfolio that is the last word in the agreed IT spend for the year. For all of these stakeholders it is difficult to explain why you spent 20% of the budget and then just quit the project with nothing much to show for it. And what's worse is that you intend using this same approach for all of your projects; maybe they will work and maybe they won't. The problem is, i f you present the outcome of an Agile project in the same way as for Waterfall, then governance and budget allocation will become an increasing challenge with every 'stopped' project, and your transition to Agile will fail because you wont allow your projects to fail. Agile represents a different way of managing value and developing outcomes In Waterfall, every detail of the outcome is established as a metric for success, with some being Critical Success Factors. These are promised at the start and measured at the end. Since all of the money is allocated up front, and project management is concerned with overall outcome more than specific features, then it can be impossible to manage the cash for value relationship of specific features and/or outcomes. With Agile, individual outcomes have value and there is a minimum set (the Minimum Viable Product) which are required for an Agile project to be said to have delivered. Everything else is additional value at additional cost. This relationship between value and investment is micro-economic and enables far greater Return on Investment if it can be managed properly. The problem is that no project will survive Finance department scrutiny of every activity, or project governance by a portfolio management function - apart from the enormous project overheads, what happens when expected ROI is missed for a key feature that is the catalyst for other outcomes? Thankfully, the structure of delivering Agile is to enable self-organising teams and value/outcome-centric Product Managers. The relationship between these is to manage the detail, and as any transition to Agile progresses, so the experience and skills to do so effectively improves. For governance and financial control use Value Management V alue Management enables a more flexible relationship between a Product and it's financial investment by focusing on the rule of diminishing returns within every project, and then working with Product Owners to determine when the money is best spent elsewhere. Value management allows you to do this without diminishing Executive and Finance Department scrutiny of the overall returns on the corporate investments being made. For this reason, implementing Value Management as part of your Lean Portfolio Management is a critical part of your digital transformation journey. Value Management has one eye on specific investments but is more concerned with assuring a balanced investment within the confines set down in the annual budgeting process. It differs from Portfolio Management in that balancing the investment can be done within and across 'living' projects and product developments. Value Management throttles and accelerates the quest for value between in-flight developments. A Value Management function will validate expenditure in successful developments, investing in the Product Backlogs where value is perceived to be within grasp, and challenging expenditure on projects that have reached the limits of efficient value extraction. To this extent, effective Value Management is extracting maximum value from all projects at all times and highlighting those projects that have the greatest opportunity for success, as well as those that may have reached the end of the road. This value extraction across the portfolio creates an environment of trust and provides visible outcomes from the IT investment budget as a whole, meaning that some of your projects will genuinely be 'Safe to Fail'. For Agile to work it needs to develop trust in the value that is generated by the method across the portfolio and not to focus on specific investments. In a similar fashion to personal wealth management, this is achieved by managing all Agile projects within a portfolio, reporting on the value under management and explaining investment decisions at a higher level. To evaluate how your business can implement Value Management in your digital transformation contact us at info@cwlconsulting.com
More Posts
Share by: