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 