This article consists of a small set of stories. Each story is an analogy to explain my concept of how Vision is applied to IT Governance. I hope you enjoy this article. Please feel free to pass it along. It will also be posted on my web site at http://robertperrine.biz.

I began by assessing the work left to complete. All prior work, the good and the bad, was a sunk cost. I then talked with the resources and learned of the feuds and fiefdoms that dominated this landscape. There was no project folder. No history. No estimates. No timeline. But we did have plenty of deadlines. Based upon those conversations I sketched out a list of milestones. If all went well we could finish this project in the second quarter of the following year.

Based upon my conversations I sensed that this project lacked a vision. Everyone was committed but no one could agree on what they were committed to. I looked at my calendar and picked a date. That was our target date. I mattered less whether or not that date was the best date or a date assessed by doing the forward and backward pass with weighed averages. I needed a date that implied a vision.

I then went to the local novelty shop and bought six small pinatas. The next morning I went to each of the principle stakeholders offices, asked for a few minutes to speak and set one piņata on their desk. "Cinco de Mayo. We will finish the migration on Cinco de Mayo". All wanted to know how I knew that date. Ah, the clever wisdom of project management, various tools and techniques, it is all in the PMBOK. And I conveyed a sense of conviction that it would be Cinco de Mayo. Most of those managers kept their pinatas on their desk for the next nine months. Passing in the hallway they would greet me with "Cinco de Mayo". We had a vision.

Now, achieving that vision was a completely different matter. The feuds continued. Various managers attempted to decimate each other's camps. Key resources left in frustration. But throughout management there was one common vision - this project is going to finish on Cinco de Mayo. And in spite of how much each team dreaded the thought of cooperating, each knew that their manager had bought into this vision. And no team wanted to be the team responsible for missing that date.

 
Sixty-Day Countdown The customer liked the demo and loved the functionality of our software. The deal was set but there was one condition - move the code off Windows and over to Linux and finish the work in ninety days. The engineering manager balked, reassessed, typed up his resume and walked out the door. The project manager looked around, saw the fingers pointing at him and vanished. So someone yanked me out of a customer location and brought me in for a meeting. "Fix it. We need the revenue."

First prerequisite - I asked for a project centric team. There were already battles a plenty between the teams so there had to be a single overall manager. "Agreed". Next, I needed a technical lead, a Subject Matter Expert, the one person that understands this domain better than anyone else. And they found him.

I explained the problem to Mr. SME and asked him to give me his best estimate on how to accomplish the work in the remaining seventy days. It took him a few days and he came back with a plan. Send everyone offsite for two weeks of training and we can finish the conversion within one year. Wrong plan.

With sixty-five days left I opened the "opportunity" to the team. I was surprised by who walked in my door later that afternoon. He explained that he does not know the current application, does not know the language we have proposed for the conversion and will need a lot of help. But, he believes it is doable. All he asked for was a couple days to learn this language, examine the current code and get back to me.

With sixty days left we held a team meeting in the US office and I followed up with conference calls to India and Ireland office. Raju is our new project lead. He will establish the architecture. All other work is cancelled. Every resource in the engineering department is to focus exclusively on this project. Raju picked up enough syntax to code in this language in two days, everyone who thinks they code better than Raju had better keep up. Everyone that wants to learn from Raju now has an opportunity.

I setup a daily status check-in with every programmer. Everyone had assignments either in coding or testing or just cleaning up the old code so it could be converted. I began my day with a 7am call to Ireland and ended my day with a 9pm call to India. We finished close enough to that deadline to keep the customer content.

How did we do it? By having a clearly defined vision, by having sponsorship, by having visionaries that believed it could be done. And guess what, the one year estimate was probably a pretty good estimate. But by setting clearly defined objectives and properly managing the resources we did it in sixty.

 
Ownership Version two of ITIL has ten disciplines. My boss wanted all ten, simultaneously. I would rather have done two or maybe four. He wanted ten.

I put it out to the team to solicit volunteers. And occasionally I twisted a few arms. Soon we had seven disciplines with champions. My next goal was to transfer ownership. I did that by asking each of those champions to write the pages in our project plan that described what they thought was achievable and how they planned to do it. My next biggest challenge was to get them to decrease scope. I really prefer the challenge of encouraging people to hold back rather than trying to push them.

It took a while, but we soon had a well documented plan that described what we would do with each discipline during the next twelve months. And my only role was to mentor those champions.

 
Environmental Concerns The world is full of chaos. My view of my role as a manager is to prevent chaos from touching my group. My goal is to create an environment of peace with challenges. Peace so the team feels secure and is willing to take chances. Challenges to keep the team growing and not let them stagnate. If you can create such an environment your team will grow in ways you never thought possible. Let each person grow and you will be surprised at what they can achieve. Give each the freedom to challenge themselves and your role will change from enforcer to mentor. Get all of those brains working at the same time and you will soon realize just how feeble your own efforts are compared to that of a team.

 
If you have any feedback on this, I can be reached at robert@RobertPerrine.biz.

Thank you for taking the time to read this article. I hope you found it entertaining.