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.

India

Happy Ganesh Chaturthi – An Ancient Greeting For Modern Times

September 2, 2014 Keith Haviland Leave a comment

This little article arose from a simple greeting I made to ”all those who live in, love and connect with India”. It was especially meant for the great many friends I had made while working with India in the last decade and a half. I made my greeting via very simple Facebook and lLinkedin messages on the proper day , August 29th 2014.

The message was Happy Ganesh Chaturi.

Ganesha Chaturthi is the Hindu festival celebrated in honour of the god Ganesha, the elephant-headed god. In business in India, and in particular when non-Indians met Indians for the first time, a model of Ganesha is one of the most common gifts. (I can see three such models in my own office as I type this).

With a couple of days I had received more than 200 likes and quite a few return greetings. It was probably seen by well over a thousand people and although it couldn’t really be described as going viral, I was touched that it had struck a cord. I also noticed that many of the greetings I received were from non-Indians, mainly those who had some link with India’s hugely important IT industry.

The start date of the festival typically falls between 19th August and 20 September, varying according to the exact phase of the moon. Clay images – sometimes of enormous scale and ornateness – are kept in temporary shrines, and then with great pomp, they are immersed in water. This is especially popular and elaborate in Maharashtra and other parts of Western and Southern India. It seems great fun, although with true meaning.

Ganesha is a positive symbol. He is the Lord of success and destroyer of evils and obstacles. He represents quite a lot of other good things, such as education, knowledge, wisdom and wealth.

But more than that – precisely because images of Ganesha are given so many times as gifts between Indians and non-Indians – Ganesha now represents connection between cultures, and modern India itself – a vibrant, complex country that is taking its place in the world. Of all the Hindu symbols, it is Ganesha that is the most known outside India and its diaspora.

So for all of you connected with India, and a little late (although my original greeting was on time), here is to a Happy Ganesh Chaturth, and success and auspicious beginnings for you all. Ganpati Bappa Morya.

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.   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.

The image “Ganesh mimarjanam 2 EDITED” by Vijay Bandari shown with this article is licensed under Creative Commons Attribution 2.0 via Wikimedia Commons.

Delivery, Masters of Delivery

Masters of Delivery, Episode 1: Leon Makes a Plan, Manages the Issues

September 2, 2014 Keith Haviland Leave a comment

Sometimes the most profound points are the simplest. This article is about the essential foundation of achieving good or extraordinary delivery results from any major program or project. Make a plan, manage the issues. This is the essence of project management, and program management.

Let’s take a real example – rather a small one by some standards, but one that reflects a common experience in software development.

Context

The context was this. I had been given responsibility for a very large program to develop a software and business solution for a number of British utilities. That program had started a number of months back, and was troubled. The original plan has been created with misaligned expectations between the parties involved – expectations around the balance of scope, schedule and budget. That took careful, close work with the clients and suppliers involved to unpick. In the end, the program would be delivered just under the revised budget I had planned, and the solution would support at peak near 25% of UK electricity production.

An Impossible Schedule?

But that lay in what seemed a distant future. Right now, I was deep in discussion with my good friend Leon. Leon would himself go on to become a true master of deliveryand lead gigantic programs for significant and global clients. But on that particular day we faced the daunting task of testing and fixing the business functionality of a vast system in just 8 weeks to fit in with our complex overall schedule, a schedule determined as always by business dates. The test phase alone would involve the work of around 100 people, including our clients. It was the critical path on which all else depended.

How to decompose the problem? And to ensure success? Leon and I spoke at great length. The insight we had was simple, but critical. We had to form the best plan we could, then manage the inevitable issues that would arise given scale and speed.

Planning and Preparing …

The core plan was formed using a standard estimating model, but we knew we had to prepare to manage the coming issues, defects and changes exceptionally well. So, we added or extended the following:

Systems and resources to record status by individual tester, individual software defect and much more. We wanted to have perfect insight into exactly where we were, and in a way that wasn’t a burden on the team.
Earned value tracking that showed how much we had achieved versus the ambition of the plan. We wanted to know exactly how well we were doing.
The technical capability to create almost an arbitrary number of virtual testing environments. In these days of the cloud, this would have been much easier. However, even with more primitive tools, we very deliberately invested in understanding and then provisioning what we needed. We made sure we could rebuild the application fast. We wanted to make show intellectual effort wasn’t held up by basic resource constraints.
Automated regression testing. Even today, this is a build effort that many try to avoid. But there is no better way of ensuring that a system remains stable as it is changed via multiple paths, and by multiple hands. We wanted to ensure we always had a working application, and did not accidently break it.
A twice-daily meeting structure that focused only on issues and their resolution.We wanted nothing to slow down the rhythm of progress.

Communication, Building Support, Making Culture

And then came more expectations management. We took the team – across suppliers and client personnel, from junior developer through to board level sponsors, through our plan. We would need their help. We wanted no surprises in status. We wanted people to own their issues, to pro-actively seek resolution and not hand-off trouble in emails. We needed our clients to support the drive for schedule, while we needed to support the drive for accurate scope and a system that would work functionally. The hard cultural and client work we had put in paid off. We gained much support.

We were exceptionally well prepared.

Wheels, Buses …

So, we started our eight weeks of test execution. Even assuming a 7-day week, each day represented almost 2% of schedule.

This was scary stuff, but we were exceptionally well prepared.

The first day didn’t go well. This was probably fine. Any new undertaking will have teething issues. Then the second day passed, and progress was slower than the plan demanded. Maybe that was fine as well. It was still early days.

A week passed. Almost 13% of schedule. We were 50% behind were we planned to be. This was a major issue. The traffic lights on our status reports glared red. A dark cloud settled over the team. This was the time when temptation may make leaders bang tables, and add extra people without the time to train them.

The Team Looks for Solutions …

But issues are there to be managed, and not all risks can be predicted. So Leon looked at the data, and spoke to his team. The team’s insight was of course the most valuable, and they weren’t defensive. They had been well trained. They were looking for solutions.

Leon and the team made the following changes, with precision:

Increased the number of test environments even more
Made productivity improvements to a test data tool
Gave two hours training on test data to the team
Introduced even finer reporting, not so much to give management extra visibility, but to allow the teams to see hourly and daily inch progress. And that we made visible on whiteboards, so all could see progress.

We had included the smallest amount of schedule contingency in the planned. We used it, and recast the plan.

We started to meet our new plan. And by the end of week 8 we hit the date – at great velocity maybe, but we hit the date, and the software moved into an implementation phase. It would go live successfully, down the implementation road that lay ahead.

On reflection, we had prepared a decent plan – maybe even an exceptional one – and the investment in systems, reporting and environments had been highly worthwhile. We had created a platform, where small changes had helped recover the plan.

But above all, we had been prepared – with tools, processes and more – to handle the inevitable issues. Most importantly, we had been culturally prepared to have the honesty to face up to our execution issues and fix them.

Make a Plan, Manage the issues.

To put it simply: we had a simple goal, a plan, ambition, and confidence we would try our best. But that is never enough. We were prepared from the first moment as a team to understand and proactively fix our mistakes, knowing that is part of any large undertaking. And that is the essence of good delivery.

Cloud, Mobile, Technology Services

New Dangers, Opportunities: mobile, cloud and changing client expectations will deconstruct and reshape IT services.

September 2, 2014 Keith Haviland 1 Comment

As in the Chinese proverb, we inhabit interesting times. Disruptive changes in client expectations and the accelerating evolution of technology are remaking the IT services industry. It is a time of long change, bringing challenge and possibility and opportunity. Let’s see why.

Results of the Quarter: Mixed Performance in Outsourcing, New Growth in Consulting

Most of my career has been spent in providing tech services, so I watched the cycle of summer 2014 earnings announcements from the big IT services companies with much interest.

One stand out set of results came from the giant India-based outsourcer TCS. It managed quarter on quarter revenue growth that almost matched the annual growth of some of its major competitors. A headline from the India Business Standard said “TCS Q1 results prove elephants can dance”.

But overall the mood across the sector was muted as the multi-national and major Indian players reported. Other providers did not do so well. There was greater variability in results than in previous quarters. Total cost of ownership and pricing remained major factors for clients of big IT and BPO services. It is a tough market.

Conversely, the feedback I get from speaking to leaders of classic consultancy firms is straightforwardly positive. Many of the traditional players have seen annual consulting growth around 10%, and some upstart new entrants are doing much better than that. There is demand for classic, high-end systems integration skills coupled with new digital capability. There is new energy in onshore recruiting markets and raw competition for the most modern skills.

Given that consulting and system integration have often been seen as traditional and declining business areas, what’s happening? Let’s start by looking at outsourcing and Application Development and Management (ADM) services.

Outsourcing Under Pressure

Classic outsourcing –primarily a global delivery/offshore business these days – remains a huge market. It is also one under considerable pressure, and long-term pressure at that. This partly originates from clients. In recent conversations with board members of client organisations, I have been told often of dissatisfaction with the true value of much of modern outsourcing.

As a result, the market is deconstructing and transforming the offerings it wants from suppliers. Many clients want more control and more value. So, many contracts continue to become smaller and shorter. Other clients seek the ultimate cost solution. There are now a small number of very large, broad and long-term engagements – covering infrastructure, applications, BPO and consultancy, where suppliers are offering intensely competitive rates, and simultaneously buying the client’s assets, or paying a price for the existing IT department.

A Cycle of Renewals and a Battle for Market Share

Importantly, the outsourcing sales cycle is now one largely based on renewals, where clients put out existing contracts for rebid. The result is a ruthless battle for market share – red in tooth and claw. It is a classic commodity market. There will be winners, but the likely long-term outcome is a smaller number of larger players.

I’ve led teams that built market leading cost structures, and that introduced global delivery and productivity innovation at large scale, But any company with strong interests in this market will need to continuously and radically hone its on and offshore cost base, and seek new innovation to drive productivity. There will be times when capital will need to be used boldly to win deals.

Acceleration in Technology

The new activity in consulting on the other hand is part fuelled by shifts and disruption in technology, and the creation of new business model possibilities.

The code word for this is “Digital” of course. It works well as shorthand, and all the major global players have a digital strategy and vision, looking for new growth in what a constrained total services market.

But any supply-side player or CIO also needs to make sure they aren’t simply painting speed stripes on the side of their 10-year old SUV and then stenciling a large ‘D’ on the hood. Digital shouldn’t just be a re-branding of old e-Commerce models. We need to be much more specific about the disruptions, opportunities and challenges.

Mobile-first, Cloud-first

One of the simplest and best visions of the new world comes from Microsoft, and was summarised in CEO Satya Nadella’s recent email to all his employees. He talks of a mobile-first and cloud-first world, made up of billions of PCs, tablets, mobile devices and sensors that run “cloud service-based apps spanning work and life”. The implication is that we should see this world, and its opportunities, as based on the integration of mobile, cloud and applications. The recent tie-up between Apple and IBM also underlines this pattern. Other digital definitions include data, analytics and social tech – vital disciplines – but for me “mobile-first/cloud-first” is the essence of the current tech wave.

Mobile usage already dominates Internet access in some parts of the world. It will everywhere. Cloud moves increasingly to mainstream use. One simple example: There are still teams that take 3 months to provision development and production environments, sometimes because of market regulation. One UK based start-up team I know automatically create their dev environments under Amazon Web Services every morning and shut them down every evening to avoid paying overnight costs. That is a vast difference in productivity.

Indeed, one of the reasons that there is so much enthusiastic start-up activity is the ease of creating the environments to build and run apps. Young entrepreneurs assume the cloud – in fact they live and breathe the cloud. It gives them instant potential reach, and instant visibility,

Software as a Service and the Changing World of Applications

As a concept, cloud starts with reasonably cost competitive and elastic access to infrastructure and platforms. It is also increasingly about access to a rich and developing market of apps and services, under the banner of SaaS or Software as a Service. It is this that will make cloud of fundamental importance. Indeed, the fastest growing skill needs I’ve seen over the last two years are precisely around the configuration of SaaS apps like Salesforce and similar.

And the use of SaaS gets bolder, larger and more complex. High-end system integration skills are increasingly needed for cloud integration.

Early in the Life-Cycle and the Growth Curve

Another key insight is that we are early in the life cycle of our mobile-first and cloud-first world. Given the histories of Nokia and Blackberry, mobile is a market subject to fast learning and fast change. We should not assume a world dominated by Samsung and Apple devices. For example, high spec, lower cost devices from China are making rapid progress in domestic and international markets. Other examples of evolution in progress include the current vast human experiment with form-factors, or the large number of emerging technologies for handling mobile payments on the hoof.

Many Platforms, Many Choices

Here’s another important symptom of an immature market: the CTO of a significant, world-class B2C company has complained to me of the increasing differences between mobile universes – iOS, Android, Windows – and the effort required to deploy consistent, high-quality apps across them. It eats too much of his dev budget.

We have simultaneously made it easier to run software, and harder to write it.

We all have folk memories of a simpler world of the 1990s and early 21 century. There was a roughly standard market architecture based around Windows PCs, the Web, a limited number of server types and a small number of dev and database choices of significance.

Now is a time much more reminiscent of the 1970s and 80s. There are major choices to be made: iOS, Android, various incarnations of Windows, Google, Amazon Web Services, Tizen, many choices of language and database, and decisions to be made between classic enterprise software and cloud-served enterprise upstarts. Public cloud services can be relatively expensive for some domains – which means careful thinking and prototyping is important – and billing of cloud services can be complex.

A New Dawn for Architects

People are looking for help. One small start-up I like has created tools for enterprises to build very simple cross-platform mobile apps. They get extraordinary senior access to corporates as enterprises grapple with the new choices, and the resulting complexity.

So one great need, and for IT services companies one of the opportunities, is for informed architects – people who can shape integrated solutions across these platforms, across mobile and cloud, and then across business function, data and social tools. Such thought leaders are needed more than ever. And there is also a market premium for developers who are fluent with the new tech.

Faster and Better and Cheaper?

Businesses have also long lost patience with the cult of the large program – a long-term trend of course, but the new technology seems to offer an additional promise of greater agility, and responsiveness.

The software development model is shifting from something akin to building cathedrals to something more like town planning where a good architecture connects a network of small apps teams delivering in Agile sprints or smaller, more traditional releases.

Many companies are creating digital development hubs that are often onshore. The result is new demand for coding skills. The art of programming is fashionable again, and with web development, individual developers can make a huge business difference. It is likely that key, future IT services will be less based on process. They will be more human.

Given the integration of mobile, apps and cloud, teams are being structured around aDevOps model which infrastructure and application are treated as a connected whole. A new science of project as a service is being created.

Masters of Delivery

This will be important to get right as ambition around cloud-served systems grow. There are already a number of large-project failures that have at their core a naïve approach to Agile. So, we will need a new generation of what I call Masters of Delivery, people with leadership and project management skills able to bring and adapt their insights around scale and managing complexity to the new tech.

These new development approaches may increase speed, but at the cost of some complexity. Systems become networks of cloud services. Projects become networks of apps teams.

There is more opportunity here. Another bright start-up team I know is developing new ops tools for instrumenting and managing applications in the Cloud, They gained customers almost from the first day of business, so large is the need. More challenging will be the creation of better, re-usable architectures that are inter-operable across mobile, cloud (private/public), and enterprise/legacy platforms, but both the need and an enormous opportunity are there.

Putting It Together

To summarize and conclude:

Firstly, traditional big IT services – based on outsourcing and ADM models – remain a large market, but one that is highly commoditized, and competitive. The focus on cost will remain fundamental, driven by competition for market-share.

Opportunity – Transforming Outsourcing

But here is also a gigantic opportunity for new types of service, where human effort is replaced and augmented by automation. In fact, as clients switch to cloud-served apps, the outsourcing model as a whole will need radical overhaul. This will likely be a long journey, given the early and evolving nature of relevant technology, and the fact that building complex software to support multiple client organizations requires real investment. The big IT players have many resources. They will need to use them.

Opportunity – New Integration Services

Secondly, we are all embarked on a ten-year transition to that mobile-first and cloud-first universe. This creates new opportunity, and open space for people and new start-ups.

We will need new tools and architectures to manage and integrate networks of teams, devices, infrastructure and apps. We will need world-class architects to make big choices and work across an integrated stack that links infrastructure, application and business. We will need re-engineered and re-vitalized project management and systems integration skills that can create the project-as-a-service and agile delivery models of the future. And the process of building systems will likely be less process-driven, and more based around human-skills and good tools.

Opportunity – Reshaping the Service Model

IT services companies can themselves deliver these capabilities in reshaped ways and at reduced cost. New types of flexible relationships with employees are not only possible, but often desired. There is an opportunity for the brave to re-invent and upgrade global delivery culture around new aspirations. And course, architectural frameworks, SaaS and automation can be used directly to automate, deliver and enable such services. IBM is already providing online “digital service offerings” across social analytics, inspection of SAP and Oracle systems, and more. The possibilities for creativity are immense.

It is a time of long change, and as always that brings challenge and possibility and opportunity – for individuals, established companies and new entrants.

Keith Haviland is a business and technology leader, with a special focus on how to combine big vision and practical execution at the largest scale.   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

Achieving the Incredible – General Principles from NASA Mission Control

September 2, 2014 Keith Haviland Leave a comment

Throughout my career, I have often thought about those qualities required of people and teams when delivering large-scale and complex undertakings.

It takes a special kind of leader and a special kind of group to aim at incredible things with success, and especially deal with the inevitable problems that come from very large teams, businesses and highly-complex programs. There’s much to say around culture, how to organise, how to plan and how to operate and communicate. Handling deep issues and major change is also part of the art. It is a subject that fascinates me, because in the end we are a social, teaming species that achieves its potential through working together.

To get started, below is one of the best set of principles I have seen for running scale and complexity, and for when management, team work and leadership really matter.These were developed by NASA mission operations over the years – primarily learning from Mercury, Gemini and Apollo. They have been popularised by the great Gene Kranz among others – he led operations for the Apollo 11 landing, the Apollo 13 rescue and much more.

These Apollo-era technical triumphs were also the triumphs of large, interconnected teams, linked by a strong simple vision, sophisticated management systems and the principles below. As Gene Kranz himself said: “We had risen to probably one of the greatest challenges in history, put a man on the moon in the decade. We’d created incredible technologies. But what was most important, we’d created the teams, what I call the human factor. People who were energized by a mission.”

It is also interesting to note that in the shuttle era, there were times when the principles weren’t fully applied – and the resulting cultural comprises had tragic consequences with Challenger and Columbia. The flawed and complacent decision to launch Challenger to maintain schedule was very different from the bold move to launch Apollo 8 – essentially a Saturn V rocket test flight – to go around the moon, where the risks were understood and managed. The principle of vigilance has been added as a result. No individual or team can can take its performance for granted, and risk and change are eternal.

The core principles are not tied to spaceflight and are strong principles for any team trying to achieve the large scale, complex and incredible. They are rules for making any kind of history, open to all of us. Enjoy.

Foundations of Mission Operations

1.To instil within ourselves these qualities essential to professional excellence

Discipline…Being able to follow as well as to lead, knowing that we must master ourselves before we can master our task.

Competence…There being no substitute for total preparation and complete dedication, for space will not tolerate the careless or indifferent.

Confidence…Believing in ourselves as well as others, knowing that we must master fear and hesitation before we can succeed.

Responsibility…Realizing that it cannot be shifted to others, for it belongs to each of us; we must answer for what we do, or fail to do.

Toughness…Taking a stand when we must; to try again, and again, even if it means following a more difficult path.

Teamwork…Respecting and utilizing the abilities of others, realizing that we work toward a common goal, for success depends upon the efforts of all.

Vigilance… Always attentive to the dangers of spaceflight; Never accepting success as a substitute for rigor in everything we do.

2.To always be aware that suddenly and unexpectedly we may find ourselves in a role where our performance has ultimate consequences.

3.To recognize that the greatest error is not to have tried and failed, but that in the trying we do not give it our best effort.

Technology, Delivery and Digital Culture

Monthly Archives: September 2014

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

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

Happy Ganesh Chaturthi – An Ancient Greeting For Modern Times

Masters of Delivery, Episode 1: Leon Makes a Plan, Manages the Issues

Achieving the Incredible – General Principles from NASA Mission Control

Writings from Keith Haviland