The presentation discusses scope creep and how to manage it in small and medium size consulting projects. Included are discussions of what is scope, how to set scope, what is risk, imprudent vs. prudent risk, balancing scope and risk, and assignment of risk. The link points to a summary article. (Summer 2001)

Within software projects, the risk of scope creep can dramatically affect the outcome of the project. Dealing with this risk in a professional manner allows consultants and clients to succeed in every project.

Scope and Scope Creep

In software engineering, answering the following questions will give one the "scope" of software [1]:

Context. How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context?

Information objectives. What customer-visible data objects are produced as output from software? What data objects are required for input?

Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?

These four elements: the context, objectives, function, and performance make up the scope. Each must be clear and understandable at both the management and technical levels.

"Scope creep" is the expansion of scope. This occurs when any of the four elements are not clearly defined. In the average project, this will lead to more work to do before the project is complete.

Scope creep appears in projects with timelines that do not contain enough time to fully understand the client's needs. It can also appear in incrementally phased projects. For example, a complex e-commerce website development project commonly exhibits scope creep because project managers cannot easily define the four elements early. In these cases, the scope defined for one release may be pushed or pulled to another phase by the client's expectations, marketing or legal delays, or simply because the client changed his mind.

Scope creep becomes a risk in these situations because; it leads to an increase in the resources (such as time, materials, and people), it drives up costs, and lowers profits to both parties. It happens to all projects because over time things change. The difference between a success and a failure rests in the management of the projects and the ability to understand the different types of risks and allocate them correctly.

Imprudent vs. Prudent Risk

In order to be successful, a consultant must be able to properly recognize all risks and take only prudent risks.

Imprudent risk would occur if you represented yourself as an "expert" in an area you are not, worked with a lack of client involvement and accountability, [4] failed to scope the project or lacked the proper relationship with the client. These would create a high-risk situation where the risk was unnecessary.

Prudent risk would occur if you did not represent yourself as an "expert" in a field that is new to you; if there were a collaborative partnership in which you and the client were jointly accountable for design, implementation, and outcome; and if you were working with a client with whom you had a strong history. [4]

Examples of projects that can involve imprudent or prudent risks of scope creep include: (1) Networking project for a network design company - it depends, but most likely a prudent risk because the company will understand possible scope creep areas and account for them. (2) Software system project for a network design company - it depends, but probably an imprudent risk because this company will likely fail to scope the project correctly. (3) Exploring new ventures - it depends.

For each of the above it always depends. Number one could easily become a project nightmare without sufficient management and two could be prudent if information is available to all parties involved. The classification of prudent and imprudent risk depends on the details of the project - the people, process, and product. Nevertheless, good news, if one can avoid imprudent risks there are general methods to manage the prudent risk of scope creep.

First, define scope up front and early in the project lifecycle and hold the client and consultant to the document. The advantage: a clearly defined and known scope sets expectations for both parties. The disadvantage: clients may want something that falls outside of scope and the consultant must say no or the project will suffer scope creep. This could potentially hurt the relationship. When the number of unknowns is high, this method is not recommended.

Second, one could allocate the risks to the client and consultant in the form of partnership (legally or figuratively). The advantage: working together creates prudent risk where everyone is responsible for progress and everyone knows that things can change. The disadvantage: possible legal requirements and limitations will slow or prevent the project's start if the lawyers involved introduce legal delays.

Third, the most commonly used method is to bill for time and materials. The advantages: work will get done on a project; scope can grow and take more time or materials; and the consultant can expand their role, keep working, and satisfy every need of the client. The disadvantage: another project may need consultant resources three months out, if the scope grows resources will not be available. The client may also have a deadline that changes based on newly added tasks. Finally, some parties may want to produce or see detailed work records of both time and materials used which will add overhead for the project - and there can still be disagreements over what the consultant and client will pay for.

Conclusion

Both the client and the consultant must conduct risk analysis, assign the risks, and take responsibility for managing them. This ensures that both the client and the consultant take on only prudent risks (avoiding disastrous imprudent risks) and receive mutual benefit from the transaction.

References

Ryan Dibble is a Consultant for Dibble Group Inc. and lives in Dearborn Hts., MI. He is a member of HKN, IEEE, and the ACM. To contact him write rdibble@dibble.net.

Copyright © 2001 Dibble Group Inc. All Rights Reserved.

see also http://dibble.net/pp/ManagingSoftwareScopeCreepAsARisk.html