People have expectations. Individuals, teams, or organizations have a strong belief that something is going to happen in the future.
Project sponsors expect projects to be completed in a timely fashion. Developers expect clear requirements. Testers expect the test region to be stable. Users expect that all of their needs will be met. Vendors expect a statement of work.
Sometimes the expectations are valid; other times the expectations are false. The individual’s expectations are unrealistic or invalid. What causes false expectations and how can we set and maintain the proper expectations?
The Muck and Mire of Expectations
Let’s look at seven common causes of false expectations and what we can do about each. Take note that all of these problems are related to communications.
- Things are not discussed adequately. For example: Why do the users of software expect one thing and get something different in projects? One of the top reasons that projects fail is due to a lack of user input. Be sure to involve appropriate stakeholders in your discussions (whether it’s software requirements or anything else). Summarize and document decisions.
- Things are miscommunicated or not communicated at all. Another reason people have false expectations is due to information not being communicated properly. Check your sources and verify information before communicating.
- Things are misunderstood. Sometimes the information is correct but is misunderstood. The receiver’s environment, experience, language, and culture may affect the way the receiver interprets the message. Create the message with the audience in mind. You may wish to test the message with a small group before distributing to a larger audience.
- Things are over promised. Sometimes, well-meaning people make promises that can’t be kept. The promise maker thinks things can be accomplished but the individual doesn’t understand the requirements, constraints, and required resources and budget. Validate requirements. Get estimates from experienced personnel. Make sure you have adequate budget and resources. Stay focused on delivering the promises.
- Things change. In the course of developing new products or services, things may change. It’s easy for a small group to make decisions and fail to communicate the changes to the other affected stakeholders. Define a method for capturing and communicating changes to stakeholders.
- Things get lost. One group specifies the requirements. Another group creates a design. Another group may perform the build process…and yet a different group may test and accept something being created. It’s no wonder that things get lost in the process. Consider tracking things/requirements from one process to the next to check off and make sure the things specified early in an endeavor end up in the final product.
- Things are constrained. Someone may share a need in a strategic planning session or a requirements session. There seems to be agreement in the room. Later the idea is cut due to resource or budget constraints, but the person who shared the need does not know about the cut. Communicate the final plans to stakeholders. Communicate through different channels – don’t assume everyone will read an email.