Aim Small, Miss Small

I have already talked about some of things that I have found help a large program or project be successful, these include:

·         The critical skills needed by the PM

·         My belief that you have to go fast

·         That going fast is best done with a small tight team

·         That doing fundamental change can be pretty challenging for all involved

·         And that some people don’t like change, and actually that’s okay

I now want to move on to the psychology of change, and its practical implications.

Let’s start by quickly summarizing what we know about the start of a program but might not admit.

1. The objective of a large program is generally described as a pithy one liner, but IT people know, and user communities don’t necessarily know, that it takes thousands of interrelated things (tasks, components, integrations, tests, and so on) to achieve the end game of a large program.

2. The end date driving the program is generally stated as a hard stop but is often an aspirational objective (executives are smart, and understand the normal failure rate of IT projects, so they set a high bar, knowing that some level of failure is likely).

3. Program scope creep is a big scary monster that just won’t die, but everybody involved in the program at some stage will be convinced that it can be subdued.

4. When you start a project, the potential issues list resembles an iceberg, with only 1/8th visible, and 7/8ths invisible.             

5. NOBODY reads a project charter that is more than 3 pages long, and NOBODY understands a plan outline (e.g. a Gantt Chart) with more than 30 or so lines in it.

6. People outside of the project at any level in an organization will glaze over when presented with a “detailed” charter and plan, and will think that the PM must know what they are doing to have produced such a detailed document. They don’t! (see numbers 4 & 5)

7. User communities have often not been through a large scale functional change in their working lives (two examples, global air traffic control systems are over 40 years old, and the US nuclear arsenal still requires floppy disks to operate, I could go on, but won’t embarrass private sector companies). 

So in short, we have a major program with a cool one line description, that requires management of massive complexity to achieve, most of the problems are not visible, and the project is constantly changing in the details, which nobody understands, and most of the recipients of this change have never been through this before. 

What could possibly go wrong?!

Just before despair sets in, I would remind you of one sentence where all of the above applies:

“I believe that this Nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to earth” – JFK, May, 1961.

Based on the above characteristics of a new program, one must give some thought about how to resolve a game plan that has some chance of success. This game plan will exist somewhere on a continuum which stretches from, at one extreme, “just go for it and hope” to the other “lets plan everything, and then we’ll know if it’s possible”. There is a problem with this continuum though:

·         “Just go for it and hope” isn’t really a strategy for the start of a program (you may need it later on, but that is another story)   

·         Progress towards knowing everything takes time, if the end point is fixed, that is burning your most precious resource.

·         In the early stages of finding things you are only likely to see the easily visible issues.

·         “Knowing everything” isn’t a fixed point, because getting there takes time, and the passing of time correlates pretty strongly to the rate of change

So where to stop along the line: I believe that this is where experience of doing horrible big projects really counts. This is the process I go through.

1.       Get your team working on something which you know will get you closer to the finish line, do this first! It doesn’t matter whether this is defining scope, building environments, writing supplier contracts, this sets the tone for urgency in your team and in the customer. In the first few weeks there should be no time where your team isn’t doing something which will be needed at the finish line.     

2.       Very quickly establish the scope, time, and budget for the project, literally in a few days with input from your team.

3.       Lay down a simple roadmap that shows the journey from A to Z in no more than 20-25 steps

4.       Talk to constituents to get their feedback on your big project steps, and ask why that can’t be done. (I’m assuming here that they will say “you can’t do that” or “that won’t work”)

5.       Adjust the high level plan accordingly

6.       You now have a high level plan that has accounted for the main issues raised, and everybody is really uneasy about it, but can’t put their finger on why it will fail.

7.       Set a specific date for go live based on this plan, and your assessment of its reality, get executive approval to proceed, and say it loud and proud.  

8.       You know that this is not how the project is going to go, but you also know you have set a peg in the ground for time.  

You now have 2 things, a fixed time, and people working on scope, your management objective is to now align productivity with the high level plan and scope with the plan. This is where “Aim Small, Miss Small” (a line from the Mel Gibson film, “The Patriot”) comes in. Now you, your team, and the client are all aimed at a specific date, and you are asking     

1.       Did we make a day’s progress today

2.       If something went wrong, how do you compensate, either by fixing the issue, or accelerating something else or preferably both

3.       What is coming up that will block my team from making a day for a day

4.       How do I get the blockage out of the way before my team gets to it

5.       Are we advancing the ball

I have read a number of positive attitude books (which, being British, I am inclined to be skeptical about, but that’s for another day). These books have a common thread, that you should envision success. I have found that in big programs, envisioning a very specific date is the same thing, this is aim small, and it helps:

1.       Everybody being involved in getting problems identified, escalated where necessary, and cleared

2.       Limits the window of change for scope creep, which in turn helps prioritization

3.       Allows the program manager to encourage (yes, I mean twist arms) focus, acknowledgement and acceptance of the coming change

4.       Encourages priority in vendors and partners

Another common facet of self-help books is the acknowledgement that a person cannot know and control everything, but working hard at your focus has more chance of success than you can believe. Aim Small is this in technology programs, a program manager can’t know everything but they need to deal with the high priority and urgent things to achieve their goal.

Aim Small is all about aiming at something very specific because in the event you miss the exact target, you may well be close enough to still achieve the objective. Miss Small is all about still achieving the objective, even if you miss the specific target. How I see that play out in program management terms is that we are at the cusp of going live, but are we ready:

1.       We have gotten very close, are we really ready to push the “go” button, the business is at stake

2.       If we take 48 hours, can we solve anything, can we calm the stress levels

3.       Getting here has been a proactive, complex and chaotic journey, so stop, breath, think clearly.

Miss Small is about being 48 hours, or a week, later than a specific (and somewhat arbitrary) date planned maybe over a year ago.

A week late, with a healthy business, and executive and business team support on a major new system is success.

Aim Small, Miss Small!

One final point, in pretty much every major program I have been part of over the last 30 years, there has been a time, deep into the project, where every team member, business user, and executive, and logic tells you that this time it won’t work, that the winds have been blowing in the wrong direction for too long.

Experience has taught me to have faith, grit my teeth, and work hard. The wind will change direction, just focus on making day for a day.

Some people just don't like change, and that's okay!

See my previous post for some context, and my definition of what a big horrible technology program is, but let’s just say I’ve ridden at a few rodeos.

In my last articles, I put forward the following positions for managing big horrible technology programs:  

  1. You have to go fast
  2. Not everybody is going to be happy when you bring change
  3. If you are going to go fast, do it with a small team

Now I want to explore the role of people in organizational stability during change. 

 Given the title, I expect the reader will think this article is about how difficult people always want to stop you succeeding; weirdly it’s almost the exact opposite. Let me explain.

 Healthy organizations are made up of many types of people, some looking for a stable paycheck, some strategic thinkers, some revolutionaries, some leaders, some followers, some looking for an easy ride, some looking to progress their careers, I could go on but I hope you get the point. What I find interesting is that the blend of these different types is affected by the culture and role of the organization. Let's consider some examples:

 A County Superior Court - Personally, I like the Judges in my County Superior Courts, and the staff that support them, to have a high level of consistency and stability, and a lower level of revolutionaries, a culture of standardized process and fairness, and fewer mavericks. These characteristics produce a more consistent, and I believe better, justice system.

 An Online Retailer – In this still fast evolving field, I would be looking for a higher proportion of people prepared to take risks, to get out there and to take on the world, because that helps push the organization forward, but also some slightly more flexible, but stable people, who run the operational part of the business, but can cope with the demands of rapid growth. With this blend there is more potential for success in the interactive environment. There have been many examples over the last 20 years of web based companies having explosive growth, effectively doing more of the same, more quickly. And every one of those companies for example Amazon, Google, Facebook, include employees who are operationally consistent.

Key to the success of both extremes of organization is a need for some people who feel comfortable with underlying stability, and feel that their way of doing things is fine. These people are needed for the success of the organization, often despite the lack of fanfare for their roles. Very likely, inherent in the psychological makeup of these people, is a resistance to change. These are your Laggards.

 Now we have established our subjects, let’s discuss how change affects them.

They are cautious, resistant, and possibly scared, and will try to stay in their own box, hoping this change will just go away. They believe that there is an amorphous “better way” to make progress that doesn’t involve this level of disruption to them, but there is often no clarity behind this “better way”. It tends to be a mirage. Most of all, they don’t want this!

Their opinion of radical change agents (like me!) is that we are just plain crazy, likely to push the organization into dysfunction and/or bankruptcy, and the plans we present are ridiculously optimistic and unrealistic, that somehow we have convinced the leadership that this craziness is possible, but it’s just not!

And that’s okay, actually for me, it’s better than okay, it’s essential to success. As a change agent, these people are the source of input that needs to be processed, so that the voice in my head tells me when I am pushing too hard (or sometimes, though rarely, not hard enough!). Yes, they are always going to be counteractive to change, but once you understand the individuals, it is possible to discern stress levels within this negativity, and they will delight in telling you the problems. They have just given you a useful program barometer, and a set of problems to overcome.      

 The key to dealing with Laggards is to be very assertive in pushing them towards the go-live, really, give them no options other than to ride the train, but crucially, listen to their input. It is crucial to understand their fears, and I don’t mean let them speak, I mean really understand, then prioritize them in your own mind and with your program leadership team, then follow up on a point by point basis. It is very likely that your follow up will not be accepted, and that is not really the intent. The intent is that you have, and show you have, thought about their concerns.

 After the push and shove of the go-live of a big program, it will be time to listen again, and be very gentle with them for the subsequent 6-9 months (depending on the size and impact of the technology program's change on the organization). You did disturb their psychological balance for a while and they need to re-stabilize. After this period of progressive improvement and stabilization they may begrudgingly say that the new system is not too bad, but not as good as the old system. And as an IT executive, you shouldn't expect any more than this.

If you were both still there 15 years later, as the systems changed again, they will react in exactly the same way about your system as they did about the previous one.

I set myself a personal objective in each new big program, there is usually that one person who is a laggard, an expert, and is acknowledged by others as having wisdom, and they are usually very good solid people. I find them and I try and win them over. I usually manage to neutralize their negative perspectives, I very occasionally win them over, and in one or two instances people who started out as extremely negative on a program, I have now known and been friends with for over 25 years.              

Life is funny!         

Want to go faster? Cut the team in half !

See my previous post for some context, and my definition of what a big horrible technology program is, but let’s just say I’ve ridden at a few rodeos.

In my last articles, I put forward the following positions:

  1. You have to go fast
  2. Not everybody is going to be happy when you bring change

Now I want to explore how to go fast, particularly as it relates to resourcing.

Most people have heard of Parkinson’s law, "work expands so as to fill the time available for its completion”, there is also a lesser known corollary, Horstman's law: "Work contracts to fit in the time we give it."

Applying both laws, and a concept that time is a fungible commodity in IT programs; consider 2 options

Option 1: The small team

  • Limits what can be done
  • Forces a focus on critical scope
  • Minimizes complexity in the program
  • Limits scope creep for practical reasons
  • Reduces costs from “start” to “production”
  • Pushes incremental scope into phase 2
  • Because of the minimized scope, the program completes more quickly
  • Because the project is done faster, real users get to use the new systems sooner
  • Because users get the system faster, real phase 2 needs are understood sooner

Option 2: The big team

  • Allows the concept of “we want the ideal system” thereby increasing scope
  • Allows “edge case” scope creep thereby increasing complexity
  • Increases “inside the box” thinking, “we do it this way - make the new system do it that way”, “we are paying for what we want”
  • Increases the costs to get to a “production” system
  • Increases the time between start and users getting their hands on the system
  • Increases the amount of time to get to real “phase 2” needs because of the focus on edge cases

I acknowledge that it may seem less palatable or seemingly sensible to run small teams at big problems, because of the forced compromises along the way, but the downsides of a large team are seldom understood, never discussed by vendors, rarely acknowledged as they are happening, and not well understood, even in retrospect, even after an embarrassing program failure.

 So now let’s think about resourcing, in the process of setting up a team to do a major technology program, one has a number of possible options:

  1. Pull together an internal team
  2. Hire an external team as future permanent employees
  3. Hire large scale systems integrator consultants
  4. Hire vendor related consultants

Of course you can blend any or all of the above, but each has its pluses and minuses.

Pull together an internal team

An organizations’ highest performing people are needed to run the business, and they’re unlikely (in the extreme) to be released for a relatively long time for a program whose success is, at this point, questionable (remember most organizations have tried big projects before and have a high failure rate. Putting lower performing people into what amounts to a heart transplant for the organization will produce correspondingly low performing results.

 Hire an external team as future permanent employees

This gives you additional talent, with “new world” skills, but less understanding of your business, and leaves you to manage the communication and activity discontinuities. Plus are these people really going to settle into the stable new world after the system is live, how is this being planned for?

Hire large scale systems integrator consultants

This almost always runs counter to my experience of success, and is by far the most expensive. I believe that this is because the personal career drivers for the senior people are not well aligned with the customers’ success. Most Buck from the client cannot be well aligned with clients’ best bang for their Buck.                    

Hire vendor related consultants

This always seems attractive, “one butt to kick” is often quoted, but I have found that big systems development firms treat their consultancy arms as a bit of an afterthought. The effect I have seen is that they are knowledgeable, but not invested in going quickly or invested in their clients’ interests.

The outlook for all of the above options is pretty grim, and realistically some element of blending is always going to happen, so how do we make this work.

 I believe that a key part of success is to do 2 things right from the start:

  1. Align personal team members' interests with the outputs desired, i.e. getting the programs' key tasks done as quickly as possible, encourage the race to get live, and
  2. Lay out a longer term vision of how all of the resources benefit in the longer term from the program, i.e. show that there is a longer term need to resolve the compromises made along the way, where business benefit can be incrementally earned by progressive improvements in the program output.

To achieve both of these things, the team needs to be no larger than that which will eventually be required to manage and support the system, and it may well be smaller, ready to either absorb resources released from the previous system, or increase organically based on the backlog of tasks developed after the program go-live To do the program, all it needs is a small team!

 Going all the way back to Steve Jobs’ comment at the top, I have found that you can develop A-Plus players, by building small teams, and setting great goals.    

 "Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has." - Margaret Mead

Fast and Friendly Just Doesn’t Exist

See my previous post for some context, and my definition of what a big horrible technology program is, but let’s just say I’ve ridden at a few rodeos.

In my last article, I talked through the benefits of carrying out major IT/technological change as quickly as possible, and now I want to expand on some of the negative implications of IT programs at lightning speed. I know that many of these issues happen in slower programs as well, but I have found them to be exacerbated by the stress associated with increased velocity.

Let’s talk about organizations first, most environments have some form of hierarchy, where decisions (like replacing a major IT system) are made at the top and the implementation work affects lower levels of the organization.  This is overly simplistic but useful for my needs here.

Assuming that the program is large and business critical, it’s pretty likely the new systems will affect hundreds, if not thousands of employees, clients, vendors, etc . There are some things specifically about the employees that are important.

  1. They have probably been working there for an average of 4.6 years (per bureau of labor statistics). In my experience, in healthy companies, it tends to be longer, and longer still for more senior staff and in government entities.
  2. Each day in that 4.7+ years, they have gained more experience in a system that is likely been in use for over 15 years, and was designed over 20 years ago. They have grown comfortable with that system, acknowledging its idiosyncrasies, and knowing how to work around them.  
  3. Some of those users are experts in the old system, their power base and professional self-esteem are wrapped up in the knowledge of that system, maybe they even helped pick it 15 years ago, maybe they have been helping it evolve for the last 15 years.
  4. A good percentage of these employees are scared by the coming change. Psychologically these people may well be happier in a stable environment     

By now you probably get the idea, while you are there to chart a new direction, based on an executive decision, the lives you are going to affect may be wary or scared already. Don’t get me wrong, there will be advocates and evangelists for the new system, but there will be plenty of suspicion at all levels in the organization.  At the top, it is fairly common for an executive team to understand the need for a replacement system, but it’s much more rare for this team to agree on how to replace, and, critically, on timing. That, plus the horrendous failure rate of large IT projects means that you are unlikely to have many more than one positive forceful executive sponsor, and often less.

Within the hierarchy there will be some who see the potential benefit, and some who don’t, and they all have some voice in the program success.     

One last point before we go on, most organizations don’t have a good understanding of the stresses and strains associated with a large IT program, often, amazingly, despite having failed previously.

It’s clear from the above that being the driver, and probably the face of that change, presents a series of delicate challenges; needing to be forceful enough to succeed, experienced enough to know when to stop pushing, and tactful enough to be able to talk about critical issues internal to the organization. The subtleties of all of these skills are mostly learned over time (or were in my case!).

This brings us to my premise, fast AND friendly just doesn’t exist. If you are an effective change agent, you will have detractors, and if you don’t, you’re not going fast enough, and that will incrementally increase the potential of failure.

How do I overcome these challenges? Here are a few of the “tools” I use:

  1. Clearly set the expectations upfront that it’s going to hurt, there will be times when we won’t be friends, and the real benefit comes after the change, not during.   
  2. Be absolutely positive and enthusiastic about a specific big, simple to explain objective, and evangelize it, to your team and the team affected by the change.
  3. Add a date, say it loudly, and make sure everybody knows that is your objective, the more loudly you say it, the more likely it is to come true.   
  4. Develop a simple, 1 page, 20 item Gantt chart that shows how it could be done. More detail is the enemy here, and the chances of it working out like this are basically zero, but it reinforces the date!
  5. As soon as possible build a presentation giving high level concepts for the program: Gantt, Vision, top 3 objectives, top 3 risks, leadership. Again evangelize, and keep coming back to the simple messages. It’s your job to handle the complexity.
  6. Be committed, professional but firm, more flexible about how, less about when, and be friendly when you can.

At the end of the program, you will have to operationalize the systems, that includes building some bridges to program detractors, making sure their needs are met, and helping them be successful getting the business benefit from the new systems.

Slow and Sure is Fundamentally Flawed

See my previous post for some context, and my definition of what a big horrible technology program is, but let’s just say I’ve ridden at a few rodeos, namely, in multiple industries, in business critical situations, I have managed and completed IT and digital programs successfully in less time than many thought possible, and often faster than anyone has heard of in their respective industry.

This series of topics covers the reality of things you are unlikely to be able to change during the implementation phase, the implications of those things, along with a series of axioms I have applied successfully over the years. My reference point for these thoughts is a big core system change in a variety of industries including accounting, insurance policy, hotel or cruise reservations, bank account systems, primary e-commerce platforms etc.  Here we go:       

  1. Slow and sure is fundamentally flawed
  2. Fast and friendly just doesn’t exist
  3. Want to go faster?, cut the team in half
  4. The laggards will never stop being laggards
  5. Aim small, miss small
  6. Advance the ball with every play
  7. It’s going to get worse, then much worse, then stable, then better, eventually
  8. Just keep swimming
  9. It’s like riding a motorcycle, everyone else is out to kill you
  10. S**t happens
  11. Be Prepared to stand alone 
  12. Grow a thick but sensitive skin 
  13. You manage success, you measure failure
  14. There are no hard and fast rules, and all rules are made to be broken ade to be broken

The list is too long to elaborate on in a single post, so I’m going to attack the list a little at a time. This post is the start of this effort.

  1. Slow and sure is fundamentally flawed

There is an argument, particularly from large management consulting firms, that the key to success with large scale business critical programs is a carefully controlled process, where detailed planning followed by controlled execution, and constant validation with the business, will effectively deliver business benefit. I thoroughly reject this hypothesis, and see it as merely a way of consultants extracting obscene fees over long periods of time.

Those of us who have dealt with large scale IT systems realize that there is a tendency towards entropy (increased chaos over time) in computer systems, which in part, causes ongoing maintenance requirements and drives maintenance teams to struggle with increasingly complex technology performing increasingly diverse tasks. To replace an enterprise IT system and get business benefit from it, the project team needs the new system to catch up and overtake the old system’s capabilities.

Hopefully the new system has some inherent advantages which are easily recognizable when the choice is made; but there tends to be less control than is typically anticipated about functional divergence after the change process starts. New regulations, a market shift, new competitors with a different business model, as well as a lack of true understanding about how the new system works, can all affect the viability or perceived viability of the program.

Other factors affect an organization’s ability to carry out a complex system transition including costs, scarcity of expert resources, logistical issues, political resistance, availability of executive support, and on a more positive note, underlying business growth.

All of these factors are adversely affected when you choose to proceed more slowly, carefully, and in a highly structured manner. The opposite effect is that these are all contained and/or their impact reduced to some degree by going more quickly; the faster you move, the smaller the impact on the business.

The IT industry has a dreadful history of failed projects, where the only perceived way of improving is to increase control, slow down, get more sign-offs, be more careful. Actually, I have found that big technology programs are like riding a bicycle, stability comes with speed.

Let me set out some of the positive aspects of going faster, acknowledging that the concept of “Change” is hard and disruptive regardless of the velocity of the program.

  1. The faster it’s done, the sooner the organization can focus on the new system, and the sooner the grumbling about change stops.
  2. The faster it’s done, the sooner you can exploit the advantages the organization wanted in the first place.
  3. The faster it’s done, the cheaper it will be (I have had to help many clients get control of their long term consultancy “partners”!)
  4. The faster you commit to the new system, the faster the organization can learn to live with the new system's idiosyncrasies (they all have them).
  5. The faster it's done, the sooner you get to the next program on the never ending list most organizations carry.
  6. The faster it's done, the less likely is the program to get stuck in a quagmire of politics.
  7. The faster it's done, the easier it is for the business to focus on understanding and adopting the minimum set of mandatory requirements, therefore reducing scope.
  8. The faster it's done, the less likely is the program to lose subject matter experts through natural attrition.

I postulate that going as quickly as absolutely possible exponentially increases the probability of success. The key is to attack a program like your life depended on it, because the program's life does.

Managing Big Horrible Technology Programs – And Succeeding - Part 1 - Critical PM Skills

For the last 33 years, I have been managing big horrible technology programs. I started very early, at the ripe old age of 22, when I was handed (by happenstance, not planning) a critical situation for the Ministry of Defence in the UK. With lots of luck and a huge amount of work, I survived, built a team from the ground up, and stabilized a complex system and its infrastructure.

I know this is an unusually young age to be given a $5m technology project, but my journey from there does mean I have seen a lot. I have been lucky enough to have managed teams and programs in the UK, USA, France, Finland, Sweden, Spain, India, Australia and a host of other countries and cultures.

At one point I got involved with the BBC to produce an Educational program about Project Management, and with the Open University in the UK co-writing a Post Grad course on the subject.

To properly define “big” and “horrible” one could use these criterion:

  1. Budgets of over $5m, up to $50m (I have been involved programs of up to $650m).
  2. Business Critical, the operation does not survive without the system, and is threatened by the existing environment, often something big is already broken, and you are in charge of the replacement.
  3. Politically complex, with multiple complex businesses, vendors, organizations, institutions, government departments and or elected bodies.
  4. Interesting “characters”, ranging from demonic and checked out executives, technical gurus, and idiosyncratic creative geniuses.
  5. A set of time / cost / quality constraints that make grown men and women cry, with maybe a government regulator thrown in.
  6. The initiative has already failed, often multiple times, and this time it can’t fail
  7. And lastly….It’s on the brink of failure when you arrive.

The question is: what skills do you need to manage a “Big Horrible Technology Program” that has some or all of these characteristics, and if you have one of these programs, what should you be looking for in the person who is going to run it for you? 

I would say the top critical skills are:

  1. An ability to pick, empower, trust, and lead a group of smart people (in my experience most people go to work and want to be successful, all they need is freedom and a little direction)
  2. An ability to develop and communicate a clear vision for a project (we are going to climb that mountain over there!)
  3. Understanding and being able to manipulate the flow and tempo of a project, (in my experience you can gently push a tempo, but not force it).
  4. Natural counter cyclical responses (when the team is very stressed, the PM is calm, when the team is calm, the PM is stressed (usually looking for the next threat)) 
  5. Creativity, an ability to solve any problem by getting the team to think differently (if we can’t do that, what can we do, how do we get to a valid response to any problem)
  6. An ability to communicate with everybody, and not be afraid of giving and receiving tough messages 
  7. An ability and willingness to be a toilet plunger, (it’s your job to get “stuff” out of the way, so everybody else can focus on forward motion)
  8. A streak of stubbornness that, by force of will alone, will not allow failure, (there is always a way)
  9. I suppose you need to be able to draw a quick project plan as well!