Tag Archives: delivery

Business, Delivery, Leadership, Masters of Delivery

Stewardship: A Fundamental Part of Good Leadership

May 24, 2015 Keith Haviland 1 Comment

“The price of greatness is responsibility.”– Winston Churchill

Meetings in Hollywood and London

The meeting was over drinks in the Roosevelt Hotel in Hollywood. It was with an old friend who I had worked for in the late 1980s. He was then leading a technology start-up in London, specialising in UNIX and Open Systems. The company was a true prototype for the eCommerce and Digital start-up waves of the 21^st Century. It was tech-savvy, youthful, ambitious and diverse. It had energy and pzazz.

It became a business success, and was sold in 1990. It was also a cultural success. People liked working there. Even today in 2015 there are occasional re-unions of the core team.

My friend had then moved to LA to try his luck in the world of film. Again he had successful, and now lives in a Spanish style villa in the Hollywood Hills.

We spoke about his plans, and mine. It wasn’t long before I realized that, although I hadn’t worked with him for twenty years or so, he wanted me to develop and be successful. He still felt his old loyalty to his previous team.

Cut to another scene. It is a few weeks later. I am having lunch in London with another old friend, someone I have worked for a little more recently. He had been a respected leader in both commerce and public service. Again, I felt that same sense of support, and quiet, steady belief. Here was someone who wanted others to succeed almost as a natural reflex.

Stewardship

This led me to reflecting on what I think is one of the most essential qualities of good leaders: stewardship.

One of my alma maters is Accenture, a company who organize people on a global scale. It has a set of simple core values intended to help define its culture. To paraphrase, these include: integrity; respect for people as individuals; a focus on acting as a team; excellence and, above all, prioritizing client service.

And as an instruction to leaders, this set of values also includes the word stewardship – which means a focus on the greater good, thinking of the future, and the development of the people around you. It has been a fundamental element of that company’s long history, arising from its origins as a partnership.

Over the years, and across companies, I have had the privilege to work with many good leaders, and the best naturally adopt a stewardship style. They care about the future of both their business and their team with a natural grace and enthusiasm. Above all, they think about the motivations, development and careers of the people who work for them.

This does not need to be at the expense of being able to make tough calls. Indeed some of the best stewards are also courageous. One leader who worked for me in building the Accenture Global Delivery Network was a red-blooded operator – able to direct without hestitation, and do the hard things at scale. He is one of the masters of delivery it has my privilege to work with. However, he also ensured that the bi-annual performance management process of a large group of people was undertaken with a huge amount of care, professionalism and objectivity. The views of his own leadership team were fully taken into account, and balanced. When it mattered, he acted as a steward. It impressed me, and a great many others, enormously.

Aspects of Stewardship

There economic models of stewardship cultures in enterprises, and a whole literature on “servant leadership.” However, what follows is my personal definition of major attributes of stewardship, written as advice for leaders and potential leaders.

A combination of strong values and an inspiring vision, communicated well. The vision is essential for setting a direction. It should be adaptable, but stable enough to allow consistent execution. The values will enable you to handle change, and trouble, and create the foundations of the culture you aim to build.
Loyalty. By this, I mean the loyalty of leaders to their teams. Great teams can be created when people know you “have their back”, that what you say is what you mean, and you want them as individuals to progress and prosper. Loyalty is something best returned, rather than exhorted or demanded.
Courage. It is important to have the skills to deal with challenges and failures in a positive way. This can mean being simple and direct about bad news, or poor performance. Truth is at the heart of delivery and learning. Courage can also mean a leader constructively standing up to his own boss when poor decisions are being made – since even great people will make poor calls.
A relentless focus on recognition. People thrive when their achievements or hard-work are celebrated. It is a core part of what most individuals will want out of their career. And sometimes a simple thank you is plenty enough. It still amazes me how many of those in management positions don’t recognize the value of this kind of simple engagement. As with loyalty, give credit, and you earn it back.
An unyielding emphasis on development. If you want long-term growth, you need to develop your team, and build a flexible leadership bench for the future. You need to worry about the progress of each individual, and what skills or encouragement they each need to succeed. This is much broader than succession planning, which often has a narrow, static focus. Indeed, when a company starts treating its middle management as an economic issue that is ultimately a failure of top leadership and their stewardship foresight.
Forward thinking. The job of a leader is to make sure future challenges are anticipated, offerings are adapted to changing markets, and structures flex with growth. As I was building the Accenture Global Delivery Network, I made myself think frequently about horizons of 3 months, 12 months and five years. It worked well, during a long and exhilarating period of quasi-exponential growth.
Providing an environment in which good can be done. When I started working with people in India, the Philippines and other developing countries, I was very struck by the intense enthusiasm for supporting local communities, and for giving something back. It was humbling, and inspirational. This taught me the importance of making sure a sense of the common good was part of the cultural fabric. Such a culture will start many experiments in achieving excellence in client-service, improvements in training, initiatives in diversity, and action to help the community and environment. And some of these experiments will work.

Benefits

What are the benefits of stewardship?

It creates the kind of positive culture where teams want to deliver excellence in client service, and continuous improvement. It enables long-term growth because you naturally create a bench of leaders able to take your place. It creates an almost unconscious loyalty, with high levels of engagement, and lower levels of attrition. And your future leaders will develop their own sense of stewardship.

It creates open channels of communication, because people work in an atmosphere of trust. It can make a real impact on local communities through an effective corporate social responsibility program. In the end you can create a place where people aspire to work, to serve and progress.

Conversely, toxic leaders who are interested in personal position first and foremost will often do a great deal of damage, and can leave ineffective teams behind them. And even formerly respected leaders who break a bond of trust can see the morale and performance of their teams drop dramatically.

However, the final message is an immensely positive one. Stewardship cultures feel right. They also are right – bringing great benefits in culture and client-service. Above all, they bring the ability to grow, at scale and in the long-term, in a dynamic and changing world.

Keith Haviland

Keith Haviland is a business and technology leader, with a special focus on how to combine big vision and practical execution at the very largest scale, and how new technologies will reshape tech services. He is a Former Partner and Global Senior Managing Director at Accenture, and founder of Accenture’s Global Delivery Network.

Published author and active film producer, including Last Man on the Moon. Advisor/investor for web and cloud-based start-ups.

Agile, Delivery, Technology, Technology Services

The Bifurcation of Technology and the Revolution in the IT Industry

October 30, 2014 Keith Haviland Leave a comment

Sometimes people start to use a phrase or word that captures a moment of change. You hear friends and colleagues using it, and it starts to crop up in the media. One such example I’ve heard several times in the last few weeks is bifurcation, as a dry shorthand for the current momentous transformation in IT and IT services. The trends I noted in an article (here) in the summer are accelerating, and fast.

A recent, excellent article in the Economist covers this well. The bifurcation is the dual-track nature of growth in IT. Services and products related to mobile and cloud are expanding, and sometimes with extraordinary growth rates. Conversely, traditional IT sectors “are growing slowly or even shrinking”. The sectors under pressure include most types of hardware, traditional enterprise software, and classical IT services.

The combination of the differential growth characteristics means the IT industry overall is showing modest growth. The Economist quotes a number of 3% overall. Other commentators will give numbers even closer to zero. It is a challenging environment.

One result of this is the beginning of significant change in the corporate structures of IT suppliers. Larger companies are acquiring faster-growing companies. That is the usual cycle. More profoundly, some large companies will radically reshape themselves. As the Economist describes “HP’s recent decision to break itself up was merely the opening shot … Others will shed businesses that have become commoditised …IBM announced that it will pay Globalfoundries, a contract chipmaker, to take its semiconductor business off its hands.”

The changes in technology driving these changes in business are very real. Over the last 20 years, the relentless increase in available compute power, network bandwidth and storage capacity has moved us to a world where a wide variety of very powerful devices – not always operated by people, but increasing by other machines – can connect reliably to remote services of increasing breadth and sophistication.

And what this means is that such services can potentially take advantage of real economies of scale, and can be built and provided to the entirety of the universe of consumers and business with an ease that a generation ago would have seemed startling.

A new underlying industry architecture for software is forming. It includes a complex infrastructure layer that provides cloud services, which itself faces real change as the concepts of commoditized data centre and commoditized server becomes blurred. It includes a complex range of platform options that link humans and their devices to apps and cloud services. The architecture is crowned by applications and functional services – and it is the richness of these that will accelerate the change in IT. Importantly for established businesses, there is an explicit need to add an integration layer to the architecture – since we are on a decade-long transformation, and the interfaces with legacy systems will be key concerns. Overall, the concepts of Infrastructure-as-as-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) introduced by Gartner have served us well, but need refreshing as this form of architecture becomes dominant.

These changes in architecture also change the expectations for the delivery of software and services. New companies especially want their back-end support systems to be easily, immediately and cheaply available, and provided as elastic services that will grow with them. They do not seek uniqueness or differentiation here. Instead, they want innovation and rapid development of those services that face their customers. More generally, monolithic applications are being replaced by systems of services. This brings more architectural complexity, but it allows development to be parallelized and – if well managed – delivered in much more agile ways.

There are obvious dangers here for the providers of IT services (and you can include IT departments under this heading) who are sometimes surprisingly disinterested in the way they deliver their technology services, although this is often what clients are buying.

For example: a typical feature of large companies is operator dominance where a focus on cost becomes primary – growth in a changing world is much harder and requires fortitude. Taken to excess, the focus becomes optimization of legacy services, and too much focus on tools such as global delivery – wonderful as part of a toolkit, but most effective in combination with client-facing services that bring new technology opportunity into the heart of businesses. Indeed, the best India-based IT providers realize exactly that, and understand that conventional outsourcing now has a limited shelf life.

Another sign of dysfunctional effects are mash-ups of old and new which resemble failed experiments in genetic engineering. We all know of large projects where agile approaches have been introduced at too large a scale to deal with mad schedules, and client and suppliers try to handle this with conventional procurement approaches. Fixed-price contracts and flexible iteration can be unlikely bedfellows.

But real, sun-bright opportunity at scale also exists. An eco-system of service providers has appeared around the dynamic and fast-growing company Salesforce. Salesforce transaction volumes are in 9 figures daily, and much of these are via their platform technologies, showing people are building their own apps around its Software-as-a-Service core.

Another positive example: I have come across one agile based company that hires the very best developers – aspiring for the top 1% – and undertakes only small projects with direct and strong business support. It seems to genuinely deliver the benefits of agile approaches, with great reliability. This emphasizes to me a coming focus on skills and expertise that can marry client need and the power of new tech. Like all times of change, smart tech-savvy people who understand clients and can integrate complexity will be at a premium.

And the growth rates of many larger consultancies are respectable, or simply plain good – reflecting client needs for advice and support in their transformations.

So, as always I end very optimistically. There are new opportunities for those technology service providers who can develop architectures and architects for the new world, and who can create app and tech services that can be reused across their clients. Good companies of the future will get to grips with better, more nimble ways of integrating, assembling and crafting solutions for clients as systems of services. They will invest in building the new skills and high-end expertise for 21^st century delivery – both close to clients and in their global centres. They will create new types of career, and new types of personal opportunity.

I will be writing about these positive trends in future articles. Stay tuned.

Keith Haviland is a business and technology leader, with a special focus on how to combine big vision and practical execution at the very largest scale, and how new technologies will reshape tech services. He is a Former Partner and Global Senior Managing Director at Accenture, and founder of Accenture’s Global Delivery Network. Published author and active film producer, including Last Man on the Moon. Advisor/investor for web and cloud-based start-ups.

Delivery, India, Masters of Delivery, Spaceflight

When Speed and Agility Matter: Moving with the Lightning

October 14, 2014 Keith Haviland Leave a comment

Episode 3 of the Masters of Delivery

The Problem of Time

I’ve spent much of my career focused on how to plan and manage one of the most precious and complex resources: time – and especially how time relates to project scale and complexity.

In software development and technology-driven business projects, one of the clearest and most dramatic trade-offs is between speed and cost. There is a simple rule: the shorter the schedule, the bigger the total effort, and associated cost. The dynamics of organizing and connecting people around common processes will become increasingly stressed when time is tight. The scope for error and rework increases significantly.

Indeed, there are schedule and scale combinations that are simply impossible to achieve, for which – to coin a phrase from the great Fred Brooks – there is no silver, magic bullet. Rome, an Olympic stadium, and even average size software projects cannot be built in a day.

When faced with demands for impossible schedules, where the balance of scope and schedule simply do not fit, I normally take people through the complex dynamics of time and teams. I stress the need for a proper amount of time to understand a business and develop a design, and the option of delivering function in iterations so that some benefit can be gained earlier.

One Year Vs. Five Years

Conversely, as Peter Drucker once said: “We greatly overestimate what we can accomplish in one year. But we greatly underestimate what we can accomplish in five years.”

Five years or more gives enough time for big change, enough time to create a business or even a market.

One personal example of that is when I was part of the team that founded Accenture’s India Delivery Centres in 2001. We had a short-term plan focused on 200 people, but I also drew out a longer-term plan on a whiteboard that spanned three to four years and would get us to 10,000 people in multiple cities. It captured our strategic intent. We would meet both plans.

Moving with the Lightning

However, there are times when magic will work, when external events demand a schedule that is improbably short and – even more remarkably – the right team with the right motivation and the right support achieves that timescale. Such moments can create real belief in a program or team, leading to greater success at ever larger scales. The insights learned from these experiences can also help people think through agility, an increasing demand from many senior leaders in our hyperactive era.

So, it is those moments when teams move with the lightning, when great things are done fast, that I want to explore in what follows. Let’s start with the inspiration for this article – a spaceship.

America’s First Spaceship

I was researching the history of NASA Mission Control. This was for a potential film project, and also out of simple curiosity about how the great and mighty NASA machine of the 1960s and early 70s was created.

One of the key sources is the book Flight: My Life in Mission Control by Christopher Kraft who conceived and built the first versions of NASA mission control. It is a book that tells the human and organizational story of the space program, and one I would recommend to any student of delivery.

The following sequence jumped out at me, around the Request for Proposal or RFP process for America’s first manned spacecraft – the Mercury capsule.

It was this:

1^st October 1958, NASA created
7^th November 1958, RFP Published and RFP conference
12^th January 1959, contract awarded to McDonnell Aircraft Corporation
Early February 1959, McDonnell sign contracts

By today’s standards, this is extraordinarily fast. It is genuinely astounding. This is not the RFP for an IT system, or office supplies. It is an RFP for a spaceship.

In a matter of weeks, the direction for America’s first manned space program had been set and a partner selected. The Mercury program had initial challenges – such as an infamous unmanned flight that reached a height of 4 inches – but overall it succeeded completely, and with the knowledge and expertise created America would reach the moon less than 11 years after NASA was created.

Kraft himself summarizes the spirit of the times with “That can-do, will-do attitude preceded us everywhere we went.”

This incredible example demonstrates some of the themes we will explore later in the article: strong mission, strong leadership, great skills and motivation.

Above all it shows that there are times when great things can indeed be done quickly.

The Move: 3 Weeks and 300 Very Busy People

This example is not nearly so grand. It didn’t change broad history, but it did help create a major technology delivery centre, and a new business. It was, by normal corporate standards, a magnificent achievement.

We had started our new business in a charming, worn art-deco style building beside the Thames. We were in the midst of a major software development, with 300 people designing, developing and testing releases of a major software product. The work in total was tens of thousands of days. Testing in particular is very sensitive to environment – the software configurations, networks, workstation and server technology need to be absolutely correct, and the physical space needs to support intense teamwork on the grand scale.

Although the building faced the river, it was cheap to rent. And the reason it was cheap – which I didn’t know at the time – was that there was a one-month notice period in the lease.

Our facilities people had deemed it unlikely to happen. Their judgement was usually faultless, but this time they were wrong. The owner wanted to rebuild, and start demolition soon.

So, one day we faced just over 3 weeks for a move – with no target future building and no plan, and 300 people working hard on a tough schedule for multiple clients. As we expanded, we would develop true business continuity and would be able to handle loss of a facility with ease, but this was early in our history.

We had an immense problem.

The first task was not to panic, or analyse quite why we were where we were. As we have seen in previous articles, status is to be understood with blunt honesty, and issues are there to be managed.

As for the next task, I asked a true Master of Delivery – “RK” – to plan and execute the move. RK had an exceptional grasp of the full technology stack – from the wires to the complex distributed software environment. He also understood what an objective meant, and would work with enormous passion towards that.

I asked him to target just one day – the move day – of down time for the team. RK smiled.

Key Strands

So, we created a plan around a number of parallel strands that RK would operate with complete authority.

Strand 1 was creating the mission, and instilling a sense of belief about the date. We wanted people to feel that their efforts would help make a little corporate history.

Strand 2 was about people. We staffed key roles immediately with some of our best, taking a short term hit on other activities. We chose those who had general management skills, and precision, since we needed delegation to be effective. We would expect everyone to be hands-on – acting much like people do in start-ups.

Strand 3 was a search for a suitable empty space. We looked in what in London is called mid-town, between the West End and the City. It was less fashionable then than it is these days, and we found three spaces of the right scale and cost. Two were dreadful – cramped spaces in out-dated concrete buildings, that would require much work. One, however, was acceptable. This was the key piece of luck we needed. We had found our future home – an Edwardian building near London’s legal district.

Strand 4 was design. We established the minimum design around building layout, furniture, a LAN, working servers and wide area communications. That was placed under firm control. Any change would be reviewed carefully.

Strand 5 was to focus on logistics with true military precision. We analysed lead times, placed orders – leased and borrowed equipment that wouldn’t arrive on time – and asked our suppliers to make the extra effort to support us.

And then, came the daily grind of execution. We met the deadline, and had people working effectively on the first day of operation of the new building. We lost only a few hours of productive work.

And it turned out that the technology design was not only effective … it was near perfect. RK had poured all his knowledge into the design, and we had no time for the usual compromises.

“500 in 5”

This is an example that I come back to repeatedly in my thinking, a key moment in my experiences in creating large delivery centres in India, and a lesson in how to get teams to do incredible things.

We had been in operation for around 18 months, reaching 500 people. This had required sustained effort since our business was then not widely known among our target talent pool. We had worked hard with candidates, even explained ourselves to their families, and organized dedicated training and conference days to attract people to apply. Overall, with a little difficultly, we had balanced demand and supply effectively. Our HR team had made a brilliant start.

Now things were changing and demand was increasing. We were beginning to see supply challenges.

I wanted to understand trends – I always want to understand trends since part of any leadership role is looking ahead – and went through the data in detail.

The reason for the new demand for people was a large, recent increase in active and potential clients. We had established a successful business. We were seeing the early days of a much larger future increase – the work at each new client would likely grow, and need more people.

Exponential Change

We had reached a tipping point. Roughly speaking, we were seeing the beginnings of an exponential, non-linear trend. Most people will naturally plan around linear and steady change, but with positive feedback, human enterprises can go through remarkable and fast changes – creating echoes of the growth of the Internet, the progress of a hit single, or viral video. The topic of exponential, human change is a topic I will be returning to in later articles.

The good news was that we had what seemed to be the start of a tremendous opportunity. The bad news was that we needed a non-linear response.

Setting the Goal

We had a talented local leader who was strong, charismatic and a true business builder. Our local HR lead was one of the most positive and dedicated professionals I have ever had the privilege to work with. They had been carefully chosen, and in their different ways they were both Masters of Delivery. They would go on to make very major contributions.

I asked them this. Although, it has taken eighteen months to grow to 500 people, we need to hire 500 people in the next five weeks. Can you do it?

Those who have built and worked in start-ups know how hard an ask this was. Talent is the key resource and often the key constraint.

And the mood of that meeting? When a world of pain and hard work was opening up before us. It was tremendous – full of energy and laughter. They had that “can-do, will-do attitude” Chris Kraft had seen at NASA.

They went for it. We briefed the team … making it their moment of making history. We hired good contractors to support the core professionals. We arranged for virtual interviews from people across the globe. We created a large war room, dotted with white boards to record real-time status.

And then we filtered CVs and held interviews, thousands and thousands and thousands of times.

By the end of the period they had made 526 offers to good candidates. They had beaten the target. They had made their own piece of history. And after that, the team knew what they were capable of, and created one of the best large-scale recruiting engines in India, eventually capable of hiring many thousands a month.

General Principles

So, what general threads can we pull out of my three very different examples? When can a leader or business ask for remarkable efforts in a remarkable short time frame?

My conclusions are as follows (although I would also be delighted to hear your thoughts). They are similar to the Ten Commandments we saw in Episode 2 of Masters of Delivery, but tuned completely to very rapid execution.

This cannot be business as usual. Remarkable effort should be reserved for times of remarkable need. The examples we have looked it where against the background of the space race, or clear, urgent, business challenges.
But in such times, it will sometimes pay-off enormously to have ambition and the courage to ask for that remarkable effort.
Judgement is essential to make sure the undertaking has the right characteristics to succeed. Suitable examples include:

The work can be undertaken by a small number of experts. For example, it was possible to create a high-level spacecraft design in weeks. Building the spacecraft would take another two years (superb in itself).
Or the work can be scaled and duplicated across people and teams – as in our recruiting example.
It is self-contained, with few external dependencies.

There must be a clear mission, a worthwhile purpose. This must be communicated to everybody. And people enjoy doing great things; enjoy making their own pieces of history – so communicate to inspire.
The mission must be understood, valued and supported by the team. It’s hard to ask people to work long hours. It is much easier and much more effective to ask them to work for a goal.
Assign the best team. It is remarkable how many projects fail, even mission critical ones, because hard choices about resources are not made. When timescales are fundamental, staff your best people and clear their decks. Less urgent issues will wait.
And “best team” means people with experience – in every one of our three examples,the teams were led and staffed by people who had prior experience of great relevance.
Above assign a qualified leader – a leader and subject matter expert – and concentrate authority in that person.
Create a simple plan, simple reporting – whiteboards can be the most powerful tool for management – and a simple decision making process for issues and changes.
Look after the team – get the key stakeholders or senior executives to spend time with them, deal with food and transport issues generously, give them support staff without hesitation.

Keith Haviland is a business and technology leader, with a special focus on how to combine big vision and practical execution at the very largest scale, and how new technologies will reshape tech services. He is a Former Partner and Global Senior Managing Director at Accenture, and founder of Accenture’s Global Delivery Network.  Published author and active film producer, including Last Man on the Moon. Advisor/investor for web and cloud-based start-ups.

Delivery, Leadership, Masters of Delivery, Technology Services

Masters of Delivery, Episode 2 : Ten Commandments for Successful Program Delivery

September 12, 2014 Keith Haviland 3 Comments

This article provides guidance for those leading or working in a large program. Its original name was WB and the Tablets of Stone until I went for something more directly informative. We’ll see why in a moment.

Let’s introduce WB first.

WB is another Master of Delivery I am privileged to know – a natural results-driven program manager, who can instinctively drive the largest projects and programs to completion. He has a flair for action, for handling scale and a gritty humour. He is a kind of Indiana Jones or Hans Solo of program management. So, in a galaxy a not so long time ago …

Context

We faced two years of hard work on a major program across much innovative software development, and data conversion of records covering the activities of millions of people. This would be followed by re-casting business processes from customer billing to how a set of large call centres operated. As many will know, a large call centre quickly goes off the rails with any system problem. Even with good fallback procedures, work queues can build rapidly and customers will hang on the phone for what seems like interminable periods.

In short, the new system would drive almost the entirety of our client’s business. It was high risk. And to create and deploy it, we would assemble a large team – around 400 at peak – across technologists, business people, operations and executives. It was a team of teams.

Defining Goals, Culture and Behaviour

WB and I wanted a simple way of defining and communicating our goals, and the culture and behaviours we wanted. As WB would put it, “‘the job of leadership is to create an environment in which people can succeed’, and the ten commandments became one of the major vehicles for achieving this.

This is a common management pattern. Many projects summarize their approach in ten bullet points. Indeed, I once informed a very capable member of a Quality Team that there was a typo in the ten commandments of Quality they had just published – there were just nine. That document was republished fast.

Good Ideas Get Reused

Our “commandments” were to strike an unusual chord with the team, who liked them, and bought into the aspiration they represented.. They are distinctive in their focus on team behaviour. They push control and issue resolution into the team (although ultimate accountability must still reside with program leadership).There is nothing on method, process or technique, although these were important in the background. In essence, these commandments were about creating a mission, a team and a driven culture of success, at scale.

As is often the case with things that work, our ten commandments become viral across a wide community. They have been used, with scant modification, on many projects. They are still being used.

And the reason for the sub-title of WB and the Tablets of Stone is that we came very close to having them engraved on real stone tablets. We had got our mad scheme costed, and we had chosen the shape of the tablets. We thought this little bit of theatre would help get the message across. In the end, we decided we were getting a little too impressed with ourselves, and went for a more portable presentation.

The Ten Commandments

These were the ten commandments:

Meet Your Promises
Act as One Team.
Aim to be Exceptional, Exceed Targets
Understand and Report True Status
Finished Means Finished – Never Leave Problems Unresolved
Take Full Ownership. Ask, Escalate, Push
Be Ready for Change
Learn
Take Pride. Have Fun. Celebrate Success.
Meet Your Promises

Let’s look at each one in detail.

Meet Your Promises

We wanted a huge focus on what the client needed, what would make them successful and what had been agreed. Our promises were therefore the target scope, the schedule and the cost budget. We wanted that to be in the thoughts of our team, every minute of every hour of every hard-working day.

I think this is fundamental. It is the foundation principle for all good delivery.

Scope, schedule and budget eventually become commitments, and not eternal items of negotiation. Indeed base-lining is a key management skill. Program leaders will always have to handle change, but must keep the baseline in mind. And they should instill that can do mentality in their teams. That attitude builds client or business trust, and so makes easier the hard times when tough decisions are necessary. In fact, we shared the ten commandments with our clients. We wanted them to be part of the mission.

As part of this, all programs need a purpose that is easy to understand and communicate. Every individual team-member should understand the promises they are supporting. At one level a Concorde is hundreds of thousands of precision components. The simple goal however was to fly passengers supersonically and safely. Any worthwhile program should be easily summarizable. The fine details should also be communicated. Understanding scope, and the basics of any contract, should be a goal for each individual.

Act as One Team.

A team of teams automatically means boundaries. These boundaries can be complex – within a software development team, between the dev team and the business, between a business and its suppliers, between a team and services operated in a cloud, or simply between physical locations.

The challenges that result include: simple blame games, high politics, schoolchild howler style misunderstandings, Everest-sized integration issues, subtle cultural problems and more.

One of my great insights was running a leadership team that consisted of good individuals – actually great individuals – who simply did not function as a team. Boundaries became patrolled borders. With enormous reluctance, I had to change things.

We will look at some of these situations in later articles. Things that will bind a team together include:

A simple set of goals (like the ten commandments!)
A decent scope definition
A good architect who understands links between teams
A plan that may be hard, but is believable
Good management
Good connections with the business
Dealing with personality and ego issues, especially in leadership roles
Creating a community, and celebrating success

Above all, the aim should be for a culture that encourages the building of trust. It always has to be earned via praxis, but must always be expected.

Aim to be Exceptional, Exceed Targets

We wanted people to aim high for themselves, and for the team. We especially wanted to avoid the kind of foggy ennui you can find on large programs.

Part of premise is this. Setting specific goals generates higher levels of performance than general goals, and the higher the target the more a person will do to reach that target [this comes from the research of Edwin Locke at the University of Maryland.]

One of my best personal examples of this comes from elsewhere, from my experiences in creating large delivery centres in India. It took our team eighteen months to grow to 500 people. Then potential demand started to increase exponentially. We could have gotten away with continued moderate growth, but I asked the team to aim very high and recruit the next 500 people in the next five weeks. Importantly, I let them go away to think about it.

They went for it. They worked almost 24×7 for five weeks, with a short break for an important cricket match.

By the end of the period they had made 526 offers to good candidates. They had made their own piece of history. And after that, the team knew what they were capable of, and created one of the best large-scale recruiting engines in India. We will return to this example in a future article.

Understand and Report True Status

To this, we added the text:

Good News = +2 points

Bad News = -1 point

Wrong News = – 1 billion points

This usually raises a smile. It is meant to. Gentle humour is one of the best ways of communicating. But the point it makes is deeply serious. In any team of teams, responsibility and control should be distributed. That is the most effective approach, and it requires transparency and trust.

Good progress is always good. But bad news is useful because something can be done about a known problem. Bad news will also often uncover systematic issues – in the design, the development process, or similar. As we saw in Episode 1 of Masters of Delivery, all programs are about forming a plan and then managing the issues.

It is wrong news that is poisonous to a large program, and wrong news can be generated by a good team, proud of what they are doing, who want to fix their issues before they become visible.

The test of a team and its management is always through tough times – times I once described as when the sky is dark with the wings of headless chickens coming home to roost.

So, WB and I spent time building this culture of No Surprises, and creating a sense of accountability for knowing status, being transparent and feeling able to report trouble. Above all we wanted people to have the courage to ask for help.

That also requires a certain generosity in management who equally need to view bad news as useful. I would go further: the primary job of management in execution is to help their team with issues

Finished Means Finished – Never Leave Problems Unresolved.

Any team-based process, and certainly any large program, is a series of queues as work moves through the hands and minds of team members. So, any hold-ups have knock on effects. The trick to managing schedule is to get issues resolved fast, so work moves through the system as planned.

A team I once adopted on another project had been stuck in functional design for more than a year. Everything was work in progress. As so often is the case, the team was good. The issue was that there was no systematic connection with the users or key business sponsors, and rather than fix that, every time a design got stuck, new work was started. To resolve the issue, we built bridges and followed a systematic closedown plan in a defined sequence. It worked.

Another well-known aspect is phase containment. Larger projects will almost always consist of releases divided into phases – such as design, build, and test. Problems and gaps in design or requirements will be ruthlessly punished in later testing.

The essence of all of this is to avoid the 90% complete syndrome. The implied remaining 10% is most often the hard, expensive stuff to fix. To quote a British advertising slogan, “Finished” should mean “what it says on the tin.”. Finished should mean finished, completed, done.

Fixing hard problems when they are discovered is almost always the fastest and cheapest tactic.

Take Full Ownership. Ask, Escalate, Push

With the sub-text: Email alone does not count

WB and I faced a tough schedule. Our plans were achievable, but they were also hard. We needed a dynamic culture, and a positive buzz in our team. In particular, we wanted people to:

Feel they owned their own work fully, and were responsible for completing it
Have a sense of reasonable urgency, not to be passive or overly patient in an ‘awaiting’ status.

We especially wanted to avoid seeing the sending of an email as a significant action, or as introducing an allowable delay. We also wanted people to feel free to use management when a decision was needed, – without that seeming an issue between peers. Debate and differences are not conflict, but part of any large team.

This an important topic in a globalizing world where sub-teams will be routinely located in different places, shifted by many time zones. Each sub-team has to take direct responsibility for its own work – but also work hard on interacting effectively with other teams in other locations.

Be Ready for Change

Change is universal – we cannot escape the second law of thermodynamics. Larger programs are prone to being impacted by change, because they will run for months and years. Change can include:

Passionate support for new requirements
Unexpected changes in the business, which can result in new work, reduced budgets or cancellation
Regulation changes
Sponsors getting replaced with people with different ideas

There is much modern thinking around Agile development, which embraces change, and creates cross-functional teams that work in short iterations. This suits certain types of problem, at a certain scale, but there will always be larger projects with a different rhythm.

The key message in this commandment is be ready. It is a job of a project manager or program leader to handle issues and change well, and not let change become mindless, infinite churn. Projects can plan for change via contingency and specific change windows in projects with multiple releases.

The level of engineering of any approach to handle change depends on project scale, but the following will always be required.

An anchor – a baseline – from which the impact of change can be judged
Adaptability and resilience in program leadership
Contingency and change windows
A process for tracking and making decisions about change understood by business sponsors
An architect or architect team who can assess impacts across a whole system

Learn

What did we mean by this? One part was personal. We wanted team members, and the client people we worked with to be successful, and to learn from the experience.

Again, the team dimension was critical. WB and I had three releases ahead of us. We needed the team to learn as a whole so we could:

Apply insights to improve business functionally
Innovate around tools and environments
Understand and avoid the first time through issues with Release 1
Gather actual metrics against estimates to improve future planning and set productivity and quality improvement targets.

Learning also gives the chance for senior members of the team to demonstrate stewardship by coaching, and handing on their own experience and insights.

The phrase Continuous Improvement captures some of this, but it is dry, implying process improvement. I prefer the more human notion of a learning team, learning collectively and at individual level.

Take Pride. Have Fun. Celebrate Success

Any team becomes a community. Any large team is likely to be a young community, given the way such teams are built-up, capable of great energy and commitment.

Building a team “brand” around the purpose of a program, and its attitude and results is one step in accessing that energy. Communication of clear goals, and creating that sense of making history will help here.

A healthy level of having fun, of good social interaction also helps make a good team, and although it doesn’t have to be managed, it needs to be recognized as important and supported. It is particularly necessary in today’s global teams, and I would recommend starting any distributed relationship with physical meetings where people can get to know each other, and allow time for social events.

The third element in this commandment is about recognition. Those familiar with Maslow’s hierarchy of needs will remember than esteem and recognition rank highly. People thrive on doing good work, which is noticed and celebrated.

Celebration can be real time. Testing management requires a unique approach, and one talented leader I know used a bell to mark when a test pass had been successful. As a result, applause rippled through his team several times a day. On the last day of testing, the final ring of the bell generated a standing ovation – including from our clients.

Celebration can be personal – public and deserved notes of praise or thanks go a long way. It can be a formal event to mark a major team success.

Create the right spirit, and the rewards are long-term – team-members will work with each other again and again. Such self-sustaining communities, especially if they are open, are powerful, and valuable.

10. Meet Your Promises

We end where we started. Any program is about a set of promises: to your client or business users, your own team if you have one, and your own management. Great delivery is about meeting all these promises, and learning a little something yourself.

Get something done, and make a little history, today.

Keith Haviland is a business and technology leader, with a special focus on how to combine big vision and practical execution at the very largest scale, and how new technologies will reshape tech services. He is a Former Partner and Global Senior Managing Director at Accenture, and founder of Accenture’s Global Delivery Network. Published author and active film producer, including Last Man on the Moon. Advisor/investor for web and cloud-based start-ups.

Technology, Delivery and Digital Culture