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: , , , , , , , , , ,

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: , , , , , , , , , , ,

Trust, truth and talking things through

April 10, 2012

Collaboration thrives on trust, truth and a willingness to talk things through.  When these elements are present for people in a team or in a department, those people take responsibility, use their authority wisely, and develop a climate of openness.

Here are key principles and other aspects of each of these elements.

Trust

I trust you if you speak and act with respect and maintain that respect when you communicate with others about me

Team members gain trust by doing what they say they will do.  But even more important in gaining trust is being respectful when speaking to a person or to someone else about a person.

In addition, a manager should always defend the team’s boundaries.  This includes alerting the team when there is a potential conflict with another team or manager and backing up the team when it needed.

Truth

If you believe you’re never wrong, you should not be on a team or in management.

Truthfulness is, of course, saying what’s true and not saying what’s false.  But much more important is being willing to own your own mistakes and misunderstandings.  By being open to correcting yourself, you make space for me to do the same.  You also make willingness to adapt and learn part of our shared culture.

A lot of the work of business is finding out what’s true – about a market, about a product, or about the world.  As long as we’re open to learning, which means there are things we don’t know, we encourage real inquiry that leads to knowledge and good decisions.

Talking things through

 “Talking things through” is being willing to address conflict.

Since conflict is inevitable, we need healthy ways to deal with it.  The best way is to acknowledge its existence right away, but not by making the other person wrong.  We can state what we see as disagreement without disrespect or rancor.  Start from assuming that the other person has a valid reason for their view.  Then start listening rather than arguing.

While compromise is one way to resolve conflict, there is a better way.  Begin by understanding the values and intentions of the other person.  Then search for ways to resolve the conflict while advancing both your own and the other person’s values.

What about incentives?  People who are collaborating successfully need very little additional incentives, because the process of collaboration – and the successes it generates – are rewarding enough.  Create an environment where there is trust, truth and talking things through, and you need only get out of the way.

Filed Under: Agile Management 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: , , , , , , , ,

Success always looks easy

March 13, 2012

With all the news about IT projects that go bad, you would think that we’d hear more news about projects that go well.  Then we could just copy down the “best practices” that led to the success and – voilà – our projects would come out perfectly every time.

But life is not so simple.  While we can enumerate key problems that led to failure by analyzing projects, it is much harder to point to one factor and say “this is what made this project successful.”  Success depends not only on avoiding the pitfalls, but also on bringing together all of the essential project elements.  Sometimes those elements are not so easy to identify.

Example 1:  I once struggled for 7 months with a project team that couldn’t seem to get all the right pieces together.  In fact, what was needed was to remove two members of the team.  One of them was in a key contributor position, but was just not disciplined enough to produce his part of the code (this was a firmware team).  The other was simply not contributing to the team because he didn’t understand his role and was not capable of fulfilling it.  While I had recommended the removal of these two on my 3rd day on the project, I had not insisted, and the result was a long slog.

What happens when you remove non-contributors from the team?  First of all, someone else on the team steps up to do what needs to be done.  Second of all, the whole team becomes more productive (and happy) because they are no longer saddled with the unproductive members.

Example 2: A client company launched a transition to Agile development methods in the development of a major sales-support package.  They hired an experienced team of software people and an Agile coach.  The program went well.  I was asked to assess the team and the project during its first year.  My assessment:  this team will do well no matter what methodology they use – because they are experienced people who know how to work in a team.

There was also an invisible success factor, invisible to the remote business people who chartered my assessment.  Within the ranks of IT management was an individual Director-level manager who secretly supported the Agile transition.  I say “secretly,” because the CIO turned out to be opposed to any special treatment of software developers (compared with, say, treatment of call-center operators), let alone “Agile” teams.  This manager quietly encouraged the Agile team and provided me with insight into all of the IT department politics that could affect the team’s performance.

If you manage to identify and engage the key success factors in real projects, you’ll be regarded as a genius.  But don’t let it go to your head, because a lot of it is luck.  Luck that is aided by keeping your eyes and your mind open.

If you’re managing a major project, it’s best to call upon resources (not just people, but information or equipment or software) that help compensate for any shortfall. So it’s a good idea to continually build up your network of contacts, your access to information, and your knowledge of available equipment and software.  Then, when you run into a roadblock, you can call on your network to help find what you need.  And of course, it doesn’t hurt to have a secret ally in the management ranks.

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

Stranger ways to fail

February 29, 2012

In the last article, I gave three reasons for IT project failure.  These are not the only ways to fail!  In this article I describe failure modes I’ve seen that are much less conventional – and harder to overcome without serious dedication at the top.

Here are the three reasons from last time:

  1. They’re not defined well
  2. The people doing the work are not a team
  3. They don’t have enough resources or the right resources

And here are the new ones:

4.    Management is fighting over who controls the project

There’s nothing nastier in corporate politics than a turf battle.  All the best-intentioned platitudes about teamwork and customer-centricity are forgotten when there is a fight for power.  If these are happening in an organization near you, then you’re probably hunkered down, waiting for the chips to fall.  The project work is also probably way behind schedule and no one is willing to take any risks while the battles are fought.

These projects usually falter when the funding becomes uncertain because of the battles.  That of course leads to failure reason #3 above.

5.    The project has been chartered in order to show off a capability, rather than to accomplish a real, customer-oriented goal

A U.S.-based company I was working in asked me to manage a development project that was being done on the other side of the Atlantic.  Why?  I found out later it was simply because the former VP of Software was now in Europe and he wanted to show off the capability of the European software development team.  Although we managed to deliver the product and the team performed well, the product was not well received.  It was really unnecessary.

6.    Middle management is truly incompetent

A client company started development on a system that was way outside the company’s traditional area of expertise.  When the managers realized they needed an essential software component and asked for it, the development team showed them the component that they had already developed, because it made no sense to proceed without it.

This company’s first and second level managers were in over their heads with regard to the technology.  What made it worse is that the two levels of managers protected each other from showing their weakness to anyone above the second level.  Both the system and the company folded within a few years.

7.    The CEO and the executive staff don’t support the project because they don’t understand its significance.

A company I worked for was the first disruptor of markets for the big players in computer systems.  It offered systems that were an order of magnitude less costly than the competitors, and this not only opened up markets and applications that were new, it began to eat into the margins and the market share of the big players.

Twenty years later, other new companies began offering systems that were an order of magnitude less costly than this company’s systems.  The company couldn’t respond adequately because the top management did not understand how these “cheap” systems could do what the more costly ones did.  They also failed to grasp the significance of software as a business, separate from the “iron” of computer hardware.  The company ended by being acquired by one of the upstart disruptors.

If you can find your way to a safe place to proceed with your project, keep on trying to establish good practices and excellent communication.  And if you’re depending on successful completion of the project?  Then get clear about what’s going wrong, and get help.

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