Project Management

Finding the Requirements Tree

Michael R. Wood is a Business Process Improvement & IT Strategist Independent Consultant. He is creator of the business process-improvement methodology called HELIX and founder of The Natural Intelligence Group, a strategy, process improvement and technology consulting company. He is also a CPA, has served as an Adjunct Professor in Pepperdine's Management MBA program, an Associate Professor at California Lutheran University, and on the boards of numerous professional organizations. Mr. Wood is a sought after presenter of HELIX workshops and seminars in both the U.S. and Europe.


Trending Articles

The Value of Building Diverse Skills

by Mark Mullaly, Ph.D., PMP

To be a capable generalist requires reframing our own self-perception—and how we communicate our abilities and shape the perception of others. The value of the generalist is not about having wells of expertise in a broad array of domains. Success as a generalist instead requires three very specific talents...

Topic Teasers Vol. 134: Unexpected Changes Lead to Alphabet Madness

by Barbee Davis, MA, PHR, PMP, PMI-ACP, PMI-PBA

Question: Due to the pandemic, my original project estimates aren't accurate. It’s not enough that we are over budget and behind schedule, I now need a way to show management how I predict this work will change financially and in terms of time. I learned some alphabet formulas to pass the PMP® exam, but that was years ago. Is there a simple way to calculate this stuff?

PM Development Strategies

by Andy Jordan

With project management being a more diverse discipline than ever, what’s the right strategy for developing people into, through and beyond project management?

In 1981, ComputerWorld published my in-depth article called “System Design--A Model Based Approach”. In that article, I suggested that there was a missing phase to the traditional System Development Life Cycle (SDLC): requirements discovery. Today, over 30 years later as I talk with IT executives and business application developers, the No. 1 issue they seem to struggle with most is how to divine requirements from users. The lament is always the same
 “How can users provide requirements when they don’t know what they want?”
Perhaps it’s a matter of approach and tools that exasperate them in their elusive quest to find the requirements tree and to harvest its bounty.
The good news is that the industry is plentiful with requirements discovery tools. The bad news is that many are steeped in complex syntax, unwieldy models, strange jargon and obtuse tools that make the discovery process difficult, frustrating and painful.
The secret to rapidly capturing requirements lays in understanding the business processes that the application is suppose to leverage and support. It requires a fast and easy-to-understand set of tools and techniques that can be used with cross-functional workgroups to identify process defects, process improvement opportunities, map out existing workflows and conceptualize alternative workflows against which improvement concepts can be validated. The goal of the discovery process is to create the models and framework needed to:
  • Identify Value Gaps -- Misalignments between the business objectives and the outcomes each business process produces down to the procedure level
  • Identify & Model Workflows and Phases -- Maps of every core workflow both existing and proposed
  • Correlate Value Gap to Workflow Intersections -- Map value gaps to existing workflows and value improvement opportunities to proposed workflows validating solution alignment
  • Identify & Define IPOs -- Every input, process and output (IPOs) needed to support the improved business process
  • Identify & Define Object Transformations -- Every explicit and implicit transformation of data objects for each IPO (down to the logical data table level)
  • Identify & Define Action Triggers -- Every trigger that sparks people and systems to take action
  • Identify & Define Process Failures -- Potential process failures and remedies (prevention, advance warning and rapid detection & resolution)
  • Identify & Model Natural Data Model -- The underlying “Natural” data model needed to support and reflect the nature of the business (independent of current policies and practices).
In essence, the Requirements Discovery Phase yields a macro level specification that drives the rest of the development lifecycle. By modeling the business first the underlying business application requirements are revealed.
Armed with this knowledge, the application development team can quickly develop the following:
  • Business Case with Change Concepts and ROI for each deliverable
  • Statement of Work documents
  • Phasing & Release Strategies
  • Package Evaluation Requirements for assessing buy vs. build decisions
  • Requirements and Design specifications that can be mapped, tested and validated against the macro level specifications developed during the discovery process.
  • When done correctly the discovery process also yields the following benefits:
  • Identification of all critical stakeholders
  • Stakeholder and user buy-in to the improvements defined\user ownership of the solution
  • Projects that are alignment with business goals and strategies
  • More complete and resilient scope
  • Criteria for the development of business performance scorecards
  • Measurable criteria for determining that can be achieved by the initiative
There are a plethora of workshops, books and even university level courses dedicated to requirements discovery. Well-known frameworks and methods like Six Sigma, The Helix Methodology, Volere, RUP (Rationale Unified Process) and RapidTrak have been around for years, some dating back to the late 1970s. Yet it has only been in the last few years, since the arrival of Business Process Improvement and Management, that discovery has become recognized as the single most critical factor in delivering aligned IT value in the workplace.
Even SOA exalts the need to map out core business processes as a starting point in any SOA initiative. To the informed reader, there can be little doubt that the Requirements Tree of Knowledge has its roots established in modeling the cross-functional business processes in context to business strategies and goals of the enterprise. It is in the gap between how things work today and how they need to work to achieve core business objectives that the fruit of the requirements tree can be harvested.
However, with an abundance of methods ranging from the pragmatic to the theoretical comes confusion wrapped in a murky mud of hype and hyperbole. Which methods work best? Which methods are field tested and proven? Which modeling tools work best? Which techniques yield the fastest, quickest and best results? The questions become endless, and for good reason. Consider the following list of diagramming techniques that all purport to do map workflow processes:
  • Data Flow Diagrams
  • Swim Lane Charts
  • State Diagrams
  • Workflow Diagrams
  • Traditional Flow Charts
  • Cross Functional Flow Charts
  • Value Stream Maps
  • ITIL Diagrams
  • TQM Diagrams
  • UML Model Diagrams
…and the list goes on.
Is there any wonder why application developers are confused, frustrated and capitulate to old and outdated approaches? Add the need to be expert in facilitation techniques, data modeling, failure analysis, SIPOC, DMAIC, DMADV, GAP Analysis, etc. and in terms like artifacts, actors, closed-loop systems and triggers, and the mud gets thick and deep fast.
As in the evolution of any body of knowledge, each inventor of a method creates their own language, models and syntax to describe it. Over time a common language emerges, standards are set and universality is achieved. But until that time we only have principles, track records and consistency of outcomes achieved as evaluation tools. We therefore must become students of the subject in order to insure that what we adopt as our company’s standard is appropriate.
The eight key outcomes presented earlier can be used to assist you in evaluating requirements discovery methods and tools. A quality tool set (models, forms, techniques, etc.) should deliver the eight key outcomes needed for a complete requirements discovery solution. If your approach falls short, then it should be either augmented or replaced. Let’s take a closer look at each of these outcomes.
Identify Value Gaps
In context to discovering information system requirements, a
GAP Analysis identifies areas within a current business process where improvements can be made. This is done by contrasting the current situation (or state) of components of a process to more preferred “future” state (or goal).
Wikipedia defines a GAP Analysis as:
“A business assessment tool enabling a company to compare its actual performance with its potential performance. This provides the company with insight to areas which have room for improvement. The process involves determining, documenting and approving the variance between business requirements and current capabilities. Gap analysis naturally flows from benchmarking or other assessments.”
The secrets to a good GAP Analysis are as follows:
  • Create a context for the GAP Analysis by framing it within the confines of achieving specific, operationally measurable business goals and objectives.
  • Collect the initial GAP data via the facilitating of cross-functional focus groups (knowledgeable representatives from each organization involved in performing the business process in question).
  • Quantify each current and future state in terms of frequency, defects, cost / revenue benefits, competitive advantage, customer service level improvement, etc.
  • Evaluate each future state’s feasibility in terms of controllable vs. uncontrollable variables, imposed organizational constraints and windows of opportunity.
When a GAP Analysis is collected interactively in cross-functional work sessions, the outcome is a consensus on what changes need to be made to current business processes and practices in order to move the enterprise closer to achieving its business goals and objectives.
In Part 2 of this two-part series, we will look at the rest of the key outcomes.

Want more content like this?

Sign up below to access other content on

Sign Up

Already Signed up? Login here.

Related Content

Reviews (3)

Login/join to subscribe

"There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened."

- Douglas Adams