Tag Archives: project manager

People don’t like change. (Or do they?)

I seem to be having a lot of conversations at the moment around whether people (you, me and everyone else) like and embrace change, or whether they resist it. The same question arises for companies. Like a lot of these questions, I think it depends. As individuals we don’t mind change, given appropriate circumstances. Organisations also want to change (and in today’s business environment it seems to be a question of changing or becoming irrelevant). However, people in organisations are usually strongly incentivised to dislike change, especially if they want to make that next repayment on their new mortgage. Fixing this, and creating a culture that embraces change, means changing the way we think about and structure our organisations and our careers. It means rethinking the rules of enterprise IT.

Every time a conversation comes around to the topic of change, I’m always reminded of a visit I made to a Toyota factory something like a decade ago. It’s so long ago now that I can’t even remember the reason for the visit, but that’s not the point of this missive.

Toyota, like most businesses, loves change. (Many large companies reorganise so often that change seems to be the only constant.) Change, embodied in the development of the Toyota Production System, was what took Toyota from the bottom of the global car industry to the top. Change is also why many of us have moved companies, following jobs as our employers reorganise their operations. For some of us, change is an opportunity. For many though, change is the tool of the man as he tries to disrupt our lives. Change means unwanted relocations, pay cuts, career stalls, or the need to shift jobs when we don’t want to. Change is something to be resisted.

What was interesting about my visit to Toyota though, was the attitude of the workers on the shop floor had to change. They didn’t hate it. They didn’t even resist it. They actually arrived at work each day eager to see how work practices had been changed since the end of their last shift.

A Toyota assembly line circa 2000.
A Toyota assembly line circa 2000

The concrete example I saw of this was the pre-sorting of seatbelt parts into coloured tubs. Apparently only a few weeks earlier the parts had been arranged on a wall. All hooks and dangling parts, like your Dad’s tools in the shed. When a car came down the assembly line a worker would select the parts appropriate for the car model, and then attach them to the car. Each seat belt had roughly four parts, so that meant there was three unnecessary decisions. Unnecessary decisions usually mean mistakes, mistakes waste time and money, and there were a number of mistakes made.

One day a member of the shop floor team had had the bright idea of pre-sorting the seat belts to avoid these mistakes. Some coloured tubs were sourced (some of the shop floor team drove to the local Walmart with a little petty cash), parts were sorted into tubs, and they gave the idea a trial run. Selecting seatbelt parts for a car now only required one decision: which tub?

The idea was a huge success; error rates went down dramatically. I hear that it was even taken global, and implemented in most Toyota factories around the world. (Though being around ten years ago, and with today’s rapid pace of change, I expect that the tubs have been superseded by now.)

What’s interesting about this story is that the change originated on the shop floor, from the assembly line worker who were actively looking to improve operations, rather than from head office as part of a reorganisation. Some of the improvements I heard about even resulted in the elimination of jobs, with the workers redeployed elsewhere in the factory. Workers weren’t just changing how they did something, they were also changing what they did. Change was what made the work interesting and engaging for the workers, rather than being seen as an oppressive tool used by the man.

I think we can safely set aside the idea that works don’t like change, as this story is not an isolated incident. Why then, do so many people resist change? Why, for every Toyota factory, there is a story like the UK newspaper industry, where workers (and unions) resisted change for decades, until Rupert Murdoch came along.

Rupert Murdoch, destroyer of unions, and good Melbourne boy
Rupert Murdoch, destroyer of unions, and good Melbourne boy

The problem is not people or organisations, but people in organisations.

People are funny things; they tend to do what you incentivise them to do. There’s an excellent article over at the NY Times, The no-stars all-star, which talks about measurement and incentives in basketball. We often talk about “what gets measured determines what gets done” from an employee incentive point of view, but this article puts some real meat on the bones of that argument.

Shane Battier, the no-stars all-star
Shane Battier, the no-stars all-star

As the article says (on page two):

There is a tension, peculiar to basketball, between the interests of the team and the interests of the individual. The game continually tempts the people who play it to do things that are not in the interest of the group.

A little later it goes on to mention (on page three):

A point guard might selfishly give up an open shot for an assist. You can see it happen every night, when he’s racing down court for an open layup, and instead of taking it, he passes it back to a trailing teammate. The teammate usually finishes with some sensational dunk, but the likelihood of scoring nevertheless declined. “The marginal assist is worth more money to the point guard than the marginal point,” Morey says.

The point guard’s career is defined by the number of assists he makes (among other metrics), and he’ll try and increase the number of assets even if it’s not in the best interest of the team. After all, teams come and go, while he has a career to maintain.

Once you place a person into a role you have put them on a career path which will determine their attitude to change.

Usually we take an operational approach to defining roles, rewarding people for the volume of work they are responsible for. Career progression then means increasing the amount of work they are responsible for, regardless of what this means for the company.

Measuring a project manager in terms of head count or revenue under management will give them a strong preference for creating ever bigger projects. It doesn’t matter if the right thing to do is create more, smaller projects, rather than run a programme of a few major projects as we have in the past. Your project manager’s career path is to increase their head count and revenue under management. And they do have those private school fees due soon.

Just like the point guard, change that will prevent career progression will be resisted (remember those kids in private school), even if it is counter to the company’s best interests. Which makes the current transformation we’re seeing in IT all the more important, because if we set the wrong incentives in place then we just might be our own worst enemies.

We can’t force a square peg into a round hole; nor can we force our existing employees to take their current roles and careers into a new organisational model. They just don’t fit. Take IT for example. We can’t expect many modern IT departments to spontaneously modernise themselves, transforming into agile business-technology engines under their own volition. It’s not that the departments don’t want to change: they do. Nor are most of the employees, as individuals, opposed (remember the Toyota example). But the combination of people and organisation will repel all but the most destructive boarders.

It’s interesting how other games, games other than basketball that is, have structural solutions to this problem. One solution is the line-up in baseball. From the NY Times article (page two, again):

“There is no way to selfishly get across home plate,” as Morey puts it. “If instead of there being a lineup, I could muscle my way to the plate and hit every single time and damage the efficiency of the team — that would be the analogy.”

Solving this problem in IT means rethinking the rules of IT.

The game of IT has, for the last few decades, been determined by the need to deliver large, enterprise applications into the IT estate. Keep the lights on, don’t lose orders, and automate anything that hasn’t yet been automated. Oh — and I’d like my reports accurate and on time. IT as the game of operational engineering. It was these rules that drove the creation of most of the roles we have in enterprise IT today.

However, this has changed. Decisions are now more important than data, and the global credit crunch is driving us to reconsider the roles we need in IT. We’re trying to reinvent our IT departments for the modern era – I even posted about how this was driving the need the need to manage technology, and not applications – but we haven’t changed the rules to suit.

If we want out people to embrace change, as the people on the shop floor at Toyota did, then we need to provide them with roles and careers that support them in the new normal. And this means changing the rules. Out with the more – more applications, larger projects, more people – and in with the new.

So what are the new rules for IT?

We can be our own worst enemy

The only certainties in life are death and taxes, or so we’ve been told on numerous occasions. I’d like to add “change” to the list. Change, be it business change or change in our personal lives, has accelerated to the point that we can expect the environment we inhabit to change significantly in the immediate future, let along over the length of our careers. If we want our business to remain competitive in this ever evolving landscape, then overcoming our (and our team’s) own resistance to change is our biggest challenge.

The rules we have built our careers on, rules forged back in the industrial revolution, are starting to come apart. Most folk—from the Baby Boomers through to Gen Y—expect the skills they acquired in their formative years to support them well through to retirement. How we conduct business might change radically, driven by technological and societal change, but what we did in business could be assumed to change at a slower than generational pace. We might order over the internet rather than via a physical catalogue, or call a person via a mobile rather than call a place via a landline, but skills we learnt in our formative years would still serve us well. For example, project managers manage ever increasingly complex projects over the length of their career, even though how they manage projects has migrated from paper GANTT charts to MS Project, and now onto BaseCamp.

Which is interesting, as it is this what, the doctrine, which most people use to define themselves. A project manager manages projects, and has (most likely) built their career by managing increasingly larger projects and, eventually, programs. Enterprise architects work their way toward managing ever larger transformation programs. Consultants work to become stream leads, team leaders, finally running large teams across entire sectors or geographies. An so on. The length of someones career sees them narrowing their focus to specialise in a particular doctrine, while expanding their management responsibilities. It is this doctrine which most people define themselves by, and their career is an constant investment in doctrine to enhance their skills, increasing their value with respect to the doctrine they chose to focus on.

This is fine in a world when the doctrines a business needs to operate change slower than the duration of a typical career. But what happens if the pace of change accelerates? When the length of the average career becomes significantly longer than the useful life of the doctrines the business requires.

We’ve reached an interesting technological inflection point. Information technology to date could be characterized as the race for automation. The vast bulk of enterprise applications have been focused on automating a previously manual task. This might be data management (general ledger, CRM, et al) or transforming data (SAP APO). The applications we developed were designed as bolt-ons to existing business models. Much like adding an after-market turbo charger to your faithful steed. Most (if not all) of the doctrines in the technology profession have grown to support this model: the development and deployment of large IT assets to support an existing business.

However, the role of technology in business is changing. The market of enterprise applications has matured to the point where a range of vendors can supply you with applications to automate any area of the business you care to name, making these applications ubiquitous and commoditized.The new, emerging, model has us looking beyond business technology alignment, trying and identify new business models which can exploit synergies between the two. A trend Forrester has termed, Business-Technology.

The focus has shifted from asset to outcome, changing the rules we built our careers on. Our tendency to define ourselves by the doctrine we learnt/developed yesterday has become a liability. We focus on how we do something, not why we do it, making it hard to change our habits when the assumptions they are founded on no longer apply. With our old doctrines founded on the development and management of large IT assets, we’re ill-equipped to adapt to the new engagement models Business-Technology requires.

The shift to an outcome focus is part of the acceleration of the pace of business. The winners in this environment are constantly inventing new doctrine as they look for better ways to achieve the same outcome. How we conduct business is changing so rapidly that we can’t expect to be doing the same thing in five years time, let alone for the rest of our career. What we learnt to do in our mid 20’s is no longer (entirely) relevant, and doesn’t deliver the same outcome as it used to. Isn’t the definition of insanity continuing to do something the we know doesn’t work? So why, then, do we continue to launch major transformation programmes when we know they have a low chance of success in the current business and social environment? Doctrine has become dogma.

We need to (re)define ourselves along the lines of “I solve problems”: identifying with the outcomes we deliver, at both personal and departmental levels. This allows us to consider a range of doctrines/options/alternatives and look for the best path forward. If we adopt “I am an TOGAF enterprise architect” (or SixSigma black belt, or Prince2, or …) then they will just crank the handle as the process has become more important than the goal. If we adopt “how can I effectively evolve this IT estate the with tools I have”, then we’ll be more successful.

Rolls-Royce and Craig’s List are good examples of organisations using a focus on outcomes to driver their businesses forward. Bruce Lee might even be the poster child of this problem solving mentality. He studies a wide range of fighting doctrines, and designed some of his own, in an attempt to break his habits and find a better way.