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.