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

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

Three causes of IT project failure

February 13, 2012

IT projects often don’t get done.  Not just done late, but not done at all.  Industry statistics show that over 50% of major IT projects are not regarded as successful. They get abandoned because they’re too late or because they’re so far over budget that the sponsors give up.  Many more deliver something, but not what the sponsors really want, and not on time within budget.

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.

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