Wednesday, October 21, 2009

Managing Risk in IT organizations [John Levy]

Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy.

1. IT Operations and Development must be managed differently. Development is Engineering and must be managed as such. Outsourcing of Development does not convert it into Operations – it is still Engineering.

2. Measurements for IT Operations and Engineering (Development) are different: Development should be measured based on expected ROI plus certain strategic factors; Operations should be measured based on predictability of spending and certain Quality of Service measures, along with regular and consistent assessment of relevance of those measures to the business. [This is analogous to market risk in financial portfolios]

3. Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy. In addition, the probability of future failures remains undiminished so long as the management shortcomings are not addressed.

4. The cost of failure in IT Development always exceeds the allocated budget for the activity, because failure has consequences beyond the immediate failed project, both for people and for other projects. For example, one major factor of risk that increases when a development project fails is the loss of key people. It is rare to find IT management mitigating this risk immediately on learning of a development failure.

5. Failures and losses in IT Operations usually involve either directly managed operations centers or outsourced providers’ operations. Outsourced operations are inherently riskier because the providers’ operations are less visible, and therefore less known, to Operations managers. [Cf. Failure in Microsoft-provided services for Sidekick smart phones, Oct., 2009] [This is analogous to credit or counterparty risk in financial transactions]

6. IT management should be able to communicate to top management the nature of the tradeoffs in IT Operations and Development, so that strategic implications of decisions in IT are well understood at the top level. This means that financial factors must not be the exclusive determinants of IT decisions. The CIO should not report through the CFO.

7. Multi-year planning is essential for both IT Operations and Development. A roadmap for rationalization and integration of resources and services is necessary, even if it must be revised multiple times per year as new equipment and services are needed. Contingency planning and scenario analysis related to possible shortcomings of vendors and outsourced services must be part of the plans.

Above thoughts on IT management are based on my recent experiences at a client company and were triggered by a paper, “Risk Management Failures” by Prof. Rene Stultz, Fisher College of Business, Ohio State University, published by Cornerstone Research

John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on high-tech management, Get Out of the Way, is due out in 2009. More info is at


Tuesday, October 20, 2009

Problem Solving, Shared Leadership and the Enneagram [Matt Schlegel]

In recent blogs I have described the steps of a problem-solving methodology that I have found works extraordinarily well in helping teams solve complex problems. What I have also found is that different team members contribute in different ways, and their contributions are better aligned with some steps of the problem-solving process than others. Imagine if there were a way to understand how each team member best contributes to the problem solving. Imagine if you had a way to ensure that there were strong contributors at each step of the way through the problem-solving process. Also, imagine if you understood when there was too much or too little representation of a particular strength so that you could avoid some classic problem-solving mistakes (for instance, paralysis by analysis.) The next sequence of blogs will describe the connection between people’s strengths and weaknesses and the process itself.

The basic premise of this discussion is that we can find a method that does provide a link between each step in the problem-solving process and people’s strengths and weaknesses. I discovered such a link while studying the Enneagram. For those of you not familiar with the Enneagram, I recommend checking out this link. I find that this book is a great introduction to the Enneagram.

During an Enneagram workshop I attended, the question was raised as to why there are numbers to describe the different personality types. The instructor indicated that the numbers are arranged in the order that people solve problems. Voila! The Enneagram not only describes 9 basic personality types, but it also describes the order in which each type contributes to a way humans solve problems. Fascinating! It was based on this bit of inspiration that I started to develop the problem-solving process I have described in previous blogs. In using this process with teams, I did find that there is a strong correlation between a person’s Enneagram type and their ability to contribute to the problem-solving process. I used this correlation to promote leadership of those with particular strengths as the team needed those strengths during a particular phase. Asking people to do what they are naturally gifted to do yields remarkable results. I believe this is one of the most powerful aspects of this problem-solving process.

Matt Schlegel has studied the Enneagram since 2001. His introduction to the Enneagram came through his family. Over time, he found that it was a useful tool in helping resolve conflicts in the workplace and getting teams to work together more effectively. He also discovered its powerful use as a problem-solving tool. Matt continues to study the Enneagram, discovering something new and interesting with every encounter.


Saturday, October 17, 2009

Introducing Myself [Robert Lasater]

Hello everyone. My name is Robert Lasater. I am the engineer responsible for maintaining this blog.If you have issues, questions or comments, you can contact me at rlasater "at" hotmail . com

My goal for this blog is to provide a forum for people at all levels of engineering leadship. For example, as a software engineer I am an individual contributor, but I have led projects from initial requirements to full scale deployments, working with domain experts, quality assurance, and customer representatives. So I want this blog to be relevant and helpful to people like myself.

Obviously the blog should also be of help and interest to team leads - people who have one or more people reporting to them, most likely supervised by a manager or director - through managers, directors to vice presidents of engineering.

Anyway, I have been working this blog for a few weeks and look forward to working with the EL SIG team to make it a Must See site for engineering leaders in Silicon Valley and across the nation and the world.

Robert Lasater is a software developer with several years of experience leading projects to develop firmware for embedded systems.


Monday, October 12, 2009

Problem Solving Tool - Step 8: Smoothing the Feathers [Matt Schlegel]

The problem-solving team has performed an apparent miracle. A transformative change has taken place in the organization. Results have been measured and confirmed – the goals that the team set out to achieve have been reached, and the problem has been solved. Is it time to celebrate? Well, hold on just a minute.

Whenever there is a transformative change within an organization, there will be perceived “winners” and “losers.” There will be those whose position in the company is apparently improved and those whose position is apparently diminished. Humans are great detectors of these types of changes – we cannot help ourselves, it is just what we do. The 8th and final step of this process (at least numerically speaking) is to reach out to all those people that are affected by the change, find out what is working well and what is not working well in the post-transformation organization.

The team is no longer selling the change. The most important skill at this point in the process is LISTENING. It is particularly important to listen to those who have undergone disruptive change in the way that they perform their function. Not only has this change been emotionally unsettling, there also may be new, unforeseen issues that are impeding workflow. It is important to capture these issues and concerns, address them as well as possible, and ensure that all workflows are moving effectively.

Continuous Improvement

Inevitably, there will be some issues raised during this final listening step of great enough magnitude as to require more than a quick and simple fix. Capture those issues. The interesting thing about this process is that it is not linear, but circular. After the change, new problems arise and can be addressed with the same process, back to step #1. In this manner, an organization can be continually evaluating its effectiveness and taking the steps necessary to improve itself in a never ending cycle, a cycle of continuous improvement.

Time to Celebrate

Okay, the team has taken the time to listen to those who have concerns. You have implemented quick fixes to address the simple concerns, and have recorded those concerns of greater magnitude for careful consideration later. Importantly, you have included all those affected and taken the time to smooth any ruffled feathers. Now, it is time to celebrate! The problem is solved, the metaphoric dragon slain. Take the time to enjoy your success as a team. You deserve it.

In the next series of blogs I will return to the idea of sharing leadership during the problem-solving process.

As an engineering manager, Matt Schlegel had the opportunity to organize/sponsor some memorable celebrations. His favorites to date are canoeing on the Russian River, kayaking in Elkhorn Slough, and cooking at Culinary Center of Monterey. What have been your most memorable team celebrations?


Friday, October 2, 2009

You Say “Later”, They Hear “Never” [Tanya Berezin]

I don’t have a crystal ball but this I can see without one. If you manage software development projects, this will happen on your next one:

  • Customers (or Marketing or Product Management) will want more than your team can deliver.
  • It will be your job to tell them that.
  • They won’t be happy.

You’ll need to deal with the immediate issue of salvaging your release and the longer term need to reestablish your credibility with the customers.

The immediate problem usually is somewhat straightforward. If you cannot get more resources - time, people, money, tools, etc. - and you cannot compromise quality, you’ll have to work with your customers to cut some planned features. Once you agree on what gets cut, they’ll want to know when the cut features will make it into the product. And, sometimes silently and sometimes out loud, they’ll wonder if these features will ever make it in.

You can’t blame them for being suspicious: they’ve had to postpone features on other projects before and in many cases these features never got implemented at all. But you need to tackle this concern quickly and persuasively, or negotiating scope again in the future will be much, much harder.

I will assume the features you postponed are worth implementing. (See my previous post on how to artfully say “no” to unnecessary work.) How will you assure your customers that you are only delaying the work, not burying it permanently?

1. Show the backlog.

Use your project backlog, product roadmap, or another list that shows planned features in priority order. (You don’t have one? Put one together as soon as you can.) Your customers worked with you on it, so pull it out and remind them what you were thinking of when you prioritized the list. If the business context has changed, now is a very good time to review and change this list. If not, your customers will be reminded that you were planning all along to add features over time and that hasn’t changed.

2. Discuss risks.

Acknowledge that reality can intervene with your best intentions. Your project could lose the backing of your sponsor; a new competitor could show up and you’d have to change what you are doing; or any of hundreds of other things quite outside of your control could happen. (For a list of typical project risks go to and navigate to the Resources & Tools section.) Show your customer your top risks list (you have one, right?) and your contingency and prevention plans for each. This will reassure them that you are doing all you can to protect the planned features from being permanently on hold.

3. Deliver.

Of course, the best thing you can do to maintain your credibility is to deliver what you promise. So when you do cut scope for one release, don’t overpromise for the next one. Keep track of what you estimated your team could do and what they actually did and improve your estimates over time.

This way, next time you say “later” to a feature, your customers won’t hear “never!”

Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at