Change is often desirable and sometimes necessary, but it may still be resisted by those required to implement it. A common reason for this resistance is that people are uneasy when dealing with unfamiliar things and tend to view them as being unreasonably difficult. A way around this is to allow people to continue doing what they have been doing but have that generate different and more desirable results.

While insanity is sometimes defined as doing the same things over and over but expecting different results, it is possible to do the same things over and over and actually get different results. Projects can take advantage of this to deliver new things which seem familiar and easy-to-use. This is accomplished by replacing an established cause-and-effect relationship with a same-cause-but-different-effect relationship.

The following is a simple example. It was desired to increase air flow into a room when it was occupied. People already flicked a switch to turn a light on or off when they entered or exited that room. By placing a fan on the circuit controlled by that switch, flicking that switch now also turned that fan on and off. People keep doing what they had always done (flicking the switch), but that same action now delivered a different result.

Starting a new project can be an opportunity to work with a clean slate and create something new and exciting, but that may not be best for the customer. It is generally good to view a new product, service or organization from the perspective of those who are expected to use it. If it appears complicated or intimidating, it is likely to encounter resistance. This can sometimes be addressed by allowing people to keep doing what they already do – to keep that slate looking the same.

The following is a real life example. A suite of custom software applications was developed for use by a clerical staff. The staff had been using older software which was no longer supported and had limited functionality. The new software was designed to be more attractive, more intuitive, more functional, and with a modern interface. The functionality (output), reports generated, etc., were substantially enhanced with the new software.

The clerical staff liked the attractive layout, the built-in help, and the intuitive UI, but balked at having to learn new things in order to keep doing the same old job. The new interface was changed so the staff could continue to use the old work steps to access the new functionality. The new product was then embraced by the staff (partially because its concerns had been addressed) with the side benefits that training time and user errors were reduced because people continued doing what they knew how to do.

This “insane” approach prioritizes doing what is easiest for the customer over what is easiest for the project. It transfers some of the customer’s implementation costs to the project. Those designing the project must take the time to learn the customer’s wants and needs. This may require working with those who will actually use the project output and not just their managers or supervisors. This is a Value Engineering approach that considers total cost and an Agile approach focused on customer satisfaction.

The “insane” approach, doing the same things over and over to get different results, can reduce customer resistance and increase customer satisfaction. It is generally more difficult to design a new output around an existing interface than to design an interface specifically for that output. Fitting the output to an existing interface can increase development time and costs but reduce implementation, training and user error, time and costs. Its corollary, doing different things to get the same results, can reduce development time and costs.

Since the real deadlines are often unknown, completing projects expeditiously is a wise practice. Good scheduling helps to do this.

A schedule should be an iterative and evolving plan. It is a model of an expected future that can be examined, critiqued and hopefully improved. A schedule is not a prophesy, a prediction or a promise. People who set out to do something usually have at least some idea of how they will get that done. When those ideas are collected, organized and written down, they form the basis of a schedule.

Schedules have been used to lie, terrorize project teams and create completely unrealistic expectations. These are abuses of scheduling and are not inherent in scheduling itself. Bad or abusive schedules are tied to bad or abusive management practices. Agile sometimes seems to view scheduling as a bad or abusive management practice. This is a mistake.

The Agile practice of doing the most important things first is a good one. The expectation this means projects can release whatever they have on hand at any time ignores the impact of competition. In a noncompetitive environment, such as internal IT projects, any improvement is valuable and a partial release can be useful. In a highly competitive environment, such as online games, incomplete or noncompetitive releases serve no useful purpose.

Good schedules help to clarify what the most important things are. This includes the things which take a long time to do, so that they can be started sooner, and the seemingly unimportant things on which more important things depend. Good schedules provide a benchmark against which progress can be measured and illuminate where more resources should be applied or expectations changed.

When setting out to accomplish something, it is a good idea to identify what is needed to accomplish it. Scheduling is not a perfect way to do this, but it is a better way than sprinting from point to point in the hope of reaching the final destination before the money runs out or someone else gets there first.

It is argued that setting and meeting deadlines can force the premature release of poor quality products. While it is certainly a bad idea to release a poor quality product, there have been too many instances of poor quality in late releases to believe that delays translate into good quality. They do translate into higher costs and missed opportunities. A good schedule is a valuable aid in meeting deadlines with quality releases.

Two things are required to deliver a project on schedule: realistic deadlines and a team determined to meet them.

When managing projects, it may help to remember that you are doing something at odds with most business practices and upsetting to many people. Projects are temporary and create something new. Most businesses are ongoing operations which recreate the same things. Because projects create something new, they are all at some level about change. Change is hard, feared and resisted.

Where operations do the same things over and over, projects do something unique. Where operations are intended to be ongoing, projects are intended to end. As operations and projects are fundamentally different, it should be apparent that the organizations, methods and mind sets best suited for operations are not the best for projects.

People, as individuals, are not central to operations. Operations are procedure-centric. They improve and refine their procedures to the point where who follows them has little impact on the quality or quantity of what is produced. Operations take advantage of the predictability inherent in repetition to insure a consistent product.

Procedures, which rely on repetition, are less useful for projects. Projects, which are always doing something new, rely on people. Projects are people-centric. Projects rely on contributions from people as individuals to create something new. Change comes from people, not procedures.

Businesses often forgo change until forced to change in order to compete in a changing and competitive world. When forced to change, projects are the instruments which implement that change. There are different types of change and different types of projects.

Project types

Projects types range from the evolutionary to the revolutionary. At one end of the range are evolutionary projects which implement incremental change, something that is very similar to what has been done before or is being done in other organizations. At the other end are truly revolutionary projects, those which seek to do something that has never been done before. The more revolutionary the project, the less predictable and less operations-like it is.

Most projects are evolutionary. When people can work in the same departments, for the same bosses, with the same people, and do nearly the same work they have done for operations, projects are neat, predictable and unthreatening. Operations are most likely to undertake evolutionary projects. These are well-suited to operations’ organizations, mind sets and experiences. When change is allowed, it is usually kept to a minimum.

Real change, revolutionary change, is hard on operations. Revolutionary change requires imagination, a willingness to take risks and an organization that allows things to be done differently. Doing things the same way (but expecting different results) does not bring change. Despite this, many operations will attempt to conduct revolutionary projects as if they are just a different type of operation.

Projects only succeed if they have the right resources. These include leadership, flexibility and determination. An organization that cannot provide these resources cannot change as it needs to. It cannot evolve. Organization that cannot evolve become extinct. Change is not only hard, it is necessary.