When we see the same view every day, we get complacent. We no longer notice certain details. Habit, rather than choice, controls many of our behavioral responses. We may be doing fine, but such a limited view doesn’t promote getting any better, and leaves us vulnerable to changes outside our control. Or we may be missing points that are essential to the success we want.

I started taking photographs with a Kodak brownie camera. It had a simple lens that approximated the field of view of the human eye. Years later, when I bought an interchangeable lens camera, it came with only one lens with a similar field of view. Photographers call this a “normal lens” for that reason. You can take good pictures with such a lens, but it limits the range of pictures you can take.

Sometimes I could borrow my father’s zoom telephoto lens and use it on my camera. This lens allowed me to see differently. It brought more distant objects closer, and created interesting contrasts with closer objects. I loved this lens, and used it whenever I got the chance because it allowed me to take photos that were not possible with my normal lens. It allowed me to see the world in a different way.

Over time, I bought a range of different focal length lenses. This gave me more options than a “boring normal lens” and an “exciting telephoto.” I had enough choices that I needed to consider what lens was best for the photograph I wanted. Or, what lens was a good choice for the context where I would be shooting. Or, what lens was a good choice to get me unstuck from seeing scenes in the same way.

I see comparable choices in software development projects. In many corporate environments, a project manager may be focused on delivering something that meets the requested requirements within the time and money budget provided. That’s certainly a measure of success. If we could do that every time, we should certainly be happy.

Or will we? Perhaps our explicit requirements leave out some implicit ones that are important. Should the system be easy to understand and use? Should errors be easy to identify and correct? Should errors be caught and action taken to minimize damage? Should the system repel malicious users, and keep private data in confidence?

Only delivering that which is explicitly requested will lead to disappointment. To do a better job, we should broaden our view to include the context in which the system will be used. This will help us understand the implicit requirements that make up what is wanted. Of course, it’s best if we confirm those desires with the stakeholders.

When our focus is on part of a larger project, things get even more complicated. Our handling of implicit requirements must be compatible with the work of others. A piecemeal approach makes errors more likely, more expensive, and harder to correct. Sometimes, such as with the federal healthcare.gov insurance exchange, the gaps between components lead to embarrassing headlines. It’s important to get some view of the overall larger project, even if the contractual landscape makes that hard to do.

Taking a broader view is certainly helpful for making our project a success, but if we’re not careful, it can become our “new, exciting view” and limit us as much as our old “normal view.” This broader view should augment our standard focus of accomplishing the project we’ve been assigned, not replace it. A broader view can help us avoid tunnel vision, but puts us in danger of seeing only a superficial overview.

It’s often said, “the devil is in the details.” Besides our normal project focus and a wider view that takes in the project context, we need a close-up view of the details. Are we taking care of the little things that are necessary for success?

Is our code robust enough to handle unexpected values? Does it check that space is available when storing information, handling “disk full” or “array boundary” issues? Is the code easy to read and understand, so that when new people come on the project they can work on it without introducing errors? Is the code simple enough to modify that last minute changes aren’t likely to break the system? Is knowledge spread enough that the project is not at risk if a key player gets sick?

These are just a few of the myriad details that can make or break our project. No one person can attend to them all, so project managers naturally delegate them to their technical staff. It’s not wise to quit looking at the details after delegating, though. Not hearing of problems is not the same as not having problems. You can’t do much about problems or potential problems if you don’t know about them. How can you ensure that you’re seeing an accurate picture?

A prudent project manager does not rely on any single view of the situation. Zoom in on the details. Zoom out to the bigger picture. Look at the project issues that are your principal domain. Keep varying the view to see things you might other wise miss. Think of other ways to view the situation. Consider the viewpoints of others. If you’re lucky, you can ask them, but otherwise try to imagine what aspects are important to them. Think about those who might judge the project after the fact, those who will maintain the code, or who will support the users, or who will be responsible for the accuracy of financial reports or the security of customer and corporate information. Don’t ever get stuck on a single view of your world.

This post was previously published on ProjectManagement.com.