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.

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.

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.

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.

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 3^rd 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.

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.

Why do these projects fail to complete? Here are three major causes of IT project failure.

1. They’re not defined well

If the sponsors don’t define the project well, the people implementing it will apply their own ideas to define the outcomes.  This usually leads the project astray, because no matter how technically competent the implementers are, they are not mind-readers and they rarely have a clear idea of the business purpose of the project.

The best way to define an IT project is to start with the end – defining the measurable impact on business parameters that the project is intended to have.  From these, derive criteria for completion including demonstrations of the key capabilities and measurable test results.  If this seems hard to do, then you need to review why the project is being done.

2. The people doing the work are not a team

People implementing the project need to behave as a team.  If they don’t, the project is likely to fail.

You need good teamwork to get a project done.  What’s good teamwork?  It’s good communication with blaming; it’s clear acceptance of accountability for doing what each member said he or she would do;  it’s working cooperatively to solve the inevitable problems that come up.

If your implementation team is split across town or across continents, there needs to be active management of the communications so that the teamwork criteria are met.  Agile development, which relies a lot on self-directed teams, requires outstanding teamwork before any benefit from the Agile principles will pay off.

For example, a client company I worked with had parts of its web implementation team split between two facilities 750 miles apart.  When not enough results were coming through, the manager decided that Agile methods would solve the problem.  But the two parts of the “team” did not trust each other and each blamed the other part for the lack of results.  Only after bringing the top dozen people together in one room for two days per month did they begin to work out their common goals and start to solve the problems.

Leadership is also required in a self-directed team.  Leadership in this context means actively managing the team process and the management.

3. They don’t have enough resources or the right resources

The effort needed to complete an IT project is often underestimated.  A combination of implementer optimism and wishful thinking on the part of the sponsor conspires to make the budget for many projects inadequate.  This causes an unpleasant surprise when the project is nowhere near complete when the budget is spent.

You also need the right resources.  People who have the skill and competence to plan, design, code, test and deploy the program are necessary.  If any part of this sequence is weak, then a lot of time and effort can be lost during the project.

The implementers need the right tools, including software tools and a work environment in which they can use them properly.

Under-estimation of the scope of a project may lead it to grow too big for a single team to accomplish within the time required.  That can lead to further complications, because multiple-team projects require segmentation of the effort into coherent modules, and then the integration of the whole project has to be done by an integration team.  So when you discover the realistic effort needed to accomplish the project, you may also have to rework the whole management structures used to implement it.

If you want to insulate your company from IT project failures, you need to pay attention to project definition, team formation and adequate resources.  Then you have a chance to beat the odds and reap a successful conclusion to your IT project.

Software people are different, so their managers need to be able to deal with the difference.  Effective software managers know what’s critical to a well-functioning software team and those managers get good at providing it, even in the face of obstacles.

Obstacles come from upper management that doesn’t understand how software, and software people, is unique.  As a result, they assume that a manager who has skills in Operations can just as well manage software.

I’ve seen IT shops where the best software people left the company quickly after being treated as if they were call-center operators.  For example, the management assumed that the software people could be located anywhere in the building, that they didn’t need any special whiteboards to keep track of their project information.

Why should you care? After all, can’t you just hire the brains you need for software?  Well, not so fast.  You’re competing with every company in the world for the same kind of brains. Unless you’re in an entrepreneurial, fast growing, innovative company, software people will not prefer working for you over going to work in a more exciting environment.

IT is undergoing rapid change, primarily driven by the availability of cloud services.  But the cloud just moves the data centers to somewhere else. If you look closely at internal IT activities, you will realize that IT is itself a software-intensive activity.

This sounds self-evident, but it’s not a joke.  It’s a reality that many financial and operations executives fail to understand.  Everyone, from the business analysts to the website deployment people are not just software users – they have to understand software principles to do their work.

Business competition will come from new players, and from old players who master software tools and the business possibilities opened up by software.

As software becomes an integral part of business, there is a subtle shift in what management has to do and to know.  You now need staff – or consultants – who are knowledgeable about software and its workings.  And from them you need to learn what software means for the future of your business.

Is there something you’ve learned recently about software?  I welcome your comments.

There’s been a lot written about how IT and business are misaligned.  See for example, Susan Cramm’s excellent book.[1]  But how do they get that way?  One cause is that many IT people don’t understand business.  Another is financial invisibility of IT due to budgeting processes.  But these are not the big killer causes.

I believe there are three major causes:  physical distance, psychological distance, and IT overload.

Physical distance of IT from the business leads to isolation in many ways.  One of my client companies had their IT people in a city 750 miles away from the home office.  Not only did this impose communication barriers, it meant that the IT people were living in a different culture from the home office people – even though both locations are in the United States.  Of course, when you add in the distance to some of the offshore contractors who are handling some IT services, physical distance means even more cultural distance.

Psychological distance can be caused by having objectives that don’t relate to business goals and by being managed in a “silo.”  For example, IT may report in to the CFO, and management metrics may relate only to financial performance.  As long as IT is budgeted as an operational expense, then no amount of encouragement will get IT managers to view what they’re doing as a strategic investment.  This can be aggravated by failing to include IT people in business planning.  Finally, I’ve seen IT organizations where the business tools used by the rest of the business are not in use in IT.

IT management overload is the third major cause of misalignment.  Beyond the usual overload caused by rapidly changing technology and shifting responsibilities (associated with Cloud services, for example), IT management is typically trying to do more with less budget.  As the pressure to perform increases, IT management concentrates on operational measures rather than business metrics.  In addition, technology shifts are raising the cost and complexity of legacy system support.  So IT managers tend to focus on reducing these burdens, rather than looking for new initiatives to support.

Where can we start to correct the lack of alignment between IT and business?  After addressing physical location and reporting structures, the most productive way to get alignment is with common metrics.  Look for business metrics that are relevant to concrete business results and are particularly dependent on IT service delivery.  Then make sure that IT managers understand the business metrics.  Finally, make sure that they buy in to being measured by these metrics.  To do that, of course, it is best to include them in business planning processes – and not just as number-providers.

What are your experiences with IT – Business alignment?  I welcome your comments.

The Cloud

Everyone touts “the Cloud” as the latest thing, yet many aspects of the Cloud have been around for years. If you’re using Salesforce.com, for example, you’ve had software as a service (SaaS) for as long as you’ve been a subscriber. In my office, we use a CRM (customer-relationship manager) service named Highrise by a company called 37Signals. There are many satisfied users of these cloud services, but it’s best if you understand the tradeoffs and pitfalls. Here’s a quick summary:

What’s most unusual about the Cloud? – it accommodates temporary load variations

Using software that’s running “in the Cloud” gives you the capability to radically change your usage of the computers. So if you have a temporary load that is 100 times your average load, you can “provision” a bunch of servers and cover your needs in just a few minutes’ interaction with the cloud service.

What’s the biggest caveat about using the Cloud? – you have to be using standardized services

Cloud service providers can give you what you want in a moment’s notice. But unless you’re using a service that is standard – that is, not much different from everybody’s else’s service – you will not find it economical. So don’t look to cloud services to differentiate you from your competitors, because they are probably using the same or a similar service, too.

What’s the payoff of using the Cloud? – OpEx, not CapEx

You pay only for what you use, and it’s usually a lot less than the cost of provisioning your own data center and buying the software. So using the cloud lets you get IT work done efficiently on operating expenses alone.

What else could be a problem in using the Cloud?

1. Security – don’t plan to put your most confidential data into the cloud. For the data you do put in the cloud, make sure you have adequate backup and restore capability, or suitable data duplication.
2. Availability – be sure to check on service level agreements (SLAs) from your cloud providers. Think about how many minutes of downtime a year you can afford, then compare the offerings.
3. Competitive services – there aren’t many cloud service standards yet, so moving from one cloud provider to another can be a problem.
4. Rogue IT – If you’re managing IT for a large organization, you may discover that department managers are buying their own cloud services. This may be efficient and effective for them, but it could undermine your efforts to get IT to be consistent and effective across the organization. Get out in front of your users’ needs, and offer consulting on cloud services to your departments.

For a longer essay on the ups and downs of cloud services, I recommend you read Robert Keahey’s article titled, “The CFO’s Guide to the Cloud”.

Agile

Agile software development originated with the “Agile Manifesto” in 2001. I like to describe it as a bunch of software developers who got together and said to themselves, “We’ve been so badly managed for so long, surely we can do better ourselves.” So they laid down 4 values and 12 principles for software development. Since then, Agile has proven to be 2 to 3 times more efficient than previous “waterfall” methods for many types of software development. And the Agile principles have begun to be taken into other areas of management. Here are a few key things you should know about Agile:

What’s most unusual about Agile? – progress is more visible

Agile methods work by dividing up a large project into increments that can be done in short intervals. The interval chosen is usually 2 or 3 weeks. At the end of each interval, the project team demonstrates working software. Since you can see the software working sooner and more often, you get more confidence that the claimed progress is real, because you can see it.

What’s the biggest caveat about using Agile? – it requires more involvement by business people.

A development team in an Agile project requires daily access to a business person who is responsible for the results. This guarantees that software developers can talk over what the requirements really mean. It also requires the business person to be on-call every day, as well as present in person at the end-of-iteration reviews every 2 weeks. Don’t expect an Agile team to be effective if you don’t provide for this level of time commitment by one of the business leaders.

What’s the payoff of using Agile? – you can keep up with changes in the market and in your business priorities.

At each interval the priorities are set for what should be done in the next iteration, so you can adapt the project to changing conditions as you go. This helps to keep you from paying for a lot of work on the wrong thing. In fact, this could allow you to kill a project after only 10% of it is done, rather than having to wait until 60% to 80% of it is done to find out it’s the wrong thing.

What are other benefits of using Agile? – Agile could infect your company’s project management system and make everything you do more efficient. At the very least, using Agile for software development in IT will make your business people and your IT people work closer together on major developments. And that couldn’t be bad, right?