Want your I.T./ Digital project to succeed? Identify your Project Crusader.

I specialize in fixing I.T./Digital projects and programs that have gone wrong. Over the last 30 years I have raked over the ashes of project after project that has failed, and many others on the brink of failure. They are characterized by massive expenditures in time and money, embarrassment all around, and everybody involved scuttling to avoid the blame.

When I interview project managers it’s pretty difficult to get them to admit they have nasty projects in their managerial background. Hmmmm, that's weird, because some data suggests that 70% of projects fail.

There is a lot of opinion, some based on data, about why projects fail, here are 3 examples of that:

1.      https://www.proprofs.com/c/project/common-reasons-for-project-failure/

2.      https://project-management.com/top-10-main-causes-of-project-failure/

3.      https://www.youtube.com/watch?v=CTHHiBNXJ6w

Project failures run across methodologies, environments, internal teams versus external vendors, custom software versus packages, on-prem versus cloud. It seems like there is no escape. A crap-shoot where you might get lucky, but equally, you might not.

At this point, I’ll be blunt!

NONE of these lists of reasons for failure EVER mention what I believe to be the single biggest flaw in I.T./Digital projects. Pretty much every project I have been involved in needed a

Project Crusader

Someone in the project, who has some authority who is prepared to do whatever it takes to make the project succeed.

• Project Crusaders don’t force a process, they force common sense

• Project Crusaders don’t just measure progress they manage progress

• Project Crusaders lead when the going gets tough, acting as a beacon of hope

• Project Crusaders look for opportunities in problems, and look to reduce problems in opportunities

• Project Crusaders go over, round or through the wall

• Project Crusaders make sure the whole team survives, thrives and gets to the top of the mountain.

None of these attributes are role specific, they can be a product manager, a project manager, a project executive, or a skilled team member. None of these attributes appear in the myriad of methodologies.      

I am often asked what I do, and my response is that I manage big scary I.T. projects, the bigger and scarier the better.

In practice, managing a project, regardless of size, is a very small part of what I do. Most of the mental effort I apply to a project is as a Project Crusader.

I will make the project succeed, sometimes, in the darkest moments, by sheer force of will alone.

I don’t say the above to toot my own horn, I say it so that you can look at your I.T./Digital Project or Program, and you can either see the Project Crusader or there is a very high probability that you will fail.

If you need help, visit www.h7i.com    

Early indicators of a Problem I.T./Digital Project

Many books have been written about IT project disasters, and many studies show the appallingly high rate of failure of projects even today, but how do you spot a project that is going to be a disaster before it turns into one.

With over 30 years’ experience of rescuing and resolving I.T./Digital disasters of one type or another, I think there are several key indicators which taken together, strongly point to an project problem , the prelude to an I.T. disaster. The intent here is to help business sponsors spot these indicators, and therefore have the potential to manage the issues before they escalate into a full-blown disaster.

Most readers will be aware of the three governing dynamics of projects, Time, Cost, and Scope, I have indicators for these, and for a fourth, Commitment. Taken together they can be used as a reference point, perhaps to call a timeout, and fix issues before they become crises.

The 25% Combo, Time & Cost. 

Let’s look at the combination of time and cost. When combined they can be looked at as projected overrun, let’s take an example: You are starting a complex IT project with 20% contingency, where the 20% can be consumed in time, (late delivery), or budget ($ overspend), or a mix of the two.

Later, this combined 20% is projected to be consumed, with a 15% cost overrun, but also a 6% time delay. You then have a problem that needs dealing with, as it is likely to grow. in our problem project quiz we have set the overrun bar at 25% to give a little margin of error.

My rationale is that if the project spends its 20% contingency but comes in on time, that’s a success, likewise if it goes 20% beyond its dates but remains within budget, it’s a success, and finally, if it is 10% over on both, that’s a win. If the expected overrun is significantly beyond this, you have a problem.

The scale of the problem is defined by the distance to the finish line when the contingency is expected to be consumed.

If the project is verifiably close to finishing but strays outside the projected overrun limit, then the situation is a little painful, but a sprint finish will probably get you over the line. If the project is only 50% complete and is now projected to cross the projected overrun limit line, you have a major problem.

Scope – complexity and expected quality

The scope consists of 2 principle elements, complexity (or breadth) and quality. Complexity should be defined as early as possible in a project as a multi-section prioritized list with various levels, ranging from the minimum viable product (MVP = Business Critical = “must have” etc), through to the perceived ultimate requirement (with lower priority items listed where known). The success of the project depends on delivering to the MVP as quickly as possible. Do not be in a situation where all scope is a high priority, this in its own right will likely cause the project to fail.

The key measure pointing to a potential for crisis in a project is, is the MVP stable or growing? If functions or complexity are being added, are they also being removed to keep the total MVP bucket size the same? If the scope bucket size grows by over 10%, you have a potential for a crisis. 

Moving on to Quality, software should work, but more importantly, when it doesn’t, what is the difference between the fault raise rate and the fix rate, is it trending towards being negative (more defects fixed than found) then the project is making progress. In large projects, this trend may take a little time to show itself at the start of testing, but it will not take long. Secondly, what is the defect re-raise rate, how many defects reappear or were never fixed despite being “cleared”. In my experience, if this rate is over 3-5% you have a quality problem and a potential for crisis.

Finally, commitment for all parties

Are the sponsor, customer, supplier, project manager, and the team committed to the success of the project? Taking each in turn:

Sponsor / Customer: Do you really need this project to be successful? Are you holding regular, real reviews of the project, and are you clearing escalated issues in a timely manner? Have you allocated your resources to the project (despite the fact that they all have “real” full-time jobs?)

Supplier: Is your team motivated to the client’s success, appropriately skilled, and sized to be successful, are you reviewing this on an ongoing basis?

Project Manager: Are you committed to delivering this project, regardless of the problems that may arise, are you prepared to manage the project, not just measure it? Are you ready to take advantage of opportunities to go faster, (because some things will slow you down, and it’s your job to figure out how to compensate)

Team: Have the client and supplier teams bonded, and are they successfully working together, achieving the common goal of completing the project.

The absence of any of these facets of commitment is likely to push the project into crisis, which will ultimately surface in vendor friction and time, budget and scope issues.

In Conclusion, IT projects are hard, and it’s easy to get them badly wrong. The key to avoiding a disaster is to understand when they are starting to go off the rails. That is the time to face the potential problem before it turns into a disaster, these simple measures can be used by non-technical executives to get a real idea of where their projects are.  

Advance the Ball with EVERY Play: Managing Big Horrible Technology Programs – And Succeeding

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

• Some people don’t like change, and actually, that’s okay

• Focusing on a very specific endpoint – aim small, miss small  

I now want to move on to the nitty-gritty of day by day project success.

By now, I hope you have realized that there is a very messy underbelly in all large projects, if you haven’t got that yet, please go back to step 1 and read forward back to here.

In this article I want to start looking at what it takes to make progress on a project, and how to take advantage of opportunities to accelerate (there will be plenty of times a project tries to slow down, trust me on this one!)

In the process of planning and building a team, you will have developed some form of high level Gantt chart with major activities in it. The next critical activity is to understand, in detail, (I know, I hate those words), what the tasks are and what the critical path is through those activities.

Project Managers are often taught that there is a single critical path, which is theoretically true, but practically useless. In practice, in a complicated project or program the critical path may well be a bit of a spiders web of complexity, i.e. there are many paths that could become the critical path with the help of a tiny delay on the task and this can be the case many times over for many different paths. In fact one could easily argue that the more time intense the project, the more complex the “almost critical path” will be.

However aggressive the plan you have built, it should represent some form of reasonable reality, which may be stated as “with a fair wind and an assertive attitude we can do this”. Oh, to live in that world! As an experienced project manager you know that “fair winds” merely sits on a continuum that runs from calms to hurricanes, and every day on the project may bring different weather.

The point of Project Management is to be able to read the weather on any given day, and use the weather to maximize the chance of success, understanding that on larger programs the weather may well be different in different parts of the program. After the title of this piece being a soccer analogy, I will now switch to a sailing metaphor. What does becalmed look like:

·        You are struggling for sign off on requirements or deliverables 

·        There is political dysfunction making the destination unclear

·        Critical resources have gone AWOL

·        Supporting users have lost enthusiasm, objecting users are gaining strength

·        An external dependency failed to materialize

Each of these, and many more, can have a material effect on the potential success, but…

1.     If you are managing this project you probably had some warning signs

2.     You should have already thought through some contingencies

3.     You will have already made sure every member of your team has multiple layers of back up tasks, in case they get becalmed on task one, or two, or three.    

4.     You need to be prepared to get in people’s faces and make it work, this means using all of your psychological tools to get movement in your direction

Lastly…

5.     It is your job to find a way to make progress, regardless of the size and scale of the becalming.

What does that look like? It doesn’t mean just sit and hope, it means figuring out how:

·        The team can achieve the objective another way

·        The team can advance other tasks

·        The team can rest, knowing specifically that this calm means that a storm will come

·        You can get project executive intervention

·        You can walk the executive halls and be the intervention

·        You and the team can look for opportunities to make progress

These are critical times, if the team can manage to make a day’s work today, it doesn’t matter that it is made up of tasks the team was meant to do on another day, that just means that as the project manager you have to have flexibility and be able to rearrange the plan to still be successful.

Then the storm arrives…

Circumstances develop on the project that mean your only constraint is the availability of resources to do tasks. There is typically a hurricane just before a critical go live where all of the delayed deliverables magically turn up. Or where the consequences of previous becalmings cause a concertina effect on a major deliverable date. Hopefully you are in a position by this stage to take advantage of 5 things:

1.     The team understands that they are a team that stands or falls together, and that problem solving has been institutionalized as a team activity not a managers’ responsibility. Make no mistake, a project managers ability to bind together a team to respond to adverse circumstances is the crucial skill in delivering successful complex projects and programs.  

2.     The team already understands that flexibility and resourcefulness are key to being successful, because these have been used frequently in periods of becalming.

3.     The becalming periods themselves have been effectively utilized so that the hurricane is minimized even before it arrives.

4.     Remember that detailed understanding of the critical path and tasks I talked about, this gives you an ability to prioritize and focus.   

5.     These periods tend to be intense but relatively short, and it is a managers’ responsibility to encourage the team to do whatever it takes. If the team has bought in to the goal, and you as manager are a servant leader, the team will be able to push through and be successful.

I have been involved and seen teams do seemingly impossible things as a result of these abilities to handle hurricanes and storms.

Conclusion

A Project or Program Manager’s responsibility is to make sure that the ball moves forward with every play, inherent in that is the need for teambuilding around a common higher purpose objective, flexibility to respond to adversity and opportunities, and a stubbornness, to just make it work. The larger the project the more sophisticated the managers actions will become to achieve these goals.

Next: It’s going to get worse, then much worse, then stable, then better, eventually

Happy Projects, Comments always welcome! Kevin

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- Why Change Management is crucial

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!

Thoughts?