Navigating the Grey Zone: When Projects Don’t Quite Meet Expectations

Bridging the Gap: Strategies to Align Outcomes with Client Aspirations in Future Projects

It is easy to understand that the success of any project hinges on the quality and precision of its specifications. That’s why project sponsors, that is, the customer, must always provide comprehensive, accurate, and high-quality project specifications before going to tender. As is often the case, in my experience, there is always something missing, leaving the customer with a mostly, but not entirely, functional application that does not meet expectations.

Disclosure. I use Generative AI tools to help me when writing. From outline suggestions to topics or subtleties, I had yet to think of.

See more articles, posts, and discussions about business, project management, Generative AI and Creative Writing on Medium here. If you have not already, subscribe to Medium. Or follow me here on Substack.

Software companies will build exactly what you ask them to build within the limitations of technology. The key word here is exactly. That is, as specified in the supplied documentation. If the specification of requirements is lacking in detail or not specific enough, then the delivered software will not be all that the client expected. In a worst-case scenario, this could be termed a failed project.

Shatter Complexity: Requirements Gathering Essentials

The Dichotomy of Client Expectations and Project Deliverables

Software projects can fail for many reasons, but the most common cause is a lack of precise requirements. Without a clear understanding of the business requirements and user needs, it is difficult for the project team to understand what the project must accomplish and how it should function. Poor communication between team members and stakeholders can, therefore, lead to project failure. If stakeholders are not involved throughout the project, their needs may not be met, resulting in a product or service that does not fully meet their expectations.

Trust can be a casualty of a project falling short of expectations. Building trust between people or organisations takes time, but this trust can be blown overnight.

Consider this scenario: when a new or existing client requests a new product or service or for an extension of an existing one, one of the worst mistakes is to assume that the client knows exactly what they want. Of course, they will believe that they do, and there is always the possibility that they might be correct. However, it is always wise to assume that the client only has a vague idea of the requirements.

Client Relations must be built on mutual trust and respect. Otherwise, Watch Out!

If, on the other hand, sufficient time is taken to ensure that all client expectations are properly documented and thus delivered, then the trust between the two sides can only grow. They often lead to follow-on projects.

Bridging the Expectation-Delivery Gap

Ensuring that all client expectations have been adequately met in the final document is time-consuming

and seemingly expensive. The investment is always worthwhile, as discovering that the deliverable is missing some rarely used but vital function during the closing stages of the project will prove to be even more expensive and time-consuming to fix.

Here are some simple best practices for producing an accurate Specification of Requirements document and the matching, technically slanted, Functional Specification document. They are taken from an earlier article published in May 2023.

Practical requirements analysis and client specifications result from best practices promoting thoroughness, clarity, and collaboration. Following these practices will create specifications that align with client expectations. Here are some essential best practices to consider:

1. Engage stakeholders from the outset: Involve key stakeholders, including clients, end-users, subject matter experts, and project team members, from the early stages of requirements analysis.
2. Define a structured approach: Establish a structured approach to requirements analysis, including clear steps, methodologies, and documentation templates.
3. Conduct thorough requirement gathering: Use techniques such as workshops, interviews, and surveys to gather requirements comprehensively.
4. Prioritise requirements based on their impact, feasibility, and alignment with the project’s objectives.
5. Document requirements effectively: Use standardised formats and tools to document requirements, ensuring clarity, completeness, and ease of understanding.
6. Validate and verify requirements: Regularly validate and verify requirements with stakeholders to ensure accuracy, completeness, and alignment.
7. Facilitate ongoing communication and collaboration: Foster open and frequent communication with clients and stakeholders.
8. Consider change management: Recognise that requirements may evolve.
9. Use visual aids and prototypes: Visual aids, such as flowcharts, wireframes, or prototypes, can help stakeholders visualise the project’s features and functionalities.
10. Foster a culture of continuous improvement: Encourage a mindset of constant improvement by capturing lessons learned from each project.

Unveiling the Key to Project Success: The Power of Requirements Analysis and Client Specifications

Unforeseen and Unplanned

The list of customer requirements may be completed with a high degree of accuracy. However, hidden amongst them can be one or two that, while they seem simple on paper when it comes to implementation, are impossible due to technical limitations. Web applications are notorious for this situation as the developers do not have free reign over the environment but must adhere to specific fundamental rules.

Similar problems can occur when the development team understands the customer’s vision of how a function should operate differently. On the surface, both sides seem to agree on the requirement completely. But on the developer side, accounting for known technical limitations, which they may think is obvious, precludes building exactly as the customer wishes.

Over the years, I have repeatedly witnessed at least one issue in the final project deliverable, leading inevitably to customer disappointment. I will not mention specific projects or customers, but I struggle to remember a single one hundred per cent successfully delivered software project.

Foreseen and Planned

It’s not enough to provide the appropriate documents in the project’s early stages (the Specification of Requirements and the Functional Specification); they may look perfectly wholly and reasonably aligned. The unforeseen problems are, for a high percentage, avoidable at this stage.

During the initial technical analysis, the key areas containing any unknowns must be given special attention. They must be subjected to detailed review by a team, possibly even to the depth of producing a semi-working prototype of the proposed solutions. The trick is to identify these potential problem areas during the initial analysis. To ensure that nothing is missed, two independent analysts should ideally be enlisted for every project. Even if this is impossible, the initial analysis should, at minimum, be independently reviewed (a Cold Eye Review).

Once all unknowns have been satisfactorily addressed or demonstrated, the Functional Specification may be prepared. Only then can the customer and the developer agree on the project’s Scope of Work. The extra effort involved with such a thorough technical analysis should not be considered an undesired cost but an investment. Any knowledge gained from the exercise can only benefit anyone involved in future projects and challenges.

We foster problem-solving skills, adaptability, and resilience within the development team by facing these challenges. The customer’s trust can only be enhanced by exhibiting professionalism and dedication to achieving a mutually satisfactory result.

Final Thoughts

As you can see from the links, I’ve covered several aspects of this week’s article before and will do so again. Related, that is, not rehashing the same content repeatedly. This article revolves around software development projects. However, most of the points discussed are equally valid within any industry.

The key to all projects is stakeholder involvement; the more invested and informed all stakeholders are, the greater the chance of getting a project right the first time. A rarity today.

I was going to publish another article this week, but I’ve decided against it. It is very personal; I don’t know if I have the guts yet. Perhaps next week or next month. Or maybe not…

---

See more articles, posts, and discussions about business, project management, human nature, Generative AI and Creative Writing on Medium here. If you have not already, subscribe to Medium. Or follow me here on Substack. The KodifyIT Substack newsletter is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber. I would appreciate the support; you won’t regret it. 👍

I apologise to my readers for some of the spellings you may feel are incorrect. I was born and brought up in the United Kingdom, and this is the spelling I am comfortable with (Grammarly is happy with it anyway).