If there is one constant in today's business and technology environment, it is change. The ability to respond to change in a client's business, its requirements for technology, the overall business climate, and new technologies are all critical factors for success.

Information technology must pay a return like any other business investment. Where to invest, how much to invest, and how quickly to expect results are critical factors that require knowledge of the competitive environment.

Some key questions to ask for every project:

Supportive executive sponsorship and a sound funding model are critical factors in the success of technology projects. Initiating a project includes establishing a sound business case and gaining supportive sponsors and users.

Key questions:

See Steve McConnell's "Software Project Survival Guide" for a more detailed treatment.

An engagement's technical environment has several aspects:

From a technical point of view, it is important to understand not only where the client is, but where the client intends to be. Is the client moving from mainframe systems to distributed object technology? Does the client want to web-enable its workforce? Is it moving toward integrating off-the-shelf software, or is it attempting to custom-build internal applications based on commercial or open source frameworks?

Often a business's hardest problems are less technical than organizational. How should it organize to deploy and use technology? Every engagement takes place in the context of an organization with it own history, culture, practices, and morale - factors which may make or break a technology project.

Key questions:

The criticality of affected systems is a prime consideration in planning and deploying any new technology. As Alistair Cockburn notes in his "Crystal Methodologies", what is risked by a system's failure determines how critical it is. Systems that are not very critical risk only comfort or convenience. More critical systems pose risks to discretionary money or, more critically, essential money or organizational continuity. The most critical systems are those whose failure put lives at risk.

How critical a system is influences the nature and scope of project documentation, the test procedures, and the kinds of technology that can be safely deployed. The more critical the project the more risk-adverse are management and development teams - and the more care that must be taken at every stage of production.

A project's size is one of the key determinants of its success. Larger projects fail far more often than small projects. Because of their greater risk, large projects require more detailed and extensive management and are necessarily less efficient than small projects. The same development methods are not appropriate for both - it is as much a mistake to extend techniques suitable only for small teams to 200-person programs as it is to overburden a small job with a heavyweight methodology. (See Alistair Cockburn's article for a good discussion).

It may seem obvious that when a business deploys information technology, the business should benefit. But putting this principle first and pursuing it relentlessly has far-reaching consequences.

Agile development methodologies such as [http://www.controlchaos.com/manage.htm] Scrum emphasize "business value driven software development."

Rather than fitting all projects to a rigid methodology, Ariel consultants use risk identification and reduction techniques to focus resources, which are always limited, on the most critical risks first.

The future holds no certainties. No matter how carefully planned, a project will not go as predicted. Planning to reduce risk shifts the emphasis from trying to predict a result to being prepared for the possibility that desired results don't happen. Because risk combines elements of value and likelihood, focusing on risk helps planners keep business priorities and value foremost.

Most management techniques exist to reduce risk. Document-intensive methodologies (useful for very large projects) attempt to reduce risk of miscommunication and personnel change by capturing information on paper. Testing regimes reduce risks to product quality. Company picnics reduce the risk of employee burnout. And so on.

However, each project has a different distribution of risks. For one project, introducing leading-edge technology may be the biggest risk. Another project might have an extremely short time to market. Untrained staff might be the foremost problem in a third. Planning to reduce risk tailors management to each project's unique situation.

The Ariel Partners approach to communication, "Understand and Verify," has application to every aspect of our engagements. It starts with a thorough understanding of each client's unique requirements and communication of that understanding back to the client. But it continues throughout the engagement.

When planning projects, we take care to establish and document robust communication channels within and among teams. Testing goes beyond the development shop, bringing business users into the process of specifying functional tests and verifying their success. We monitor every practice to insure that developers understand customer requirements and that customers can verify that they have been understood.

Risks increase with the size and scope of a project. Risks increase with the length of a project. The best way to reduce the risk of a large project is to 1) divide it into smaller, shorter pieces, 2) do the most important parts first, and 3) do as much in parallel as possible.

Long time intervals between deliveries are a huge project risk. The business loses sight of progress, systems become unresponsive to change, and developer morale deteriorates. "Incremental Delivery" is a critical success factor for technology projects and one of the key Ariel methods.

Although a well-managed large team can achieve more than a small team, communication overhead makes large teams considerably less efficient than small teams of equal skill. A team of four experts is likely to be faster and produce a higher quality result than a team of twelve average developers. Whenever possible, projects should be broken down into small, coherent teams with limited requirements for communication among teams.

Integrity is our highest value. It entails honesty, reliability, fairness and commitment to providing value to our clients. Why should integrity be a principle of our engagement methods? Because it informs every interaction with clients, subcontractors, our clients' customers, and among ourselves.

Our clients rely on us to provide accurate and honest assessments, whether the news is good or bad. We have no need to polish our resumes at our customers' expense. Because we are a small organization, we have no interest in padding projects with unnecessary personnel. Our goal is to make ourselves dispensable to our clients by leaving them with products, tools, and teams that work.