Tag Archives: program management

Business, Delivery, Leadership, Spaceflight, Technology, Technology Services

Failure is an Option

January 14, 2015 Keith Haviland Leave a comment

Things will always go wrong, but excellent preparation and strong leadership can turn failure into a kind of success.

The story of Apollo13 is a parable of gritty resolve, technology excellence, calm heroism and teamwork. For anyone focused on leadership, operations and program management it is absolutely the purest of inspirations.

The film of Apollo 13 centres around the phrase “Failure is Not an Option,” invented post the original drama in a conversation between Jerry Bostick – one of the great Apollo flight controllers – and the filmmakers. It summarises a key part of the culture of Apollo era NASA, and it has found its way onto the walls or desks of many a leader’s office. It is part of the DNA of modern business culture, and of any sizeable delivery project.

Lessons from the Space Program

But one of the reasons that the crew was recovered was this: throughout its history, NASA and mission control knew that failure was precisely an option, and they designed, built and tested to deal with that simple truth. The spacecraft systems had – where physically possible – redundancy. The use of a Lunar Module as a lifeboat had already been examined and analyzed before Apollo 13. In the end, a old manufacturing defect caused an electrical failure with almost catastrophic consequences. It was precisely because Mission Control was used to dealing with issues that Apollo 13 became what has been called a “successful failure” and “NASA’s finest hour.”

The ability to respond like this was hard earned. The Gemini program – sandwiched between the first tentative manned flights of Mercury, and the Apollo program that got to the moon – was designed to test the technologies and control mechanisms needed for deep space. It was a very deliberate series of steps. Almost everything that could go wrong did: fuel cells broke, an errant thruster meant that Gemini 8 was almost lost, rendezvous and docking took many attempts to get right and space walks (EVAs in NASA speak) proved much harder than anybody was expecting. And then the Apollo 1 fire – where three astronauts were actually lost on the launch pad – created a period of deep introspection, followed by much redesign and learning. In 18 months, the spacecraft was fundamentally re-engineered. The final step towards Apollo was the hardest.

But, after less than a decade of hard, hard work – NASA systems worked at a standard almost unique in human achievement.

So, with near infinite planning and rehearsal, NASA could handle issues and error with a speed and a confidence that is still remarkable. Through preparation, failure could be turned into success.

Challenges of a Life More Ordinary

All of us have faced challenges of a lesser kind in our careers. I was once responsible for a major software platform that showed real, but occasional and obscure issues the moment it went into production, expensively tested. We put together an extraordinary SWAT team. The problem seemed to be data driven, and software related and simply embarrassing. I nick-named it Freddie, after the Nightmare on Elm Street movies. It turned out to be a physical issue in wiring – which was hugely surprising and easily fixed. The software platform worked perfectly once that was resolved.

Another example: In the early days of Accenture’s India delivery centres, we had planned for redundancy and were using two major cables for data to and from the US and Europe. But although they were many kilometres apart, both went through the Mediterranean. A mighty Algerian earthquake brought great sadness to North Africa, and broke both cables. We scrambled, improvised, maintained client services, and then bought additional capacity in the Pacific. We now had a network on which the sun never set. It was a lesson in what resilience and risk management really means.

Soon enough, and much more often than not, we learnt to handle most failures and problems with fluency. In the Accenture Global Delivery network we developed tiered recovery plans that could handle challenges with individual projects, buildings, and cities. So we were able to handle problems that – at scale – happen frequently. These included transport issues, point technology failures, political actions and much more – all without missing a single beat. Our two priorities were firstly people’s safety and well being, and secondly client service, always in that order.

Technology – New Tools and New Risks

As technology develops, there are new tools but also new risks. On the benefit side, the Cloud brings tremendous, generally reliable compute power at increasingly low cost. Someone else has thought through service levels and availability, and invested in gigantic industrialized data centres. The cloud’s elasticity also allows smart users to side step common capacity issues during peak usage. These are huge benefits we have only just started to understand.

But even the most reliable of cloud services will suffer rare failures, and at some point a major front-page incident is inevitable. The world of hybrid clouds also brings new points of integration, and interfaces are where things often break. And agile, continuous delivery approaches means that the work of different teams must often come together quickly and – hopefully – reliably.

The recent Sony incident shows – in hugely dramatic ways – the particular risks around security and data. Our technology model has moved from programs on computers to services running in a hybrid and open world of Web and data centre. The Web reflects the overall personality of the human race – light and dark – and we have only just begun to see the long-term consequences of that in digital commerce.

Turning Failures into Success

What follows is my own summary view of those key steps required to handle the inevitably of challenges and problems. It is necessarily short.

1. Develop a Delivery Culture – Based on accountability, competence and a desire for peerless delivery and client service. Above all, there needs to be an acknowledgement that leadership and management are about both vision and managing and avoiding issues. Create plans, and then be prepared to manage the issues.

2. Understand Your Responsibilities – They will always be greater in number that you think. Some of them are general, often obvious and enshrined in law – if you employ people, handle data about humans, work in the US, work in Europe, work in India and work across borders you are surrounded by regulations. Equally importantly, the expectations with your business users or clients need to be set and mutually understood – there are many problems caused by costing one service level, and selling another. Solving a service problem might take hours or days. Solving a problem with expectations and contracts may be the work of months and years.

3. Architect and Design – Business processes and use cases (and indeed users!) need to account for failure modes. The design for technical architectures must acknowledge and deal with component and service failures – and they must be able to recover. As discussed above, cloud services can solve resilience issues by offering the benefits of large-scale, industrialised supply, but they also bring new risks around integration between old and new. Cloud brings new management challenges.

4. Automate – Automation (properly designed, properly tested) can be your friend. Automated recovery and security scripts are much less error prone than those done by people under stress. There are many automated tools and services that can help test and assess your security environment. Automated configuration management brings formal traceability – essential for the highest levels of reliability. Automated regression testing is a great tool to reduce the costs of testing in the longer term.

5. Test – Test for failure modes in both software and business process. Test at points of integration. Test around service and service failures. Test at, and beyond, a system’s capacity limits. Test security. Test recovery. Test testing.

6. Plan for Problems – Introduce a relevant level of risk management. Create plans for business continuity across technology systems and business processes. Understand what happens if a system fails, but also what happens if your team can’t get to the office, or a client declares a security issue.

7. Rehearse Invest in regular rehearsals of problem handling and recovery. Include a robust process for debriefing.

8. Anticipate and Gather Intelligence – For any undertaking of significance, understand potential issues and risks. Larger organisations will need to understand emerging security issues – from the small, technical and specific to more abstract global threats. Truly global organisations will need to sometimes understand patterns of weather – for example: to determine if transport systems are at threat. (I even once developed personal expertise in seismic science and volcanism.)

9. Respond – But finally acknowledge that there will be major issues that will happen, and such issues will often be unexpected. So, a team must focus on:

Simply accepting accountability, focusing on resolution and accepting the short-term personal consequences. It is what you are paid for.
Setting-up a management structure for the crisis, and trigger relevant business continuity plans
Setting up an expert SWAT team, including what is needed from suppliers.
How to report diagnosis and resolution – be accurate, be simple, avoid false optimism and be frequent
How to communicate with stakeholders in a way that balances information flow and the need for a core team to focus on resolution
How to handle media, if you are providing a public service
And after the problem is solved and the coffee machine is temporarily retired, how does the team learn

And finally a Toast …

In previous articles, I have acknowledged the Masters of Delivery I have come across in my varied career.

In this domain covered by this article, I have worked with people in roles such as“Global Asset Protection”, “Chief Information Security Officer” and teams across the world responsible for business continuity, security and engineering reliable cloud services. They work on the kind of activity that often goes unacknowledged when things go well – but in the emerging distributed and open future technology world, they are all essential. To me, these are unsung “Masters of Delivery.” Given this is the start of 2015, let’s raise a virtual glass in celebration of their work. We all benefit by it.

Keith Haviland

This is a longer version of an article originally posted on linkedin. 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, Spaceflight

The Last Man on the Moon, True Leadership and Bold Programs

September 20, 2014 Keith Haviland Leave a comment

“I went to the Moon. What can’t you do?” – Gene Cernan

I have had the privilege of being part of the production team for the forthcoming and extraordinary film Last Man on the Moon, which is about the remarkable life of Apollo astronaut Eugene Cernan. The Executive Producer is Mark Stewart, the Director is Mark Craig, and the Producer is Gareth Dodds. You can find the film’s impressive trailer here.

The film has been previewed at SpaceFest in Pasadena, and at Sheffield Docfest. It received standing ovations, and good initial reviews from the Hollywood Reporter (see here) and the Guardian (see here). It combines modern footage, well-judged and well-executed special effect sequences, and excellent archive (including much footage that is rarely seen, and personal archive film of Cernan’s early years).

Like all great films. it works at many levels.

It looks beautiful. It is intensely human and at times funny or moving. It appeals to a wide audience, and people with little interest in spaceflight still become engrossed in its gripping story about a man, his family and his friends. The section about the Apollo 1 fire is deeply sad. The treatment of Apollo 17 is celebratory, and sometimes approaches the spiritual.

For me, as a student of how men and women become leaders and how teams of people, and teams of teams, can work together to achieve extraordinary things, the film has two inspirational stories to tell.

A Personal Journey of Real Achievement

The first is Captain Cernan’s remarkable personal journey. From humble beginnings, he became a skilled Navy aviator. He was next accepted as an astronaut, and the film allows you to share his raw joy at that moment. During his NASA career, he faced some difficult missions, dealt with genuine tragedy, and makes his own mistakes – including a poorly timed and avoidable helicopter trash. But he retained his passion, his ambition and an absolute focus on the program. He put in his 10,000 hours of learning, working and more. As a result, he was selected to be the commander of an Apollo mission to the moon – an achievement he shares with only eight other humans. He had become a remarkable leader, and to this day can still light a room and inspire people with his presence.

Insights into an Extraordinary Program

The second story is that – although the film is first and foremost a brilliant insight into a life- it is also simply the best summary I have seen of the golden age of the US space program as a program.

There is a scene early in the film where Captain Cernan watches a recording of Jack Kennedy’s famous speech that launched the moon program, delivered at Rice University in Houston on September 12, 1962.

The speech is redolent with history. It sets a simple, but gigantic purpose and even defines a schedule. It is a perfect example of initiating a program with scalpel-like precision.

“”We choose to go to the moon. We choose to go to the moon… (interrupted by applause) we choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too”.

The film then cuts to Gene Kranz, who reminds us that at this point the US had just minutes of manned spaceflight experience. A goal of enormous scale had been set.

A Difficult Beginning

The birth of the US space program was not easy. The film only touches on this with brief archive clips, but like any new complex program, and any new technology there were multiple failures.

One was the “four inch flight” where a thankfully unmanned Mercury-Redstone rose four inches before the engine shut down, and the rocket returned to its pad. The small escape rocket lifted off by itself, and the parachutes spilled out over the still-fueled main rocket, threatening to drag it over.

The first six flights of the Lunar Ranger program – America’s first unmanned missions to the moon – failed. There were more launch failures. The target (i.e. the moon) was missed, and cameras failed.

But all good programs are built to deal with issues, and to learn. The Mercury program did put the first US astronauts into orbit, safely. And the last three Lunar Ranger missions were completely successful, returning the first close-up images of the Lunar surface.

Gemini 9

Cernan’s first mission was Gemini 9. It wasn’t meant to be. He and Tom Stafford (the commander) were the back-up crew, but the main crew of Elliot See and Charlie Bassett were killed in a plane crash in bad weather – captured in a melancholic use of archive and voice over in the film.

Gemini was a sequence of two-man craft, designed to test in Earth orbit basic techniques of spacecraft rendezvous, docking and space walking. From a program viewpoint, it was an essential period of developing, prototyping and testing elements needed for later missions. It was a stepping-stone to Apollo and the moon.

Gemini 9 proved to be hard.

Angry Alligator

One part of the mission was to simulate docking with an unmanned Augmented Target Docking Adapter or ATDA. When Cernan and Stafford arrived they found the other craft slowly rotating, with the two sections of the cone-shaped nose shroud still attached. Stafford famously said at this point: “It looks like an angry alligator out here rotating around”.

Cernan and Stafford saw that, although the shroud’s explosive bolts had fired, two lanyards were still keeping the shroud pieces together. It would turn out that boundaries between teams, and process problems, had led to an incorrect launch configuration.

Gemini 9's Angry Alligator -NASA Image — Gemini 9’s Angry Alligator -NASA Image

A Dangerous Spacewalk

Another part of the mission, and this is a major and dramatic segment of the film, involved a spacewalk, or EVA in NASA jargon.

The truth was that at this point in the space program, nobody understood space walks properly.

The objective of the EVA was for Cernan to use a prototype Astronaut Maneuvering Unit or AMU, a science-fiction-like rocket pack. The first problem was that, after pumping up his suit it “became so stiff that it didn’t want to bend at all.” Then as he left the hatch, he began tumbling wildly, twisted around by his umbilical.

He eventually got to the rear of the spacecraft, where the AMU has been stowed.

His suit had “all the flexibility of a rusty suit of armor” and the work around the AMU proved to be much harder than expected. A lack of hand and footholds meant he could not get easy leverage to help him turn valves and enable other movements. His pulse reached 180 beats per minute. Eventually the EVA was abandoned, and the AMU left where it was.

Gene Cernan during the problematic Gemini 9 space walk

NASA would learn a lot from this failed spacewalk, showing the power of a focus on improvement that is an necessary part of any large program. They would add hand and footholds for easy leverage – which Buzz Aldrin would demonstrate successfully on a later Gemini mission. They would redesign their space suits to avoid overheating, and they would balance workloads more effectively for future Gemini and Apollo EVAs.

Apollo 10

Cernan’s next mission was Apollo 10, again working with Tom Stafford as commander.

This was a full dress rehearsal for Apollo 11, the moon landing. Such rehearsals are essential parts of any large program but especially important in something as dangerous as a spaceflight.

The Apollo 10 lunar module would get within 8 miles of the lunar surface. The mission would provide data to calibrate the powered descent guidance system for future missions, test the mission control procedures and communications systems needed for landing, and provide many other insights.

The film elegantly captures the beauty of the flight, and its arrival above the alien landscape of the film.

But, as with many other types of dress rehearsals, there was a moment of real crisis. As the Lunar dropped its first, descent stage, it began to roll and twist very violently. This had been caused by a small error in setting the controls. As Cernan remembers in the film, he observed the horizon spinning through the window many times. It was a moment of high danger, eventually resolved.

But overall, Apollo 10 was a tremendous success. It would pave the way for Apollo 11, and Neil Armstrong’s great leap for mankind.

Apollo 17

Apollo 17 was Cernan’s last mission and for him an immense personal achievement. He had proved himself capable of leadership, and he was selected to be the Apollo 17commander. As a side effect of that, he would become the Last Man on the Moon, for at least a while.

Apollo 17 would be one of the great Apollo missions, the culmination of a decade of work from a team numbering in the hundreds of thousands. It has a strong science element, and carried the only Apollo scientist-astronaut, geologist Harrison Schmidtt. They would spend three days exploring a large area with their Lunar Roving Vehicle or LRV.

In many important ways, the mission was built around the learning from Cernan’s previous flights – in the design of the spacesuits for the lunar surface, and the structuring of the EVAs, and in the data collected from the Apollo 10 rehearsal.

Apollo 17 was just not a single mission, involving a brave crew of three – it was part of a sequence, of a well-organized and well-managed series of missions that formed part of the boldest program ever undertaken, by a team of extraordinary scale. It shows what we are capable of.

Achievement, Aspiration and Opportunity

And the film ends with a voice-over from Commander Cernan that captures that sense of achievement, aspiration and opportunity.

“I went to the Moon. What can’t you do?”

The trailer of the film Last Man on the Moon is available here.

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