Published: February 19 2010, 04:34 PM | 1 Comment(s)
by Steve Romero

I received a tweet today from two of my coworkers @crystallyn and @JoannMoretti with a link calling for participants in the upcoming "10th Annual Grace Hopper Celebration of Women in Computing" http://bit.ly/bGRai9.

I have a huge soft-spot in my heart for Grace Hopper. I started my IT career as a Data Processing Technician in the U.S. Navy. After serving 3 years in Military Operations on the Amphibious Command Ship Blue Ridge, I spent 4 years working at the Naval Regional Data Automation Center at Naval Air Station North Island in Coronado. In my last year of service I was honored to be one of non-commissioned officers invited to meet and listen to this amazing person. http://admiralgracehopper.com/.

For those of you unfamiliar with Grace Hopper, she is one of the most important people in the history of computers. Notice I said "people." As the "Mother of COBOL" and one of the only women in the group of computer pioneers at Harvard in the mid 1940s, I could easily label her as the most important "woman" in the history of computers. And though the conference celebrating women in computing is aptly named after Grace Hopper, I view her as one of the most influential "people" in my life.

Before I met Grace Hopper, I was quite happy being one of the less than 3000 (at the time) computer professionals in the Navy. Computers were still very sexy and mysterious and most people were impressed when I told them about my work (making it more acceptable for me to be in the Navy - during a very unpopular time to be in the U.S. Military). Though I was quite satisfied with my Navy career choice, the chance to work on computers was not the main reason I joined the Navy. I enlisted because it was the only possible way I could put myself through college.

I soon learned about Grace Hopper, given at the time she was the oldest Commissioned Officer in the Navy (granted by Presidential exception). She was not only one our most famous officers, she worked in my profession. So I was in awe of her when I sat in one of the front rows of the small theatre on base (she made the Commissioned Officers stand in the rear) and listened to tales of her storied career and offerings of advice and inspiration.

She was so frank, honest, forthright and humble. She didn't speak down to us, even though she was a giant in the industry. She seemed larger than life, though I don't think she was much more than 5 feet tall. After meeting and listening to her, I knew I would work in the computer field for the rest of my life. (If you had asked me what I was going to do for a living on the morning before I met Grace Hopper, I would have said I wanted to join a company with an Executive Mentoring/Training program.)

There are 3 memories that stuck with me after all these years:

First, she told the story about how she worked with the team of Engineers to first find (and coin the term) a "bug" in the system http://bit.ly/AkKuz .

The second thing I will never forget is her passing out nanoseconds to a few of us in the audience. Nanoseconds? Actually, she handed out 6 inch strands of insulated wire. This was after she described how she told an engineer she was struggling with understanding the concept of a nanosecond. After some deliberation, the engineer did some calculations, picked up a spool of wire, and cut a 6-inch-length. He then told Grace, "This is how far light travels in a nanosecond."  This was my very first example of translating technology speak into business terms (of which I had no appreciation at the time).

Finally, what left the greatest impression by far was this quote, "It is easier to ask for forgiveness, than it is to ask for permission." The enlisted ranks roared and applauded when we heard this, and as if acting as one, we all turned to look at the wide-eyed non-clapping high-ranking Officers standing in the rear of the theatre.

When I saw the tweet this morning, it brought back a flood of wonderful memories and reminded me what it means to be inspired by someone and to inspire others. And now I am finally to the point of my post. Who is inspiring young people to join the ranks of computer and IT professionals today?

I am a regular speaker at San Francisco State University's Masters Program - where they dedicate one night each Information Systems semester to my presentation and discussion of IT Governance. At each of these classes I ask the approximately 30 students if any of them plan to pursue a career in IT. I rarely see a hand raised. This reality has been supported by a number of studies I have seen showing that graduate and post graduate degrees in the IT field have been steadily declining.

I am sure the "10th Annual Grace Hopper Celebration of Women in Computing" will cover the topic of attracting young women to our ranks. Mattel is doing their part, having just released Tech Barbie http://bit.ly/dgdYHN.

Who else is inspiring young people to pursue a career in IT? Who (if anyone) inspired you or somebody you know to work in the computer field? How will we continue to attract talent to our industry?

UPDATE: Great news! According to a February 22, 2010 12:04 AM ET Network World online article http://bit.ly/acDwPv, "Leading universities report that enrollment in computer science and engineering courses is up significantly this year among students pursuing computer science majors as well as those studying other subjects, particularly science or business." The article also said, "At Stanford University, the number of students declaring themselves as computer science majors is up 40% from last year."

I was so excited to see this. I am sure it has much to do with the "recession-proof" aspect of many IT roles. Let's hope the trend continues, even after the economy turns around.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: February 16 2010, 09:55 AM | 5 Comment(s)
by Steve Romero

I was recently asked by an online Magazine for a half dozen common Project Management mistakes. I was happy to oblige despite my reservations when it comes to talking about Project Management mistakes. My reluctance is based on my belief that most project failures result from poor Project and Portfolio Management (PPM) processes - or the lack of them. I actually believe project failures would occur more frequently if not for the heroics of so many capable Project Management professionals.

Even so, there are some things I believe a Project Manager can do to drastically improve a project's chance for success.

Project Sponsorship

Lacking the appropriate engaged Project Sponsor can doom an IT Project. In addition to providing the horsepower to overcome the issues and risks that inevitably threaten every project, Project Sponsors provide a direct link to Corporate Leadership and Strategy. A recent online CIO Magazine Article studies showed the link between project success and business strategy http://bit.ly/2xi1zs. The study found "the tighter a project's connection to the business strategy, the smoother it will progress. Conversely, the more tenuous the link between the project and strategy, the more challenges the project will encounter." In addition to ensuring projects are linked to Corporate strategy, Executive Project Sponsors provide the oversight to make sure the project stays on track to fulfill that strategy - by simultaneously monitoring the project's performance and corporate strategic direction (which may change during the course of the project).

Poor Project Definition

Ill-defined projects are doomed from the start. It is imperative for all projects to have concrete business and technical objectives and an accurate understanding and description of what is required to realize them. Nothing ensures projects are correctly defined more than a reliable project business case process followed by a dependable project charter process. A reliable project business case process provides the data needed to determine not only if a project should be done, but if it can be done. Once approved a dependable project charter process accurately describes the Who, What, Where and When of the project. The ValIT Framework from the IT Governance Institute provides some great suggestions for elements frequently overlooked or answered in IT Project Business Cases:

• The business benefits targeted, their alignment with business strategy - who in the business will be responsible for securing them
• The business changes needed to create additional value
• The investments needed to make the business changes
• The investments required to change or add new IT services and infrastructure
• The ongoing IT and business costs of operating in the changed way
• The risks inherent in the above, including any constraints or dependencies
• Who will be accountable for the successful creation of optimal value
• How the investment and value creation will be monitored throughout the economic life cycle, and the metrics to be used

Inattention to Business Process Change

Every major study over the past decade has shown that at least 50% of IT Projects fail (missing schedule, exceeding budgets, not delivering required performance). In many cases, inattention to Business Process Change is at the root of these project failures. The focus for many IT Projects is on the technology being deployed, with little or no attention paid to the required business process changes. The Project Manager delivers the system but the new technology is not understood or even used. Very few technologies drive change in and of themselves. Rather, new technology must be accompanied by the business process changes required to exploit the new technology. These business process changes necessitate an understanding and execution of the process management and organizational change management disciplines so essential to affecting human behavior. The Project Definition Phase must determine if these business process changes are in or outside of the scope of the IT Project.

Not Knowing Which Success Factor is Most Important: Schedule, Cost, Performance

As noted above, IT Projects fail for different reasons. The project could be late, over-budget and underperforming. There is a classic project management saying: Cost, Schedule or Performance - pick any two. Project Managers must know which of these Project Success Factors is most critical in regard to project success. The Project Sponsor should work with Project Executive Steering Team to reach a consensus as to which is the highest priority and manage the project accordingly.

Poor Communication

Poor communication is an obvious detriment to IT Projects. Every Project Manager should develop and maintain a formal, well-thought, comprehensive Project Communication Plan. A project Manager must know who needs what information and when and how that information will be provided. This requires a Project Manager to not only understand the decisions required to govern projects to their successful conclusion, they must also map those decisions to the data required to ensure they are reasoned and rational. The other dimension to overcoming poor communication is the essential need for Project Managers to provide accurate data as fast as possible. In doing so, Project Managers must overcome any urge to hide bad news or downplay issues and risks.

Inappropriate Process and Methodology

Some IT projects fail due to the lack of appropriate project management process and methodology. This doesn't only occur when no methodology is applied. Failures can also occur when too much process is inflicted on the project team. Project Managers must have an expert understanding of proven project management processes and methodology. This understanding is essential to apply the correct "flavor" of project management methodology and to strike the delicate and tenuous balance between too much or too little process.

What do you think of the list? What other mistakes plague IT Projects?

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: February 08 2010, 02:46 PM | 2 Comment(s)
by Steve Romero

How are the processes in your organization? Do people follow them? Do they work well?

Many if not most of the companies I visit struggle when it comes to process. Process continues to be a four-letter-word. Processes are viewed as bureaucratic, cumbersome, overly-complex and slow. In most cases, these views are indeed warranted.

I recently spent the evening with two senior IT leaders from a major technology company. They work in what I call a "loose" IT environment. They have little or no governance and very little formal process. Their teams are comprised of people who have worked together for many years and "just get the work done."

This model has served them in the past, quite successfully. But the company has recently experienced incredible success and growth and the work is coming at a much faster rate while staffing levels remain the same. Yes, the work is still getting done, but these two Senior IT Leaders see disaster looming on the horizon. The pain and negative residue has greatly increased from the chaos and aftermath of informal and ad hoc work processes. They anticipate a day of reckoning if they don't take action.

The actions they are investigating are governance and process, and they do so at their own peril. Their company views these disciplines in a very negative light. These two Leaders recognize they have a tough row to hoe ahead and we spent the evening discussing their challenge and sharing ideas.

My time with them inspired me to post a list of very high-level recommendations for introducing governance and process to an organization that is dead-set against these conventions.

1. Ensure you have an acute understanding of customer needs and your business objectives
2. Uncover and reveal the problems associated with meeting those needs and objectives
3. Recognize and learn to empathize with those who feel the most pain from these problems
4. Identify an Executive Sponsor and/or enlist a legion of rank-and-file supporters
5. Quantify the cost of the problems
6. Ascertain the potential solutions to the problems
7. Quantify the cost of the solutions
8. Recognize and listen to the people that are against your solutions or just anti-process
9. Do not take a prescriptive approach to any proposed solution
10. Know there is no one-size-that-fits-all
11. Select the correct "flavor" of the solution - dictated by the specific problems to be solved and influenced by the current culture, capacity, and capability of the organization
12. Thoughtfully implement the solution - in multiple iterative phases that produce measurable improvements quickly
13. Take what you learn from previous process implementation phases and apply that knowledge to improving subsequent phases
14. Constantly strike the balance between too much and too little process and between too complex and too simple
15. Take a sympathetic position with everyone who hates your process and gain an understanding of what incents them to avoid, undermine or destroy your process
16. Measure results and respond accordingly

Yes, this is a very high-level and minimal list, but I think it's a good start. I could expand on any of these points to an enormous degree but I want to keep this post simple. I would love to hear what you think of the list and if you have anything to add. I, like the two IT Leaders taking on the process challenge, can always use the help.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share

Published: February 02 2010, 02:48 PM | no comments
by Steve Romero

How are your business partner relationships? Are they working for you? Are you doing all you can so they do work for you? In other words, are you governing your business partner relationships?

First, the term "business partner" can mean many things. I am referring to external or extended business relationships. These are the folks with whom you partner to enhance revenues through licensing and/or distribution agreements, supplement internal resources or provide capability outside of your core competencies.

I list "Outsourcing Services" as an essential Governance process. This process:

• Facilitates the decision that services are better provided externally
• Oversees Vendor and contract management
• Enables fact-based price comparisons
• Sets clear expectations for provider performance
• Ensures architectural fit

These processes are necessary to ensure an enterprise gets its monies-worth from these partnerships. In addition to managing this economic risk, the services listed above help you to ensure your partners do not damage your good name and reputation. Governance of your business partners is just as critical as governing your own organization (if not more so).

I suggest there enterprises need to do more to realize maximum value from your business partne relationships. I want to supplement good governance with practices and behaviors that establish empathy and trust between both parties. I was exposed to this idea while working at one of my former companies and again during my recent visit to Prague.

In a previous position, I worked for a CIO who believed in establishing what he called "Social Contracts" with our business partners. These contracts had no legal standing whatsoever and were never intended to replace those that did. Instead, the agreements were meant to establish a mutual understanding and appreciation of each party's vision and mission with the hope of fostering a relationship of trust and shared interest.

I was reminded of this approach when I visited Prague last week. Eastern Europe has a wealth of emerging markets. Numerous businesses have established a presence in many of these countries. Given the infancy of many of these markets, many companies rely on partnering with other businesses to establish their presence. This creates a plethora of global market challenges and increases the need to thoughtfully address the care-and-feeding of these relationships.

I spent the morning delivering my PPM presentation to some customers and prospects. I then delivered the same presentation to a group of Partners in the afternoon which was followed by an evening of dining and continued knowledge-sharing. The goal of my visit was to increase their understanding of governance and PPM while introducing them to my role and opening the door for continued interaction and assistance. I spent an amazing evening with Partners from Prague, Budapest, Zagreb, Warsaw, Istanbul, Bratislava and Bucharest. We had a wonderful time and learned a lot from each other. It was a great experience and I am certain our very personal time together has set the stage to do great things jointly in the future.

After a fantastic dinner and some local beverages, one of my fellow employees from Budapest told this joke that I believe captures the spirit of this post:

It was a bitter winter, even by Siberia standards. A pack of wolves was near death due to starvation, with only a few able to muster the strength to hunt. As they wandered the frozen wasteland, they came upon a single emaciated rabbit.  Before they could attack, the rabbit screamed, "Wait! I can help you!" The wolves paused and the rabbit explained, "I am but one scrawny, starving rabbit. Eating me won't save even one of you, let alone your whole pack. But if you spare me, I can tell you where a heard of deer are hiding. You can eat enough to survive this brutal winter."

With no discussion, the wolves agreed and the rabbit quickly described the location of the herd. As soon as he finished the wolves pounced on the helpless bunny and devoured him. After all, they were wolves.

The wolves then followed the rabbit's directions and indeed came upon the hidden herd. They attacked and were able to kill and eat their fill. After they finished gorging themselves, one wolf paused to reflect on their broken promise. "You know," the wolf said, "That rabbit saved our lives. We should go back and pay our respects and give him a proper burial." The rest of the pack agreed, found the few bones left scattered in the snow, and buried them in the frozen tundra.

As they stood over the burial site, one of the wolves suggested that one of them should say some last words. After a period a befuddled silence, one of the wolves offered, "He was a good friend." The others wolves disagreed because they hardly knew the rabbit. Another wolf suggested, "He was a good enemy." The pack did not like this either because after all, the rabbit did save their lives. Finally, one wolf shouted, "I know! He was a good partner."

I will close with the hope that in your business partnerships, you are neither the rabbit nor the wolf.

Steve Romero, IT Governance Evangelist

Share this post:  Email

Share