Infamous

Have you ever seen a program or show by Derren Brown? If so, you might believe magic does exist in some real sense. What he does during a show is nothing short of breathtaking and has people scratching heads and whispering loudly as to how his wizardry is achieved. Recently I went to see his latest stage show, Infamous. Without giving away any of the details of the show (which was excellent), it made me think about creativity, talent and the path people travel to develop their skills. He weaves a story throughout the show about the trials of his childhood. It seems much of what happened shaped him and helped him hone his skills and passion, and, in some way, developed his desire to be infamous.

Sir Ken Robinson spoke in his 2006 TED talk about creativity and how the whole of our education system (indeed all education systems on earth) systematically remove creativity throughout school by focusing more on numeracy, literacy, logic and critical thinking rather than allowing people to explore their creative potential. His talk is funny and compelling, and makes you think about how you were educated and how your children are going to be educated. You should watch it if you haven’t. I agree with the thesis and I see the output of our education system every day – generally, folks shy away from innovation and creativity for fear of failure and non-conformity. Ever heard the term ‘I don’t want to stick my head above the parapet’? Our education system and the modern large company workplace seem to value similar things: conformity, standardisation and management-by-objective target setting. For the orthodoxy these words are all reasonable and positive things. Yet, they are the very things that remove creative thinking, make people compliant and turn people into sheepwalkers, and ultimately remove creativity and innovation from the workplace. In his book, The Element, Ken Robinson talks about many people who found their passion. Their life’s work. All of their stories are about trials and tribulations. It touches on the failure in the school system to captivate and motivate that person and how they developed a tenacity to find their talents elsewhere. Through these trials each person developed the character, found their passion and developed their skills to a point that they are in their element. He asserts that some of the most successful people you will ever meet didn’t do well in school.

In a previous post about the power of environment  I touch upon the influences that shape us to develop skills. Every one of us goes through a formal education system and that environment has a different effect on every person. I believe we need to reduce the idea of conformity and standardisation, and improve the chances for people to develop their own passions. Everyone needs trials. And they need opportunity to compete, react, rebel, create, fail, create again, fail again and again and again. Much of this has been removed from schools in favour of teaching specific things to pass tests. It doesn’t help us invent and create new things. People (children and adults alike) need the support to build the capability to keep dusting themselves off and trying again.

Workplaces are becoming extensions of the education system as technology moves faster now than ever before and things we are need now to compete in the modern business world now were only invented in the last 10 – 5 years. Most of us couldn’t have learned those things within our education system. They are alien. The problem is that neither the workplace nor the education system has the approach to deal with this reality and it comes down to capacity of the individual rather than a deliberate approach to help build the capability.

This is what sets the stories like Derren’s apart from all of the people who were discouraged to really develop their passion and stopped. This is the bit where the system doesn’t work. We need an environment that works the whole brain and body, and spirit to keep trying regardless if you conform to the norms or not. It cannot be just about focusing on words and numbers. Failure and creativity are not the same thing. But you cannot be creative without being able to fail. I bet Derren did many times.


Predicting the future?

Have you ever wondered what education might look like in 50 years?  Could this affect your business?  Do you know what future skills your business might need?  The internet is changing many things, not least education.  How about the political landscape?  Would a collapse of democracy affect you?  Would a supreme leader of Earth change the way you did business?  How would you react if international air travel was banned?  What technology trends out there will change the way consumers interact with your product?  Do you think your products will make any sense in 15 years time?  The world’s population was 2.8 billion in 1954. It is currently 7 billion. In 50 years it has more than doubled. What will happen in the next 50 years?  I wonder what the next world wide web is and how it might support 14 billion connected people?  Is this an opportunity of an increased marketplace, or does this create a problem?  This post from jobsworth really resonated with some things that I’ve been thinking about recently during my travels and client engagements.

One criticism that enterprises sometimes throw at agile methods is that it isn’t strong at dealing with future needs rather preferring to focus on the immediate needs of the here and now. It is true, most agile approaches do look to break big things down into smaller incremental chunks that can be used to build up a working model of reality by focusing on empirical feedback and working solutions, and focusing on the most valuable items that we know about today.  After all, people only really know what they want when they see it and when it feels urgent and real.  But, this doesn’t mean we should neglect the future or not even plan for it.  Some things take a long time to put in place and there is no point waiting until it is upon us to deal with it.  It will be too late.  We know education and capability improvement programmes take a long time to bed down.  We know things that materially change society don’t happen overnight. We also know that some big problems require big solutions.  But not always.

Agility is not about doing Agile.  It is about being able to respond to market conditions and forces.  As the famous Wayne Gretzky quote says you need to skate to where the puck is going to be, not where it has been.   If this is the case we need to be scanning the horizons, taking risks and learning fast.  In sporting terms this would be known as ‘reading the game’.  The best way to respond is to change and opportunity is by being prepared, learning our industries, examining other industries and learning about different walks of life and having time to consider what might become.  Oh, and it would be useful to have working practices that allow you to respond and react to changing conditions and priorities.

“I skate to where the puck is going to be, not where it has been.” – Wayne Gretzky

Enterprises today are successful based on what they have done in the past and present, and are full of people who have made great careers based on those conditions.  It is hard to challenge the things that made you what you are.  But many business models are being challenged.  Customers are changing.  Technology is changing.  Society is changing.

These enterprises might have people who see potential shifts that open up future challenges and opportunity, but how does the ‘elephant dance’ as a whole? The Scenario Planning process devised in Shell was a way to improve the overall management of one of the biggest companies in the world to better react to future possibilities.  Scenario planning was their way of working through extreme scenarios that are unlikely to ever be 100% true, but have core elements of truth and possibilities that can help managers create better responses to changing and uncertain conditions.  When people are open and conscious of potential changes, they are more likely to react and spot ways to solve future problems.

In his book, Joseph Jaworski explains the key elements of the process:

Instead of relying on forecasts (which are invariably wrong) the Shell Group does its planning for the future through the use of decision scenarios. Scenario planning [...] is not about making plans, but is the process whereby management teams change their mental models of the business environment and the world.  In the Shell Group, scenario planning is a trigger to institutional learning.  A manager’s inner model never mirrors reality, he explained – it’s always a construct.  The scenario process is aimed at these perceptions inside the mind of a decision maker.  By presenting other ways of seeing the world, decision scenarios give managers something very precious:  the ability to re-perceive reality, leading to strategic insights beyond the mind’s reach.

Scenario planners [...] included experts in economics, sociopolitics, energy, the environment, and technology.  They conduct ongoing conversations with fifty or so top managers in the Shell Group and with a network of remarkable, leading-edge thinkers from around the world in many disciplines: politics, science, education, business, economics, technology, religion, and the arts.  Every three years or so, they synthesize this information into two or more scenarios – stories about how the business might evolve over the coming years and decades.

This process is also highlighted in solving tough problems and was a key enabler to unsticking some of the really hard problems that South Africa once faced.  I wonder what some of our famous brands and traditional businesses that we all know and love today will look like in 50 years time.  It will be interesting to see how software and technology will be dealt with in the future enterprise as more core processes and experiences are enshrined in technology interactions.  I wonder if business leaders and technology leaders will be one and the same thing.  I wonder what capabilities people will need as standard to operate in the business place of the future.  I think an institutional, systemic process that encourages organisational learning that encourages real examination of future trends and marketplace dynamics, plus an approach to delivery that embraces change is a powerful combination to consider.  I wonder who will embrace such approaches and do this well.


From a customer’s perspective

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.


Lacking a spine

Last night was a terrible one for Manchester United. They were comprehensively beaten by Newcastle United; A team six places behind them in the premiership. In some of the post-match reports the spine of the Newcastle team were heralded. This is a phrase that you often come across in football (soccer) and many other team based sports.  The spine of a football team is: the goalkeeper, one of more central defenders, one or more central midfielders and at least one of the forwards.  The spine of the team is the core that allows the rest to perform around them.  A spine that is in unison, strong and powerful is key to success of any top-flight sports team.  The spine discussed in these reports is a team within a team (eleven people on the pitch) within a team (the squad of players and the management, coaching staff and other supporting members). There are often many spines within different organisation structures, but there can be only one performing on a football pitch at the moment of play.

The telegraph described “There was a pace and purpose to Newcastle’s football, a quickness to their tempo as they poured forward, black-and-white-striped streaks”.  The report goes on to describe how the different elements of the spine of the team were critical in making this situation real.  Each player brought something to the spine on the night.  They clicked.  They were in harmony.  It wasn’t really expected though.

It is amazing to think that on a different night, in different conditions the same spine may have been completely ineffective.  Or, with one change of personnel in the spine, they may have been overrun by six goals the other way.  That is the reality of teams in different situations.  Individuals can make a difference, both positive and negative.  Normally the Manchester United spine is the one lauded at the end of a match.  Not their opposition’s.  Manchester United, on the night, lacked a spine.

Shared purpose, interdependent roles and shared responsibilities supported by organisational structure and a goal that measures the team not the individual are important.  But they also need to have time together to be effective.  They need to learn instinctively who will do what and what skills are required to deal with different situations.  They need to examine the conditions they are going to be playing in and who the opposition is going to put in their way.  Tuckman’s model of Forming, Storming, Norming and Performing explains the phases over time that are required.  This happens both outside of the playing pitch and then also on any single time that team get together to take on their opposition.

In business there are many teams each requiring strong spines.  The elements of a spine is normally made up of individual members who come together to bring different elements of a business into cohesion.  These are the people we trust, make things happen, generally good communicators who know their roles and responsibilities, and the skills of the wider team, what is important and how to get things done with the people around them.  The similarities to the team within a team within a team notion is clear.  When developing new IT systems or products the players on the pitch are the team delivering the work.  They are (or should be) supported by other well-functioning teams (finance, PMO, HR, Project/Programme Management) with interconnecting member who help them prepare for, plan and execute to meet the goals set by the wider organisation and by them themselves.  If any of these teams don’t have strong interconnected spines then trouble for the team on the pitch looms.  The team playing the game is not enough.


The IT Mindset and Managing Vendors

A slave to the business?

Have you ever come across someone who, when asked, tells you they work in IT? I wonder about this answer, what it means, who they actually work for, and why they don’t tell you about the work that their company does. I mean, IT isn’t a company, is it? In fact, I more often hear the speculation as to whether IT exists at all? That is, whether IT is a part of the business rather than apart from the business. When I hear people answer that they work in IT, I conjure up images of many IT departments that I have walked into and feel my life-source drain slowly away from my body. I call this phenomenon the IT Mindset.

A mindset is a way of thinking that determines somebody’s behaviour and outlook. The IT mindset is a state-of-mind that puts people who work with IT technology at a subservient position to people who work within a business. It promotes the idea that the people working in IT are order-takers of the people who work in Operations or Customer Services or Marketing or Finance or Strategy or anyone who requires some technology solution that helps them do their jobs. This mindset comes through crystal clear in organisations where IT people refer to other members of the same company as their ‘customer’. For me, the customer is external to the company and is a person or business that pays money in return for the goods or service sold by the company. Thinking of anyone else as the customer is not a healthy view.

Not the norm

I was in an excellent session last week of one of my customers where they were talking about their first step of a transformation journey to change the way they bring products, services and features to market. This session had people from suppliers, technology and business units talking about the success that they had started to see after embarking on a transformation that included many agile and lean concepts. There was an air of back-slapping that was quite refreshing from large enterprises and there was a real sense of camaraderie that isn’t often seen. The CIO was watching this session and actively acknowledged and praised this behaviour, and told a story of how, when he first became the CIO, he was surprised at how much IT got the blame for all of the failures to deliver and how things had been steadily changing over the last year or so. In fact, it wasn’t even really the people within IT getting the blame; it was the suppliers. The interesting thing about this comment is that the CIO was a long-serving member of the business and was previously a marketing executive for the firm.

The interesting thing about this is that most of the elements of the transformation hasn’t really been in the IT department. It has been in the relationship of the people and their departments, and how the work is broken down into manageable chunks and passed effectively between the different groups in a steady stream. Funnily enough, these changes have actually helped the suppliers’ business as well as delivered more value to the customers, and made the way work gets delivered more enjoyable for all parties. Tritely, it could be considered a win-win-win situation.

So, why is this not the modus operandi for enterprises? Because people focus on power, politics and managing their turfs. Because people put others into boxes and stereotypes. Because managers don’t understand the psychological contracts between departments (and, indeed, suppliers). Because IT people haven’t figured out that they can add more value to their business and understand their business better than most. In my last post, I touched upon an issue that can create massive problems for a successful project or system delivery. Most of the problems described stemmed from different approaches for managing relationships and communication gaps between different parties who have competing and conflicting requirements, and from people who can create very different mindsets in how departments and suppliers interact with one another. Relationships need to be managed.

The Psychological Contract

The psychological contract was a concept introduced in 1960 by Argyris and has been used to describe the mutual awareness that employers and employees have for each others’ needs beyond their contractual obligations. This is a concept that is continually being reviewed as employees have more choices in what they do and how they do it, and as work is becoming more knowledge based. I believe that the same metaphor can be applied to the interactions between groups. Guest and Conway have further defined this contract as “It is generally not written down, it is somewhat blurred at the edges and it cannot be enforced in a court or tribunal… it is implicit. It is also dynamic – it develops over time as expensive accumulators. Employment conditions change and employees re-evaluate their expectations”. At the heart of this contract exists trust, depth-of-relationship, mutual benefits, understanding and dependability. This is very different to how most business treat their IT relationships and supplier relationships.

I used to spend a lot of time with my procurement department when I worked for BT because of a problem with a supplier relationship and their product. Nothing really met with our expectation, and, unfortunately, it led to many legal discussions focusing on penalties. This was a complex process of learning about the history of the relationship in both contractual and experience terms. Many people had been involved in the relationship and many people had set and reset expectations about the value of the relationship. No continuity of the relationship existed, so it fell to me to define what we wanted out of the relationship and to consider what we would be prepared for the supplier to get out of it. In this example, the one thing that was abundantly clear was that the performance of the product and delivery had to be improved otherwise we would not be successful, and it wasn’t going to be solved with the existing mindset and behaviours from both parties.

The Arbinger Institute have done lots of work in helping solve issues between parties (normally individuals) working with each other. Their central premise comes down to one of self-deception. In short, it points to the fact that people normally blame others for the relationship that they have, not themselves, and that the most effective way of breaking the cycle of an unhealthy relationship is to focus on changing your own behaviours.

Changing our ways

What does this have to do with the IT Mindset and Managing Vendors? Everything! There is often a very human instinct to look to pass off the risk of our own shortcomings or unknowns to others. This is normally more of a reputation or responsibility risk being passed (remember, nobody ever got fired by hiring IBM?) rather than any real business risk. Business risk cannot really be passed as a failure to deliver is still a failure to deliver and damages the firm’s ability to deliver value.

Enterprises today are at a point where most products and services are based on some sort of technology and have some form of vendor involvement. Michael Porter’s value chain has very much been extended to third parties and no company lives in isolation of other companies who can help them create enormous value. Having a mindset of ‘we’re in this together’ and ‘we all succeed or fail’ is necessary for performance. End-to-end thinking without organisational boundaries is more important today as things become more complex and complicated. Every part of the system needs to be positively engaged to bring innovation, critical thinking, energy and enthusiasm to the workplace. All parties within a value chain need to feel a sense of ownership and accountability to make things happen and to succeed. I have seen this challenge to the IT Mindset work wonders within companies. I have also seen changing the focus of supplier relationship from one of persecution based on problems, legal discussion and procurement beatings, to working collaboratively for success be extremely successful.

The IT department needs to figure out how to behave differently. They need to be the business. They need to stop waiting for a written invitation. Also, as Business Leaders, IT Directors need work alongside their colleagues to actively review and monitor the intentions towards other individuals, departments and third-parties, and make sure any policies, processes, pride and prejudices don’t get in the way of the whole business being as successful as it can be.


Value, Flow and Quality

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.



What can the enterprise learn from DSL Max?

Thinking about networks

My formative years in technology and delivery were spent in the telecoms industry.  I have learned a lot about how networks work, how they are controlled, managed and planned, and the strategies involved to deliver certain qualities of service to customers.  In fact, at one point in my career I was responsible for designing and delivering all of the systems that planned, designed and stored most of the network assets and services within BT.  I spend most of my time now considering how enterprises deliver value through projects, programmes, products and services and I find there are many overlaps between the two worlds.  I have been re-reading Don Reinertsen’sThe Principles of Product Development Flow‘ recently and it brought me back again how telecoms theory can influence the delivery of value in an enterprise.

A past experience

The last major programme I worked on in BT before leaving was designed to introduce a 24MB broadband service to large parts of the UK.  There were many firsts in technology underpinning this programme in creating a ubiquitous IP core network and how that would be planned, managed and controlled, but the key element that would enable the faster (and I know other technologies are faster, but not as available) speed to customers was based on a technology called DSL Max which had previously been used in the rollout of 8MB broadband.  This technology was designed to enable any copper line carrying broadband to an end customer’s house to be as quick as it can physically be.

DSL Max is an example of a ‘Rate-adaptive service’.  Wikipedia describes it as ‘… intended to offer the best possible speed attainable, which may vary over time. The maximum speed permitted is determined both by current line conditions and the level of noise, and also by recent history based on factors including the rate of communications errors and the best and worst DSL modem sync speeds achieved during some recent period of time …Customers with long lines or poor quality lines or who experience high levels of noise or interference will be limited to much slower transfer rates, and some customers whose lines are very poor or who are affected by high levels of noise may be unable to obtain service at all.[1]

Interestingly, this technology has created a little bit of contention in the marketplace because customers like to know the exact speed that they are likely to get from their broadband provider, but this technology says (at least in the copper network) that you will receive the fastest possible speed.  It reminds me of the need from enterprises to know exactly how each team compare to one another and how fast they will go in the next 6 months – it kind of misses the point!

The technology does not necessarily dictate the ultimate end-to-end service speed because of the different aspects of how the core network and internet operate, but it has a major influence as to what the end-to-end speed can be. The interesting points, for me, from the excerpt above is the there are a number of factors that can influence speed – the end points or Interfaces (DSL Modems), Distance (from the Controlling elements), Noise and Interference – and it may vary over time.  In some ways the things that impact network speed are similar to those that can impact speed-to-market for companies.

What does this mean for teams?

The team is an interesting construct because different people look at different parts of groups as teams.  Agile folks generally consider a team to be a small (7 +/- 2)  cross-functional unit of people delivering valuable features.  But for something like the programme delivering 24MB across the UK, the ‘team’ spanned hundreds (and maybe) thousands of people.  I was part of an IT leadership team tasked to deliver the overall programme that needed to operate as a team, and I also had around 300 people who were part of teams actually building features internal to my department and across other departments through integrated systems and technology.  In this sort of environment it is very difficult to define what a team should look like or how small value units might operate within this context to a shared goal for the organisation.  That is where project management has a role to play.

In Management 3.0, Jurgen Appelo covers structures and teams really well, and discusses the principles about the size of teams, the structure of teams and their interactions.  I liked his approach to the topic, because I have always found the rhetoric from the Agile community a little disconcerting and not too achievable in the context of massive programmes of work.  One of his points is the idea that the project managers role is to manage a project and not the people, which is counter to how most project managers and organisations behave.  For us though, it really made sense and that was the approach we had taken within the programme – we created networks of teams that came together to deliver value for the customer and disbanded to work with other teams.  That is to say, we allowed the teams doing the real work of developing solutions to be small enough so that they could self-organise around their own technologies, domains and features, but created some more ‘functional’ teams to act as nodes of understanding, communication and alignment between teams.  Our goal was to align all the different teams up-and-down the programme in order to deliver incremental business scenarios.  To start off with, we needed to give it a little nudge in the right direction as self-organisation wasn’t going to work across the different suppliers, organisational units and technologies.

My job as a manager was to help make all of my team units as effective and valuable as they could be across the wider programme.  In short, my focus was to manage and deal with the Interfaces, Distance, Noise and Interference impacting my teams so I could enable them to go as fast as we could go.

As a side note, this was for the good of the overall programme: the area I had inherited to ‘fix’ were already identified as the bottleneck for the overall delivery and a certain pressure came with that ‘gift’.

Noise

The definition of noise is: it can block, distort, change or interfere with the meaning of a message in human, animal and electronic communication.

I think anyone who has worked in any organisation can recognise noise.  The world is full of things that can distract you from the task at hand.  One of the roles of a manager is to limit unhelpful noise.  There have been many times in organisations I have worked in that I have witnessed people creating noise for the sake of wanting to be heard.  Throwing rocks from the sidelines.  Passing judgement on the work of others.  Often, this noise is like ‘anti-value’ for a team.  Noise can come from many directions when delivering complicated, integrated technology solutions for complex businesses.  It can come from the technology itself (especially if the technology chosen is new to a team – or just new).  It can come from centralised groups who are not focused on the flow of value and are part of ‘economy of scale’ thinking.  It can come from people who don’t really understand what a team is doing.  It can come from project managers who feel that they need to control activities because ‘that’s their job’.  It can come from people who are detailing the requirements if they don’t understand their own business.  In short, as a manager, you need to have eyes in the back of your head, but more importantly you have to be available to reduce the noise affecting a team.  Being there to breakdown organisational roadblocks and issues is an extremely valuable role when done well.

Interference

Interference is anything which alters, modifies, or disrupts a signal as it travels along a channel between a source and a receiver. The term typically refers to the addition of unwanted signals to a useful signal.

Similar to noise, Interference can come from many angles in an organisation.  In telecoms their are a couple of common Interference types such as Cross Talk and Adjacent Channel Interference that can have a major impact on the performance of a circuit.  The weather can sometimes make things worse too.  I think there are a couple of common interference personas in organisations:

  1. The Bulldozer – a more senior person who wants to come in and set direction.  Someone who generally bullies a team into doing what they want them to do without understand the full context.
  2. The Know-It-All – someone who solves the problems for the teams.  This person can take away any accountability and responsibility for a team and leave them headless when they are not around.  They can all set direction that often tries to solve the future and complicates the immediate task.
  3. The Seagull – we have all had senior managers and advisors who take a peek at a situation, swoops in, makes some snap decisions and swoops out again.  They don’t take the time to understand what is really going on and help the team.  Seagulls can sometimes be Know-it-alls.
  4. The Jobsworth – the homework checker who doesn’t like what they are seeing and have other goals to deliver that are not necessarily in support of the project being delivered.  I do have some sympathy for this role as everyone has their job to be done… it would just be nice for people to be able to apply some judgement to a situation.  These may well be the people who would want to compare one team against another.
  5. The Person-who-has-something-to-prove – people act from their own perspectives, and people’s goals don’t always align to the goals of the team.  This might be someone who wants to make a name for themselves, or someone who wants to exert their authority in a political situation.  Whatever the reason, this is something to be aware of.
  6. The Spare-Wheel – someone who doesn’t really know what their role is in the team.  They might have once been a manager of a team in an older organisational context that now doesn’t really know how to add value.  Changing organisations can often create Spare Wheels, so beware.

I’m sure there are many other personas we could name.  I would be happy to hear some of yours. The key thing for managers and leaders are to keep an eye out for interfering behaviours.  Advice is all well and good, if it does genuinely support the goals and needs of a team, but this does need to be managed carefully.

Distance

In the context of the programme, the distance I am talking about is that between the teams day-to-day work with their heads down working alongside their own product/domain specialists and that of the end-to-end business and Integration points.  In one respect distance issue is the same in both telecoms and enterprises – the further away you are (in space and time) the more the communication degrades.  It is often easy to become fixated with ‘getting your bit done’ in a large programme like this, but it is only as an end-to-end team would we be successful.  A lot of my job as a manager was about making connections between the different teams and stepping into situations where misalignment was occurring without any of the teams being aware that this was happening.  In large, complex organisations you cannot hope to know the full complexity of the political landscape and the intimate detail of the working software.  You must have bridges and connectors to get the right people talking at the right time.

Interfaces

In the metaphor of the copper line telephony service, the Interface is a Modem or other Network Node.  These are the senders and receivers of information.  In an agile team, this might be a Product Owner or another team that you need to interface your software with.  It might be someone within the business who will use your system.  It might be some other interaction.  Whatever it is, interfaces have a real ability to impact overall velocity of a team.  This is an area where the wider ‘team’ in a programme sense needs to spend time to discuss how interactions will take place and how alignment will happen to keep the overall system moving forward as quickly and effectively as it can.  Often, interfaces span organisational boundaries, technical boundaries or priorities and managers need to be aware how these can impact the teams.  Teams can start to self-organise once interfaces are understood and relationships are built.  Often the role of a manger with the wider organisational context is to grease the wheels of an organisation and make the connections to start with.  It can all flow from there.

Wrapping it all up

Ultimately, as a manager of an organisation, you want your teams to go as fast as they possible can go and that the organisation, as a result, goes as fast as it can go (we don’t want fast teams if the whole slows down!), and in order to do that, special attention needs to be given to the things that can hamper a team’s performance.  Noise, Interference and Distance are not things that you can do too much about in a simple copper network (there are some things you can do to help, but, only so much), but they are all areas that can be managed and looked at in complex organisational environments.  A lot of these elements are often overlooked by managers and in some cases it is the manager takes on the personas described.  Forearmed is forewarned.  The success of your programme may depend on it.



Follow

Get every new post delivered to your Inbox.