What generates energy for your team?

June 25, 2012

How do you evaluate how well a team is functioning? A key indicator is energy.  Energy is a quality of the interactions going on in the room the team is working in, a quality that you feel when you’re in the room with them.

There are a variety of types of energy.  A team may have intensity caused by anger or by competitiveness; or it may have high enthusiasm expressed by outbursts of joking and fun.  There may be quiet most of the time, interspersed with interactions that express appreciation or admiration (wow! Factor).   Or there can be a sullen tone in a team that resents its mission or its management.  Sometimes, a team pulls itself together and generates camaraderie because it is facing a common enemy – its management.

The energy of a team is a good predictor of its effectiveness.  The best teams have at least occasional bursts of intensity, and they maintain respectful, if joking, relations with each other.

As leader of teams, part of your mission is to sense the energy of the team and to intervene when things are not going well.  Unhealthy interactions are an early predictor of decay in a team.  You should be ready to make necessary adjustments when you see things unraveling.

Energy-related things you can do as leader

Here are some things you can do to keep team energy positive.

Most teams we work with have people from diverse backgrounds.  Rather than cover over the differences in culture and style among the team members, call upon those differences in an appreciative way.  For example, if one of the team members comes from a culture, such as the Philippines or Thailand, in which harmony is the supreme value, ask that person review the team’s interaction ground rules.  While many Americans relish confrontation and argument, others may prefer that the ground rules keep them from having to argue in a contentious way.

You should encourage everyone on the team to ask questions of members who typically have different views to get feedback about a proposed technique, method or solution.  In this way you help the team to revel in diversity and appreciate their differences, rather than viewing differences as being in the way.

A few years ago, I was facilitating a team of business and IT specialists who were working to overcome their history of finger-pointing and frustration with each other.  We had a dozen people in the room, and they quickly took to the task of listing what was working, what was not working, and prioritizing the actions to fix their dysfunction.  As the process entered the second full day, I noticed that one person had not yet said anything during the group work.  I began to wonder why the leaders had included this person.

Normally I would go out of my way to be sure that everyone’s voice is heard, no matter how briefly.  However, in this case I let the process continue without intervening.  Several hours into problem-solving, the team was looking for ideas to deal with how to communicate certain technical details between their offices, 750 miles apart.  Suddenly, the previously quiet person spoke up with a proposal.  The suggestion was brilliant, and the team quickly adopted it.  The lesson for me was to trust the team and the process – the leaders knew this person had something to contribute, and they knew he would speak up when he had something to say.

Make space for the team

You have a responsibility to guide the energy of the team.  You can do this in a positive way by doing these things:

  1. Create a common space – common ground – where the team can interact informally, even if they do not inhabit a common room when they’re working.  This is where they can trade stories, post items of interest on the walls, and find out what’s going on with the team.  Put key information there, but leave a lot of room for their own preferred items.
  2. Set the tone for the team by being a good listener, appreciating the work of each individual, and providing honest feedback about what you observe.  Don’t indulge in disrespectful humor or gossip.  And keep your own energy up, so that you don’t need to draw energy from the team.
  3. Get out of the way.  Most of the team interactions don’t need your guidance.  Check in with what’s happening at various moments through the day or week, but don’t try to guide everything.  If you give your team permission to try out and adopt processes that aren’t necessarily pre-defined, they’ll generate their own enthusiasm and will often surprise you with their creativity.

 

Filed Under: Agile Management Tagged With: , , , , , , , , , ,

Why is software maintenance so expensive?

June 12, 2012

When we purchase a piece of software – even as a service – we tend to think that the major expense is finished with the purchase price.  But it’s not true.  Whether you buy, build your own, or rent software, it always costs more in ongoing expenses than the initial price.  Why?

Developing software is an expensive proposition.  Not only do the people cost a lot, but they use expensive tools, and they always seem to need more time than was estimated at the front end of the project.  So we should not be surprised that software sells for a lot of money, even when the vendor is selling a lot of copies.

But why does maintaining that software cost so much?  Here are some of the reasons:

Software by its nature is constantly evolving.  Not only do users ask for new and modified features, but the systems on which the software runs keep changing, so the software has to be modified to fit new environments.  These factors guarantee that updates have to be released several times a year to keep things current.

Just because you bought the software doesn’t mean you – or the rest of your staff – know how to use it well.  So you need people to study up on the software’s functions and then teach others how to make the best use of it.  If you don’t, you won’t realize the full benefit that the software offers.

The worst thing that can happen to a software user is to learn that the vendor has gone out of business.  So you want the vendor to do what it takes to keep making those updates and upgrades available.  This means that the vendor also has to keep a stable of specialists assigned to the software product, even if it is no longer the mainstay of the vendor’s business.  And those specialists have to aware of how customers are using the product, and what kind of support they need.  So you’re willing to pay for that support, if the product is of great value to you.

When things go wrong, you need someone to call.  If you’re a big enterprise and the software is integral to your operations, you’ll want that someone to be nearby – and on your own payroll.  Otherwise, the person will not feel the urgency that you do when there’s a failure.  So you, too, have to maintain a staff of specialists who keep up to date with the software’s features and failings, and know how to work around any problem that comes up.

Furthermore, when something fails, you typically don’t know whether it was caused by a software bug in the application, a system failure or something gone haywire in the infrastructure (such as the network).  So you need IT specialists who can diagnose failures and then pursue the solutions no matter where the failure originated.

Can you avoid all of these expenses by using software in the cloud?  Not so fast.  You may save money by renting software that runs in the cloud, but you have to be ready to accept a standardized version of the software that everyone else is running, too.  Or you’ll have to pay extra for customization, which leads you right back into the ongoing costs of maintenance.

You’ll also have to endure the changes that come when the cloud-based software vendor decides to upgrade the system – on the vendor’s timetable, not yours.  So maybe you need those specialists in IT after all?  And the cost savings of the cloud are not completely one-sided.

Filed Under: Painless IT Tagged With: , , , , , , , ,

Why is it so hard to get good software?

May 29, 2012

Once we get over our wonder at the broad capabilities of software running on modern computers and devices, we begin to ask why so much of the software we use is of questionable quality.  Between vulnerabilities to malware and constant updates to correct problems, it seems that software is never stable and reliable.  Why?

Software is abstract, invisible and runs at very high speed.  This combination of features makes developing software the domain of a special kind of person who can deal with the abstractions and with the incredibly fine detail of software creation.  Managing a group of such people also requires a special kind of talent as well, because there are tradeoffs to be made between getting new features added and stabilizing the functions that are already built-in.

Usually, the pressures of commercial software development lead software marketers to place much more emphasis on new features than on stability, because features are what differentiate one software product from another.  However, the long-term stability of a product also contributes a lot to the product’s reputation.

Software testing is the usual way to verify proper functioning before shipment.  But since software development routinely takes longer than anticipated, it is the testing that gets short shrift in many cases.  The result is premature delivery of software that is not yet ready for commercial use.

A 2002 study commissioned by the National Institute of Standards and Technology found software bugs cost the U.S. economy about $59.5 billion annually. The same study found that more than a third of that cost — about $22.2 billion — could be eliminated by improving testing.     http://on.msnbc.com/Kae58w

In addition, the operating context of software is constantly changing.  As operating system upgrades are released, the software that works under that operating system often must be adapted to the upgrades.  This means that a lot of the work of keeping a software package current goes to merely maintain the capabilities that were already built.

Users continue to ask for new features.  And marketers want the software to be useful in more contexts – such as making an app useful on an Android phone in addition to an iPhone.  These demands guarantee that a software package will always have an endless backlog of potential changes in the “to-do” list.

As more contexts are supported and more features are added, the software inevitably becomes more complex.  And complexity multiplies the difficulty of testing, and also makes each change to the software riskier.  The more interactions that are possible with each part of the code, the more possibilities there are for mistakes.

What can I do to help make software better?

Purchasers of software don’t have very high expectations, because the track record of the software industry does not set a very high bar.  If users demanded better software and rejected poor software, software vendors would provide better packages – or go out of business.  Why don’t we demand better software?

One reason is that it is hard to switch.  Once we have adopted a piece of software for some function, we tend to stay with it.  First of all, it’s what we are familiar with.  This “makes us rather bear those ills we have than fly to others that we know not of.” [Shakespeare – Hamlet]  The cost of learning a new system is high, and we tend to stay with what is familiar, even if it is painful to use.

Second, the vendors of software don’t often make it easy for us to switch to another vendor.  Try taking an Access database and “porting” it to FileMaker Pro.  The conversion process is a barrier that most of us are unwilling to undertake.  In addition, there may be many people who need to be trained in the new system if we switch.  That adds to the cost.

In the future, we should look at the cost of switching before committing to a software vendor or cloud system.  The more “open” the system, the better for us in the long term.

And we should always insist on demonstrably high quality in software.  Keep this in mind the next time you’re making a purchase decision.

 

Filed Under: Painless IT Tagged With: , , , , , , , , , , , ,

Why don’t IT people understand our business?

May 16, 2012

Executives seem to agree that IT people – technicians and their leaders – do not understand the business very well.  This causes all sorts of trouble when making financial decisions on major IT projects.  Why don’t IT people “get” the business?

1.    They’re too busy studying technology.

We all know that information technology is complex.  It’s not surprising to learn that IT people have to put in a lot of time just keeping up with the changing technologies.

But CFOs and Controllers also have to spend a lot of time keeping up with regulatory and financial standards.  That doesn’t excuse them from acquiring a good working knowledge of the industry and the specifics of the enterprise’s products and markets.  So we shouldn’t let the IT folks off the hook just because they’re “too busy.”

2.    They’re not trained in business

IT people typically come from engineering and technology training backgrounds.  These give them good grounding in quantitative methods, but don’t give them a feel for business tradeoffs.  Case studies in business are not part of a technologist’s training.  And those who have ventured into business for themselves usually have to hire someone else to manage the business aspects of their enterprise.

Maybe there’s something you can do about this.

3.    No one on the business side has invited IT to learn about the business

OK, so the IT people aren’t business-savvy when they come to work here.  Why don’t we invite them to learn about the business?  After all, we expect HR and other departments to have a basic grasp of what we do and for whom.  Why not IT?

Do you have a short self-study course on the nature of the enterprise’s business?  Or at least a summary from the 10K that is provided to every new employee?  This would be a start.  Even better would be a concerted effort to explain not only the basics of the business to IT people, but to outline the key performance indicators and other metrics that drive the business.

4.    No one rewards IT people for being business-savvy

Reward systems in IT typically are based on operational metrics rather than business-specific measures.  If you reward IT people only for achieving 99.9% uptime, then you should not expect them to focus on anything else.

Everyone in the enterprise needs to have a basic grasp of why we’re in business and what we provide, and to whom.  But IT people implement many of the systems that make business processes run, so they should have in-depth understanding of what’s important in the business and the meaning of the executives’ measures.

Bringing IT people out from behind the wall of technology and exposing them to business concepts and measures can only benefit everyone in the company.  And it will make your future conversations with IT a lot easier.

How well do IT people understand business in your enterprise?  Add your comments below.

Filed Under: Painless IT Tagged With: , , , , ,

Risk Management in IT

April 25, 2012

Risk management is a key area for financial leaders.  When we look at IT development projects, we’re usually focused on opportunities rather than risks.  But IT investments have risks beyond security and privacy issues.  Project failure can lead to losses even beyond the intended investment.  Here are seven ways to look at IT development projects from a risk management point of view.

1. IT Operations and IT Development must be managed differently. Development is Engineering and must be managed as such. In particular, this means that there must be a certain amount of experimentation to find the best implementation. Outsourcing of Development does not convert it into Operations – it is still Engineering.

2. Success criteria for IT Operations and IT Development are also different. Development should be measured based on expected ROI plus the strategic value of the project.  For externally visible development, time-to-market and accuracy in delivery against market requirements are also relevant measures.  Operations should be measured on predictability of spending and on Quality of Service.  Operations measures should undergo regular and consistent assessment of their relevance to the business.

3. Most failures in IT Development are caused or compounded by management errors. Very few failures are due to technical inadequacy. The probability of future failures remains undiminished so long as the management errors are not addressed. Examples of these errors include not planning for scalability or not emphasizing modularity of the implementation.

4. The cost of failure in IT Development nearly always exceeds the allocated budget for the activity. Project failure has consequences beyond the immediate failed project, both for people and for other projects.  For example, one late project often cascades through to lateness of follow-on projects.  Another risk factor is the loss of key people when a development project fails.  It is rare to find IT management mitigating this people risk immediately on learning of a development failure.

5. Failures and losses in IT Operations involve directly managed operations centers or outsourced providers’ operations. Outsourced operations are inherently riskier because the providers’ operations are less visible, and therefore less familiar, to Operations managers.

6. IT management should be able to communicate to top management the tradeoffs in IT Operations and Development, so that they understand the strategic implications of decisions in IT.  Operational budget must not be the exclusive determinant of IT decisions. In general, the CIO should not report through the CFO.

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

If these ideas resonate with your experience – or if you disagree, please add your comments below.

These thoughts were triggered by a recent paper, “Risk Management Failures” (http://tinyurl.com/7ew4t79) by Prof. René Stultz of Ohio State University, published by Cornerstone Research in 2009 (http://cornerstone.com).  With thanks to Andre Neumann-Loreck for his feedback and comments.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , , , , ,

It’s actually easier to do the right thing

March 26, 2012

The right thing is to plan, organize and execute with long-term results in mind.  But nearly every manager is so driven by short-term metrics that they fail to account for longer-term effects of their decisions and actions.  As a result, they accomplish less for themselves and for their organizations, making them less effective and less competitive.

Here are three ways to incorporate longer-term thinking:

1. People working for you know when they’re being put at a disadvantage due to short-term thinking.  For example, if you won’t spend the capital needed to buy the right tools, they’ll keep working, but they’ll resent both the inefficiency of the work and the lack of regard it shows for them as workers.

People will find ways to correct problems and to self-organize to be more efficient if you will only give the room to operate.  This includes trusting them to find the best way to organize and giving them enough budget to execute the plan.    Your main contribution after that is to give them enough of the bigger picture so they know how their work fits in with your objectives.

2. If you’re committed to personal growth, then you need to track your effectiveness over a longer term.  Your monthly or quarterly objectives are the table stakes in this game.  Cranking out regular results will guard your job, but it won’t make you ready for a larger role unless you include a vision of what’s possible in the longer term

If you want to be seen as an emerging leader, then you have to champion longer-term growth and improvement.  To do that, you’ll need to solicit feedback and actually listen to it.  And you’ll need ways to identify short-term objectives that are actually causing damage to longer-term results.

For example, a client company refused for years to convert to better programming language tools because changing tools would make the first project to use them take longer.  As a result, they went for years at a disadvantage compared to their competitors.   Eventually, they changed – when they merged with a competitor that was already using the tools.

3. In some areas, such as product development, experimentation is essential.  You may think that Engineering is a deductive, forward-only process; but in fact a lot of development involves eliminating the unworkable by trying it out.

Once you realize that experimentation is part of the process, you stop regarding abandoned directions as a waste of time and resources.  In fact, experiments lead to better decisions and stronger platforms on which good products are based. Since the result of having stronger platforms is not visible until the next product, you could harm your product line significantly by insisting on maximum-speed implementation.

The alternative to backtracking after an experiment is to fall off a cliff – with failure of the process.  It’s better to insist on high-quality, incremental progress.  And how do you know you are seeing incremental progress?  You have to have a longer-term vision and plan to measure it against.

Once you have the vision and the plan, it’s actually easier to do the right thing.

 

How are you keeping longer-term results in mind?  Post your comments below.

Filed Under: Agile Management, Painless IT Tagged With: , , , , , , , ,