Perspective is a pretty big player as well.
On a project early in my career, the system deployment involved a group of technicians racing around the country installing hardware in switching and transmission sites in cities as well as some pretty remote areas. One of the technicians made a wrong turn off the main highway on his way to the Picton ferry terminal to come back up to the North Island of New Zealand. Standing by the beautiful shoreline and trying to work out where he was on the map (no GPS back then), a friendly local offered him some assistance.
"Where are you trying to get to?" the local asked.
"The ferry terminal" my colleague replied.
"Ah, you can't get there from here." responded the local.
Sometimes, our projects are like that. You know what needs to be done, but you are not sure how to get there - and when you seek directions or guidance, you seem to hit a wall. People are not usually obstructing you on purpose - they might just not have a wide enough perspective to help you with the big picture.
The Cat Who Walked Through Walls
As a youth, I was a voracious reader. One novel I read was "The Cat Who Walked Through Walls" by Robert A Heinlein (1985). I don't remember much of the rest of the book, but the title and subplot, which was about a minor character as it turned out, stuck with me quite vividly.
The plotline about the cat was simply this: Periodically throughout the story, it walked through walls (not through the doorway, but right through the solid walls). When one character remarked at this amazing ability they asked "How does the cat do that?" The memorable response? The second character shrugged indifferently and said "Because he does not know that he can't." I am paraphrasing slightly, but that was the gist of it.
Ignorance, as it turns out, is not only bliss - sometimes it is incredibly empowering.
I am not saying that you should be a fool, approaching a project with no knowledge about it whatsoever, that would be suicidal - I am saying that you need to be mindful of your preconceptions and be able to put them aside, in order to tackle the really tough stuff - especially in new areas, or in areas that other people found "just too difficult" and gave up.
There have been several times in my career that I have in some sense been that cat - doing what others "know" cannot be done, because I was not trapped with excess empirical knowledge of a new knowledge area, or sometimes I was just stubborn enough to figure out a way to get things done "in spite of it all". (Actually when I come to think about it - much of what I have accomplished as a Project Manager has been "in spite of it all".)
There are other names for this - "thinking outside the box", "Green Hat thinking" (Edward de Bono), but the principle is the same - coming into something fresh with no baggage, or stepping back from "what you know" to take a fresh look can yield some amazing results.
"Everything is possible ...the impossible just takes a little longer" - Dan Brown, Digital Fortress
A Fresh Start
At the start of my second career, I was hired to manage an onsite software deployment for a customer. I was new to the Student Information Systems area, coming from a Telecom background. I received the initial 2 week product training and then was shipped off to meet the customer. What I brought with me was my technical background and experience managing projects. Other than the blur of product training, I knew very little about this new area - other than I had myself, for my K-12 years, been a student in school like most other people. No great starting advantage there!
I called back to the head office to confirm the scope of my tasks, having gone over the migration checklist and the few generic planning documents. They seemed to be a bit vague on the "how" part, so I asked them to clarify exactly what it was I was supposed to do in making sure this implementation was successful. "Just make it work" was the response (I'm not kidding, that is what they said).
Talk about huge scope statements!
So, that is what I did. I reviewed everything I could get my hands on, talked to the services team and technical support on the "hows" of the migration process. The migration involved connecting individual schools into the new central system, and part of making that work required making sure that the schools were all configured similarly - at least at the level of all of the lookup lists. This involved a series of meetings, printing out information from a few sample schools, comparing them and coming up with a set of common "standard" values for each list. Once all of the schools had made the changes, they would send up the school databases to be "scrubbed in" (test integrated) to see if things looked good from a data quality perspective before going live. Inevitably, there were a few more cycles as discrepancies were found and reported back to the district for fixing.
Oh, did I mention I had no regular staff on my project team? Well, except for a couple trainers that came in for new product training for a week or two and a couple other short staff visits, it was a solo act. The customer was my de facto project team, with myself receiving limited remote support from HQ. (Limited not because they were not helpful, they were very accommodating - I just did not know enough to ask the right questions a lot of the time).
So, what did I do? They had 68 schools (a daunting number, as each school had to be physically visited multiple times as part of this 11 month project). I was also not terribly satisfied with the "limited sample" approach - with every school having been operating independently the prior 10 years, the sample approach was not, in my mind, nearly good enough. In order to "make it work" and work well, in my view, we had to compare all of them. Even more daunting.
So, being new and fresh (and naive), I asked if there were any tools, any at all - that would allow me to extract data from the proprietary DB structure. They gave me an extract tool, and after I promised to keep the actual tool safe and out of customer hands, I developed a set of custom tools and a process to compare and validate all of the school lookup lists at once, thus enabling consistent district-wide standardization and the most successful "scrub in" test integration that had ever been performed on the first pass.
To keep the story short - those tools and process, plus the 3 1/2 customer staff I had to work with, enabled us to accomplish more in a shorter time than anyone thought possible - which then gave us more time to work on a few other things to make the overall project more successful and improve end-user buy-in.
But the key thing here is not about having some fancy set of tools, it is looking at the bigger picture and figuring out a way to get things done - when you don't know "what can't be done", or in spite of it.
At the end of the project, someone on the project confided in me that at the outset, they thought that we would actually fail - that we would not complete the integration as there was no way to get the required amount of work done in time, with the few people we had at our disposal. And in the end, we had accomplished all of that - and much more, within the limited project budget for my time there.
And all because we were not smart enough to know what could not be done - the team and I just did what needed to be done. I am so glad they had not shared that negative opinion early on - it would have most likely cast a shadow on the project and they may have been proven right, as a self-fulfilling prophecy.
Summary
If you have
nay-sayers on your projects, don't pay them much attention or let them get
under your skin - especially if you know you need to get things done
"despite" what others say. Odds are, you will figure out a way to do it -
either if you are persistent enough, or just plain not "smart" enough
to know it can't be done. And look around for some more optimistic and creative people to help you get things done.
But back to my colleague, standing lost by the shoreline:
He did manage to backtrack to the main road and continue on down to the ferry
terminal - just in time to board the last ferry of the day. But the tale he told helped
remind me that people do not all have the same perspective - and often
they are not even looking in the same direction!
Perspective affects everything we say and do. I am pretty sure the local probably meant something like "You can't get there from here, if you keep going that direction", but of course, that is not what was said. So communication is pretty important too - in both the things that are said, and remain un-said.
One final note on perspective:
Question: "What is the difference between an Optimist and a Pessimist?"
Answer: "The Optimist thinks this is the best of all possible worlds. The Pessimist is afraid the Optimist is right".
Perspective makes a difference.
Cheers, and good luck with your projects!
Great post Gazza. Real hands on project management stuff.Reminds me of the book "Sacred Cows make the best Hamburgers" which also had the same premise as Heinleins book. I worked for a guy once who came into healthcare from the mining industry. He was bold and like the cat, wlaked through all the walls and slaughtered a number of sacred cows along the way. Working with him allowed me to see the self made barriers that restrict our view.
ReplyDeleteThumbs up
ReplyDelete