12 keys for successful enterprise projects n.
Skip this Video
Loading SlideShow in 5 Seconds..
12 Keys for Successful Enterprise Projects PowerPoint Presentation
Download Presentation
12 Keys for Successful Enterprise Projects

Loading in 2 Seconds...

play fullscreen
1 / 38

12 Keys for Successful Enterprise Projects - PowerPoint PPT Presentation

  • Uploaded on

12 Keys for Successful Enterprise Projects. John Parker Enfocus Solutions Inc. www.enfocussolutions.com. Agenda. Success Rates of Enterprise IT Projects The Importance of G ood Requirements 12 Keys for Successful Enterprise Projects Build Business Analysis as an Organizational Capability

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '12 Keys for Successful Enterprise Projects' - jackie

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
12 keys for successful enterprise projects

12 Keys for Successful Enterprise Projects

John Parker

Enfocus Solutions Inc.


  • Success Rates of Enterprise IT Projects
  • The Importance of Good Requirements
  • 12 Keys for Successful Enterprise Projects
      • Build Business Analysis as an Organizational Capability
      • Document the Business Problem before Starting the Project
      • Reach Agreement on Solution Scope before Eliciting Requirements
      • Encourage Collaboration between Stakeholders and Developers
      • Address Strategy, People, Processes, and Technology
      • Use Iterative Practices for Both Requirements and Development
      • Optimize the Business Process as Part of Every Project
      • Don’t Forget the User Experience
      • Prioritize Requirements for Delivering Business Value
      • Implement Requirements-Based Project Management Practices
      • Use Requirements to Validate and Assess the Solution
      • Manage the Enterprise Portfolio to Achieve Business Results
software track record
Software Track Record
  • $230 billion allocated to IT budgets
  • Average cost per project was $1.3 million for a medium size company
  • Approximately 31% of all projects were cancelled
  • Approximately 53% of the surveyed projects failed due to:
    • cost overruns
    • delivered late
    • functionality deficient
  • Of the 84% failed and cancelled projects:
    • 1/3 had cost overruns of 189% increasing the average cost for 1/3 of the projects from $1.3 million to $2.4 million
    • 1/3 experienced time-to-market delays of 222%
    • 39% of the features and functions were not delivered

Source: The Standish Group Chaos Report,1994

waterfall vs agile projects
Waterfall vs. Agile Projects

Success rate for waterfall projects is lower than in original 1994 study. This is despitethe big focus we have seen on project management practices over the last 20 years.

Source: Standish Group Chaos Report 2011

major causes for challenged projects
Major Causes for Challenged Projects

The Standish Group Chaos Report 1994

Lack of User Input

Incomplete Requirements & Specifications

Changing Requirements & Specifications

Lack of Executive Support

Technology Incompetence

why are requirements important
Why are Requirements Important?
  • Requirements related problems, such as:
    • Lack of user input
    • Incomplete requirements
    • Changing requirements
  • Are a significant cause of project problems, such as:
    • Late delivery
    • Cost overruns
    • Reduced functionality
    • Low user satisfaction

Requirements are a Project Risk

  • Gathering and managing requirements are important challenges in project management.
  • Projects succeed or fail due to poor requirements at any time throughout the project lifecycle.
  • Thecontinuously evolving baseline of requirements needs to be managed effectively.
  • The project manager needs to assess and understand the uniqueness of the requirements gathering process for his/her individual project.
common requirement mishaps
Common Requirement Mishaps

Requirements are missing or incomplete

Requirements are defined before the business problem is understood

The requirements effort is short-cuttedto save time or money

Requirements are defined verbally, instead of in writing

Not all stakeholder perspectives are considered

The requirements are not properly validated by stakeholders, developers, and testers

Domain involvement occurs late in the project

There is minimal discussion and review of the requirements

Requirements are not properly allocated to development components

Managers or other stakeholders speak on behalf of other stakeholders

The requirements are tool or technique centric

Nonfunctional requirements are not defined

Developers gold-plate the requirements

Requirements are gathered as a wishlist instead of a set of prioritized requirements that deliver business value


3 Levels of Requirements





Solution Scope Statements



Use Cases


Business Rules


Functional Requirements

Nonfunctional Requirements

Transition Requirements




what are requirement a ttributes
What are Requirement Attributes?
  • Items that are needed to make a requirement complete
  • Dependent on a higher level requirement
  • Examples include:
    • Edits
    • Data elements
    • Usability characteristics
    • Sorting and filtering
example of requirement with its attributes
Example of Requirement with its Attributes
  • Requirement: The system shall provide an online employee directory.
  • Attributes:
    • Shall display employee last name, first name, location, and employee ID number.
    • Shall be sorted and displayed in alphabetical order by last name.
    • Shall be able to search for an employee using the last name.
    • Shall comply with corporate usability and design standards.

Characteristics of Good Requirements

  • Accurate
  • Clear
  • Understandable
  • Unambiguous
  • Testable (Verifiable)
  • Feasible
  • Independent
  • Atomic
  • Necessary
  • Implementation-free
  • Consistent
  • Complete
  • Non-redundant
why are the benefits of good requirements
Why are the Benefits of Good Requirements?

Significantly lower costs through less rework

Higher project success rates

Deliver more value to the business through effective requirements prioritization

Faster time to market through earlier detection of defects

Better alignment between IT and the business

Higher user satisfaction

More efficient testing

Avoid costly workarounds resulting from missed requirements



Requirements Management Community of Practice

12 keys for successful enterprise projects1
12 Keys for Successful Enterprise Projects
  • Build Business Analysis as an Organizational Capability
  • Document the Business Problem before Starting the Project
  • Reach Agreement on Solution Scope before Eliciting Requirements
  • Encourage Collaboration between Stakeholders and Developers
  • Address Strategy, People, Processes, and Technology
  • Use Iterative Practices for Both Requirements and Development
  • Optimize the Business Process as Part of Every Project
  • Don’t Forget the User Experience
  • Prioritize Requirements for Delivering Business Value
  • Implement Requirements-Based Project Management Practices
  • Use Requirements to Validate and Assess the Solution
  • Manage the Enterprise Portfolio to Achieve Business Results
principle 1 build business analysis as an organizational capability
Principle #1Build Business Analysis as an Organizational Capability

Business Analysis Skills are essential:

  • To ensure that projects deliver value that positively impacts the bottom line
  • To ensure stakeholder needs are documented and understood
  • To document clear and concise requirements
  • To ensure that the solution efficiently supports the business process

IT Projects must not only deliver high quality products faster, cheaper, and better, they are also increasingly expected to positively impact the bottom line.

The talents, competencies, and heroics of project managers and technologists alone cannot drive value to the organization.

principle 2 document the business problem before starting the project
Principle #2Document the Business Problem before Starting the Project
  • Many organizations use some kind of “problem statement” which is often nothing more than a list of user complaints. Merely documenting hundreds of complaints or listing hundred of prescribed requirements from some authority does not accurately document what the true problem is.
  • Robin Goldsmith’s problem pyramid is an excellent method to define the business problem. It consists of six steps:
  • Identify the problem, opportunity, or challenge
  • Define current performance measures
  • Define target performance measures
  • Determine the cause of the problem
  • Define what should be done to resolve the problem
  • Define how the problem will be solved
principle 3 reach agreement on solution scope before eliciting requirements
Principle #3 Reach Agreement on Solution Scope before Eliciting Requirements

Solution Scope

The Product or Solution Scope is the characteristics, features, or function of the product or service that is to be built. Solution scope is all about the solution to be implemented: how will it look, how will it function, and other characteristics, etc. A business analyst prepares the product or solution scope.

Project Scope

Project Scope includes all the work needed to be done to create a product or deliver a service or result. Project Scope is all about the project; it defines the work required to create and deploy the product. The project scope statement is prepared by the project manager.

solution scope
Solution Scope

Principle #3 Reach Agreement on Solution Scope before Eliciting Requirements

The solution scope is the basis for determining the project scope.

Typically, the project manager determines the cost and time based on the solution or product scope, or the solution to the problem. Doing it any other way increases the risk of project failure—not on time, over budget, or not completely delivered.

Defining the solution scope is typically the responsibility of the business or requirements analyst.

Solution scope is defined as part of requirements development, which is one phase of a typical project or systems development life cycle.

The clearer you make the distinction between the project itself and the resulting product or solution, especially with upper level management, the more likelihood there is of success in delivering that product or solution within the framework of your project.

what are solution scope statements
What are Solution Scope Statements?

Principle #3 Reach Agreement on Solution Scope before Eliciting Requirements

Scope statements are high level features of the proposed solution

They are used to capture stakeholder needs and organize requirements

They are prioritized so that the features that deliver the most value are worked on first

Scope statements significantly reduce solution scope creep

solution scope1
Solution Scope

Principle #3 Reach Agreement on Solution Scope before Eliciting Requirements

The strategic objective of a scope statement is to define focus!!! Without focus, all requirements elicitation best practices will be done in vain. Scope statements should have the following characteristics:

Be clear and concise

Contain a short description that explains the business purpose

Be prioritized

Support a business objective

Focus on the solution, not the work to be done, which is defined in the project scope statement

principle 4 encourage collaboration between stakeholders and developers
Principle #4Encourage Collaboration between Stakeholders and Developers

Today, for most organizations, the development cycle is a black hole. Requirements are developed, and then stakeholders are left in the dark until the system is ready for deployment.

Often, stakeholders are not even given a copy of the business case, the project vision, or the project objectives.

Except for possibly being able to view the project plan and maybe receiving occasional status reports which are often presented only to the project owner, the stakeholder has no idea where the project is really at.

All parties involved on the project will achieve a better result if they work together and cooperate as partners.

Excellent software products are the result of a well-executed design based on excellent requirements.

High-quality requirements result from effective communication and collaboration between developers and customers–a partnership.


Principle #4Encourage Collaboration between Stakeholders and Developers

Miscommunication is at the root of all problems between technologists, business owners, and end users. Very often, one party is from Mars and the other is from Venus, or even Pluto.

We often go into discussions as if we are all working from a common basis of understanding. But the truth is very different.

Each party brings to the conversation a different perspective, set of expectations, and base of experience and knowledge. This makes for a challenging mix to manage. It also makes it a challenge to keep everyone happy.

stakeholder participation
Stakeholder Participation

Principle #4Encourage Collaboration between Stakeholders and Developers


  • Learn background and purpose of project
  • Document and express needs
  • Document business rules
  • Gather relevant background materials
  • Review and validate requirements
  • Participate in requirement prioritization
  • Review design documents
  • Participate in software and prototype demonstrations
  • Participate in retrospectives and capturing lessons learned
  • Provide additional information for unclear requirements
  • Build test scenarios and test cases for user acceptance testing
  • Perform user acceptance tests
  • Approve changes to requirement specifications
  • Define transition requirements
  • Help prepare the organization for change
principle 5 address strategy people processes and technology
Principle #5Address Strategy, People, Processes, and Technology

Many enterprise projects focus solely on software and ignore vital people and process problems.

Enterprises that take this approach and apply technology to solve complex challenges often find out that the technology multiplies the impact and visibility of the initial problem.

The building blocks of a potential enterprise success are in the people, processes, and technology that make up the organization.

principle 6 use iterative and incremental practices for both requirements and development
Principle #6Use Iterative and Incremental Practices for Both Requirements and Development

Iterative development is an approach to building software in which the overall lifecycle is composed of several iterations in sequence. Each iteration is a self-contained mini-project composed of activities, such as requirements, design, programming, and test. The goal for the end of an iteration is a release consisting of a stable, integrated, and tested partially complete system.

Most iteration releases are internal, a baseline primarily for the benefit of the development team—they are not released externally. The final iteration release is the complete product, released to the market or customer.

Agile development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuing to be maximized throughout the development process.

As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process. 

Requirements development should also be iterative and incremental.

waterfall vs agile projects1
Waterfall vs. Agile Projects

Principle #6Use Iterative and Incremental Practices for Both Requirements and Development

Source: Standish Group Chaos Report 2011

principle 7 optimize the business process as part of every project
Principle #7Optimize the Business Process as Part of Every Project
  • The vast majority of application software is used to automate business processes. Enterprises do not purchase ERP or CRM systems just because they are fun.
  • Requirements are often defined to automate an “as is” process versus an optimized “to be” process.
  • Team members, working with stakeholders, should challenge the assumptions upon which the current process is built, as many of the underlying assumptions may have changed since the process was designed.
  • For companies to achieve business objectives, such as the ones below, it will be necessary to optimize the business process. Providing automation is only part of optimizing the process:
    • To better serve customers
    • To improve the ability to anticipate, manage, and respond to changes in the marketplace
    • To increase revenue and maximize business opportunities
    • To reduce inefficiencies and errors
    • To eliminate waste and reduce costs
principle 8 don t forget the user experience
Principle #8Don’t Forget the User Experience
  • User-centered design, often referred to as UCD, is a design philosophy in which extensive attention is focused on considering the needs, wants, and limitations of end users at each stage of the design process.  
  • User-centered design can be characterized as a multi-stage problem solving process that not only requires designers to analyze and foresee how users are likely to use an interface, but also tests the validity of their assumptions with regards to user behavior in real world tests with actual users.
  • User participation enhances system quality through a more accurate and complete identification of user needs and expertise about the organization.
  • The major benefits of User Centered Design are:
    • Increased customer/user satisfaction
    • Reduced cost of ownership and support
    • Increased efficiency
    • Increased user acceptance
principle 9 prioritize requirements for delivering business value
Principle #9Prioritize Requirements for Delivering Business Value

One characteristic of excellent requirements is that they are explicitly prioritized.

When customer expectations are high, timelines are short, and resources are limited, you want to make sure the product contains the most essential functions.

Establishing each chunk of a functionality’s relative importance lets you sequence construction to provide the greatest product value at the lowest cost.

Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements.

principle 10 implement requirements based project management practices
Principle #10Implement Requirements-Based Project Management Practices
  • For all significant project failures, requirements were wholly or partly missing.
  • Whenever a project team jumps directly into implementation (in the mistaken belief it saves time and effort because members “know” what is need) it invariably leads to a delayed or cancelled result.
  • “Build-first-ask-questions-later” projects significantly overrun their budgets and deliver less than optimum systems.
  • Requirements can be used by project and program managers, team leaders, and business analysts to deliver value on enterprise projects. Requirements can be used for:
    • Used as input to project planning and decision-making
    • Determine whether to invest in a project
    • Deliver more appropriate products with a quick cycle time
    • Measure and estimate the development effort
    • Drive user acceptance and system testing
    • Manage stakeholder involvement and expectations
    • Establish priorities
    • Communicate across business and technological boundaries
principle 11 use requirements to validate and assess the solution
Principle #11Use Requirements to Validate and Assess the Solution
  • A project can be on time, within budget, and deliver everything that was asked for and still not solve the business problem. In fact, the product may not even be used by the business in the end.
  • It is the role of the business analyst to work with the stakeholders to validate and assess the solution to ensure it meets the business needs.
  • During design and development, the business analyst plays the role of customer representative on the solution team. The analyst works with the solution team to make sure that the results of the development effort still solve the business problem.
    • During design, the business analyst assists the systems analyst to make trade-off decisions among various technical solutions, bringing any impacts to the solution document back to the business for review.
    • During the build and early testing phases, the business analyst makes sure the solution document still matches the solution. During late testing stages—system and acceptance—the business analyst prepares test cases for users and participates fully in the acceptance test stage.
    • After the product is delivered, the business analyst makes sure the solution is successfully transitioned into the business environment.
principle 12 manage the enterprise portfolio to achieve business results
Principle #12Manage the Enterprise Portfolio to Achieve Business Results

Year after year, enterprises spend a considerable percentage of their budget on projects. Most of these projects have significant IT components; however, the results for many of the projects are less than desirable.

CIOs are under constant pressure to reduce IT costs and add value to the bottom line through IT products and services and are constantly searching for new ideas and approaches to improve IT performance.

Portfolio management is used to manage the demand for IT projects—it provides the executive team with a system-wide view of projects across the enterprise, which makes it possible to make informed decisions about where investments should be focused.

Strategic goals are translated into tactical programs with supporting projects through the portfolio management process.

By aligning investments with projects that deliver outcomes to achieve strategic goals, portfolio management leads directly to improvements to the bottom line.

additional materials giveaways
Additional Materials - Giveaways

Leave your business card and I will send to you this week.

  • Requirements Excellence Framework
    • Business Analysis Perspective
    • Stakeholder Perspective
  • CIO Whitepaper – 12 Principles for Successful Enterprise Projects
  • Checklist for Aligning IT with the Business
  • Business Benefits by Balanced Score Card
  • Enterprise Project Model
  • Controlling Requirement Scope Creep
  • Characteristics of Excellent Requirements
contact information
Contact Information

John ParkerPresident and CEOEnfocus Solutions Inc.



210-259-1140 Cell

210-957-8765 Office