Digital Mosaic Home Page The right mix of specialists.
Home About Us Clients Research Partners Join Our Team Contact Us
Aligning IT to business, sizing projects, business case building
-Determine Business Scope
-Optimize SME Participation

Accelerating the quality and speed of needs assessments, requirements elicitation and requirements documentation
-Scope & Feasibility Assessment
-Business Requirements Definition
-Audit requirements/Triage projects

Tools, templates and specialist practices for selecting and managing vendors
-Getting Solutions that Fit
-Issue and Evaluate RFPs

Business case building, research, market planning
-Get a Mosaic Analyst
-Research & Business Case Assist

Pragmatic training for improving business analyst productivity
-Course 1: Business Requirements
-Course 2: Lead & Facilitate
-All Our Courses

Take the next step . . .


Challenge: How do you know when you have all the business requirements?

If your organization does not have an answer for this question, internal projects could have excessive risk that will significantly overrun time and budget.  External projects will run the risk of ending in failure. Of course you can manage this risk by sheer force of will and the skill of a key person but eventually playing the odds by not addressing the process will lead to an expensive failure

The most common reason for a catastrophic failure ending in litigation is a failure to adequately define requirements and use this definition as an integrated part of project delivery management.

In today’s world of increased financial scrutiny of institutions, can audit committees reasonably approve the spending on a $10 million initiative without first conducting its own tests to determine if corporate risks have been adequately managed? Can you think of at least 3 times when a project seemed to be in a ‘continuous discovery’ of requirements mode or were forced through to result in the delivery of a largely dysfunctional system?

The management of project and corporate risk must start with how your organization:

  • Initiates a project in a way that scope, roles in requirements participation and the overwhelming layers of information which must be developed can be streamlined and systematically managed.
  • Ensures appropriate and sufficient participation from subject experts.
  • Ultimately tests if scope has been properly assessed before releasing funds if spending is significant.

Ask yourself:

Before approving spending on a enterprise IT project, would corporate risk be better managed if the board was able to assess the probability of a large project overrun based on the project documentation provided by management?

Before initiating a project, would it be useful for the SVP of a Line of Business to know precisely how much time will be needed from each member of their team to properly develop business requirements?

At the early stage of defining a project, do your project managers have a role that links your project management process to your process for building business requirements?


"Your team brought the project together and gave us excellent value ... You helped us get objective data to management so that our team could focus on making the key decisions... [We got] traction on an initiative that could possibly drop hundreds of thousands of dollars to our bottom line."
Tech Data Canada

Contact Us

Contact us today

White Paper

GETTING BUSINESS REQUIREMENTS RIGHT: Fixing the highest-leverage stages in the System Development Life Cycle

White Paper

It is 80 times more expensive to miss a requirement than to: GET REQUIREMENTS RIGHT