Turning IT Project Failures Around

by Brandon Epperson

One advantage of being part of IT project implementation is being part of the postmortem process when they fail. This unique perspective offers an opportunity to assess the underlying causes of these failures and, more importantly, proactively recognize these causes to prevent them from happening again.

In fact, what I’ve seen over the years of post-mortems is that no matter the project size and scope, one central element clung to each of these failures: a lack of properly-captured user-driven business requirements. Yet, with the right user requirement framework in place, even the largest, most complex projects can be executed in a way that all stakeholders can be proud of.

Why User-Driven Business Requirements Are So Vital

Business requirements instruct the IT architecture and development teams on how to design and build a technical solution so that it grows the overall business and satisfies its customers. Without business requirements, you can find yourself in a common but unfortunate situation: your IT organization spending months in planning and development to create an end-product that is functional but that is disappointing to the end user. This is all because the user and their needs were not compiled during the planning and development phases.

When a business unit is ready to make technology changes, those changes must be properly described to the IT team in sufficient detail, making it apparent what the business unit wants and needs. For instance, consider telling Rosie, the 30th century AI robot on The Jetson’s, to clean your home. The concept of housecleaning sounds so simple. But to do the job properly Rosie will need to be programmed with every single element of what house cleaning means…and what it doesn’t mean. Even something as simple as, “Don’t vacuum over the cat.” will need to be turned into a well-thought-out set of instructions to ensure Rosie first identifies what a cat is, responds to the identification, and then establishes an alternate path.

No matter the project scope, developing business requirements must be a collaborative approach where business analysts are tasked with exploring, guiding, and capturing all relevant project needs. This extra effort on the front-end will ensure that months down the road, the completed project will enjoy a clear sign-off for meeting the user’s needs.

A Framework For Business Requirement Collection

The 4-step Elicit-Capture-Agree-Memorialize (ECAM) framework provides clear guidelines for how IT professionals can collect the information they need to gather useful user requirements.

1.  Elicit

During this stage, the business analyst is introduced to the project, the organization, and the challenges that stand between the business and a successful deployment. At this stage, the business analyst will reach out to users to learn about their needs. It is the analyst’s goal to move users away from speaking about changes they want to see within their current systems and orient them towards talking about the ideal they want to see.

There are several techniques business analysts can use to help business owners imagine this ideal:

  • Conduct a requirements meeting will all relevant users to create a storyboard/process follow model that encapsulates the full user experience.
  • Complete one-on-one user interviews.
  • Lead group brainstorming sessions.
  • Review existing standard operating procedures.

2. Capture

A good business analyst will ensure that requirements are documented in a way that makes development and testing as fluid and comprehensive as possible. How these requirements are captured can vary depending on the nature of the requirements (e.g. functional vs. non-functional) as well as the desired methodology of the enterprise.

Some organizations may develop their own templates and methodologies for capturing requirements to institutionalize the process. Regardless of which approach you follow, the end goal is the same: collect use requirements in a way that captures the end user’s needs as well as the nuances of their potential use cases.

3. Agree

At the agree stage, you are seeking your user’s approval to move to the next stage in the project or, if you’re at the very end, to move the project into Production. This stage can often be stressful. But it doesn’t have to be.

To make this a seamless stage, create objective guidelines upfront for what it will take for stakeholders to sign off on a particular project stage. By tying these guidelines to your initial business requirements document, you know your team is on the correct development path and your users will be able to see that their requirements have clearly been met.

By formalizing what it will take to get to “Agree,” you’ll be able to easily move onto the next stage of a project without the common hiccups that rise up when lacking clear approval structure.

4. Memorialize

How you collect meeting notes, summarize user sessions and compile sideline discussions will vary from organization. Regardless of your unique process, you’ll want to find a clear, easy-to-follow way that aggregates that information and memorializes the requirements. When the business analyst properly memorializes the requirements, their audience will be able to see that their business needs are fully captured and will have a clear roadmap for how the IT organization will address them.

A good memorialization also comes with one major upside: it helps clarify throughout the development cycle the project’s scope and trajectory, keeping the business unit and IT team fully aligned.

Final Thoughts

Leveraging the ECAM process is an ideal way to unite your business and IT teams so that everyone is rowing in the same direction. By creating a structure to your business requirements process, it takes what has traditionally been thoughts and ideas on the part of the business unit and transforms them into actionable steps the IT team can act on to improve the organization’s goals.

Keep in mind that it’s never too late to implement the ECAM process. Even if your project is in full swing and has fairly loose requirements, taking a step back and applying this framework can move you on the right path to satisfied sign-offs.