Why software projects fail.

Simply put, software projects fail because somebody's expectations weren't met. Perhaps those expectations were unknown, unclear, or unrealistic. It doesn't matter. The result is the same. At best, resources get wasted, and stakeholder confidence is eroded. At worst, trust is completely lost and the project is a failure.

Building software is complex and software projects don't always hit the mark from a business perspective. But a project should never fail because of unknown, unclear, or unrealistic expectations. Even in the case of missed business goals. Realistic expectations regarding that risk should have been set before the project began. A calculated risks not paying off isn't a project failure. But not setting realistic expectations regarding those risks is.

Understanding Expectations

Even the smallest software project will have all kinds of stakeholder expectations. There will be functionality expectation, along with; usability, aesthetic, performance, scalability, maintenance, support, security, timeframe, cost expectations, along with many others. It's safe to assume that you won't uncover every expectation up-front so discovering and clarifying expectations is an ongoing process. But generally speaking, the sooner you uncover and clarify expectations, the better off you are.

The most challenging part of the discovery process is that stakeholders often “won’t know what they don’t know.” So, they won’t be able to communicate all expectations up-front. For example, you can’t expect someone who isn’t familiar with software security to have clear expectations regarding what security measures should be implemented. However, if the system gets hacked, you can absolutely expect them to feel like their expectations weren’t met - and rightly so. If our expectation as a project planner is that the client should always be clear on all their expectations, that’s an unrealistic expectation on our part.

As the project planner, it’s our responsibility to understand the expectations stakeholders are clear on. It’s also our responsibility to bring up and clarify things that stakeholders might not be thinking about. Planning is about envisioning the future. So a good plan will be like having a crystal ball. It’s our job to make that crystal ball.

Sure, client expectations can change. But that is an expectation that should be clear also. For example, spending more time in planning and discovery will likely help reduce scope creep. But not always. If the project itself is a discovery process, it might be better to define requirements and set expectations as the project progresses. But either way, it should be clear that you’re building from a fixed set of requirements, you’ll be adding requirements as you go, or some clear combination.

Expectation Types

Again, there will be all kinds of expectations. But most will fall into one of the following categories:

Requirements: What are the functional and general requirements of the project?
Cost: What is the project budget and how will it be allocated?
Timeline: Are there key deadlines that must be met?
Design: How will the project be designed and what technologies will be used?
Resources: What personnel, hardware, and software resources are available for the project?
Risk: What risks are associated with the project and how will they be managed?
Testing: How will the project be tested and what criteria will be used to evaluate quality?
Maintenance: What processes and procedures will be used to ensure the project remains up-to-date and secure?

Asking questions - lots of them - is the key to uncovering and understanding expectations. Every project is different, so there isn’t a one size fits all list of questions you should ask. But more questions, and fewer assumptions is what you’re going for.

The person leading the discovery process needs to be experienced enough to ask the right questions. Further, depending on the complexity of the project, you might need multiple people, with experience in different areas, to ask all the necessary questions. But asking the right questions is critical to an effective discovery process and ultimately to the project’s success.

So, the project planner’s first, and arguably most important responsibility, is to ensure the discovery process is done thoroughly by qualified individuals. As a result of the discovery process, you should have a clear understanding of stakeholder expectations, or it should be clear that expectations will be defined as the project progresses.

When the initial expectations have been clarified we ready to begin defining project goals and objectives. We'll cover that in the next post.