Why Success is Difficult: Part Two

I started this series of blogs on project management challenges with a discussion of project management success factors (“Three Pillars of Project Management”). Then I asked the questions – if we have known how to be successful for over 20 years, why is it so difficult? What are the challenges? In my most recent blog, I talked about Challenge #1 – Uncertainty. Today I will share some thoughts on about managing Challenge #2.

Project Management Challenge #2 – Requirements

There are a myriad of examples in the literature (and the web) on how unclear and ambiguous requirements contributed to project failures.   This occurs at both “layers” of requirements I presented in the previous discussion on project management success factors. There are challenges associated with each.

Often project goals and objectives are cannot be articulated, so how do you know they are achievable? How can the project be successful? Often they cannot be articulated because they are not derived from solid business requirements. I have been in projects where the sponsor or business owner was uncertain about what they wanted. Other times the stakeholders had different ideas about the goals and objectives of the project.

The technical and performance requirements provide the details of the product or service to be delivered. The project is not a success if we cannot deliver what the customer needs.   On just about every project I have managed there were business needs and advances in technology that resulted in changes in requirements. I have worked with customers that constantly changed their mind about what they wanted and even one customer admitted they were unsure about what they wanted.

Managing the Challenges

Here are several practices that I have used to manage the challenges:

• Ask for the Business Case. The business’ justification for the project should be documented. The justification will include the business requirements, often expressed as expected business benefits. The business case should provide the purpose of the project, the expected business benefits, and the different options considered to meet the business need for the project. Other business requirements such as expected costs and duration, as well as associated risks should be in the business case. Additionally, key stakeholders and sponsors should be identified and their expectations reflected in the business case.

• Use a Business Analyst. One of my key resources on a project is a business analyst; someone who works with an organization or business and analyzes a domain (real or hypothetical) and documents its business processes. They analyze new capabilities or gaps in capabilities and present them as business requirements. They have the skill to interact with customers and work with them to prioritize the requirements. A business analyst can help set up a requirements management / configuration management process. They help ensure technical / performance requirements meet business needs.

• Build a Work Breakdown Structure. From a project execution perspective, a work breakdown structure (WBS) will put structure to the project work. The technical and performance requirements can be identified for each WBS element, usually in a requirements or specifications document or WBS Dictionary.

• Implement a Requirements Management Process. A formal requirements management system will provide a process to identify, document, analyze, and trace requirements, including validation and verification of requirements, throughout the project lifecycle. A key part of the system is process to manage changes in requirements. The system should include tools and techniques that will facilitate requirements management.

Delivering successful projects not only involves knowing the “success factors” but also understanding the challenges in managing projects, and more importantly, the ways to address the challenges. It starts with the basics of project management, and then applying the skills and tools to manage the challenges.