In most organisations IT is a central function. It started off as the experts who ran large mainframes with huge tapes. Weird science to many of the day. Even, Tom Watson of IBM predicted there would probably only be need for 5 of these things in the world. How wrong he was. IT then became the place that looked after all the computers on our desks. Growing to the hundreds and thousands. It grew to a department looking after e-mail, and a PC and handheld device for every employee. We’re now talking hundreds of thousands of devices within a major enterprise. Then IT started looking after the company website, and the infrastructure that manages all of our enterprise applications. All the while they were probably dealing with the telephone systems too. Basically, anything Technology related. Along the way it also picked up other disciplines: software engineers and solution designers and enterprise architects and service managers and user experience experts and project managers and testers. All this seems an eclectic mix of responsibilities, and it seems odd to lump all of these under one umbrella called the IT function. I wonder why we did. Was it because it was still weird science for the masses. It was only the technically minded folks who really got it, and it wasn’t really what the business was about. Unfortunately, for most companies now, IT is the business. Our products are IT based. Our service is IT based. Our processes are enshrined in what IT can do, and our people are only as good as our IT systems allows us to be. Our customers are tech savvy and they engage with us in new ways. No longer can an IT service manager really be separate from ‘the business’. If IT doesn’t work our business does not work. A software engineer who develops the core user experience, operational experience, process experience is the front-line of the brand and the customer experience. We need a new approach for IT.
Lean IT is a set of concepts that has been gaining much traction over the last decade. It has started to look at how we can bring in some of the lean manufacturing concepts into the IT world. It started by looking back at the toyota production system, and what made them produce great products that conquered the US car market. But, today people are scrutinising the Toyota Product Development System in more detail because they realise that innovation and creativity is not so much about removing waste and variation out of repeatable manufacturing processes, but developing compelling products and services that require pushing boundaries, exploring solutions and working with customers more closely. It is inherently about more agile ways of working. It is about Lean Software Development and Lean Product Development. It is about a philosophy of collaboration, learning and creating feedback and empowering people to deliver what is right and in the right way. It represents the world of strategy promoted by Henry Mintzberg or Gary Hamel with their focus on learning, innovation and creative strategy in shaping and creating new markets. This is not so much about doing what we’ve always done more efficiently. It is about creating customer experiences and products that are loved and sought after.
The Lean IT movement looks how you might enable and sustain a lean transformation that enables you to be more customer focused, and how the culture of the organisation needs to develop to embrace collaboration, and working across boundaries to deliver an outstanding service for customers. This is in direct contrast to how most businesses set themselves up. Functional silos are normal. There is a belief that economies come from scale by bringing together functional expertise. This is not untrue for some things. It comes at a cost though, so shouldn’t be considered a general rule of thumb in environments where innovation and creativity are being sought, and where speed is essential. The cost is that these functions and departments are focused on their bit and not the end-to-end flow of value from a customer standpoint.
Bringing new products and services to market is a value stream known as Concept-to-market. This includes creative input from all functions across a business. Doing it fast will require us to focus on the value stream goal and not the functional goals. The same can be said for another key value stream that exists in most organisations, Order-to-Cash. Sales and Delivery need to work in tandem. The IT supporting these functions needs to work.
There are some elements of the central IT function that can and should remain central, but much doesn’t or shouldn’t have to be. How might you decide? Put simply, does pulling people into a silo slow down delivery in the eyes of the market in a way that might hamper our competitiveness? If yes, you should consider focusing on the value stream. If no, you might consider developing it as a function. If it isn’t on the critical path then it might be better value to consider economies of scale.
I prefer to consider things from the customers’ perspective first. After all, there is no value stream without them. We can’t make something more cost effective without first satisfying our customers to the extent that they are prepared to pay for the product or service. We actually cannot remove waste from a value stream without their being value first. So, what does the customer think about our organisation design and the place IT has in it? Not a lot, but they might feel the consequences of our choices. What do they think about the service they receive? Do they care how we set ourselves up? The person I use as my benchmark on this thinking is my wife, Helen. She always has great suggestions on how service can improve from the companies she deals with. She couldn’t care less about the organisational structure and decisions going on behind the corporate walls on how we manage ourselves and set goals. Her suggestions always make me smile as I then start thinking about how the organisation will be set up and why her suggestion will be a nightmare to implement because there will be no direct line of sight between the backlog of work for the specific system or process that will need to be changed and the customer experience being felt by the paying customer. There will be many layers between the person who wants something (Helen) and the person who can do something about it (a software developer or some other creative engineer who knows how things work).
The ‘Order-to-Cash‘ lifecycle is a great place for organisations to start when examining their focus. It exists for most (if not all) profit making enterprises on earth. It might look different in different industries and organisations, but at the highest abstraction everyone has one. Think Amazon and buying a book. Think ordering broadband. Think getting a new credit card (maybe the cash is going in the opposite direction for this one). All of these will have many different computer systems supporting the process. That could be the telephones, the e-mail, a website, the Customer Relationship Management system, the Billing Engine, the Workflow Engine, the Service Management systems, the Inventory Control systems. All of them will have a part to play in any fulfillment journey. For some forward thinking companies this might also include an interaction on facebook. Another one through twitter. These all play a part on the experience of interacting with the company. Each interaction gives us an opportunity to delight or disappoint. From a customer’s perspective, if one of these elements is not functioning then it isn’t working. It doesn’t matter if our CRM system has a 99% Service Level Guarantee from supplier X if the billing engine can’t allow us to complete an order. The customer doesn’t care about our CRM or our billing engine. If the Website is down, the service is down. It doesn’t matter if we cannot complete an order because of an out-of-memory error within our workflow engine that passes jobs and tasks around our enterprise. The customer just doesn’t care.
If every system has a target of 99% uptime and there are 10 systems in a customer journey then the actual uptime ‘target’ is now less than 90%. 1 in 10 times a customer might come along and something not be right. That is a big deal. Imagine now 20 systems. We have sub-optimised the whole system from the customer perspective, but we’ve probably made sensible organisational design decisions and the targets we’ve given our staff are probably okay, right? Wrong.
This becomes worse when we consider how my wife’s improvement idea might make its way into the future service. This is the intersection between the Order-to-Cash processes and the Concept-to-Market process. If each system has a queue of work that they are crunching through in some arbitrary order, or if a critical transformation project is hogging all of the delivery capacity of our business, then it might take years for any idea to filter through our Concept-to-Market process to be implemented. We might be slowly losing our customers because we are focusing on our own internal transformations. Our functional decomposition seemed a good idea to group people together into logical departments of like-minded people who all have the same goals of CRM or Billing, but they do make our ability to respond to the people who make us money (customers) in a really terrible way.
The concepts behind Lean IT teaches us to think differently. We need to focus on the Value for our customers. We need to focus on the Flow of our improvements and new features of their service, and how we interact with our customers to find out how we are doing. And we need to focus on the quality that they receive from our service. Every IT interaction is a Moment of Truth.
I know we need to consider our IT strategy in terms of how we might share data across different products and services, and how we might re-use capabilities in order to help us launch future products more quickly, but this does not necessarily mean we need to bring everyone together into functional silos. The customer experience is what attracts our paying customers. It is what will keep our paying customers. It is also, if we don’t get it right, the reason why people will leave.
We need to get the tension right between the customer experience and the architectural purity of our systems and organisational design.
Our first goal is to look through the eyes of the people that create value, and then figure out the grouping, management and scaling problems that all enterprises have. We need to encourage customer perspective in every job.
The PMI Announcement
As a result of the news that the PMI have endorsed Agile Project Management I was doing some reading around the topic and came across this article. The question posed seems like a very traditional project management question because it is asked from the basis that everything is delivered at the end of a project. It doesn’t consider that a scope could be wrong, or the times are impossible or the costs are not enough. This is what project managers are taught and this is one of the reasons that so many projects fail, in my opinion. To be able to predict an arbitrary date sometime into the future that is months, years or decades away is a nonsense. Predicting how much money you might spend or what the scope might be during that period seems even more impossible to my mind. And when you finally throw in poorly managed engineering techniques which diminishes the quality, you are always left at the end increasing time, budgets and reducing the scope. Without having built up any knowledge as to whether your predictions might be accurate or not people are committing to the parameters of time, cost and scope (quality is always high at the beginning of any project when it is just a thought in someone’s head, but diminishes when the reality of building stuff actually kicks in which is why the commitment of any project doesn’t really consider quality).
I know this is quite a glum scenario, but there you are. It is still the most common scenario that I see in environments where projects are the norm and commitments are made to be concrete on the back of an approved project. I think the fact that the project is really the only construct discussed by the project management community is what creates this thinking – the clue is in the title! I remember saying to a client a couple of years back ‘I guarantee 100% that you will NOT get 100% of the things you are thinking of right now on the date in your project plan that is over 18 months away. But, how about we work with a little more uncertainty and we aim to deliver 60% to 70% between this date and this date approximately 18 months away so that we can get something into the field for a real trial with real customers, and we would have already got feedback on what we have been doing at regular intervals beforehand. Which one would you prefer?’ The debate that this created was interesting, because people started to say: ‘well, it would be good to get something to play with before the end date and something we could show our customers’. Others were still very much: ‘well, we have to deliver everything on the date’. So, I simply asked: ‘what is everything?’. Stunned silence followed.
I know many of you will have been in similar surreal conversations in your work too, but it always strikes me as a little… well, stupid. The proliferation of the idea that complicated projects can be predicted so accurately is absurd. The XP game has demonstrated many times to many teams that even the simplest tasks (like blowing up balloons) cannot be predicted accurately until we have a few goes at it. If we try the same project over and over again, I guarantee we will get good at that project.
You get what you think about
I have come across this saying a number of times: Watch your thoughts for they become your words. Watch your words for they become your actions. Watch your actions for they become your habits. Watch your habits for they become your character. See your character become your destiny. I don’t know who this should be attributed to, but I do like it. In this context, it brings to my mind the fact that the focus of the project management community is focusing on the wrong things.
I remember when I got my first real budget responsibility as an IT Director. It was a very significant sum of money and one of my more mature and long-serving colleagues took me aside and said: ‘Phil, always hit your numbers. Never underspend or overspend your budgets. This is the most important aspect of your job. Hit your numbers and you will be fine.’ The young, idealistic me was a little taken aback by this advice. I thought the point was to deliver the projects and programmes, but apparently I was mistaken. How naive.
For me, the focus on trading time, cost and scope off against one another is the wrong focus. I think managers should be focusing on Value, Flow and Quality. Each of these words require many more posts to do them justice, but my intention here is to say that the project managers (or any managers involved in delivering products, services, systems, projects, programmes etc) should focus on creating these three things in their organisations. I am not arguing that cost control is unimportant. It is important. But, it is ridiculous to believe that this is the most important thing. The biggest ‘cost’ of a business is a failure to turn ideas into valuable products and services that meet or exceed the expectations of customers. Going further, there is an implicit cost of not delivering quickly. For every extra day a feature takes to be delivered a day has been lost reaping economic benefit for that feature. This is the Cost of Delay and managers need to understand this.
Value is not fluffy
One argument I have heard on numerous occasions is that it is difficult to really understand the value of an individual feature or activity, and that’s why we focus on cost. We know how to deal with costs. Value is difficult to measure. This makes no sense to me. If it does to anyone who reads this, please try to enlighten me. I do want to learn.
In the agile community the word value is used a lot. In fact, in my experience it is overused and abused to argue for the things that people want to do rather than things that have real value (i.e. money/economic benefit). I hear the cries now: ‘What about other value types such as happiness of employees?’. Happy people has an economic benefit. Heskett et al postulated a model called the Service Profit Chain that links employees, customers and quality into a profit model. The challenge is creating a value model that works for your business that allows you to trade off different features, requirements and improvements in what you intend to deliver and the way you intend to deliver them. Please remember that any model you create can be refined as you learn more about how that model is being used. You might not get it right first time, but you can definitely have a good debate with your finance director about how you trade things off for the highest economic return.
Projects are short-sighted
One of the problems with projects is that they are inherently short-sighted. A project manager is judged on their ability to deliver the project, however they do that. It doesn’t matter what state they leave any underlying IT systems, product architectures or people who were working on the project. Managing the assets of a business with a view for the longer-term is a philosophy that is promoted in lean, and is an important principle to be instilled in managers and should be considered when designing any organisational structures and philosophies. When I see organisations that are set up solely around projects and not the underlying components and systems I get nervous. If more than one project manager affects a common platform without any need to care about the quality they leave behind and the ability for the next project manager to be successful then there is an issue. Projects do not promote flow. They should be used more sparingly than they are.
Quality is not negotiable
One of the strongest statements that has come out of the agile community is that Quality is not negotiable. As I mentioned in a previous post you need to demand technical excellence. However, as I mentioned previously, when people think about quality at the inception of a project it is easy to think that your project is going to be of the highest quality, but reality bites when you get going. It is easy to have standards about your engineering when you are in the throws of thrashing out your requirements and design in a traditional project. But, why do we believe spending our time on requirements and design at the beginning of a project is more valuable and important than spending time of creating the right environment for building high quality software? Quality and productivity are inextricably linked. Poor quality now will slow you down in the future. Great quality now will increase the flow of value and improve speed-to-market over the longer-term.
A virtuous circle
Time, cost and scope are often called the Iron Triangle. It sounds like a very negative phrase. I prefer to think about something that creates a virtuous cycle. Value, Flow and Quality creates a virtuous circle. This does not mean you are challenging the laws of physics as the article mentioned at the beginning suggested, but it does change the mindset about how you can manage your product, service and IT deliveries. The idea is to go as fast as you can possibly go. Managing projects to time, cost and quality hasn’t given us the ability to go as fast as we can go. If the PMI’s announcement starts to educate project managers to start thinking this way, then I believe it is a really valuable move for our industry. Time for a change? I think so.
A few weeks ago I was facilitating a session with a group of people responsible for delivering a software platform to support a number of very large institutions in complex markets. The session was centred around how you could create more collaboration, predictability, communication and feedback into their delivery cycle and how the different groups and roles might better interact with each other to deliver higher quality, valuable software and solutions to their customers. They have had problems meeting their commitments to-date and when they have delivered it hasn’t really met their customers’ requirements. A common problem that we’ve all heard about many times now.
Their normal approach is full of hand-offs, long lead times between specifying something and seeing it in reality to provide real feedback, and very document rich to support people’s ailing memories across these long lead times. During this session there was a real feeling of parochialism. The Development Manager was arguing the QA needed to step up to do such and such. The QA Manager was saying the Dev were always delivering sub-standard work. Everyone was pointing at the requirements still being worked on. And the designers and architects had such grand plans that weren’t achievable. It was the classic example of the silo organisation. The interesting thing is that all of their backs are against the wall because they have deliveries to hit. My point to them was: QA fails, you ALL fail. Dev fails, you ALL fail. Design fails, you ALL fail. There was silence in the room and then the penny dropped. They realised that they should be a team.
I read two blog posts yesterday that made me think about this situation. The first was the TradableQualityHypothesis by Martin Fowler. The second was Mike Gaultieri’s ‘Want Better Quality? Fire Your QA Team‘. Both posts were ultimately about the ownership, accountability and responsibility of quality. For some organisations they believe that quality is improved by spending more time on getting the requirements right. For others it is about getting the design right. For a lot it is about spending all the time on QA. Not many firms actually believe (in my experience) that the developers are really the ones who can help because it has become for large enterprises a commodity – which is completely wrong. However, for the teams and organisations who actually produce high quality work they understand it is about everyone systemically collaborating and working together to develop solutions. Everyone is responsible for quality. Interestingly, in Mike’s article, the extreme position of firing the ‘Quality’ team had the amazing effect of everyone else taking accountability and responsibility for the quality of the output. It would be interesting to understand what actually happened and if it supported the hypothesis of Tradable Quality too. My guess is that the Internal Quality was increased significantly as a result.
I’m not necessarily espousing that all teams need to fire their QA departments, but I am very much of the mind that all of the roles and responsibilities need to be blended into a one-team mentality whereby everyone succeeds or fails on each others’ quality and performance. The key thing for me is that Managers and Directors need to understand that they will damage their future business unless they really understand this. As I said in my last post, Demand Technical Excellence, or you will all have a case of high dynamic complexity and lots of finger waving when the IT platforms grind to a halt.
In his book Solving Tough Problems, Adam Kahane describes 3 types of complexity: dynamic, generative, and social. Dynamic complexity describes the time and distance between when a cause is in introduced within a system and when the effect is stumbled across. The closer the time and space of cause and effect the lower the dynamic complexity. Generative complexity is the subject of how well known a problem is and how many time that problem has been solved. In other words how predictable and familiar a problem is. The final complexity type, social complexity, is about how aligned people and groups are in terms of assumptions, beliefs, values and objectives. A well-functioning would ordinarily have low social complexity because people understand the values and objectives of the groups and take the time to share assumptions.
In emergn our jobs allow us to work with teams, projects, programmes and business units who are all looking to solve complex organisational issues that contribute to delivering products and services. The techniques we deploy from the agile and lean philosophies are geared towards lowering these three areas of complexity.
IT is Business
My main interaction within enterprises are with IT Directors, CIOs, leaders of business change and other Product/Service Directors who have responsibility of delivering new or improved products and services to their customers. One of the similarities of all our clients is that their businesses are highly reliant on IT deliveries and the quality of the software that forms the fabric of their operations. In fact, most modern organisations are now so reliant on IT that any IT transformations are really business transformations. This is quite a problem for a lot of businesses because a lot of people still see them as separate. The old thinking of ‘we need to outsource software engineering/IT as it’s not a core part of our business’ needs to be re-looked at or, at the least, needs to be understood better so it can be managed better.
10 Years of Agile
I have been visiting a number of our clients over the year who are undergoing major transformations in their IT systems to better support their business need for increasing speed-to-market, lowering the total cost of ownership and creating better customer experiences. This is a very common set of objectives and most companies are turning to agile and lean for solutions. Over the last weekend, 33 people from the world of agile got together to celebrate the last 10 years since the agile manifesto was introduced and to discuss the next phase of evolution. The first area that has been mentioned in every write up of the event is ‘Demand Technical Excellence’. In my role prior to emergn I was responsible for tens of millions of pounds of software and I recognise this point to be so important. I am often astounded (and dismayed) by the lack of interest by my peers in the need for excellent software craftsmanship and standards. Even more discouraging is the belief that this problem can be outsourced to a company whose fulltime occupation is to deliver software yet fail to show the levels of quality you would expect. This belief is often a bout of wishful thinking and sometimes comes with the belief that the harder someone stamps their foot and demands quality the more likely they are to get it. My view is that if you want quicker speed-to-market, lower cost-of-ownership and better customer experiences then you’d better invest in quality. Focusing on lowering the cost and speed of change of your software platforms will have a huge economic benefit for a business and will allow your customers to participate alongside you to develop excellent features that they really, really want. For me, this renewed focus from the industry is an excellent outcome of the event.
My advice for enterprises is that they’d better hire people who really care about and understand software and their business, and know how to really manage and monitor the software being delivered and how it is delivered by outsourcing partners. Relying on wishful thinking and contracts that ‘protect’ them will not be enough to remain at the top of increasingly competitive environments. This is a case of high dynamic complexity. Poor software engineering has massive implications to a company yet the effects of the cause are noticed years later and for years to come and across many areas of an organisation. This means the problem is not a simple one to solve, but one that will have a material benefit for a long time to come.
Companies that have moved forward with agile and lean transformations including rolling out Scrum, Kanban and other people/process oriented changes are making good strides forward which shouldn’t be ignored. However, without the investment in the quality of software and improving the technical excellence competency, the transformation can only go so far and any investments in whizzy new strategic architectures will probably end up in the same place.