Subscribe via RSS Feed

Forrester Webinar Uncovers the Ugly Truth About Project Failure

This afternoon, I participated in a webinar with Forrester Research (full recording embedded below).  The turnout was great and, as expected, the energy on this particular topic was high.  After all, who among us hasn’t lived through the pain of project failure?

We spent an hour with Forrester Analyst, Mary Gerush, who shared some valuable insight on why requirements definition is the key to avoiding project failure. Says Mary, requirements “must be a collaborative, business driven approach” in order to get the business what it needs.

Some of Mary’s key points included:

  1. Finding and fixing a software problem after delivery is often 100x more expensive than finding and fixing it during the requirements and design phase.
  2. Slide07-300x225In addition to the financial impact of project failure, the damage done to the entire organization can be brutal:  End users go elsewhere. The trust of your business partners evaporates.  The development team loses confidence.
  3. Business and technology teams struggle to work together for many reasons: Economic challenges; consumer insistence on instant satisfaction; business and technology silos; multi-channel product distribution; third party partnerships; and new integrated environments.  Now we have many stakeholders with varying motivation and needs … often at odds with each other.
  4. Unfortunately, these varied groups of stakeholders may or may not know how to tell you what they need. There’s often a gap between what the stakeholder wants … what the project team has to understand … and what really has to be done.
  5. Business-Technology (BT) partnerships can change this game. A BT approach requires business stakeholders to take ownership of requirements and make the time commitment to be proactively involved.
  6. Business success is all that matters.  Instead of measuring business success in terms of on time/on budget, we should measure it by benefits realization, customer satisfaction and ROI.
  7. Slide23-300x225The BT Requirements life cycle starts by establishing a clear business vision and measuring success in terms of business impact.
  8. Success means recognizing that requirements live before, during and after a project.

When it comes to requirements, I continually emphasize the importance of creating a shared vision of success between the business stakeholders first, and then between business and IT.  When all the business stakeholders agree to exactly what they need, it makes it easier for the development team to deliver it!

We heard in the webinar that in order for the business to get what it wants, it must commit the time to collaborate on the business issues. One of my favorite parts of a project is when the business perspective on success criteria begins to emerge – without geek talk or specifications. This is when everyone involved feels totally confident for the first time that a common vision of success is achievable and will get clearly communicated to the development team.

Within the next couple days, we’ll post a recording of the webinar here. So, come back for a review and feel free to pass it along to your colleagues.

How about your team? How do you keep your business stakeholders committed and engaged in the requirements process?

View the webinar in it’s entirety:

Tags: , , , ,

Category: For Practitioners, Requirements Definition

Comments (1)

Trackback URL | Comments RSS Feed

  1. Cathy Brunsting says:

    I was unable to listen to the webinar live (vacation … grandkids), so I am really happy to see it here. It was excellent.

    What really resonated with me is the need for enforcing best practices around getting alignment amongst the business stakeholders and between the business stakeholders and IT. Without clear business objectives and defined business success criteria, the delivery team will be unable to know when they have been successful. The definition of “success” is then left up to individual interpretation – which means that the project will be perceived as unsuccessful by at least some people.

    The delivery team needs to hold the business stakeholders accountable for defining the objectives and business success criteria, *before* they accept responsibility for delivering a successful project. When success cannot be clearly defined, the entire team (business and IT) needs make the risk to project visible and transparent to project sponsor and/or senior mangement.

Leave a Reply




If you want a picture to show with your comment, go get a Gravatar.